Deterministic governance
The authority to permit or block an AI action belongs in a validator that decides the same way every time — not in the probabilistic model that proposed it.
Deterministic governance is an architecture for controlling AI systems in which the authority to permit or block an action is held by a deterministic validator, not by the probabilistic model that proposes the action. Given identical system state and an identical proposed action, the validator always returns an identical verdict — accept or reject — independent of the model's sampling, temperature, or reasoning path.
As AI systems move from producing outputs to taking actions inside regulated workflows — booking trades, releasing payments, onboarding suppliers, moving clinical records — the prevailing governance question, how do we make the model safer?, becomes the wrong one. A probabilistic system has a non-zero error rate by construction and therefore cannot supply the deterministic guarantee that regulated rules demand. We argue that meaningful control requires moving enforcement out of the probabilistic layer entirely. Under deterministic governance, reasoning is structurally separated from authority: the model proposes freely, while a deterministic validator decides, and the rule set the validator enforces is captured as a formal specification proven internally consistent before any code is generated from it. Each verdict is reproducible bit-for-bit from recorded state and committed to a tamper-evident log, so the question "would the same decision be reached again under identical conditions?" can be answered with proof rather than narrative. We set out the architecture (propose, decide, prove), the four properties that distinguish it from probabilistic guardrails, human-in-the-loop review, and post-hoc auditing, and its application to financial services, payments, healthcare, and procurement.
Probabilistic systems cannot make deterministic promises.
In any regulated system there are rules that must hold. Not usually. Not 99.9% of the time. Always. A model that is right almost all the time is still, by construction, wrong some of the time — and "some of the time" is exactly the case a supervisor will ask about the next morning.
Most governance frameworks were built for outputs: model cards, bias reviews, a human signing off on a recommendation. They were not built for actions, where a wrong step is a regulatory breach or a client harm. When AI takes the action, the governance layer has to sit upstream of execution, not downstream of it. A log is not a control; an audit trail reconstructed after the fact is not evidence. The guarantee has to be architectural. We make the full argument here.
02 — The architecturePropose, decide, prove.
Deterministic governance separates what the AI proposes from what the institution allows, and leaves evidence behind every allowed action.
The model reasons freely — that is what it is good at. A deterministic validator then evaluates each proposed action against the current state and returns one verdict. The rule set behind that verdict is not tested or reviewed into approximate correctness; it is a formal specification, proven internally consistent before a line of enforcement code exists. This is the role of Spec++ and the Compliance Operator.
03 — PropertiesWhat makes governance deterministic.
Determinism
Identical state and an identical proposed action yield an identical verdict. The decision is fixed by the inputs, not by sampling, temperature, or the path the model took to get there.
Provability
The rule set the validator enforces is captured as a formal specification and proven internally consistent — for example via SAT/SMT checking — before code is generated from it. Theorems, not promises.
Reproducibility
Every verdict can be reconstructed bit-for-bit from recorded state. The question "would the same decision be reached again under identical conditions?" has a literal answer.
Tamper-evidence
Each verdict, and the state it was made against, is committed to a hash-chained log that can be verified independently — producing examination-ready evidence rather than post-hoc narrative.
What deterministic governance is not.
- ≠Guardrails or safety filters. These are usually themselves probabilistic — another model that is right most of the time. Deterministic governance removes enforcement from the probabilistic layer entirely.
- ≠Human-in-the-loop. A person approving a proposal they did not generate, against data they cannot fully process in the time given, is a ceremony, not a control. Humans steward the specification; the validator checks every action.
- ≠Post-hoc auditing. Reconstructing a story from chat logs after an incident is not evidence. The verdict and its justification exist at the moment of decision.
- ≠Explainability. An explanation describes what a model probably did. Deterministic governance establishes what the system was permitted to do, and proves it.
Where it sits relative to formal methods.
Deterministic governance is where formal methods meet AI operation. Formal verification establishes that a specification is sound; the deterministic validator then enforces that specification at runtime, decision by decision. The term is emerging across the field — in work on reproducibility as an epistemic commitment, and on deterministic enforcement boundaries for autonomous systems — and Riley Betts' contribution is the architecture that makes it shippable in regulated production: a proven specification, a deterministic validator, and cryptographic evidence. The deeper technical treatment lives in our research and Spec++ explainer.
06 — FAQCommon questions.
What is deterministic governance?
An architecture in which the authority to permit or block an AI action is held by a deterministic validator, not the probabilistic model that proposes the action. Identical state and an identical proposed action always produce an identical verdict — accept or reject — independent of the model's sampling or reasoning path.
How is it different from AI guardrails or safety filters?
Guardrails are usually probabilistic themselves — right most of the time. Deterministic governance moves enforcement out of the probabilistic layer, so the rule that must hold cannot drift, be talked around, or be wrong some fraction of the time.
Why can't a probabilistic model enforce its own rules?
Regulated rules must hold always, not 99.9% of the time. A probabilistic system has a non-zero error rate by construction, so it cannot supply a deterministic guarantee. The response is to separate reasoning from authority: let the model reason, but let a deterministic validator decide.
Is it the same as human-in-the-loop?
No. Human-in-the-loop asks a person to approve a proposal they did not generate against data they cannot fully process in time — a ceremony, not a control. Deterministic governance puts the guarantee in the architecture and has humans steward the specification instead.
How does it relate to formal verification?
The rule set the validator enforces is a formal specification, proven internally consistent (for example via SAT/SMT) before code is generated. Verification establishes soundness; the validator enforces it at runtime.
Where is it used?
Wherever AI takes consequential actions in regulated or high-stakes workflows: financial services, payments, healthcare, and procurement — domains where a wrong action is a breach and where someone can later ask which rule applied and whether it held.
Turn AI risk into an architectural property.
Start with a fixed-scope pilot on your highest-risk workflow: agents propose, a formally specified validator decides, and every consequential action can carry evidence you can show a regulator or the board.