Run History

Publication, execution and correction operations have durable run records. A run keeps its operation key, frozen source revision, input hash, timing, result reference and status. Numbered operation steps preserve input and output references, external receipt details and any receipt evidence. Retry attempts have their own attempt number, timing and failure reason.

When an operation fails or needs reconciliation, the operations lead can inspect the run before deciding whether to retry or investigate a source discrepancy. The same key connects related attempts so a second invocation does not look like an unrelated procedure. State history separately records the actor, original and resulting status, revision and reason. The lead can therefore check both what the operation tried to do and what status change was actually recorded.

• Durable run. A run keeps the operation key, source revision, input hash, timing, result and failure reason.
• Detailed trace. Numbered publication steps retain input, output and receipt references; correction attempts keep retry timing and status.
• State change. State history records the actor, source revision, prior status, new status and reason.

The Operations Lead and Admin should agree who investigates a Failed or reconciliation required run and who may retry the original operation. Use the same operation key when checking a repeated request and compare its source revision and input hash with the recorded run. Decide where external receipt evidence will be retained so its reference remains useful after a source system changes. A retry attempt and a durable run answer different questions; train the team to inspect the relevant record for the action being checked. Preserve the original failure reason when the team later completes a correction.

Publish one reviewed revision, then inspect the run, numbered publication step and status transition. Ask the Operations Lead to identify the frozen revision and resulting status from the records. Next, use an executed revision that requires correction. Inspect its earlier result, compensating run and attempt, and the transition back to Reviewed. If an attempt is Unknown or the run needs reconciliation, pause before repeating the action. Compare the operation key and source revision with the original request, then record what the team learned in the appropriate failure reason or state history.

• Run exceptions — Find failed runs and those requiring reconciliation.
• Retry attempts — Inspect failed or unknown attempts by operation key.

See the first handoff and the next decision.