The scenario below is an illustration, not a client account.
A designer decides to get serious about AI governance. She spends a weekend mapping out eleven agents, a research role, a QA role, an editor, and a router between them. By Wednesday she has stopped using it, and the same tone problem is back in the client email she sent that morning.
What is the smallest AI workflow that actually governs anything?
One recurring correction, turned into three things: a rule that a later draft can break, a checkpoint between “looks done” and “ships” that can return a failure, and a condition under which the rule gets retired.
Rule, hold, retire. That is the whole unit. It does not install an operating system and it does not remove your approval. It makes the missing layer visible, in one place, for one mistake you actually have.
Why the small version is the serious version
The instinct to build the big thing first is not laziness, it is the opposite. It is a competent person taking the problem seriously and reaching for a proportionate response.
It fails for a boring reason. A company of agents multiplies the number of places a correction can be lost while adding no place where a draft can be stopped. You get more machinery and the same recurrence.
The small version is harder to argue with, because when it fails it tells you exactly what failed.
What a governed loop is
A workflow is governed when a criterion can be broken, a draft can be held, and a wrong or stale rule can be changed on the record. A workspace full of context and instructions is informed. Informed is not governed.
That distinction is the entire article. Most failed setups are richly informed. They have the standing instructions, the project brief, the second brain, the pinned note. What they do not have is anything that can say no.
The three moves
| Move | What changes | What makes it real |
|---|---|---|
| Write a rule that can fail | Turn a repeated correction into a situated rule: what must not happen, when it applies, and why | A future draft can be shown to pass or break it. “Be better” cannot |
| Put a checkpoint before shipping | Add a step between “looks done” and “ships” that is not another full reread by you | The checkpoint can return a fail, and a held draft proves it has |
| Retire the rule when its reason expires | Remove or revise constraints that no longer protect the business | The active rule set stays authoritative instead of becoming a graveyard of old reactions |
Worked through one mistake
Take a real one: the drafts keep claiming results you cannot evidence.
The rule. Never invent a customer result. That is persistent, it applies across all client-facing work, and the reason is that you have no case studies yet and will not manufacture any.
The criterion. This is the step almost everyone skips. The rule is not checkable as written, so make it testable for one artifact: every result claim on this page must map to a dated evidence record, and an unmapped result claim holds the draft.
Notice the criterion is written before the draft exists. That ordering is load-bearing. A criterion written after you have read the output will drift toward the output, because you now know what the answer looks like and the standard quietly reshapes itself around it.
The verdict. The check runs and records what happened: pass, revise, hold, or escalate, with the failed criterion attached. The verdict is information about the draft.
The permission. Separate decision, separate owner. A passing draft may still require you to approve publication. Passing a check is not authority to act on the world.
The retirement condition. What would have to change for this rule to be wrong? Perhaps: when three completed engagements have permissioned, dated results, this rule narrows rather than disappears. Write that down now, while you still remember why you made the rule.
What the loop gives you that reassurance does not
Here is the part that changes how the week feels.
When a bad draft gets through, the loop tells you which thing broke.
If the applicable correction was never loaded, that is a context-selection failure. The fix is in how work gets its context.
If the correction was loaded and the violating draft passed anyway, that is a gate failure. The fix is in the criterion.
If the draft was held, the system refused it, and you have the artifact and the failed criterion to prove it.
“I must be prompting wrong” stops being a private suspicion and becomes a testable diagnosis with three branches. That is worth more than any amount of confidence about the setup.
The boundary, stated plainly
Three moves do not install a complete operating system. They do not guarantee a correction will persist. They do not remove your approval, and they are not supposed to.
There is no performance curve here, no timeline, and no claim about how much time this saves. What is claimed is narrower: a workflow in which nothing can fail is not governing anything, and one correction is enough to find out whether yours can.
Try this now (5 minutes)
Take the correction you repeated most this month.
Write two lines.
Line one, the rule: what must not happen, and when it applies.
Line two, the check: how would you know a draft had broken this? Make it specific enough that someone other than you could run it.
If you cannot write line two, that is the finding. It means the correction has been a preference all along, which is exactly why it keeps coming back.
Then add the third line while the reason is fresh: what would have to change for this rule to be wrong?
Where to go next
The record these entries live in is the correction ledger.
If you want to know why the checkpoint has to be separate from the generator, the model is not the operating system covers the authority boundaries.
If you want to put a number on whether any of this moved, how to measure AI output quality is the measurement side.
And The Three Fixes walks the rule, the hold, and the retirement condition with you.
Frequently asked questions
Why start with one correction instead of building the whole system? Because one correction is the smallest thing that can prove the mechanism works in your business rather than in an article. It exercises every part of the loop: a rule has to be written so a draft can break it, a checkpoint has to be able to return a fail, and the rule has to be able to leave. If that does not work for one correction, it will not work for forty.
What makes a rule “able to fail”? A second line underneath it. The rule says what must not happen. The check says how you would know a draft had broken it. “Never open a client email with a question” is a rule. “The first sentence does not end in a question mark” is what makes it checkable. A rule you cannot check is a preference.
What if the checkpoint holds something it should not have? Then you have learned something specific and cheap, which is the point. A false hold tells you the criterion is too broad, and you narrow it. Count them: true holds and false holds, reported with their denominators. A checkpoint that has never held anything is not proof of quality, it is usually proof that nothing is being checked.
Will the mistake stop coming back? No, and any product that says otherwise is overclaiming. One governed correction does not install the operating system and does not guarantee persistence. What it does is make a missing layer visible and turn a private suspicion into a testable diagnosis. If the correction was never loaded, that is a context-selection failure. If it was loaded and the bad draft still passed, that is a gate failure. Those are different problems with different fixes.