The process inventory you built in the last lesson comes back from review with one cell highlighted in red. Of the 47 processes your organization actually runs, 29 have no current documentation at all. Not stale documentation, not thin documentation: none. The knowledge lives in the hands of the people who do the work, and in the last twelve months two of those people have resigned and one has retired. You take the finding to your director and ask for budget to fix it, and she does the math out loud: a proper standard operating procedure, written the traditional way, costs a business analyst two to three days per process. Twenty-nine processes at two and a half days each is roughly 72 analyst-days, more than three months of one person's full-time calendar, and there is no such person and no such calendar. She closes the spreadsheet and says the sentence that has killed a thousand documentation projects: "We'll get to it after the AI rollout." This lesson exists to reverse that sentence. The documentation is not what comes after the AI rollout. Done right, with a recorder, a transcript, and a drafting prompt, it is one of the first things the AI rollout produces, at about an hour of drafting effort per process, provided you spend the time you saved on the one thing you must never skip: verification.

Twenty-Nine SOPs and No Budget: The Math That Changed

Start with what a standard operating procedure (SOP) actually is, because the definition carries the stakes. An SOP is a document that tells a competent person exactly how to perform a process: the steps in order, the systems touched, the decision points, the thresholds, the exceptions, and what to do when things go wrong. It is not a description of work. It is an instruction for work. That distinction matters more than any other sentence in this lesson, because a description that contains an error misinforms a reader, but an instruction that contains an error redirects a worker. Someone will follow it. That is the entire point of the document, and it is also the entire risk.

Now the old economics. The traditional method for producing a good SOP is genuinely good: a business analyst shadows the performer for a session or two, takes notes, drafts the document, walks the draft back through the performer, revises, and publishes. Done properly it takes two to three days of analyst time per process, and the output is trustworthy precisely because a skilled human witnessed the work and negotiated every sentence with the person who does it. The problem was never quality. The problem is that at two to three days per process, 29 undocumented processes cost roughly 72 analyst-days. Put an illustrative loaded rate of $600 a day on that and you are asking for about $43,000 and a quarter of someone's year to produce documents that, in most organizations, nobody gets promoted for writing. The request dies in the budget meeting every single time, and the documentation debt rolls forward another year, compounding quietly as people leave.

Why should you care enough to fight for it anyway? Because everything else in this program stands on it. In Level 1 you learned the process readiness bar: a process is ready for AI when it is stable, documented, and measurable. This lesson is the engine for the middle word. An undocumented process cannot be assessed, cannot be redesigned, cannot be handed to an AI workflow, and cannot even be measured honestly, because nobody agrees on where it starts and ends. MIT's autopsy of the 95 percent of enterprise generative AI pilots that produced no measurable return found adoption without transformation at the center of the wreckage: tools bolted onto work nobody had mapped or redesigned. Documentation debt is transformation debt wearing older clothes. And BCG's 10-20-70 rule, the program's standing arithmetic, says 70 percent of AI success is people and process work. Writing down how the work actually happens is about as 70-percent as work gets.

The new economics look like this, and the rest of the lesson teaches you to earn them honestly. You record a narrated walkthrough of the process, roughly 30 to 45 minutes. You transcribe it, which modern tools do in minutes. You feed the transcript to an AI with a carefully built drafting prompt, and in well under an hour of prompting and iteration you hold a structured draft SOP. Then, and this is where this lesson diverges from every breathless video about "write your SOPs in five minutes with AI," you spend more time verifying the draft than you spent creating it. Total elapsed effort per process: around three hours instead of two to three days. Multiply by 29 and the impossible project becomes roughly eleven working days of distributed effort. That is a project your director will fund. But only the verification makes it a project she should fund.

The deliverable you will build across this lesson is the Walkthrough-to-SOP Kit, and it has exactly three components: the Recording Script (how to run a narrated walkthrough that produces a transcript worth drafting from), the SOP Drafting Prompt (a template-constrained prompt with honesty clauses built in), and the Two-Pass Verification Protocol (a desk check and a do-it test that stand between the draft and the word "published"). Three pieces of paper. Together they turn a $43,000 problem into an eleven-day habit.

Component One: The Recording Script, Because the Transcript Is the Raw Material

