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 fieldCopy from the sourceHuman-only decision
Record identityWork-order, permit, alarm, or log IDWhether another record supersedes it
Observed stateTimestamped observation and written statusDiagnosis or risk classification
Active controlExact hold, isolation, and prohibited actionPermission to remove, bypass, or release it
Next recorded actionOnly the action already documentedUnrecorded priority, assignee, or deadline
Transfer evidenceQuestions, verification, receiver, and timeAcceptance 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.

IDCurrent evidence-backed stateControl or closure evidenceNext action, owner, dueReceiver state
WO-104Photo-eye fault observed at 13:42; work in progress; sensor ETA absent“DO NOT RESTART CONVEYOR B”; LOTO controlled by authorised maintenanceVerify isolation and speak with maintenance; owner null; due nullPending written and face-to-face exchange
WO-105Printer jam cleared; outgoing supervisor closed the record at 11:2250 consecutive labels printed without error at 11:18; no promise of permanent repairNo further action recorded; owner null; due nullReceiver checks closure and test evidence
WO-106Dock light flicker reported at 12:31; open and not inspectedNo inspection, diagnosis, or safety rating suppliedNext action null; owner null; due nullReceiver 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.

Retained ChatGPT Temporary Chat output showing three fictional work orders, a do not restart instruction, null owner and due fields, and pending two-way acknowledgement
Actual retained test: the handover keeps the LOTO hold and missing assignments visible, and leaves receiver acknowledgement pending. Credit: Grow AI Skills retained ChatGPT test screenshot. Open full-size image.

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 fieldWhy the change is dangerousChecker result
Receiver changed to acknowledgedNo incoming person participated in the synthetic chat runRejected: receiver acknowledgement invented
Owner set to incoming technicianThe packet records no next-shift assignmentRejected: missing assignment invented
“Not inspected” removed from WO-106The omission hides the boundary on what is knownRejected: 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

  1. Freeze the source window. Record the shift, systems, extraction time, and any late-update procedure.
  2. Minimise sensitive content. Keep role names and IDs needed for operations; remove medical information, credentials, private contacts, and unrelated personnel notes.
  3. Separate observations from instructions. An observed symptom belongs in a different field from an authoritative control.
  4. Create the typed draft. Require one row per ID, exact control text, visible nulls, and a pending receiver state.
  5. Reconcile record by record. Open the live source and compare state, timestamp, owner, dependency, part status, control, and closure evidence.
  6. Conduct the two-way exchange. The incoming person asks questions and verifies high-consequence states through the approved procedure.
  7. 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.