Three Reports of Saved, One Readable Record

The external reviewer said it had saved the audit, and the audit was not in the shared record. The next editorial step depended on it being there.

The workflow had taken a conversational success reply as proof of a durable handoff. The external write path had been unavailable. The “saved” reply did not make the record retrievable by the receiving system.

That gap shows up whenever one agent, person, or service prepares material for another. A write request, a status message, and a readable record are related, but they are three different states.

The check belongs on the receiving side

The pattern is small enough to state plainly:

1. A source draft is saved at a known location.
2. An independent reviewer reads the draft and produces an audit.
3. The reviewer proposes a write to the authoritative shared destination, and a person authorises the bounded write before it proceeds.
4. The receiving agent reads the exact expected path from that destination.
5. Only a readable record with the expected identity can advance the workflow.
6. A person decides which recommendations to apply and whether any release should happen.

Step four is the control that matters. It asks the system that will rely on the handoff whether the record is there, instead of asking the reviewing system whether its work succeeded.

An earlier archive experiment failed the same way. An agent completed a remote write without error, but it had written the result into a new folder in the wrong repository. The result looked coherent locally and was nowhere in the authoritative archive. The repair was to name the one allowed destination, treat adjacent repositories as read-only context, and verify the destination before any write. A readback check adds the matching protection after the write: the intended receiver has to retrieve the intended record from the intended location.

Five states, and “saved” is only one of them

A workflow should model at least five separate states:

State	What it means	Evidence required before the workflow advances
Proposed	The reviewer has prepared material for a stated destination.	An accountable person has selected the scope, destination, and next decision.
Write authorised	A person has approved one bounded write to the stated destination.	The approved system reports the write attempt, but this is not yet evidence that the receiver can rely on it.
Reported saved	The system claims the authorised write completed.	The receiving side must still retrieve the expected record from the agreed destination.
Readback verified	The receiving side can read the expected record at the agreed destination.	The receiving system returns the correct record at the agreed destination. A separate human decision follows; readback does not approve recommendations.
Released	An authorised person has inspected the readback evidence, accepted the relevant change, and recorded the decision to allow the next step.	The next workflow stage may proceed under its own stated controls.

The model closes off two shortcuts. One is telling an agent to retry until it says success. The other is letting a status message unlock an edit, a publication, or a downstream task.

A retry can be sensible when the problem is known and the destination is verified. Retrying without a readable target can create duplicates, partial records, or a second system that only looks plausible. In the archive test the write never failed. It succeeded, and it landed in the wrong folder.

What readback does not prove

Readback shows that a record can be found. It does not make the audit true, useful, or binding.

An AI reviewer can organize findings, point out ambiguity, compare a draft to stated constraints, and prepare a record for a person to inspect. It cannot decide which recommendation fits the context, whether the evidence is sufficient, or whether a public release should go forward. Those decisions stay with the accountable person.

So the rule is this: an agent may report a handoff, but the workflow advances only after the next system can read the agreed record and a person has decided what to do with it.

The rule adds little delay. When a handoff is real, the receiving side can prove it. When it is not, the workflow stops there, before a confident sentence turns into an invisible failure.

dxdev LESSON · paste into your AI coding agent

LESSON: Verify the receiving record before a workflow advances

WHAT TO SHARE:
The agreed authoritative destination, expected record name or identifier, the proposed write operation, and the action that would happen next.

ASK YOUR AGENT TO:
1. Restate the authoritative destination and the exact record that must exist.
2. Separate a write authorisation, a success message, and a successful readback as three different states.
3. Define a readback check that a person runs after the authorised write attempt, which retrieves the expected record from the receiving system.
4. List the evidence a person would need before any edit, publication, or external action may continue; do not gate, trigger, or evaluate that decision yourself.
5. Report a clear stop condition when the record cannot be read or does not match the expected identity.

RETURN:
A compact state table with: proposed, write authorised, reported saved, readback verified, released; plus the evidence and owner for each state.

BOUNDARY: Do not write, delete, publish, approve, route work, contact anyone, or act in an external system. A person must inspect the readback evidence and approve every consequential step.