Turning a Trusted Procedure Into a Checklist With AI
Why this matters
Turning a two-page procedure into a one-page checklist is exactly the kind of job a chat assistant does well and fast. It is also the job where it fails in the most dangerous direction. When a language model shortens a procedure, the lines it drops or merges are rarely the actions. They are the conditions: the "do not proceed until", the "this water is hot enough to scald", the "wait until it stops". A checklist that keeps every action and loses the conditions reads as complete, looks cleaner than the original, and teaches a new tech to skip the parts that protect them.
This card is the method for getting the speed without the loss: tag the source first, generate, then diff the result against the source line by line. The general standard for checking AI output before it leaves your hands is owned elsewhere. See related: The Verify-Before-You-Send Rule for AI Output.
Why the dropped line is nearly always the safety one
It is worth understanding the mechanism, because it tells you where to look. A language model produces the most likely text given what it was shown. Asked to condense, it keeps what looks like the skeleton of the task, and in nearly every procedure ever written, the skeleton is the verbs: shut off, drain, remove, replace, refill. Safety content tends to be written differently. It is phrased as a negative ("never energize"), as a condition ("only after"), as a pause ("wait until"), or it sits in a note or warning box outside the numbered steps. To a model summarizing, a pause looks like a step where nothing happens, and a warning box looks like commentary.
Merging does the same damage more quietly. "Refill the tank. Do not restore power until water runs steady from the hot tap" becomes "Refill tank and restore power": both actions survive, the condition between them does not, and the merged line looks like an improvement. Reordering comes from grouping by topic. A model that sees two electrical items and one mechanical item between them will often put the electrical items together, which is how "prove the terminals dead" ends up after "remove the access cover", the one place it cannot go.
None of this means the tool is careless. It means the tool optimizes for a clean read, and safety lines are deliberately not clean.
The method, step by step
1. Freeze the source you trust
Pick one written version, date it, and give it a version number. The source has to be a document, not a senior tech's memory, because the whole method is a comparison and you cannot diff against something that changes when you ask about it. If no trusted written version exists, stop here: generating a checklist from a procedure nobody has verified just gives an unverified procedure a tidier format. See related: Drafting an SOP From a Recorded Tech Walkthrough.
2. Number and tag every line before the tool sees it
This is the step that makes the rest mechanical, and it is the one people skip. Number each line of the source and tag it with one of five labels:
- ACTION - something the tech does.
- GATE - a condition that must be true before going on ("only after", "stop if").
- HAZARD - what can hurt someone at this point and the control for it.
- WAIT - a pause with an end condition.
- RESTORE - putting energy, pressure, water or motion back, with its precondition.
Count the tags. That count is your acceptance test later. If you skip tagging, the diff in step 4 becomes a reading exercise, and reading is exactly how the original loss gets past a tired reviewer: the shorter version reads fine.
3. Generate with instructions that name the failure
Tell the tool what you are worried about, in plain words. A prompt that works: "Turn the numbered procedure below into a one-page field checklist. Keep every line tagged GATE, HAZARD, WAIT or RESTORE as its own checklist item, with its condition stated in full. Do not merge any of those lines with another line. Keep the original order. After each item, put the source line numbers it came from in brackets." The bracketed numbers are what make the diff possible. Without them you are matching by meaning, which is slow and error-prone.
Expect the instructions to be partly ignored. They reduce the loss; they do not eliminate it. The next step is not optional because you asked nicely.
4. Diff by line number, three passes
Run three separate passes, each looking for one thing:
- Coverage. List every source number. Tick each one that appears in a bracket. Any number not ticked was dropped.
- Order. Read the bracketed numbers top to bottom. They should only ever increase. A number that goes backwards marks a reorder; decide whether it matters (it does whenever a GATE or HAZARD moved after the action it protects).
- Integrity. For every GATE, HAZARD, WAIT and RESTORE line, read the source text and the checklist text side by side. The condition has to survive word for word in meaning: the number, the "until", the "never". A merged line that kept the action and lost the condition counts as dropped.
Three passes sound slow. On a 20-line procedure they take about ten minutes, and each pass is easy because it asks one question.
5. Put back what was lost, by hand
Do not regenerate and hope. Edit the checklist directly, inserting the dropped lines from the source text verbatim, and fix the order. Regenerating gives you a new draft with a new set of losses and you start the diff over.
6. Field-run it with the source author watching
Hand the checklist to someone who has done the job a handful of times, not the senior tech, and have them work a real job from it while the person who wrote or owns the source watches. The junior finds the items that are ambiguous; the senior catches anything the checklist now implies that the source never said. A checklist that only the expert has read has only been tested by someone who does not need it.
7. Link it to its source and never edit it alone
Print the source version on the checklist ("from Water Heater Element SOP v3, March 2026"). When the procedure changes, change the source first, regenerate, and re-diff. A checklist edited on its own drifts from the procedure within a year, and then you have two documents that disagree and techs following whichever is on the truck.
Worked example: an electric water heater element swap
A shop's trusted procedure for replacing a lower element on a residential electric water heater has 22 lines. Tagged, they break down as 13 ACTION, 4 GATE, 3 HAZARD, 1 WAIT and 1 RESTORE, which is 22. The office asks a chat assistant for a one-page checklist using the prompt from step 3. It returns 15 items.
The coverage pass ticks 19 of the 22 source numbers. Three pairs of action lines were merged into single items (six source lines in three items, a reasonable condensation), lines 21 and 22 were merged into one item, and the remaining eleven lines map one to one. The three unticked lines, and the two damaged ones the other passes found, are the whole story:
SOURCE (tagged) CHECKLIST RESULT
04 GATE prove tester on known -> item 6, AFTER item 5
live, read element terminals "remove cover and
dead, prove tester again insulation" (reordered)
09 HAZARD tank water may be up -> missing
to 140 F; hose to a drain,
open drain slowly, hands off
10 HAZARD keep hose and floor -> missing
water away from the panel
13 WAIT hot tap open; wait for -> missing
drain flow to stop before
pulling the element
21 RESTORE refill with hot tap -> item 14 "refill tank
open until flow is steady, and restore power"
no air; never energize dry (condition lost)
Count what was damaged. Of the 13 ACTION lines, none were lost. Of the 9 lines that were conditions (4 GATE, 3 HAZARD, 1 WAIT, 1 RESTORE), five were dropped, reordered or stripped. Every defect sat in the condition lines.
What each defect would have done in the field. The reordered gate has a tech removing the cover and insulation on an element that has not yet been proven dead, which puts hands near terminals that may be live if the wrong breaker was opened. The live-dead-live sequence exists precisely for that case: prove the tester on a known live source, read the terminals, prove the tester again, per NFPA 70E-2021, 120.5, with the OSHA work practices at 29 CFR 1910.333(b)(2). The missing scald line sends a tech to open a drain on water that can sit at 140 F. The missing WAIT means the element comes out while the tank is still draining into the cabinet. And the stripped RESTORE line is the classic: energize the tank before it is full and the new element burns out in seconds with no water around it, a repeat visit on the shop's own time.
The fix. The office manager pasted lines 09, 10 and 13 back in verbatim, moved item 6 to sit before item 5, and split item 14 into "refill with hot tap open until flow is steady with no air" and "restore power only after that". The checklist went from 15 items to 19. It is still one page.
What would change the answer. If the source procedure had been written with its warnings inside the numbered steps rather than in a box at the bottom, the tool would likely have dropped fewer of them, which is a reason to write procedures that way in the first place. If the procedure had been purely administrative (closing out an invoice, filing a permit) there is little hazard content to lose, and a lighter single-pass check is proportionate. The three-pass diff earns its time wherever the source has GATE, HAZARD, WAIT or RESTORE lines at all.
How to tell the checklist is ready
- Every source line number appears in a bracket, and the bracketed numbers read in increasing order.
- The count of GATE, HAZARD, WAIT and RESTORE items in the checklist equals the count in the source, 9 in the example, none merged.
- A tech who had not seen the source worked a real job from it, and the source owner watched and signed off.
- The checklist names its source version, and the source is filed where the next revision will start from.
If any of these is not true, the checklist stays in the office.
References
- NFPA 70E-2021, 120.5, verification of an electrically safe work condition
- OSHA 29 CFR 1910.333(b)(2), deenergizing equipment before work on exposed parts
- See related: The Verify-Before-You-Send Rule for AI Output
- See related: What a Language Model Is Actually Doing When It Answers
- See related: Drafting an SOP From a Recorded Tech Walkthrough