In short
AI models now produce drafts and answers at almost no cost. This essay argues that none of that output should count as evidence until an independent check, one the model does not control, has had the chance to reject it. The title calls that check an oracle. A rejection stops the claim and is written down when it happens. This matters because people cite and build on what they trust, so an unchecked claim passes into every later use. Sections 2 to 4 show how I build that check into my own software, and section 5 sets out where I stand on models and how the rule binds me too. The code is public at github.com/HarperZ9/buildlang for anyone who wants to check it.
1. The rule
The rule fits in four words: models propose, oracles dispose. An oracle, in this essay, is the independent check that decides. To dispose, in the old sense the title borrows, is to settle the outcome, and the disposition is that final decision. Everything else I have to say is commentary on where those four words draw the line.
A model may draft, translate, summarize, and search, and I welcome all of that in my shop. None of it is evidence. The evidence layer is any place where later work trusts a result without checking it again, where claims get cited and built on.
Between a model's output and that layer there has to stand an independent check that can say no, a mechanism the proposer does not control. A reviewer skimming for tone falls outside that definition, and so does a second model, because a second model agreeing is a second proposal. When the check refuses, the claim stops at the door. The refusal is written down when it happens.
The phrasing sits deliberately close to the old proverb "Man proposes, God disposes," because the structure is the old structure: one party proposes, and another decides. A tireless proposer can be brilliant and right most of the time, and the disposition still belongs to something else. Machines changed the economics. Proposals used to be scarce, so treating a confident one as halfway to a finding was survivable. Now proposals are nearly free, and a discipline calibrated for scarce proposals fails quietly when they arrive in bulk.
Trust without a second check is what makes the evidence layer a layer and keeps it from being a pile. Once a generated result lands there on its own authority, every later user inherits a claim nobody ruled on, and the inheritance compounds with each reuse. So the rule holds at the door, built into the structure, and it keeps holding when people forget to be careful.
2. A receipt that re-derives
The place I hold this line hardest right now is a compiler, the program that turns code into software a computer can run. It compiles buildlang, a programming language whose code is public. A program built with it prints its results and can also emit a receipt: a sealed record of what ran, what came out, and which invariant the run was checked against. Sealed means locked with a digital fingerprint, so any later change to the record shows. An invariant is a condition the run must satisfy.
The verifier, a separate program that checks receipts, re-derives the result, which means it works the result out again. It recomputes whatever the sealed facts allow and compares the answers. It checks the invariant again, and it re-runs the program to compare the exit status, the code a program reports when it finishes, with the sealed one. Agreement is a verdict, with the full weight of one.
One record format holds this shape across five kinds of computation: fully deterministic runs, closed-form probability, seeded randomness, sampled estimates, and budgeted search. In plain terms, one receipt format works whether a program gives the same answer every time, works out an exact probability by formula, uses random numbers that can be replayed, estimates an answer from many random trials, or searches for the best answer it can find within a fixed budget. The sampled cases carry their sample counts inside the seal, because an estimate that hides how many samples it rests on cannot be checked.
Some facts cannot be re-derived exactly, and for those the honest move is to admit it. Wall-clock time, how long the run took by the clock, is the plain example. The verifier measures it again, then reports the sealed value and the fresh one side by side without forcing them to agree. Calling a second measurement a re-derivation would be the exact overclaim this whole apparatus exists to refuse. Checking this way is slower than trust and more annoying than confidence, and that slowness is the discipline itself. A receipt states what was checked and how, and nothing stronger, so a null result, a check that confirmed nothing, is reported as exactly that.
3. A check that can prove it can fail
A check that has never said no is not known to be a check. It might be a working check or a rubber stamp, and from the outside you cannot tell the two apart until the day it matters.
So the negative fixtures, forged inputs the verifier must reject, are a core part of the test suite. For every way a receipt or a chain of receipts could be forged, there is a test that forges it and demands the right refusal by name. A chain here means receipts bound together in a fixed order, so that changing, removing or reordering any one of them breaks the whole. Tamper with one sealed count inside a chained bundle and verification has to fail under the specific name for that tampering, CHAIN_LINK_UNVERIFIED, which says the chain link is unverified. A test that gets only a generic error counts as a failure. Reorder the receipts in a chain, drop one, or substitute one, and each sabotage has its own named failure. The ordinary test run exercises each of those names end to end. The verifier also carries a self-test whose whole job is to show, on demand, that the rejections still fire.
Checking systems drift toward saying yes. Deadlines and demos favor a pass, and each false alarm annoys someone into loosening the check, so every pressure on a checking system points the same way. Only deliberately maintained proof that the check still says no pushes back. The named refusal, the less pleasant answer, is the product.
4. The boundary, crossed live
Buildlang can call out to a model over a socket, a connection between two programs, and that makes the boundary concrete enough to enforce in code. The receipt layer, the part of the compiler that issues and checks receipts, refuses outright to emit or verify a scientific receipt over any program that observes a model, meaning any program that calls one. A scientific receipt is the ordinary kind from section 2. The refusal carries its own name, which marks such a run as inadmissible as evidence. A run that involves a model still has value: it counts as a proposal, and a proposal gets a different document. That document is a boundary receipt, sealed at the point where data passed between the two programs. It records only that the exchange happened at this boundary under this seal, and it makes no claim that the model was right.
This month I watched the loop close live, the full cycle from proposal to decision. A local model, one running on the machine itself, proposed a completion, a piece of generated text, over a real socket, and the shim on the far side, a small piece of connecting code, sealed a boundary receipt over the exchange. The verifier accepted that receipt. It refused a tampered copy because the seal no longer matched. A model-free kernel, a small checking program with no model inside it, then did the scientific judging under an ordinary receipt of its own. A chain bound the proposal and the disposition into one tamper-evident bundle, and each receipt in it was re-verified independently. Tampering with the model's receipt broke the chain by name. The proposal and the judgment ended up in one evidence bundle, kept apart, and that separation was tested from both sides.
The branch that carries this end to end, a working copy of the code kept apart from the main project, is in review as I write and has not been merged. I am describing a demonstration, and no shipped release contains it yet. This essay is about the distance between a demonstration and a shipped release.
Update, 3 October 2026: the receipt work described here has since shipped. The Corrections section at the end names the release.
5. The stance
I use models all day, and nothing here comes from suspicion of them. This essay is openly model-assisted, and the compiler would be years further away without them. The rule concerns which layer a model's words may land in on their own authority. The answer is none, and it does not soften as models improve. A better proposer is a better proposer. Its role stays the same, and the disposition still has to belong to something the model does not control, or the evidence layer stops being one and everything built on it inherits the difference without being told.
The rule does not exempt its author either, and that is where it costs me something. Elsewhere in the same set of tools, a preregistered confirmatory run is under way as I write. Preregistered means its plan and pass mark were written down before it started. I will not say how it is going, because no verdict has been computed yet, and the discipline that refuses a model's self-report refuses mine too. Any result I publish will come with its receipts.
The risk I am against is quieter than the loud fears about AI: disposition migrating to the proposer, one convenience at a time, until the record is a transcript of what the most fluent party said about itself. Every mechanism in this essay exists to keep the no alive somewhere the proposer cannot reach it. Models propose; oracles dispose. The receipts are public so that somebody who is neither can check both.
Process note
This essay was drafted with model assistance at my direction and edited and signed by me, as its own rule requires me to disclose. On 25 September 2026 the prose was revised into a plainer register with Claude and checked with Articulate, a prose checker I build. The revision added a short opening summary and plain definitions of technical terms, and kept the claims, sources and positions of the July text. The technical claims describe public work, principally the compiler at github.com/HarperZ9/buildlang. The demonstration in section 4 lives on an in-review branch, as the essay says. Where a sentence reaches past what the record supports, it is argument, and it should read as argument. If it does not, that is a defect.
Corrections
- 3 October 2026, update, section 4: since this essay was first published, the model boundary receipt verify arm and chain admission have shipped in buildlang 1.3.0 (6 September 2026). The live socket demonstration described here used harness-side code outside the compiler.