Choose the exact handover boundary
Start with a named site or line, an outgoing shift window, an extraction timestamp, and the record systems in scope. If operators can update work orders while the draft is being prepared, record the cutoff and reconcile again immediately before the live exchange. A model should not decide whether an alarm log, permit, maintenance record, or operator note is authoritative; your procedure must define that hierarchy.
Structure each item as a small state record. A concise narrative such as “sensor repair underway” is too weak because it can hide the no-restart instruction, the person controlling the isolation, the absent part estimate, and the fact that the next-shift owner is unknown.
| Required field | Copy from the source | Human-only decision |
|---|---|---|
| Record identity | Work-order, permit, alarm, or log ID | Whether another record supersedes it |
| Observed state | Timestamped observation and written status | Diagnosis or risk classification |
| Active control | Exact hold, isolation, and prohibited action | Permission to remove, bypass, or release it |
| Next recorded action | Only the action already documented | Unrecorded priority, assignee, or deadline |
| Transfer evidence | Questions, verification, receiver, and time | Acceptance before the exchange occurs |
A complete worked handover
We tested a fictional packet for Northwind Packaging Line 2. It contains three deliberately different work orders so that a polished summary cannot pass merely by repeating the same pattern.
| ID | Current evidence-backed state | Control or closure evidence | Next action, owner, due | Receiver state |
|---|---|---|---|---|
WO-104 | Photo-eye fault observed at 13:42; work in progress; sensor ETA absent | “DO NOT RESTART CONVEYOR B”; LOTO controlled by authorised maintenance | Verify isolation and speak with maintenance; owner null; due null | Pending written and face-to-face exchange |
WO-105 | Printer jam cleared; outgoing supervisor closed the record at 11:22 | 50 consecutive labels printed without error at 11:18; no promise of permanent repair | No further action recorded; owner null; due null | Receiver checks closure and test evidence |
WO-106 | Dock light flicker reported at 12:31; open and not inspected | No inspection, diagnosis, or safety rating supplied | Next action null; owner null; due null | Receiver sees the unresolved report |
The table is intentionally explicit about nulls. “Unassigned” is operational information. Filling the cells with a likely technician or an end-of-shift deadline would make the document look complete while making it less truthful.
Generate a typed draft instead of free prose
Tested output contract
Restrict the draft to this work-order packet.
Return one entry for every work-order ID.
Preserve written holds and prohibited actions verbatim.
Use null for an unrecorded owner or due time.
Do not diagnose, rank severity, close work, or permit restart.
End with receiver_acknowledgement:
PENDING_TWO_WAY_HANDOVER.
Use controlled status values taken from your system, not new labels invented during generation. Require the source ID on every row and put the safety summary in its own field. A JSON or spreadsheet-shaped draft is easier to count and compare than a paragraph, but it is still only a draft.

What the checker accepted
The source-consistent response passed three main conditions: all work orders appeared exactly once; the LOTO and no-restart wording survived; and no receiver acknowledgement was created. The checker also required the uninspected light to remain open and prevented an owner or due time from appearing on WO-104.
Three failures we deliberately introduced
| Changed field | Why the change is dangerous | Checker result |
|---|---|---|
| Receiver changed to acknowledged | No incoming person participated in the synthetic chat run | Rejected: receiver acknowledgement invented |
| Owner set to incoming technician | The packet records no next-shift assignment | Rejected: missing assignment invented |
“Not inspected” removed from WO-106 | The omission hides the boundary on what is known | Rejected: inspection state changed |
You can inspect the exact prompts, fictional source packet, retained JSON, Python gate, fifteen total mutation results, and SHA-256 inventory in the operations and procurement reproduction pack. Run python3 validate_retained_outputs.py after extraction. The expected summary is five positive passes, fifteen rejected mutations, and zero failures.
Run the live workflow in seven stages
- Freeze the source window. Record the shift, systems, extraction time, and any late-update procedure.
- Minimise sensitive content. Keep role names and IDs needed for operations; remove medical information, credentials, private contacts, and unrelated personnel notes.
- Separate observations from instructions. An observed symptom belongs in a different field from an authoritative control.
- Create the typed draft. Require one row per ID, exact control text, visible nulls, and a pending receiver state.
- Reconcile record by record. Open the live source and compare state, timestamp, owner, dependency, part status, control, and closure evidence.
- Conduct the two-way exchange. The incoming person asks questions and verifies high-consequence states through the approved procedure.
- Record acceptance in the designated system. Do this only after the exchange; do not backfill the AI output as evidence.
Review language that can silently change meaning
Source: “DO NOT RESTART CONVEYOR B. LOTO remains controlled by authorised maintenance. Replacement sensor requested; ETA not provided.”
Unsafe compression: “Conveyor repair is underway; monitor next shift.”
Traceable draft: “WO-104 remains in progress. Do not restart Conveyor B. LOTO remains controlled by authorised maintenance. Part ETA, next-shift owner, and due time are not recorded.”
The first rewrite removes the control owner and weakens an explicit prohibition into a monitoring suggestion. The second preserves the source state while making the unknowns usable.
A closed record is not a reliability guarantee
For WO-105, the closure and 50-label test are facts. “Permanently fixed” is not. If local procedure requires an observation window, quality check, or supervisor sign-off, include it only when the controlling record says so. Do not transform absence of recurrence during one test into a general prediction.
Manual sign-off checklist
- Open every cited record and confirm its most recent timestamp.
- Read critical prohibitions and holds aloud during the exchange.
- Verify isolation and permit state through the authorised mechanism.
- Keep unknown owner, due date, diagnosis, and severity visibly unresolved.
- Capture receiver questions and their authoritative answers.
- Make an offline fallback available when the AI tool or network is unavailable.
- Store the final acknowledgement where the organisation's procedure requires it.
Use a different record for a different job
If an event later needs causal reconstruction, move to the incident timeline workflow; do not overload the immediate handover with analysis. Track uncertain future exposure in the project risk register. When responsibility is moving between project owners rather than shifts, the project handover document adds deliverable, access, training, and acceptance controls.
Ready condition
The draft is ready to enter the organisation's handover process when every in-scope record is present once, exact controls remain unchanged, closed work retains the evidence behind closure, missing assignments stay visible, and the latest source comparison is complete. It becomes an accepted handover only when the designated people perform and record the required transfer.
