Reconciliation actions, transitions and publication failures

What a reconciliation receipt's action label proves, how an alert's identity is read, and what a failed publication retains. The receipts themselves are on Service reconciliation receipts.

Planned action labels

planned_beacon_repair, planned_adopt, planned_ensure and planned_host_probe name the selected evidence path. They are not execution receipts: report/emergency-paused decisions do not run the repair, and a failed attempt can retain its planned label when no completed action was acknowledged. Read classification, detail and acknowledged changed together. The live probe can refine an observed-endpoint or host-probe path into adoption or ensure; the label alone does not prove which host operation ran or its final state.

A host-probe repair confirms a loaded unit that runs its declared program, and ensures it instead when the beacon reads it failed: a unit its supervisor restarts without end runs its declared program between restarts, which proves who owns it and nothing about its health. ensure renders the declared definition and reloads one that differs from it (an environment the unit's catalog entry now requires, for instance); a matching definition is left loaded. The detail names which of the reasons ensured it: the host reported the unit absent, the beacon reads it failing, its declared binary was replaced since its process started, or its process could not be matched to its declared program.

Transition identity

An alert's identity is its exact host, service, unit, classification and detail fields, not a delimiter-joined name. Every prior row is considered; different units or field boundaries do not collapse into one remembered row. Identical current rows cause at most one alert attempt for a selected run, and facts already present in its pinned prior report are suppressed. Report rows remain complete in the CLI, API and Desktop. This is transition suppression, not confirmation of notification delivery or an exactly-once delivery guarantee.

Reading a publication failure

Failure logs retain:

• The actual parse, serialization, immutable-create or conditional latest operation, its object and original cause.
• expected_latest_version, the prior token when one was observed; absence means the prior read found no report, not that latest is still absent.
• acknowledged_run, the immutable receipt whose creation succeeded before a later failure. An absent acknowledgement is not proof the object is absent.
• The report identity, mode, schema, complete tally and every retained row's host, service, unit, action, classification, changed flag, beacon/endpoint evidence and detail.

The original storage error remains a failure, including a conditional-write conflict. A failed request does not establish rollback or absence of changes. A failed write alone does not prove an authorization problem: inspect the actual cause before changing namespace policies. stado config show reports the configured namespace and prefix policies, not whether its consumer succeeded.

Latest can remain older after failed publication or deliberately remain selected when a run is superseded. The CLI, report API and Desktop still show that readable receipt and its own timestamp; it is not proof this attempted run was recorded. The run log and any acknowledged immutable receipt retain the attempted run's facts without manufacturing a replacement latest report.

Return to Missing service reconciliation for repair, ownership, lease-finalization and failure-classification behavior.