The map never lies: coherence as a projection

10 min read · The coherence gate

There's a specific bug that haunts AI systems, and it's worse than any crash: the agent that confidently reports it finished work it never actually did. We call it phantom verification. The fix wasn't a better prompt. It was a different architecture for the word "done."

The lie of a settable status

In most tools, a feature's status is a field. Something — a person, or an agent — sets it to "done." The problem is that the field and the reality are two separate things, free to disagree. An agent narrates "tests pass, deployed successfully" and flips the flag. Did the tests run? Did anything deploy? The flag can't tell you. It only knows it was set.

We saw this directly: an agent claimed a verification it never ran, and that claim became the project's official truth. Once "done" is something you can say, it will eventually be said falsely.

No change is real until it's verified. And "verified" can't be a thing an agent is allowed to assert.

Make "done" a projection, not a setting

So in Doric, status isn't stored. It's computed — a read-only projection over evidence. A feature is "done" only when all of its evidence exists:

• a spec for it exists,
• code implements it (the indexer found the symbols),
• a smoke test passed,
• it was deployed,
• it was accepted.

Nobody sets that. The system reads the evidence and reports what it adds up to. If the evidence isn't there, the status simply is "in progress," no matter what anyone claims. You can't argue with a projection.

Where evidence comes from

This only works if evidence is trustworthy. So evidence can only be emitted by system actors — the smoke-test runner, the code indexer, the deployer — writing to an append-only log. Agents can propose work and narrate what they're doing, but they physically cannot write a "smoke test passed" event. That capability isn't theirs.

So the loop closes honestly. When the builder finishes, a smoke run is triggered as a system action; it writes its own pass/fail event. "It passed" exists only if that event exists. The narration and the truth can no longer drift apart, because only one of them is allowed to touch the ledger.

Lineage: how scattered evidence finds its way home

There's a subtle problem hiding here. A deploy event, a test result, and a code symbol are emitted by different actors at different times in different places. How does the system know they all concern the same feature?

Every item — a captured idea, a decision, a feature — gets a lineage ID at birth. Everything downstream carries it: the spec node, the code symbols, the smoke result, the deploy event, the acceptance. So when the projection runs, it doesn't have to guess; it gathers every piece of evidence stamped with that lineage and the closure loop closes locally. No more orphaned results with nowhere to belong.

feature "approve / reject"   lineage: ln_7c4
  ├─ spec node          ln_7c4   ✔
  ├─ code symbols       ln_7c4   ✔
  ├─ smoke_result       ln_7c4   pending
  ├─ deploy_event       ln_7c4   —
  └─ acceptance         ln_7c4   —
  ⇒ status = in progress   (computed, not claimed)

The map as the honest surface

All of this surfaces on the architecture map. A node shows its computed health — verified, pending, proposed — straight from the ledger. When the orchestrator correlates the map to the real code and finds a mismatch, it doesn't hide it; it flags it. The map is allowed to say "I'm not sure this matches reality." That honesty is the whole point.

It's why we can tell you to trust a system you never read line by line. Not because it's never wrong — but because when it's wrong, it shows you, instead of telling you it's fine.

Next: It's still yours in five years →