# Recovery decision record

Record an ambiguous business effect before choosing another attempt. This completed hypothetical example uses simulated records and state reloading, not a live ledger or payment service. It provides no production durability, concurrent-safety, or exactly-once-delivery guarantee.

This download is a paper recovery record, not the local simulator. Follow the existing-effect branch first: the correction was saved, its response was lost, and recovery must find that same correction without creating another one.

## Completed hypothetical intent

| Field                      | Record                                                                                                                          |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Tenant                     | tenant-a                                                                                                                        |
| Target invoice             | inv-100                                                                                                                         |
| Stable business operation  | resolve-inv-100-demo                                                                                                            |
| Action                     | Commit the authorized invoice resolution                                                                                        |
| Operation identity inputs  | Tenant, business-operation identity, invoice, and action; the same intended operation retains the same identity across attempts |
| Simulated caller           | reviewer-17, within tenant-a                                                                                                    |
| Simulated required scope   | `invoice-resolution:commit`                                                                                                     |
| Checked policy / approval  | policy-18 / approval-42                                                                                                         |
| Local intent before effect | Pending; identity and authority revisions recorded                                                                              |
| Excluded claim             | These labels do not authenticate or authorize anyone in a real system                                                           |

The operation record identifies the intended invoice correction. An attempt record describes a particular try at sending it. Keep later attempts attached to that same intended correction, including after a restart. A stored intent shows what was intended, not proof that the target performed the action. Do not invent a fresh operation key to get around an ambiguous prior result.

## Completed simulated lost-receipt timeline

| Sequence                  | Recorded state and limit                                                                                                    |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| 1. Record intent          | Stable operation and checked authority retained; local operation pending; zero simulated effects                            |
| 2. Apply simulated effect | One committed simulated effect exists for the same operation                                                                |
| 3. Lose receipt           | Deliberate interruption occurs before completion is recorded; local operation remains pending                               |
| 4. Reload recorded state  | Reconstruct the local simulation over its saved records inside the same program; no killed-process or external-storage test |
| 5. Read back              | Match the simulated effect's operation, tenant, and invoice; recover the existing result                                    |
| 6. Reconcile              | Completed with `reconciled_existing_effect`; `effect_created: false`; one stored simulated effect remains                   |

This walkthrough establishes the declared local simulation behavior. The simulated ledger is not an external source of truth. Temporary JSON state lacks production transactional commits, replication, corruption recovery, and competing-worker protection.

## Completed recovery decision table

| Evidence / condition                                        | Disposition                                                                                                                        |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| Matching existing effect with sufficient permitted readback | Reconcile and retain its evidence; create no new effect                                                                            |
| No stored simulated effect; approval or policy changed      | Escalate with `approval_or_policy_changed_before_effect`; no new effect                                                            |
| No stored simulated effect; old authority still matches     | Escalate with `no_effect_readback_requires_operator_decision`; still no automatic resubmission                                     |
| Readback unavailable or insufficient                        | Keep reconciliation pending and escalate; missing evidence is not evidence of absence                                              |
| Wrong tenant or missing required scope                      | Deny; recovery must not cross the authority boundary                                                                               |
| No local operation record                                   | Retain the no-record disposition and investigate with the recovery owner; absence of local state does not authorize another effect |

An empty target lookup may reflect delay, an incorrect identifier, or incomplete evidence. Ask how the target confirms a final result and how long a saved change may take to appear in the lookup. Do not conclude that no effect occurred until the evidence supports that conclusion. If it remains unknown, hold it.

## Completed next-decision record