Two lessons ago you learned the rule that governs everything a language model produces: garbage in, polished garbage out. The model will build its draft from whatever the transcript contains, fill whatever the transcript omits with plausible invention, and do both in the same confident voice. So the single highest-leverage hour in this entire workflow is not the prompting hour. It is the recording hour. A rich, specific, exception-aware transcript produces a draft that mostly needs checking. A vague, happy-path transcript produces a draft that mostly needs rewriting, and worse, produces gaps the model will quietly fill for you. Slow down here. This is craft, and it is learnable.

The narrated walkthrough: perform, don't describe

The foundational move is this: the performer does the actual task, on the actual system, while talking. Not a conference-room interview about the process from memory. A screen-recorded, microphone-on session where the invoice actually gets processed, the ticket actually gets triaged, the order actually gets released. The difference in transcript quality is enormous, for a reason every process professional will recognize: people describing work from memory describe the process as designed, while people performing work narrate the process as run. The gap between those two is where your assessment findings live, and it is also where a new hire will get stuck at 4:50 p.m. on a Friday.

Ask the narrator to follow three simple speaking rules. Name every system out loud as you enter it ("I'm now in NetSuite, the vendor record screen"). Read every value you type or check out loud ("the PO number here is the seven-digit one, not the requisition number"). Say what you are looking at before you act on it ("I'm scanning the line items for anything over the approval limit"). These rules feel awkward for the first five minutes and then become natural, and they transform the transcript from a mumble track into a document with addresses in it.

The interviewer's job: prompting for the invisible

Do not let the narrator record alone. Someone, you, sits in the session with one job: asking the questions that surface the work the narrator cannot see because it has become reflex. Experts compress. A step they have done four thousand times gets performed in silence in two seconds, and the transcript never learns it happened. Your counter-move is a short list of prompts you ask at every pause, and these three earn their place in the Recording Script verbatim:

• "What are you checking before you click approve?" This question unpacks judgment. The narrator was about to click a button; the transcript would have recorded a click. The answer records the three-item mental checklist that is the actual step.
• "What happens when that field is blank?" This question opens an exception path. Every field, every lookup, every hand-off has a failure branch, and narrators never volunteer them because today, in this recording, the field is not blank.
• "When was the last time this went wrong, and what did you do?" This question mines the incident memory. The answer is usually the most valuable ninety seconds of the whole recording: it names the fragile step, the workaround, and often the person you need to interview next.

Hunt the exception paths on purpose

Left alone, every narrator demos the happy path. It is not deception; it is politeness and habit. The clean invoice, the complete record, the cooperative counterparty. But an SOP that covers only the happy path is a map of the easy 80 percent that abandons the reader exactly when the reader needs it, in the hard 20 percent. So the Recording Script includes a deliberate exception segment: after the happy-path run, ask the narrator to pull up, or at least talk through step by step, the two or three most common exception cases. "Show me one that got rejected. Show me one where the vendor wasn't in the system. Walk me through the one that needed a manager." Ten extra minutes of recording; half the eventual value of the SOP.

When the process has variants, record two performers

If your inventory or your instincts say two people do this process differently, record both, briefly. Not to referee, to discover. When the transcripts disagree, you have found one of three things: an undocumented improvement one of them invented, an error one of them has been making, or a genuine fork that the SOP must either standardize or explicitly permit. All three are findings. A single-narrator SOP for a multi-variant process silently canonizes one person's habits as the standard, and the other performers will ignore the document from the day it ships, which teaches the whole organization that SOPs are fiction.

Component Two: The SOP Drafting Prompt, With the Honesty Clauses Built In

Now the fast part, which needs the most discipline precisely because it is fast. You have a transcript. The temptation is to paste it into a chat window with "turn this into an SOP" and admire the output. Resist, and build the prompt properly, using the four-part pattern from earlier in this level: role, task, context, format. Three features separate a professional SOP Drafting Prompt from the naive version, and each one exists because of a specific failure mode you already know.

