Facts are not a discovery problem

“I’m sorry, you’re right.”

It may be the most familiar sentence in AI-assisted work. A model gives a confident answer. We challenge it. The answer changes, often just as confidently.

Better prompts help. Guardrails help. Structured outputs can constrain the shape of a response. None of them turns an inferred answer into evidence.¹

Yet we ask models to repeatedly establish facts our systems can already state.

The error is not using probability. It is asking probability to establish the ground from which every later judgment proceeds. We are trying to establish ground truth through probabilistic systems for both code artifacts and existing business conditions that are themselves evolving in code and internal documents. Where does checkout call billing? What public routes can move money? What does this PR change structurally?

Even though these are concrete facts in the system, we answer questions like these by having a model reread the repository. Then we ask again in the next review. And again in the next agent task. You see, the repository has not forgotten. Our tools have. These facts are not a discovery problem. They are a representation problem.

The repository can state which files, symbols, routes, and relationships changed. Determining what those changes mean is a different kind of work.

Kelsey Hightower’s Zero Token Architecture begins as a joke about renaming ordinary automation, but carries a serious principle: do not spend model inference on work deterministic software already performs reliably.²

His argument applies determinism to execution. The same principle should apply to what organizations claim to know about their software.

The expensive loop

The expensive loop of querying the same facts has turned stable software facts into a recurring bill for inference. What is known, what is established, is treated like new discovery. Again, these facts are not to be discovered, but to be represented stably across tools, people, and systems the business runs on.

The same repository feeds a model session, a code review, and a security audit. Each workflow separately infers facts and produces a plausible answer.

Repository

Model session

Infer facts

Plausible answer

Code review

Infer facts

Plausible answer

Security audit

Infer facts

Plausible answer

A mechanically derived fact should remain stable for the same repository revision and extraction contract. Model answers may not.³ Each workflow repeats the inference, spends more tokens and time, and may surface a different account of the same system.

At this point, we must make a distinction between facts and judgment.

Facts are evident in the system:

1. Where does checkout call billing?
2. Which routes cross this boundary?

Mechanically derivable facts should be determined, not re-inferred.

Judgment is the interpretation people form from those facts, sometimes assisted by models.

1. Is this coupling acceptable?
2. Should this change require security review?

Models can assist judgment by explaining relationships, surfacing possibilities, and testing interpretations. They should not silently become the authority whose judgment is being recorded.

A ground should be stable enough to cite; reusable across tasks; replayable when someone asks what the repository stated at that revision; rebuilt when its source or extraction contract changes.

Parse once, cite many

The idea is a stable ground for software facts that is derived from a specific revision of the code. Stable enough to cite; reusable across tasks; replayable when someone asks what was known; rebuilt only when its source changes.

A repository revision produces a versioned ground. Deterministic extraction supplies bounded context. Probability begins on the edge from bounded context to model interpretation. Human or organizational judgment follows.

Repository revision

Versioned ground

Deterministic extraction

Bounded context

Probability begins here

Model interpretation

Human or organizational judgment

We want to derive the facts once per revision. Preserve what the code states. Spend intelligence on what it means.

Is this just another code graph?

A graph that silently goes stale is another source of uncertainty. The point is not merely extracting structure; it is tying every fact to the revision that made it true.

A ground is not a timeless description of the repository. It is a versioned account of what was true at a particular moment. Unchanged facts do not need to be rediscovered, and facts do not need to be inferred or plausibly discovered.

Git offers a useful precedent: a commit’s content-addressed identity lets us refer to a particular state rather than “the code” in the abstract. Durability still requires retaining that state.⁴

The repository cannot tell us, by itself, what “funds movement” means to an organization. That meaning must be defined, versioned, and connected to code with evidence. Code facts and business meaning belong together, but they are not the same thing.

Put the model in the right place

This is not an argument against models. It is an argument for giving them the right job, thinking about the boundaries for building stable and reliable software with agents. For example, models are valuable for:

1. Explanation
2. Compression
3. Interrogation
4. Ambiguity
5. Judgment

They should not manufacture the substrate their reasoning depends on. Truth should precede explanation. Otherwise, eloquence is doing the work of evidence.

Today, context is often assembled through similarity search and model interpretation. That is useful for finding relevance. It is unsafe as the canonical record of fact.

The problem is larger than token cost: repeated inference replaces a stable, testable, citable account with a fresh probability every time.

When two agents produce different accounts of the same repository, which account becomes history?

The model should help us decide what the facts mean. It should not have to rediscover them before every decision.

Probability should begin after grounding, not before it.