Ontology Debt: A Consistency Ledger for LLM World-Models

Here is a model that a plain accuracy score would happily call 96 percent correct. I asked it whether a row of dominoes nobody had touched all day was still standing. It said no. I asked again, in slightly different words. It said yes. Then no, then no, then no. Nothing in the scenario moved. The dominoes were a fixed fact sitting in the prompt, and the model kept knocking them over and standing them back up in its own head.

That model was GPT-5.4-nano. On the easy checks it was wrong only 3.7 percent of the time, the kind of number that gets a system shipped. But it contradicted itself 12.7 percent of the time. It was not holding a belief about the dominoes and reading it back. It was reconstructing that belief from scratch on every question, and the reconstruction was unstable.

Now hold that next to a second surprise. GPT-4o-mini looked nearly clean on the same easy checks: 3.6 percent wrong. Then I gave it harder questions, the kind that stack a few steps of reasoning on top of each other, and it got better than one in three wrong. Same model, same day, same wiring. Only the difficulty of the question changed, and it broke in half.

I found both of these with a tool I built called Ontology Debt, and the reason a single accuracy number missed them is the whole point.

What Ontology Debt checks, and why "ontology" is the right word

An ontology is a rulebook for what exists and how it connects. Think in Lego: a wheel is always a wheel, wheels attach to axles, an axle holds two wheels. You are not describing one model on the box, you are describing the categories and the rules that hold across every model you could build. A language model carries its own such rulebook, learned statistically from text: a ball behind a wall still exists, a cause comes before its effect, a quantity does not change just because you reworded the sentence. Ontology Debt checks whether that internal rulebook stays consistent with itself, and whether it matches the one you say the model should follow.

You declare your commitments in plain YAML. A commitment is a typed, severity-weighted invariant: a claim about the world you expect the model to respect. Each one carries scenarios, a family of paraphrases of each scenario, and a single machine-checkable answer.

id: object_permanence
severity: high
scenarios:
  - id: op-001
    setup: "A red ball rolls behind a screen. Nobody has touched it since."
    question: "Is the ball still behind the screen? Answer Yes or No."
    paraphrases:
      - "Right now, does the screen still have the ball behind it? Yes or No."
    expected:
      type: choice
      values: ["Yes", "No"]
      value: "Yes"

The tool probes any Anthropic-compatible or OpenAI-compatible model against all of them.

There is no LLM judge anywhere in this. Every probe demands a constrained answer, so every verdict is a plain deterministic string comparison. Run it twice and you get the same result. Hand someone the committed transcript and they can re-score it themselves without calling a model at all. I did this on purpose: a grader that is itself a language model inherits exactly the instability I am trying to measure.

The two numbers I refuse to blend

The tool reports two numbers, and it will not average them into one.

Violations are when the model contradicts your commitment. You said a ball behind a wall still exists; the model says it is gone. That is a world-model gap. A model can be consistently wrong: confidently, repeatably, in-agreement-with-itself wrong, and no amount of prompting variety will shake it loose.

Contradictions are when the model contradicts itself, across paraphrases of a single scenario, or across scenarios you declared to be logically linked. That is a robustness gap. A model can be inconsistently right, landing on the correct answer often enough to look fine on average while never actually holding the belief.

Figure 1. The split that a single score erases. GPT-5.4-nano's 96 percent is 3.7 percent violations sitting on top of 12.7 percent contradictions.

These need different fixes. A violation means the model's rulebook disagrees with yours, and you either correct the model or reconsider your commitment. A contradiction means the model has no stable rulebook to disagree with, and the fine-tune that patches a violation may do nothing for it. Any single blended score hides both behind an average, which is how the dominoes stay invisible. The second number is the one that should scare you.

Every failure goes on a ledger

Software has a word for a fault you have found but decided not to fix yet: technical debt. You write it down, you weight it, and you carry it on the books until someone pays it down. The discipline is not in being clean. It is in refusing to let a known problem disappear just because today's build happened to pass.

Ontology Debt keeps the same books. Every failure becomes a persistent, severity-weighted entry. A later run pays an item down only when it produces enough evidence that the failure is actually gone. One lucky correct answer does not close it, because one lucky answer is exactly what a contradiction-prone model hands you. If a fix regresses, the item reopens with its full history intact.

Figure 2. An entry closes on evidence, not on a good afternoon.

You are accounting for what the model believes over time, not congratulating yourself on a good run. This is the measurement habit I carried over from years in physical and data-center infrastructure, where a fault you cannot trace across time is a fault you will meet again.

The results

Two tiers, both real and committed in the repo. The format is violations / contradictions.

Floor: 6 basic packs, 750 probes.

| Model | Violations | Contradictions |

|---|---|---|

| Claude Fable 5 | 0.0% | 0.0% |

| GPT-5.5 | 0.0% | 0.0% |

| GPT-5-mini | 0.5% | 2.7% |

| GPT-4o-mini | 3.6% | 6.0% |

| GPT-5.4-nano | 3.7% | 12.7% |

Hard tier: 4 compositional packs (compositional causality, multi-hop temporal arithmetic, nested negation, stacked conservation), 300 probes.

| Model | Violations | Contradictions |

|---|---|---|

| Claude Fable 5 | 0.0% | 0.0% |

| GPT-5.5 | 0.0% | 0.0% |

| GPT-5.4 | 0.0% | 0.0% |

| GPT-5-mini | 0.0% | 0.0% |

| GPT-5.4-nano | 3.3% | 10.0% |

| GPT-4.1-mini | 29.3% | 31.7% |

| GPT-4o-mini | 35.5% | 36.7% |

Figure 3. Floor against load. GPT-4o-mini is the shape of the problem: near-clean on easy packs, one in three wrong under composition.

Read GPT-4o-mini across the two tables. It looks nearly clean on the floor and then breaks in half on the hard tier: 35.5 percent violations, and 86.7 percent on stacked conservation alone. If you had stopped at the easy packs you would have shipped believing it was fine. That gap between the two rows is the entire case for writing your own harder packs against your own domain. The floor tells you almost nothing about where a model fails under load.

Notice also what the tool is actually reading. It reads capability, not size or vintage. GPT-5-mini holds the hard tier at a flat zero, while the newer, smaller GPT-5.4-nano is the one that cracks. Bigger and more recent are not the axis that matters. Whether the model holds a stable rulebook is.

Prior art, honestly

None of the individual mechanisms are new. Probing a model's beliefs against declared constraints goes back to roughly 2021. Paraphrase-consistency measurement and self-contradiction detection each have their own lineage. What is new is the composition: user-declared typed commitments, deterministic scoring, a first-class split between violation and contradiction, and a ledger that remembers across runs. The repo ships a related-work table. If you dispute the gold labels, good. That argument is the tool working as intended, because now we are arguing about a written-down commitment instead of a vibe.

Try it

pip install "ontology-debt[all]"
ontodebt run --models mock

That runs with no API key. A deterministic mock model exercises the whole pipeline so you can see the two numbers, the packs, and the ledger before you spend a cent. The package is ontology-debt on PyPI, the CLI is ontodebt, it is Apache-2.0, and the source is at https://github.com/dimaggi-ai/ontology-debt.

Ontology Debt is one leg of a single motion: declare, then measure, then enforce. Tool Guard is the enforce leg, runtime policy over what an agent is allowed to do. Ontology Debt is the measure leg, an audit of what a model actually holds true underneath that policy. They meet at a simple idea: you cannot align what you cannot account for.

— Maggie Nanyonga