First, embed your organization's SOP template in the prompt. Paste the actual section structure your organization uses: purpose, scope, roles, prerequisites, step-by-step procedure, exceptions, escalation, revision history, whatever your standard is. If you have no standard, this lesson's worked example uses a serviceable one: Purpose, Scope and Roles, Systems and Access Required, Procedure, Exception Handling, Escalation, Revision History. Constraining the model to a template does two jobs at once: it produces a document that looks like your other documents, and it forces the model to notice what the transcript did not supply. An empty "Systems and Access Required" section is a question. An unconstrained draft would have papered over it.

Second, include the inference-marking clause, verbatim: "Mark every step you inferred rather than heard in the transcript with the tag [INFERRED]. Do not silently fill gaps. Additionally, list anything the narrator appears to have skipped or done from muscle memory without narrating it." This clause is the single most valuable sentence in the Kit. You learned in the Output Skeptic lesson that models fabricate specifics and launder uncertainty into confident prose; you cannot stop the tendency, but you can force it to wear a uniform. Every [INFERRED] tag in the draft is a pre-marked verification target. In practice a good transcript yields a draft with three to six [INFERRED] tags, and each one is either confirmed with the performer in thirty seconds or exposed as an invention that would otherwise have shipped inside a standard.

Third, force a "Gaps and Ambiguities" section at the end of the draft. Instruct the model: "End the draft with a section listing every question you would ask the performer to complete this SOP, every ambiguity in the transcript, and every exception path that was mentioned but not fully explained." Then treat that list as exactly what it is: your interview script for round two. This is the move that turns the AI from a ghostwriter into a junior analyst. A good model, given a real transcript, will produce eight to twelve genuinely sharp questions ("the narrator says rejected invoices 'go back', but does not say to whom or via which system"), and a fifteen-minute follow-up call with the performer answers all of them. Two recording sessions and one prompt now equal what the traditional shadowing method took days to gather.

Run the draft, read the gaps list, hold the follow-up conversation, feed the answers back in, and regenerate. Two iterations is typical. Total prompting and iteration time in the worked example below: 25 minutes. You now hold a four-page draft that looks finished. It is not finished. It is a suspect with excellent posture, and the next section is the interrogation.

Component Three: The Two-Pass Verification Protocol

Here is the argument of this lesson compressed to one idea. In the Verification Habit lesson you learned to scale verification to the blast radius of the deliverable. Now ask: what is the blast radius of an SOP? A report with an error misleads its readers once. An SOP with an error misleads every person who ever follows it, for as long as it stays published, with the full authority of the word "standard" behind it. An SOP is a define-the-standard document: it does not describe reality, it instructs people to produce reality. That raises the verification bar above ordinary deliverables, and it is why this protocol has two passes and why neither is optional. You saved roughly twenty hours per process on drafting. You are spending about ninety minutes of it here. This is the best trade in the entire program.

An SOP is the one document people follow without asking you first. Draft it in an hour if you like, but verify it like the standard it is about to become.

Pass 1: The desk check, draft against transcript

Sit with the draft in one window and the transcript in the other, and do three things in order. First, trace every step: each numbered step in the procedure must map to a spoken moment in the transcript or carry an [INFERRED] tag; a step that has neither is a fabrication that slipped the net, and finding even one means you re-read everything with colder eyes. Second, check every specific: each number, threshold, cutoff time, system name, role title, and field name gets compared character by character against the transcript, because specifics are where models improvise most fluently. Third, run the Output Skeptic's five patterns from earlier in this chapter as a formal sweep: fabrication (invented specifics), omission (the missing mess, especially exception paths that were in the transcript but not the draft), false confidence (hedges from the narrator rendered as certainties in the draft), smoothing (two contradictory statements averaged into one false clean rule), and template gravity (generic SOP boilerplate imported from the model's training rather than from your transcript). Budget 45 minutes. In the worked example below, this pass catches two defects that would have shipped.

Pass 2: The do-it test, the document meets a stranger

