Receipts and exceptions

An operation receipt records an action, stable operation key, expected revision, result state and occurrence time against its parent instruction. It can also carry an external reference, effect references and failure reason. That record is the starting point when an acknowledgment is lost or an outcome appears inconsistent. It lets the team distinguish a known completed effect from one that still needs investigation.

Every guarded attempt persists a receipt. An equivalent retry under the same key returns the original result; conflicting input is rejected. Scheduled reconciliation, or an authorized reviewer selecting Reconcile, reads pending and failed receipts and then checks their linked effects. A receipt becomes completed only when identity, scope, quantity and revision match. A discrepancy moves its result state to needs review with the reason recorded.

• Stable identity. The operation key keeps repeated attempts attached to the same requested effect and expected revision.
• Read-first reconciliation. The team checks receipts and linked effects before considering another provider or domain action.
• Exception ownership. A failed or needs-review receipt has its reason and parent instruction available to the person resolving it.

Decide how each action constructs an operation key and which source system can confirm its effect. Define the evidence required for a completed receipt, including external references when a provider is involved. Set who may invoke reconciliation and who handles discrepancies that require provider or finance follow-up. The Operations Overview should give this team a shared place to find pending and failed work.

Plan the correction path before the first exception. Unexecuted draft scope can be cancelled after checking related evidence and receipts. Accepted or executed scope needs a reviewer-approved compensating action against the original source identity. Preserve the execution evidence and decision history so the reason for correction remains visible.

A provider submission times out after the request leaves the system. The Operations Analyst opens the receipt, confirms its operation key and expected revision, and checks for a provider reference or linked execution event. If the effect exists and matches, reconciliation completes the receipt. If the provider has an inconsistent event, the receipt remains in review with a failure reason. The team does not submit the same request again merely because the first screen timed out.

Rehearse a second call with the same key and inputs. It should return the first result. Change the amount while keeping the key; the conflicting call should be rejected. Then rehearse an executed instruction that needs reversal. The original evidence remains, and the compensating action requires independent review. These cases test both safe retry and auditability.

• Receipts needing review — Guarded operations with discrepancies and parent instructions to investigate.
• Failed operation receipts — Failed actions with occurrence time and reason.
• Instructions by status — The underlying scope and owner for each exception.

Reconcile an uncertain outcome and review the original instruction.