The two-weeks-notice problem
You're in the ops studio. What you're doing this lesson: turn the Monday process that lives in one person's head into a written procedure a computer can check. You do not need warehouse software or a coding background to start.
Vera handles the stuck-order sweep. Every Monday she pulls the open-orders export from the WMS (warehouse management system — the software that tracks inventory and orders), filters to anything stuck past five days, requeues each one individually — never in bulk, for a reason she found out the hard way — and posts the carried list where fulfillment will actually see it. It takes her forty minutes and it has never once been written down.
Then Vera gives two weeks' notice, and you discover that "the process" was never a process. It was a person.
Two words this studio uses, so they don't stay undefined:
- SOP — standard operating procedure. The written steps for a recurring job, so someone who has never met Vera can still run Monday.
- WMS — warehouse management system. The software that holds inventory and orders; "pull the open-orders export from the WMS" means download today's stuck-order list from that system.
Your job this hour is the ops outcome: turn "how Vera does it" into a written procedure someone else can run — and catch the steps the AI invented when it filled a gap.
The capture pattern that actually works
The documented practitioner method is almost embarrassingly simple: record Vera doing the task once while she narrates, then hand the transcript to a model and ask for a stepped procedure with decision points. The speed claims around this workflow are vendor-published and uncorroborated — discount the specific numbers accordingly — but even heavily discounted, the shape holds: a reviewable draft in minutes, instead of the afternoon nobody schedules.
And then comes the part one vendor-published account is surprisingly honest about: the drafts come back with invented steps. That team's first AI-drafted SOP (standard operating procedure — the written steps for a recurring job) contained two menu paths that don't exist in their actual tool — the model hit a gap in the transcript and filled it with something plausible. Take the vendor's speed numbers with salt if you like; take this failure mode to the bank, because it's not a fluke. It's the mechanism. A language model completes patterns. Where Vera's narration skipped a beat, the draft won't show a hole. It'll show a confident, well-formatted lie.
The three rules of capture
- The performer verifies every step before v1 ships. Not the manager, not the model, not you — the person who does the task reads each line and says "that's real" or "that's invented." The draft being fluent is evidence of nothing. Fluency is what generation optimizes for.
- Gaps ship as
"unknown — ask", never as guesses. If the transcript didn't cover what happens when the export is empty, the SOP says so. A marked gap gets answered in five minutes. An invented answer gets discovered in an incident review. - The SOP carries an owner, a version, and a date — or it isn't an SOP. A procedure with no owner is a suggestion. A procedure with no version history is a rumor with formatting. When someone asks "who changed step 3 and when," the file answers, or the file failed.
An SOP that satisfies all three has the property this whole chapter is built on: someone who has never met Vera can run Vera's Monday. That's what "the process survived the resignation" means, concretely.
The next step turns these rules into a checklist a script can run — because a rule you can't lint (run an automatic check that flags missing fields) is a rule that erodes. You will not be asked to write that check from a blank page. You'll read it, fill a piece of it, then finish a function whose shape is already on the page.