Determinism Is a Security Feature

The word we use to excuse the thing we never fixed

Ask an engineer why their artificial intelligence (AI) system gave a different answer to the same question twice, and you will hear the same word. Non-determinism. It is said the way people say weather. As if it fell out of the sky and nobody is responsible for it.

I have spent enough time near security incidents to distrust any word that doubles as an excuse. Non-determinism is not weather. It is a configuration. A sampling temperature above zero, an unpinned model version, a floating-point reduction that runs in whatever order the hardware felt like that millisecond, a retrieval step that pulled a slightly different set of documents because an index updated overnight. Every one of those is a knob. Someone set it, or someone left it on the factory default and looked away. That is still a decision.

So let me say the unfashionable thing plainly. Determinism is a security feature. Reproducibility is not a luxury you bolt on once the model is clever enough. It is the property that decides whether you can ever defend what your system did. And the industry has quietly agreed to treat the absence of it as a fact of life, because the absence is cheaper to ship.

If you cannot replay it, you cannot defend it

Security has a simple test for whether a system is auditable. Can you take the inputs, the state, and the code, run them again, and get the same output? If yes, you can investigate. You can isolate which input caused the failure. You can prove to a regulator, a customer, or a court that the harm came from this cause and not that one. If no, you are holding a story, not evidence.

Most AI deployments fail this test on the first question. The model that approved or denied the loan, flagged or cleared the transaction, triaged or dismissed the patient, cannot be made to do it again. The vendor shrugs. The logs show a prompt and a response, with nothing in between that lets you reconstruct the path from one to the other. When something goes wrong, the most honest answer the operator can give is that this is roughly what they think happened. That sentence has no place in a domain where decisions touch money, health, or liberty.

Attackers understand this better than most boards do. A system that cannot reproduce its own behaviour cannot reliably detect when that behaviour has been tampered with. If your AI gives different outputs every run by design, a poisoned input or a manipulated retrieval source hides inside the noise you already told everyone to expect. You have trained your own people to stop being surprised by variation. That is a gift to anyone who wants to slip a malicious variation past them.

Non-determinism is a choice wearing the costume of an accident

Here is the part the field would rather not dwell on. Almost all of the non-determinism in a production AI system is removable, and the parts that are not removable are containable. The difference between those two categories is engineering, not magic, and most teams have never sat down to draw the line.

You can fix the sampling temperature. You can pin the exact model weights and refuse to let them drift silently under you. You can record the precise retrieval set that fed a given answer instead of pointing vaguely at a database that has since moved on. You can control the numerical execution so the same maths produces the same bits. None of this is exotic. It is ordinary engineering discipline, the kind we already demand of payment systems and flight software and anything else where being wrong twice the same way is preferable to being wrong differently every time.

What stops teams is not capability. It is incentive. Determinism is slower to build, harder to demonstrate in a demo, and it removes the convenient fog that lets a vendor say nobody could have predicted this. Leaving the randomness on is the path of least resistance, and the cost of that choice is deferred. It lands later, on the operator, in the audit, in the incident review, in the liability claim. The people who set the knob are rarely the people who pay for it.

Call it what it is. When a system is built so that it cannot account for itself, that is not an accident of the technology. It is a governance decision to externalise the cost of accountability onto whoever comes after. And in 2026 that whoever increasingly carries legal weight, not just operational annoyance.

The regulation is already pointed at this

The direction of travel is not subtle. The European Union (EU) Artificial Intelligence Act brings its substantive obligations for high-risk systems into force, with record-keeping, traceability, and human oversight written into the text rather than implied. Liability regimes across multiple jurisdictions are shifting the burden so that an operator who cannot explain a decision sits closer to being assumed at fault. The qualitative trend is consistent everywhere I look. The era where you could deploy an opaque model and treat its outputs as an act of nature is closing.

Record-keeping is the recurring word, and most teams hear it as logging. It is not. A log that you can edit after the fact, that lives on the same infrastructure as the system it describes, and that nobody can independently verify, is a diary. It proves nothing to an adversary who assumes you might be lying. The standard a regulator and a court actually need is higher. They need a record that the operator could not have altered, tied to a decision that can be reproduced, checkable by someone who trusts neither the vendor nor the cloud it ran on.

That is a far more demanding bar than the industry currently clears, and it is exactly the bar that reproducibility makes reachable. You cannot have a trustworthy record of a decision you cannot recreate. Determinism is the foundation the whole compliance structure rests on, whether or not the people writing the rules use the word. Build it in late and you are reconstructing the past from fragments. Build it in first and the record writes itself.

Sign it before it runs, then let anyone check

This is the problem we built Mickai to solve, and it is the reason I keep coming back to determinism as the first principle rather than a feature in a list. Mickai is a Sovereign Intelligence Operating System (SIOS), and it is built and live, not a slide. Underneath its fifty brains (twenty-five domain and twenty-five operational, running on the Poseidon silicon substrate) there is one rule that is not negotiable. Every action the system takes is signed before it executes, not after.

The order matters more than anything else in this essay. A record written after the fact is a confession you can revise. A record committed before the action runs is a commitment you cannot. That is the Open Audit Record (OAR). Every decision is signed in advance, hash-chained to the one before it so the sequence cannot be quietly rewritten, append-only so nothing can be removed, and protected with post-quantum signatures (the United States National Institute of Standards and Technology standard Federal Information Processing Standard 204, ML-DSA-65) so the proof does not rot the day cryptography moves on.

The detail I am proudest of is the least glamorous. You verify the record offline, in an ordinary browser, trusting us not at all. The whole point of a sovereign record is that its credibility does not depend on the vendor staying honest, staying solvent, or staying online. You hold the chain. You check the maths yourself. And because the underlying decisions are built to be reproducible rather than improvised, the record is not a story about what the system probably did. It is the thing itself, replayable, with the anchor of that audit root committed onward to Bitcoin through our Pantheon layer so even the question of when it happened cannot be argued with. We are also training our own models now, fine-tuning and specialising open foundations and building a sealed corpus, so the determinism reaches down into the weights themselves over time.

Choose the boring property

I know determinism sounds like the dull cousin of everything else in AI right now. No one writes excited posts about getting the same answer twice. But security is mostly the discipline of preferring the boring, accountable thing to the exciting, unaccountable one. The systems that survive contact with regulators, attackers, and courts are the ones that can answer the simplest question without flinching. Show me exactly what you did, and prove you could not have changed the answer afterwards.

Non-determinism was never inevitable. It was convenient. We dressed a governance choice up as a law of physics because the costume let us ship faster and answer for less. The bill for that is arriving now, in regulation, in liability, and in the slow erosion of trust in systems that cannot account for themselves. The fix is not more cleverness. It is the willingness to pin the knobs, sign the record before the action, and let anyone check. Determinism is a security feature. We just stopped charging ourselves for switching it off.