Architecture & Method

A decision is not a fact.

Three kinds of claim live in every company. A knowledge base that stores them as one kind will learn nonsense, and so will the AI that reads it.

A fact is a claim made true by what happened. A rule is a claim made true by where it holds. A decision is a claim made true by someone adopting it. They are moved by different things, they fail in different ways, and a system that cannot tell them apart will treat one as another.

Three claims, three ways to be true

Ask a team what it knows and the answers come back in one tone of voice. "The deploy failed at 14:02." "Every change ships through the acceptance gate." "We don't serve static sites from containers." All stated, all believed, all written down the same way.

They are not the same kind of thing.

The first is a fact. What makes it true is the event. A new observation can overturn it, and nothing else can.

The second is a rule. What makes it true is its applications: the cases where it held, and what happened when it didn't. A rule nobody has applied is a sentence.

The third is a decision. What makes it true is that someone adopted it, on a date, for a reason. No observation verifies a decision. No evidence refutes it. Only another decision replaces it.

Three columns. Fact: made true by what happened, moved by a new observation, fails by going stale. Rule: made true by its applications, moved by use, fails by never being applied. Decision: made true by being adopted, moved by a new decision, fails by losing its name and date.

Three kinds of claim, what makes each true, what moves it, and how it fails.

This distinction is old. Kant separated what is the case from what ought to be done, and held that a maxim is adopted by the will, not proven by evidence. We are not citing him for decoration. We are citing him because an AI tool that ignores the distinction makes two specific mistakes, and we have made both.

Read the wrong way

A language model treats everything it reads as evidence. That is what it was built to do, and it is the problem.

Hand it a decision written like a fact and it will go looking for support. It will find some, because decisions are made for reasons and the reasons are usually written nearby. It will then report the decision as verified. A decision cannot be verified. It can only be current or superseded.

Hand it a fact written like a decision and it will keep the fact after the world has changed, because decisions persist until someone replaces them. The server that was slow in June is still "slow" in October. Nobody re-decided it, so nobody moved it.

Two rows. A decision read as a fact: the model searches for evidence, finds the stated reasons, reports it verified; the correct reading is current or superseded. A fact read as a decision: the model keeps it after the event has changed, waiting for someone to re-decide it; the correct reading is a new observation moves it.

Each misreading has a signature. One produces false confidence. The other produces stale truth.

We wrote about the reader's version of this error in The Pigeon Was Not Superstitious: we read structure off our own graph that was mostly its starting values. Reading a decision as a fact is the same error one level up. The record says "this is so." The reader hears "this was shown."

The contradiction we built ourselves

Our own knowledge base accumulated contradictions for months. The cause was mechanical. Two kinds of content shared one write mode.

Session notes recorded what we believed on a date. Specification pages recorded what was true now. Both were appended to. So a page could state, in order, three different "current" values, each true when written, with nothing marking which one still held.

The fix in July was not better writing. It was three document types, each with one permitted way to change. A journal entry is written once and never edited: it is testimony about a moment. A register only appends: its entries are events. A living document is replaced in full and carries the date it was last verified. One living document per topic. If two claim the same ground, the newer date wins and the older is marked superseded, in the same session you noticed.

That is the three claim types, enforced by the write path. Decisions are journal entries with a name on them. Facts are living. Rules are registers of where they held.

Superseded, not deleted

The part people get wrong is the retirement.

When a decision is replaced, the instinct is to delete it. Delete it and you lose three things: what you believed, until when, and what changed your mind. The next person to propose the old idea has no record that it was tried.

So nothing is deleted. A replaced claim stays in the record, marked with what replaced it. It is cancelled as current truth and preserved as history. Hegel had a word for exactly this operation; we only need the behaviour.

A timeline. Claim v1, a decision with a name and date, is connected by an arrow labelled "replaced by" to Claim v2, also with a name and date. v1 is greyed but still present, labelled: still readable, what we believed, until when, replaced by what.

The old claim is cancelled as current and kept as history. Both are readable; only one is current.

The test is simple. Ask the system what it believed about a topic in June. If it can answer, the record works. If it can only tell you what it believes now, it has been deleting.

What this means for an AI tool

Three rules follow, and each is a test that runs on every write.

A claim carries its kind. Fact, rule or decision, declared at write time, never inferred later by whoever reads it.

A decision carries a name and a date, and is ranked by currency. Never by evidence, because it has none. Lookups return the current decision, and the chain behind it on request.

Replacement preserves. The old claim is marked superseded, not removed. The history on a claim is the one part of the record that cannot be rebuilt.

A model that reads a record built this way stops making the two mistakes above, not because it is cleverer, but because the record tells it which question to ask of each line: was this observed, was this applied, or was this chosen.

Common questions

Why can't a decision be verified?

Because what makes it true is that it was adopted, not that it matches the world. You can check that a decision was taken, by whom and when. You cannot check that it is correct the way you check a fact. You can only replace it.

Isn't every fact also a decision to believe it?

In a loose sense. In a record, the distinction is what moves the claim. If a new observation can overturn it without anyone's say-so, it is a fact. If only a person can replace it, it is a decision.

What happens to a rule nobody applies?

It earns nothing and sinks toward its starting value. A rule is only as true as its applications, which is why we link rules to the jobs that used them.

Why keep superseded claims at all?

Because the question "why did we stop doing X" is asked more often than "what do we do now", and only the superseded record can answer it.

Sources

Immanuel Kant, Critique of Pure Reason (1781/1787), A51/B75, and Groundwork of the Metaphysics of Morals (1785) on maxims. G. W. F. Hegel, Science of Logic (1812–1816), on sublation. Our knowledge-base write discipline, adopted 2 July 2026.

Related writing

Learning rule series · 9 of 10

← Don't Build Your Safety on a Chain of Thought You Don't Own · Nobody Reads It. The Work Asks It. →

What this means for your company. Your decisions are written down as if they were facts, and your AI reads them that way. The Knowledge Layer stores the three kinds apart, gives every decision a name, a date and what it replaced, and returns the current one when the work asks.

Knowledge Layer →