Operation trace and correction

Each guarded queue operation has a durable run with an operation key, source revision, start and completion dates, status and result reference. Numbered steps record the action, its input and output references, dates, external receipt identity and evidence. Execution attempts capture tries against a queue, including provider reference and failure reason. Together these records let an Operations Analyst examine what actually happened when an action was interrupted or a provider response was unclear.

A run reaches Succeeded only after the required effects are verified. Failed and reconciliation required runs need inspection. A step marked Unknown and an attempt marked Failed do not support declaring success. The team can use the trace to determine whether the external effect happened and whether a follow-up or correction is needed.

Operations Analyst inspects the trace; Queue Manager initiates a documented correction.

• Stable operation key. Associate attempts and state history with the selected queue operation.
• Step-level evidence. Keep numbered actions and external receipts with the run that produced them.
• Successor revision. Retain earlier steps when a correction creates new work and a new review decision.

Choose a consistent operation key from the originating request and decide who investigates a failed or ambiguous attempt. Agree how the team checks the external receipt before replaying any action. Define the information required for a correction request: which revision changed, why it changed, what compensating task will put the result right and which reviewer will decide on the successor revision.

Run a rehearsal with a confirmed effect, a failed effect and an effect whose response is unknown. The analyst should find the correct run, its numbered steps and the matching attempt. They should be able to state whether the queue result is verified or still requires reconciliation.

An assigned queue has an accepted task, but a provider timeout leaves the execution attempt uncertain. The analyst opens Runs needing attention, reads the step’s receipt identity and checks the external source. If the effect did occur, the required records can be verified before the run is marked successful. If it did not occur, the exception remains visible with its reason while the team decides the next action.

A later documented correction changes the accepted result. The Queue Manager starts the correction workflow. It preserves the prior revision and completed steps, creates a successor revision with a compensating task and sends that revision through validation and independent approval. The refreshed output comes from the new verified outcome. State history records the transition so the earlier result can still be explained.

• Runs needing attention — Failed or reconciliation-required runs with source revision and reason.
• Unfinished operation steps — Steps whose result still needs confirmation.
• Failed execution attempts — Provider attempts that need analysis.

Operation correction follows the successor revision. Task completion and receipts shows where the trace begins.