Determinism is a courtesy

Engineers talk about determinism as if it were a property of well-behaved systems — a hygiene matter, like sorted imports or a clean build. A function is deterministic if the same inputs always produce the same output; nondeterminism is the bug you chase when a test passes on your machine and fails on the server. Framed that way, it sounds like an internal concern, something the implementation team should handle quietly so the rest of us never have to think about it. I want to argue that this framing hides the most important thing about it. Whether a decision process can be re-run the same way is not, in the end, a fact about the code. It is a fact about who is allowed to argue with the result.

Start with what reproducibility actually buys you. If I can take the exact inputs a decision was given — every source it read, the rules in force, the order it consulted them in — and feed them back through the same process and watch it land in the same place, then I can do something I otherwise cannot: I can test the claim that the process produced the outcome. I can change one input and see whether the conclusion moves the way the process says it should. I can hold the inputs fixed and confirm the outcome holds. A deterministic process is one whose account of itself can be checked by someone other than its author. That is not a small thing. That is the whole basis on which we extend trust to anything we did not build ourselves.

Now consider the alternative. A process that produces a different answer each time it sees the same facts cannot be checked this way, because there is no same way to run it. Run it again and a divergence proves nothing — the divergence was always permitted. The process has no stable account of itself to interrogate. You can read its output, you can read its explanation, but you cannot subject either to the one test that does not require trusting the system: doing it again and seeing what happens. Nondeterminism does not merely make verification harder. It removes the surface verification needs.

Who pays for the variance

This is where the word courtesy earns its place. When a process is deterministic, the person who built it has done a kind of work on behalf of a person they may never meet — the one who will someday need to check the decision and will have nothing to go on but the record. Determinism is the gift of a fixed point. It says: here is exactly what I did, and you can confirm it yourself, on your own terms, without my permission and without my presence. The author has made themselves accountable to a stranger. That is what a courtesy is — an obligation discharged toward someone who has no power to compel it.

Nondeterminism withdraws that courtesy. And it is worth being precise about who absorbs the cost, because it is never the system and rarely the author. The cost lands on the person the decision affects — the applicant, the patient, the defendant, the account-holder — the one who suspects the decision was wrong and discovers that there is no way to demonstrate it, because the process that produced it will not produce it again. They are left arguing with a result that has no method behind it that anyone can reach. Their standing to contest has not been denied; it has been engineered out. The door was closed before they arrived.

Variance you cannot reproduce is not a margin of error. It is a denial of standing, written in the grammar of the system itself.

I am aware that some nondeterminism is hard to avoid, and some is even desirable. There are domains where a fixed answer would be worse than a distribution of answers, where the honest output is a spread and not a point. The argument here is not that every process must be deterministic. It is narrower and, I think, harder to escape: where a process makes consequential decisions about particular people, the variance has to be governed — captured, bounded, and accounted for in the record — rather than waved through as an implementation detail. A spread is acceptable if I can see its shape and confirm that this decision fell where the process says it should. What is not acceptable is irreducible, unrecorded variance presented as a settled result. That is a point estimate wearing the confidence of a process it cannot reproduce.

An engineering default with a governance footprint

Here is the move I want to resist: treating the determinism question as something the engineering team settles on its own, by taste or convenience, before anyone with a stake in the decision is in the room. Because the choice has a governance footprint whether or not anyone names it as governance. Allow unbounded variance into a decision path and you have decided, quietly, that the people downstream will not be able to contest what the path produces. You have made a ruling about contestability. You just made it in a standup, in the language of latency and caching and retries, where it looked like a tradeoff about performance.

This is why I think replay-determinism belongs in the same conversation as standing and admissibility, not off in a separate bucket marked technical. A decision record that promises to let you replay the decision is making a claim that only holds if the underlying process will cooperate — if the same inputs really will retrace the same path. Determinism is what makes the promise of replay anything more than a slogan. Without it, you can record everything and still have recorded nothing checkable, because the thing you would check against refuses to sit still.

So the next time a process is described to you as nondeterministic, resist the urge to file it under known limitation and move on. Ask the question that the engineering frame is built to skip: if this runs differently every time, who loses the ability to prove it ran wrong? The answer is never the author. Determinism is not the absence of a defect. It is a kindness a system pays forward to whoever has to live with what it decides — and a system that withholds it has chosen, on their behalf, that they will never get to ask.

— Dispatches · Summit Cognitive