Execution and provenance

Operation runs record the program, operation key, source revision, input hash and persisted result reference. Their states include queued, running, succeeded, failed and reconciliation required. Each run may have ordered steps with input and output references, external receipt details and receipt evidence. Execution attempts separately record the attempt number, timing, provider reference and failure reason for an approved action.

This trace matters when an external response is delayed or uncertain. A failed local attempt does not by itself say whether a provider accepted an action. The operation key and receipt fields help the team inspect the original action before deciding whether to retry or follow up. Status history records a program transition with its actor, reason, revision and operation key, so later review can connect the working state to the action that caused it.

• Run identity. Keep an operation key and program revision with each run.
• Step evidence. Record the external receipt and its evidence on the ordered step.
• State trail. Retain each program transition with actor and reason.

Operators inspect uncertain results. Reviewers use the trace when a decision depends on what happened to a prior revision. Analysts can read the recorded outcomes and exceptions without changing the execution history.

Agree which external source owns the final acknowledgement for each action. Choose how its provider reference, receipt identifier and evidence are captured. Define who investigates a run needing reconciliation and when a follow-up action is opened. Use the same operation key when checking a delayed result so the team can distinguish an existing effect from a new attempt.

Prepare cases for a successful action, a failed action and an unknown response. The team should find the correct source revision, input reference, output reference and receipt evidence for each. Decide what result reference is sufficient to close a reconciliation. A status change on the program should have an actor and reason that make sense with the operation trace.

A reviewed program has a delivery action with a recorded operation key. Its run reaches a step that sends the request, but the provider response is uncertain. The attempt retains the timing and provider reference while the run is marked for reconciliation. The operator checks the external receipt before initiating another action. If the result exists, its reference is retained on the run and the program’s later status history explains the transition. If it did not occur, the operator creates a follow-up action and records the reason for the failed attempt.

A later correction does not erase the earlier run or decision. The reviewer can still see what revision was acted on and which receipt supported the outcome. That record is especially important when a published value is superseded and the team must explain both the earlier effect and the subsequent correction.

• Runs needing reconciliation — Uncertain runs with their operation key and failure context.
• Failed execution attempts — Attempts whose result needs investigation.
• Program status board — The current program state alongside the revision being traced.

Reconcile execution follows uncertain results. Review the revision shows where the trace informs a new decision.