Pause at a human decision

The desk reviewer approves a proposed correction, then someone changes the draft's year. A system that remembers only approved=True might carry that decision onto the altered content. Even a careful reviewer cannot approve a draft they never saw.

This module makes the decision specific. We will approve and reject synthetic drafts, bind each decision to saved content, and resume only to a simulation receipt. No real reviewer account, label update or message is created.

Pause with a reviewable object

The REVIEW snapshot contains a draft, its digest, revision, source version, creation tick and deadline. The draft says what comparison was made and what action is proposed. A mismatch proposes review_possible_label_correction, not an immediate update. A match proposes recording the comparison. Both require review in this exercise.

The digest includes the run identity and exact draft fields. A changed fact, target or proposed action therefore changes the value a decision must name. Revision checking independently prevents an old caller from overwriting newer state. A digest identifies content; a revision identifies saved state. Neither is a real digital signature.

Read the review-binding visual. The review gate checks identity, content, state and time. A second gate checks content, source, budget and time before simulated finalization. A pause is not an approval, and approval does not itself perform an action.

If the diagram extends beyond the screen, scroll inside it or read the text version below.

Read the diagram as text

• A decision belongs to one exact draft at a particular time
• Aabha AI Academy · original course visual · synthetic workflow only
• Draft
• Identity + evidence
• + proposed action
• Digest/revision
• Bind exact content
• and saved state
• Review gate
• Fixture reviewer
• and valid tick
• Resume gate
• Same content/source
• before deadline
• Simulation
• Saved receipt
• zero real writes
• Example: draft tick 5, deadline 8. Decision 4 is backdated; finalization 9 is expired.
• Logical ticks and reviewer names are fixtures. They do not implement a real clock or authenticated identity.

Work through the exact decision

Run the baseline with now_tick=5. It reaches REVIEW at revision 4. Default review_ttl=3 gives deadline 8. Call review with that revision and digest, reviewer synthetic-reviewer-a, approve=True and tick 6. The phase becomes APPROVED_FOR_SIMULATION. No receipt exists yet.

Call finalize_simulation with tick 6. It verifies the saved approval and returns SIMULATED with real_writes=0. Its would_change field says whether the comparison found a mismatch. This is a statement about a fictional proposed effect, not evidence that any label changed.

Repeat finalization after the terminal receipt is saved. The same snapshot is returned, without a new event or action. Replay is different from initiating a new effect. It does not need a renewed approval window because it only returns already saved evidence.

Treat time as a defined part of the contract

Logical ticks are nonnegative integer fixtures supplied by the caller. A decision cannot precede draft creation, and a new finalization cannot precede its decision. Both must occur at or before the same deadline. The deadline is inclusive: tick 8 is accepted; tick 9 expires.

Try decision tick 4 for the draft created at tick 5. It raises ReviewError and leaves REVIEW intact. Try approving at tick 6 and finalizing at tick 9. That produces STOPPED/approval_expired_before_simulation, without a receipt. An approval window that is checked only at decision time would not enforce this second condition.

These checks are coherent simulation semantics, not a real trusted-clock implementation. A caller that lies consistently about ticks can supply fictional time. A real system would need a trusted time source and a clear policy for clock changes, delayed jobs and revalidation. No such clock or scheduler is implemented here.

Reject, expire and detect a changed source

A valid approve=False decision produces REJECTED. There is no outgoing finalization path from that phase. A wrong digest, stale revision or unknown fixture reviewer is rejected before authority changes. Source-version drift stops the run: a CAT-v1 draft cannot be approved through an engine now using CAT-v2 without revisiting the evidence under a new contract.

The reviewer allowlist is a fixture containing one literal name. It demonstrates a required authorization check but does not authenticate a person. Anyone running this local exercise can type that string. Do not expose this as an internet approval service or call it real access control.

LangGraph's interrupt documentation provides a framework mechanism for pausing and resuming. It does not replace the application's decision semantics. Module 7 will carry this exact controller into that mechanism.

Practice

1. Create a draft at tick 5. Predict and test decisions at ticks 4, 8 and 9 using independent runs. Report whether each raises an error, approves, or stops with expiry. Keep invalid attempts distinct from rejected human decisions.
2. Approve at tick 6, then finalize independent runs at ticks 5, 8 and 9. Explain why both monotonicity and expiration are checked. Verify that no new receipt exists on an expired run.
3. Try an unknown reviewer and a wrong draft digest. Show that phase remains REVIEW. Then submit a valid rejection and demonstrate that finalization is blocked.
4. Change the engine's synthetic tool from CAT-v1 to CAT-v2 before review. Explain the resulting stop and identify what a real reviewer would need to see before reconsidering the changed evidence.

Check yourself: is a typed reviewer string authentication? Does a content digest grant authority? Why does replaying a saved receipt after tick 8 differ from performing a new finalization after tick 8?

Keep a decision table and a trace with explicit logical times. Review controls are useful when their boundaries are enforced by the program and described honestly to the person using them.