The desk check proves the draft matches the transcript. It cannot prove the draft is followable, because you, the drafter, now know too much: your memory of the recording fills every gap in the text without your noticing. So the second pass hands the draft to someone who does not perform this process and asks them to execute it, step by step, in the real system or a test environment, while the actual performer stands behind them watching in silence. The performer speaks only to prevent damage, never to help. And the rule that makes this pass work is absolute: every stumble is a defect in the document, not in the reader. If the tester hesitates, the step is ambiguous. If the tester asks a question, the answer belongs in the SOP. If the tester does something wrong, the sequence or the wording sent them there. You will recognize this as the SOP-shaped version of the Expert Walkthrough from the Verification Habit lesson, and it catches the class of defects a desk check structurally cannot: missing context the narrator never said because everyone on the team already knows it, steps in an order that matches the transcript's rambling rather than the work's logic, and instructions that are accurate but ambiguous. Budget 30 minutes. It is the cheapest usability test in all of operations, and almost nobody runs it.

When both passes are done, do two small things that convert the draft into an asset. Stamp it with a version number, v1.0, and a revision history line. And attach a verification note, three lines at the bottom: drafted by AI from a recorded walkthrough on this date, desk-checked against the transcript by this person, do-it tested by this person with this performer observing. Then add one line to the Verification Log you started earlier in this level. That note is not bureaucracy. It is the difference, eighteen months from now, between an audit finding that says "AI-drafted documentation, verification evidenced" and one that says something much worse, which the failure story below spells out.

Three Hours vs. Three Days: A Worked Example, and the Cutoff That Reached the CFO

The success path: the invoice-exception SOP

All figures here are illustrative, but they are the realistic shape of the workflow. Return to the running storyline: the invoice-exception process, the one your inventory flagged as high-volume, single-performer, and undocumented. Maria in accounts payable is the performer. Here is how the Kit runs, hour by hour.

Recording: 40 minutes. Maria processes two real exception invoices with the screen recorder on while you sit beside her running the Recording Script. When she pauses before releasing one, you ask what she is checking; the answer is a three-part eyeball test (vendor match, PO linkage, amount under her release limit) that no step-list interview would ever have captured. The exception segment covers a rejected invoice and a vendor-not-in-system case. The transcript lands at about 6,800 words.

Drafting: 25 minutes. The SOP Drafting Prompt, with your organization's seven-section template embedded and both honesty clauses in place, produces a four-page draft with four [INFERRED] tags and a Gaps and Ambiguities section containing nine questions. A fifteen-minute call with Maria answers seven of them; two get parked as genuine open policy questions for her manager, which is itself a finding. Regenerate once.

Pass 1, desk check: 45 minutes. Two catches. First, one of the [INFERRED] tags sits on an approval threshold: the draft states that exceptions over $5,000 require controller sign-off, and the transcript, checked twice, never states any figure; Maria confirms the real threshold is $2,500, and a fabricated number nearly became policy. Second, the smoothing sweep catches that the draft merged two different rejection paths, price-mismatch rejections (which go back to the buyer) and quantity-mismatch rejections (which go back to receiving), into one generic "return to requester" step. The transcript clearly contains both. The model averaged them into a single false rule, exactly the pattern the Skeptic's checklist told you to hunt.

Pass 2, do-it test: 30 minutes. Daniel from the procurement team, who has never touched this process, follows the corrected draft with Maria watching. He stalls at step one: the draft begins inside the invoice queue, but Daniel cannot find the queue, because reaching it requires logging into the finance portal through the VPN, a step so habitual that Maria never narrated it and neither pass one nor your own reading noticed its absence. He stumbles twice more on ambiguous wording. Three defects, all fixed within the half hour.

Publish. Version 1.0 ships with the three-line verification note, the revision history, and one row in your Verification Log. Total elapsed effort: about three hours, against the two to three analyst-days of the traditional method. And here is the sentence to say in the budget meeting: the three hours did not buy a cheaper version of the old document. They bought the same verified confidence, because the time the AI saved on drafting was reinvested in two verification passes the traditional method often skipped.

The failure path: the cutoff that reached the CFO

Now the version of this story that gets told in a postmortem, assembled from the failure patterns this program keeps documenting. A team lead at another company, racing the same documentation backlog, runs the fast half of this workflow and skips the slow half: records a walkthrough of a finance handoff, generates the SOP, skims it once ("looks right"), publishes it to the team wiki as the standard. The draft reads beautifully. Buried in the escalation section is a cutoff time: same-day payment requests must be submitted by 2:00 p.m. The transcript never stated a time. The model pattern-matched its way to 2:00 p.m., a perfectly common cutoff in its training data, and rendered it with total confidence. The actual cutoff at this company is 11:00 a.m.

