The scenario below is an illustration, not a client account.
A founder pastes everything into one standing-instructions file. Her positioning, three customer interviews, a note about never using exclamation marks, the rule about pricing, and a line saying the AI can go ahead and publish to the blog. It is thorough, it is current, and it cannot stop a single bad draft.
Why does a correction get remembered and still change nothing?
Because a correction is only one of six different things, and most AI setups collapse all six into one prompt. Once collapsed, none of them can do its job. A rule cannot enforce, because nothing distinguishes it from a description. A criterion cannot fail a draft, because it was never written separately from the draft. And a passing check quietly becomes permission to publish.
These six objects carry different authority. Keeping them apart is what turns an informed workspace into a governed one.
The six, in one table
| Object | Its job | The question it answers |
|---|---|---|
| Source | Material the system reads, never material that instructs it | What was actually said or observed? |
| Fact | What the business has decided is true | What do we hold to be the case? |
| Rule | A persistent constraint: what must, may, or must not happen, in what scope, and why | What is not allowed? |
| Criterion | How this specific artifact gets checked, written before the result exists | How would we know this draft broke the rule? |
| Verdict | What the check returned: pass, revise, hold, or escalate, with the failed criterion | What happened when we checked? |
| Permission | What may read, write, publish, send, spend, delete, or change terms | What may happen next? |
Source is not fact
A customer interview is a source. What you concluded from it is a fact your business decided.
Those can come apart, which is exactly why they need separating. Your conclusion can be wrong while the transcript stays accurate. If the two are merged, you lose the ability to re-check a conclusion against what was actually said, and a summary quietly becomes its own proof.
There is a second reason, and it is a security reason rather than a bookkeeping one. Source material is data, not instructions. When retrieved material can issue directions to your workflow, anything you paste in becomes able to steer it. Research on indirect prompt injection identifies exactly this: models struggle to distinguish informational context from actionable instructions. Some trained defences learn surface cues instead of the distinction, and degrade sharply outside their training distribution.
No label, delimiter, or trained defence makes arbitrary sources safe. The structural answer is to keep sources in the source role, with limited permissions, and never let them cross into instructing the run.
Rule is not criterion
This is the distinction that costs people the most, and it is invisible until you look for it.
A rule persists across eligible work. Never invent a customer result.
A criterion makes that rule testable for one artifact. Every result claim on this page must map to a dated evidence record. An unmapped result claim holds the draft.
Read those again. The rule states a standard. The criterion is the thing a specific draft can fail.
A rule with no criterion has been loaded, not enforced. It is present in the context, it reads as authoritative, and nothing in the workflow can act on it. That is the mechanism behind the most demoralising experience in this whole category: you wrote the correction down, it is right there, and the draft broke it anyway.
The other direction matters too. Keeping them separate stops a style preference from hardening into absolute policy, because a criterion is scoped to an artifact type while a rule is scoped to the business.
Verdict is not permission
The check ran and returned green. That is a fact about the draft.
Whether the draft may go to a client, take payment, or change your published terms is a different decision with a different owner, and the owner is you.
Merge them and capability silently becomes authority. A draft path becomes an execution path, usually without anyone deciding that it should. The most common version is small and easy to miss: an evaluation step that “just goes ahead and posts” when it passes.
A passing draft may still require your approval. That is not an automation gap. It is the boundary working.
The test for whether you have actually separated anything
Two records need separating whenever they differ materially in any of these ways: who may change it, what produced it, how often it changes, how long it is kept, when it gets loaded, who may execute it, and what happens when it fails.
And the trap: a different filename is not a separation if the same actor can silently rewrite both. Two objects can share one file and be genuinely separated, if their authority and lifecycle are explicit and enforced. Six files with one editor and no enforcement is theatre.
Try this now (5 minutes)
Open the standing-instructions file you rely on most.
Go line by line and label each one with which of the six it is. Source, fact, rule, criterion, verdict, permission.
Three things usually surface.
Most lines are facts wearing the grammar of rules. They describe the business rather than constraining the work.
Very few are criteria. Often none. That is the finding.
And at least one line is a permission that nobody consciously granted.
The lines you cannot label at all are the ones doing several jobs at once, which is precisely why they cannot be checked or updated cleanly.
Where to go next
For why these objects belong outside the model in the first place, read the model is not the operating system.
For the record that holds rules and their criteria over time, see the correction ledger.
For what a verdict looks like once written down, the audit trail covers the record of what was checked and who approved it.
Frequently asked questions
Does this mean six separate files? No. This is an authority model, not a file count. A small operation can hold several of these in one document as long as the authority lines stay legible: who may change each one, what produced it, and what happens when it fails. The test is not how many files you have. It is whether the same actor can silently rewrite two things that should answer to different owners.
What is the practical difference between a rule and a criterion? A rule persists across eligible work: “never invent a customer result.” A criterion makes that rule testable for one artifact: “every result claim on this page must map to a dated evidence record, and an unmapped claim holds the draft.” The rule states the standard. The criterion is what a specific draft can fail. Rules without criteria are the most common reason a correction gets read and changes nothing.
Why separate a verdict from a permission? Because passing a check is information about the draft, not authority to act on the world. If a green verdict automatically authorises sending, then your evaluation step has quietly become your approval step, and capability has turned into authority. Keeping them apart is what lets a passing draft still wait for you.
Why can a source not simply be treated as a fact? Because a source is material the system reads, never material that instructs it. The interview happened and the transcript is accurate; what you concluded from it is a separate decision that can be wrong while the transcript stays right. Keeping them apart preserves your ability to re-check a conclusion against what was actually said, and it is also the boundary that keeps retrieved material from issuing instructions to your workflow.