- Existing-effect branch: reconcile the already recorded effect with its permitted readback. This is not approval for another change.
- Changed-policy branch: hold and request a scoped authority decision; policy-18 cannot authorize a new effect when policy-19 applies.
- Unchanged-policy/no-effect branch: the teaching recovery path still escalates for an operator decision; it does not auto-submit.
- Unavailable-readback branch: keep the stable operation pending with the service recovery owner and a next review point. No blind retry is allowed.
- New-effect boundary: any later effect must pass current identity, tenant, scope, applicable policy, and required fresh approval through the trusted target/service path. A copied prompt or old approval receipt cannot supply that authority.
- Target work still needed: duplicate contract, consistency/terminal-state evidence, identity and authorization, durable storage, concurrency, cancellation, retention, support, and exercised recovery objectives.

## Failure cases to exercise at the real target

| Case                                                           | Required observation                                                                                  |
| -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Duplicate delivery after known completion                      | Existing permitted result retrieved; effect count and final state verified; no duplicate effect       |
| Interruption before effect                                     | No effect concluded only with sufficient target evidence; authority rechecked before any later effect |
| Effect succeeds but receipt is lost                            | Reconciliation identifies the existing effect using the stable operation and sufficient readback      |
| Policy or approval changes while pending                       | No new effect uses stale authority; disposition and owner remain visible                              |
| Readback fails, is delayed, or returns insufficient evidence   | Operation remains unknown/pending; no default resubmission                                            |
| Wrong tenant, scope, deprovisioned caller, or expired approval | Access/action boundary denies the applicable request                                                  |
| Concurrent attempts or changed payload under one key           | Target duplicate, ordering, and payload contracts hold under exercised contention                     |
| Corrupted/missing state, restore, or cancelled work            | Recovery owner can reconstruct the declared state without resurrecting unauthorized or cancelled work |

These are proposed target obligations, not tests completed by this worksheet.

## Your working copy

Begin with the intended change, the last attempted send, and the result the target can currently confirm. Leave the operation pending if those records cannot establish what happened. Complete the authority questions before considering any new write.

### Start with these questions

1. What exact change was intended, for which customer and record?
2. Which original operation ID connects all attempts at that same change?
3. What does the receiving system currently confirm, and what remains unknown?
4. Who owns the unresolved case, and which current permissions would any new change require?

### Record intent and inspect the result

- Which workflow, target record, customer/tenant, and exact action are involved?
- What is the stable business-operation ID? Which attempt or run IDs belong to it?
- Which approved evidence store, access rules, source references and revisions, retention, and sensitive-data limits apply?
- Where is the original intent saved, which authority was checked at submission, and what was the last verified state?
- Which tenant and action does the target's duplicate key cover, how long is it retained, and what happens if the same key arrives with different contents? What test supports those answers?
- Where was the attempt interrupted, which response arrived or was lost, and what remains unknown?

| Readback check                            | Evidence and revision | Match / mismatch / unknown | Owner and next step |
| ----------------------------------------- | --------------------- | -------------------------- | ------------------- |
| Current permission to inspect this result |                       |                            |                     |
| Stable operation and target object        |                       |                            |                     |
| Tenant and action                         |                       |                            |                     |
| Relevant final state and terminal status  |                       |                            |                     |
| Consistency/visibility limitations        |                       |                            |                     |

- Should you reconcile an existing change, hold an unknown result, deny the request, escalate a confirmed no-effect result, or seek current authority?
- Why does an empty or missing lookup result establish absence, or why is it insufficient?
- Which current identity, customer/tenant, action scope, policy, and approval must be checked before any later change?
- Who may decide what happens next, what has the operator decided, and which trusted service check is still required?
- Have all attempts kept the original operation ID, without using a fresh key to hide unresolved history?
- Who owns the pending case and covers their absence, when will they review it again, and how do expiry, cancellation, or an intake stop affect it?
- Does the handoff retain the intent, attempts, source and authority revisions, last verified state, and disputed result?
- Which target failure tests ran? What effect count and final state were observed, what storage and coordination were exercised, and what remains untested?
- What safe fallback remains, and when must the workflow stop or be constrained?

Keep reconciliation of a past effect separate from permission for a new effect. A completed record supplies no automatic retry or release authority.