Three weeks later a new hire, doing exactly what new hires should do, follows the published standard. A time-critical vendor payment is submitted at 1:40 p.m., comfortably inside the documented window and two hours and forty minutes outside the real one. The payment misses the run, a contractual deadline is blown, and the vendor invokes a penalty clause. The postmortem does what postmortems do: it walks the failure back to its source, and the source is a wiki page. The page was AI-drafted. Nobody verified it. And here is the part that matters for your career: the finding that reaches the chief financial officer is not "the AI made an error." Models make errors; everyone now knows that. The finding is "we published a standard that nobody checked." The AI's name is not on that finding. The team lead's is. The new hire, incidentally, is the only person in the story who did nothing wrong: following the published SOP is the entire social contract of having SOPs, which is precisely why an unverified one is not a shortcut but a trap you set for your most conscientious colleagues.

Total cost of the two verification passes that were skipped: about 75 minutes. Hold that against the penalty clause, the postmortem hours, the frozen documentation program, and the years it takes a finance organization to trust an AI-touched document again. The math is not close.

What to Do Monday Morning

Run the Kit once, end to end, on one process. One verified SOP teaches you more than any second reading of this lesson.

1. Pick one undocumented process from your inventory. Choose a frequent, single-performer, moderate-complexity process, not your gnarliest one. You want a clean first rep.
2. Book 45 minutes with the performer and run the Recording Script. Screen recording with audio, narrated performance of real work, your three interviewer prompts at every pause, and a deliberate exception segment at the end. If you suspect variants, book a second, shorter session with a second performer.
3. Transcribe, then draft with the SOP Drafting Prompt. Embed your organization's SOP template, include the [INFERRED] clause and the muscle-memory clause verbatim, and force the Gaps and Ambiguities section. Treat the gaps list as interview round two: fifteen minutes with the performer, then regenerate.
4. Run Pass 1, the desk check. Trace every step to a spoken moment or an [INFERRED] tag, check every number, threshold, and system name against the transcript, and sweep the five Skeptic patterns, watching hardest for smoothing and fabricated specifics.
5. Run Pass 2, the do-it test. A non-performer follows the draft in the real system while the performer watches in silence. Log every stumble as a document defect and fix each one before anyone calls the SOP finished.
6. Publish v1.0 with the verification note, and log it. Version number, revision history, the three-line note naming who verified what and when, and one row in your Verification Log. Then show the before-and-after math (three hours versus three days) to whoever owns the documentation backlog, and ask for the other 28.

Key Takeaways

• Treat documentation debt as transformation debt: an inventory showing 29 of 47 processes undocumented is a readiness blocker, because the L1 bar (stable, documented, measurable) cannot be met and MIT-style adoption without transformation is the predictable result.
• Replace the unfundable math with the fundable one: two to three analyst-days per traditional SOP (roughly 72 days for 29 processes) becomes about three hours per process with a recorded walkthrough, an AI draft, and two verification passes.
• Invest your craft in the recording, not the prompt: a narrated performance of real work, interviewer prompts for the invisible ("what are you checking before you click approve?"), deliberate exception-path capture, and a second performer when variants exist, because a garbage transcript guarantees a polished garbage SOP.
• Build the SOP Drafting Prompt with all three honesty features: the embedded organizational template, the [INFERRED] tag clause plus the muscle-memory list, and the forced Gaps and Ambiguities section that becomes your second-round interview script.
• Hold SOPs to a higher verification bar than ordinary deliverables: a define-the-standard document redirects everyone who ever follows it, so an invented step or a smoothed-over exception is operational risk, not a typo.
• Run Pass 1 as a desk check against the transcript: every step traces to a spoken moment or carries [INFERRED], every number and system name is compared character by character, and the Output Skeptic's five patterns are swept formally.
• Run Pass 2 as a do-it test: a non-performer executes the draft while the performer watches in silence, and every stumble is logged as a defect in the document, never in the reader; this catches the missing login steps and ambiguous instructions no desk check can see.
• Ship every SOP with a version number, a three-line verification note, and a Verification Log entry, because the postmortem finding that ends careers is not "AI made an error" but "we published a standard nobody checked."