I overrode 2 levers in my own library today. Both had already been validated on past reports. Both came out with 1 line in a file.
That line now reads: these reports never include server scripts or suggested staff wording. No exceptions. The model didn't get better or worse today. One line changed in the file it reads before it writes anything, and every report from here forward inherits it. I never have to remember the reasoning again.
That file is an AI SOP. If you're a coach or consultant who has heard the term and assumed it meant "a prompt, but longer," this is what it actually is, how it differs from the SOPs you already have, and how to write one before Friday.
TLDR
- An AI SOP is the standing instruction set a system reads before every run. It is not a prompt and it is not a traditional SOP.
- A traditional SOP is read by a person who forgets it. An AI SOP is read by a system that doesn't.
- The most important field in an AI SOP is the reason next to each rule.
- 5 parts, all plain text. You can write the first version in an afternoon.
- Across 50+ skills, the rule files are the only part that has compounded.
What an AI SOP Is (And What It Isn't)
A standard operating procedure, the old kind, is a document that tells a person how to do a task the same way every time. Onboard a client. Close the month. Publish a post.
An AI SOP does the same job for a system. It's the file the model reads before it produces anything: what the job is, what the inputs are, what the rules are and why, what gets checked before the output ships, and what to do when something fails. Every run starts by reading it. Every change to it applies to every future run.
What it isn't: a prompt. A prompt is a request for 1 output. An AI SOP is the standing context behind every request, which is the whole difference I laid out in prompts vs AI skills. It also isn't a template, because a template has no memory and an SOP is nothing but memory.
Traditional SOP vs Prompt vs AI SOP
| Property | Traditional SOP | Prompt | AI SOP |
|---|---|---|---|
| Who reads it | A person, once, then forgets | A model, for 1 output | A model, before every run |
| What it holds | Steps | A request | Job, inputs, rules with reasons, checks, failure log |
| When it changes | Annually, if ever | Every time you type | Every time a rule earns its place |
| How a change spreads | Retraining | It doesn't | Instantly, to every future output |
| What enforces it | Hope | Nothing | A verification loop and a gate |
| Where the reasoning lives | In the author's head | Nowhere | Next to the rule |
The row that matters most is the last one. A rule without its reason is a rule you can't safely change later. "No server scripts" is a rule. "No server scripts, because the owner can't control what staff say after we're gone" is a rule you can revisit in a year and know whether it still applies.
The Line I Changed That Every Future Report Inherits
The 2 levers I overrode had earned their place. One was a server script for a board. One had a server offer a side of the hero item at the table. Both had produced results on past reports.
They came out because they're not mine to give. A menu change, a price change, a placement change: the owner controls it, and it holds after we've left. A line a server says: the owner can't control it once we're gone, and my guess is it decays fast. I haven't measured that decay. I pulled the levers on the ownership argument instead, and that argument I do stand behind.
So the SOP now says no staff wording, on any deliverable, and it overrides both levers directly. The library doesn't get a vote. I've built and rebuilt 50+ of these skills and I'll say plainly: the rule files are the only part that has compounded. Models changed. Prompts got rewritten. The SOPs kept every lesson.
How to Write an AI SOP This Week
5 parts. Plain text. Aim for 2 pages, not 20.
- 1. The job. One paragraph. What comes in, what goes out, who reads it. If you can't write this, you don't have a task, you have a wish.
- 2. The inputs. Where the material comes from and what to do if it's missing. "A call recording. If under 20 minutes or mostly admin, stop and say so." That 1 sentence prevents the confident newsletter about nothing.
- 3. Rules with reasons. Every rule gets a "because." Start with 5. Add 1 every time a piece of work gets sent back. This is the rule, not ticket discipline, and it's where the compounding comes from.
- 4. The checks. 3 to 5 questions the output gets read through before anyone sees it. Would I say this on a call? Does every claim trace to the input? Is any section doing the opposite of its job?
- 5. The failure log. What broke, when, and which rule came out of it. This is the part people skip and it's the part that makes version 6 better than version 1.
Then the rule that keeps it honest: anything a script can check, a script checks. Character counts, banned words, section order. The SOP is for judgment. The mechanical stuff goes in a template or a checker so the file stays short enough to be read. I've described how that split looks inside a real file in the anatomy of a skill file.
The Only Part That Compounds
Here's why I care about this more than about any model announcement.
A prompt is spent the moment you use it. A better model makes this week's output better and does nothing for next year's. An SOP is the one thing in the stack that gets more valuable every time something goes wrong, because the failure becomes a line and the line becomes permanent.
That's what the Rule Registry is in practice. Not a document you write once. A file that gets 1 line better every time you're annoyed, and that never forgets why.
Look, you already have SOPs somewhere. You've known for a while that nobody reads them. The part you're stuck on is that the thing that will actually read them, every time, doesn't need a training day. It needs a file.
If you want to see what a system running on one of these produces from your own material, send me 1 piece of your work. A finished asset comes back in your voice within 48 hours, and the SOP behind it is something you'd keep.
FAQs about AI SOPs
What is an AI SOP?
A standing instruction file an AI system reads before every run. It holds the job description, the inputs and what to do when they are missing, rules with the reason next to each one, the checks every output passes through, and a log of past failures. Unlike a prompt, it persists across every output. Unlike a traditional SOP, it is enforced by a verification loop rather than by memory.
How is an AI SOP different from a prompt?
A prompt requests 1 output and is spent when used. An AI SOP is the context behind every request, and a change to it applies to all future runs. Prompts do not compound. SOPs do, because every failure becomes a permanent rule.
How long should an AI SOP be?
About 2 pages. Anything a script can check, like character counts or banned words, belongs in a checker rather than in the file, so the SOP stays short enough to hold only judgment. A file that grows past a few pages of rules usually produces worse output, not better.
Do I need technical skills to write an AI SOP?
No. It is plain text with 5 parts, and the first version takes an afternoon. What it requires is the ability to state a rule and its reason in 1 sentence, which any coach or consultant who has ever sent work back already does.