Your SOPs Aren't Ready for AI, and the Reason Is Fourteen Years Old
By Chad Udell
Here's a conversation that has happened in a few hundred operations departments over the last two years.
Somebody senior says: we should point AI at our procedures. Workers ask questions, the system answers from our documentation, everyone stops calling the one guy who knows everything. Reasonable. Obviously valuable. Budget gets approved.
Six weeks later the project is stuck, and the reason has nothing to do with the model.
It's stuck because the procedures are a scanned PDF of a document that was printed, marked up by hand in 2019, and scanned again. It's stuck because the critical tolerances live inside a table inside a Word doc that converts to gibberish. It's stuck because there are three versions of the lockout procedure on the shared drive, two of them named FINAL, and nobody currently employed knows which one operations actually follows.
The model is fine. The model was never the problem. You cannot retrieve what was never structured.
Why "we'll just point AI at it" fails
Four specific blockers, in roughly the order teams hit them.
The content is pictures of words. Scanned procedures, photographed whiteboards, PDFs exported from a design tool with the text rendered as outlines. OCR gets you partway, and partway is worse than nowhere — because partway produces a system that answers confidently from a document it read 80% correctly. The 20% it got wrong includes, in my experience, a suspicious number of decimal points.
The structure is visual, not semantic. A procedure that a human reads as "seven steps, with step four containing a warning and a torque spec" is often stored as a sequence of styled paragraphs with no machine-readable indication that step four is a step, that the warning is a warning, or that 42 N·m is a value attached to a specific fastener. You can see the structure. The file doesn't contain it.
There is no version of record. This is the one that kills projects. If you can't answer "which document is authoritative right now" for a given procedure, you cannot build a retrieval system, because the system's first job is to pick a source and it has no basis for picking. Teams discover this about four weeks in, and it's not a technology problem — it's a governance problem wearing a technology costume.
Nobody owns it. The procedure was written by someone in a department that's been reorganized twice. When the manufacturer revises the spec, there is no defined path from that revision to your document. So the document ages, silently, and nothing in your system knows it has aged.
None of that is exotic. All of it is ordinary. And every bit of it had to be true before anyone had heard of a large language model.
The question we asked in 2012, for entirely different reasons
I wrote Learning Everywhere in 2012. Chapter 3 is the content strategy chapter, and it's the driest chapter in the book — it's the one about governance, audits, and ownership, which is to say it's the one nobody highlighted.
It contains a list of questions to ask about your existing content library before taking it mobile. Most of them are what you'd expect: what exists, what's missing, what's been effective, who owns it, when was it last updated.
Then there are these two:
"Is the content scrapeable (able to be pulled from the current source and reused)?"
"Does a clean, normalized form of this content exist that would be useful in a re-imagining of it?"
Those are AI-readiness questions. They are, almost word for word, the questions a competent team asks before scoping a retrieval project in 2026.
They were written to solve a completely different problem. In 2012 the concern was small screens — you couldn't take a three-column PDF designed for letter paper and render it usefully on a 3.5-inch display, so you needed the content in a form you could pull apart and reflow. The motivation was layout.
The layout problem went away. Screens got bigger, responsive design got solved, and nobody worries about reflowing a PDF anymore.
The question didn't go away. It got more important, and for a much higher-stakes reason. In 2012, content that wasn't normalized rendered badly. In 2026, content that isn't normalized produces wrong answers delivered confidently to someone holding a tool.
There's a companion line in the same chapter that I'd now write differently but still stand behind:
"Running your Flash course through some sort of HTML5 mill is not the answer. You must redesign and adapt your applications to fit within your content strategy for mobile."
Swap the nouns and it's the argument I'd make today. Running your PDF library through an embedding model is not the answer either. The conversion step is not the work. The conversion step is what you do after the work.
What we got wrong
Two things, and the second one is probably the more interesting failure.
We framed IT as the obstacle.
Chapter 3 spends real page count knocking down objections from security and IT — there's a line about "that iron curtain of IT," and an anecdote about USB ports glued shut, and a general posture that the security team is a bureaucratic drag to be routed around. Some of the advice amounts to: try it and see what the network lets you get away with.
That has aged badly, and I'd retract the tone entirely. Post-ransomware, post-supply-chain-attack, the security team's caution about what data leaves your walls and what systems touch your operational documentation is not obstruction. It's the job. If you're scoping an AI project over your SOPs right now, security is a design partner, not a gate to sneak past — and the ones who tell you no early are saving you a rebuild.
We listed findability and then dropped it.
This is the substantive miss. The chapter quotes Kristina Halvorson's definition of content strategy and reproduces her seven elements, one of which is search engine optimization. And then the chapter never returns to it. Not once. SEO appears in a bulleted list and vanishes.
Findability was really the whole game and we treated it as a footnote. We understood that content needed structure so it could be delivered in different shapes. We did not emphasize that structure would determine whether content could also be found and retrieved by a machine on a worker's behalf. That's not a small oversight — it's the difference between a chapter that was useful in 2012 and a chapter that would have been prophetic.
The audit, rewritten for 2026
Here's the 2012 list, cut from sixteen questions to eight and rewritten for retrieval rather than reflow. Run this against your procedures before you scope anything.
Is it text, or is it a picture of text?
Open the file. Try to select a sentence or text in a figure or diagram in the document with your cursor. If you can't, that document is invisible to every system you're about to buy. Count how many of your top 50 procedures fail this. The number is usually worse than people guess.
Does the file contain its own structure?
Are steps marked as steps, warnings as warnings, values as values — in the file, not just visually? A document where structure exists only in the typography is a document a machine reads as undifferentiated prose.
Can you name the authoritative version, right now, without asking anyone?
For any given procedure, one file is correct and the others are not. If determining which requires a phone call, you have a governance problem that no software will fix. Fix this before you fix anything else.
Who owns it, and do they still work here?
Ownership means a named person accountable for accuracy, not the person whose name is in the file metadata because they made a formatting change in 2021.
What triggers an update, and how does that trigger reach the document?
A manufacturer revises a spec. A regulation changes. An incident produces a corrective action. Is there a defined path from each of those events to the procedure, or does the document only change when someone happens to notice?
When does it expire?
Not "when was it last updated" — when does it stop being trustworthy? A procedure with no expiry is a procedure that will be confidently wrong at some unknown future date, and your retrieval system will have no way to know.
Is the language consistent enough to retrieve against?
If one document says "isolate the circuit," another says "de-energize," and a third says "lock out," a human knows those overlap. A retrieval system may not — and a worker searching one term may never see the document using another. Controlled vocabulary is boring and it is load-bearing.
Is it separable from its container?
Can the content be pulled out of the PDF, the wiki page, the LMS course, the SharePoint site — and still make sense? If the meaning depends on surrounding navigation or an adjacent document, it will lose that context the moment it's retrieved as a chunk.
If you only have a quarter
You will not fix everything. Don't try. Sequence it this way:
Prioritize by retrieval frequency, not by document age. The instinct is to start with the oldest documents. Wrong instinct. Start with the procedures workers actually reach for — the ones behind your most common support calls, the ones the experienced people get interrupted about. Twenty procedures done properly beats four hundred done partially, and the twenty will tell you what your real structural problems are.
Fix the version-of-record problem before the format problem. Converting a document you can't confirm is current just produces a well-structured wrong answer. Authority first, then structure, then format.
Treat the first twenty as a template, not a milestone. The point of the pilot batch isn't the twenty documents. It's learning what your structural conventions need to be so the next two hundred are mechanical.
Then, and only then, talk about the model. By the time your content is right, the specific technology you point at it will have changed anyway. That's fine. Structured, owned, current content is useful regardless of what you connect to it — which is exactly why it's the part worth investing in.
The unglamorous work is the work. It was the argument in 2012 when the payoff was a document that rendered properly on a phone, and it's a considerably better argument now that the payoff is a system that doesn't tell a technician the wrong torque spec.
SparkLearn delivers mobile training and performance support to frontline and deskless teams — built on content that's structured to be found, not just stored. See how our content model works, or get a demo.
