Answers and explanations · Recover without duplicating work

Module 6 Reference solution

A suitable key is R101|1|queue_review. E001 records that key and a destination reference. E006 compares the same material input, finds RECORDED and becomes DUPLICATE_SKIPPED. A changed payload under R101 revision 1 instead becomes identity_conflict. R104 revision 2 has its own key and must not be suppressed by R104 revision 1.

F-A: temporary read failure before side effects may be retried under the bounded policy. First retry succeeds on the supplied card, so stop retrying immediately. The hypothetical second retry is only used if the first retry fails. If the initial attempt plus both retries fail, hold and notify the owner with a non-sensitive reference. Do not create a draft from an unavailable policy.

F-B: STARTED → NEEDS_RECONCILIATION after lost acknowledgment → inspect destination by operation key → find Q109 and verify content/revision → RECORDED with Q109. A later replay references Q109. If the destination cannot be checked, leave the operation on hold; do not invent a failed write.

F-C: access denied is a configuration/permission problem, not a useful automatic retry. Stop and refer to the workflow owner. Do not weaken controls, add credentials or reconnect an account as a repair in this exercise. F-D: invalid model output receives controlled correction and validation, not a network retry loop. Persistent invalidity becomes human review. F-F: two check-then-write workers can both create an item. The basic rehearsal is explicitly single-operator. A stronger implementation must verify a unique destination key or atomic claim and safely handle the losing worker's error. A conceptual diagram does not prove it works.

M6 Q1: the write may already have happened; a read failure before any effect cannot duplicate a write. Inspect the destination before replaying an uncertain write. M6 Q2: a new timestamp produces a new key for the same intended action, defeating duplicate detection. M6 Q3: both workers can see absence before either writes. Limit the rehearsal to serial operation and state that production concurrency is unverified until a stronger control is tested.

Module 6 Ledger and evidence reveal

R210: the matching key is STARTED with no confirmed destination. Use TECHNICAL_HOLD, make zero additional queue writes and establish whether the in-progress attempt finished. A lookup or operator check must find an existing matching record, confirm no effect under the retry policy, or leave the outcome unknown. A second delivery is not evidence that the first attempt failed.

R211: the same request ID/revision now has materially different duration and message. Use HUMAN_REVIEW with identity_conflict and hold the existing operation for inspection. Retain Q211 and its original one-day content; do not overwrite it or create a second queue item under the same revision. The intake owner must establish whether the two-day content is an authorised revision and provide its proper identity. The learner must not manufacture revision 2.

R212 evidence reveal, to read only after stating the needed check: a destination lookup finds Q212 under R212|1|queue_review, with the same request revision and material content as the attempted write. Before lookup: NEEDS_RECONCILIATION, unknown outcome, no second write. After verifying the match: RECORDED → Q212, with a reconciliation note and review still PENDING. If your requested evidence was only “ask the AI whether it worked,” it was insufficient; the destination effect needed inspection.