Run Trace

Every validation, synchronization and correction workflow writes an operation run. Its operation key, source revision, time, status, input hash, result reference and failure reason give the operator a stable account of that invocation. Numbered steps record action names, input and output references, status and timing. A step can also carry an external receipt and its evidence attachment.

The trace supports a practical question: which action produced the outcome being reviewed? A provider reference on a delivery attempt helps locate the external request. The corresponding run and step show which revision supplied the input and what acknowledgement came back. Keep the definition, run and attempt together during an incident review.

• Run identity. The operation key and source revision distinguish one invocation from an updated pipeline definition.
• Ordered steps. Step numbers reveal where validation, delivery or compensation reached before a failure.
• External proof. Output reference and receipt evidence connect the internal trace to the destination response.

A failed run and a run requiring reconciliation call for different investigation. The former records an unsuccessful operation. The latter signals that the observed outcome needs comparison with destination evidence. Neither should be treated as clean completion just because a later definition has moved on.

Decide how operation keys are generated and carried into provider requests. Confirm which destination response becomes the receipt, where its evidence is retained and how long the team needs it for review. Agree how the operator handles a step with Unknown status: check the destination before reissuing a request, then document the result. The handoff to remediation should include the source revision and the failed or uncertain step.

The owner and reviewer should understand that validation also creates a run. That trace is the evidence behind a Validated revision and the pending decision. A correction creates its own run and compensating step while preserving the executed predecessor.

Suppose a sync attempt times out after sending a request. The operator opens Run Exceptions and locates the operation key and source revision. They inspect the numbered steps, then compare the last output reference and any receipt with the provider reference on the attempt. If the destination accepted the request, another send could duplicate work. If the response remains uncertain, the operator keeps the case in reconciliation and assigns a follow-up.

Once the destination outcome is established, the owner decides whether the existing revision can be reconciled or whether correction is required. A successor revision receives its own trace. The audit reader can later see both operations and the reason recorded in state history, rather than a single updated status with the earlier question erased.

• Run Exceptions — Failed or reconciliation-required operations by revision and key.
• Operation Schedule — Queued and running work with start and completion times.
• Delivery Attempts — Provider-facing attempts connected to the definition.

See synchronization, correction and the data model for the run-to-step relationship.