Deterministic Execution

After this lesson, the reader should understand:

• 01State the conditions required for deterministic evaluation.
• 02Identify sources of non-determinism in a governance pipeline.
• 03Distinguish a deterministic artifact from a probabilistic model.

The model that changed its mind

A language model applied the same policy to the same case twice and produced different outcomes. Where is the failure?

Not in the model — models are probabilistic by construction. The failure is architectural: the authority was carried inside the model instead of inside an artifact the model calls. When the artifact evaluates and the model only assists with fact extraction and presentation, the outcome becomes reproducible while the model remains useful for the parts that do not require determinism. Removing the model does not make a pipeline deterministic by itself; rule engines have quieter sources of variance of their own. Take two rules that both match a case, under a 'first match wins' policy, stored in a structure whose iteration order is not guaranteed — the same artifact can then return different verdicts on two runtimes, or after an upgrade. Take an implicit clock: a rule that reads 'now' instead of a recorded decision time gives a different answer on replay^[1]. Take floating point: 0.1 + 0.2 is not exactly 0.3 in binary arithmetic^[2], so a threshold test at the boundary can flip between languages. Take locale: string comparison and case-folding differ across environments, so 'İstanbul' may or may not equal 'istanbul'. Each of these is invisible in testing and decisive in a dispute. Determinism has to be specified^[3] — an evaluation order, a recorded timestamp, exact decimal arithmetic for money, a fixed collation — not assumed. The strongest objection is that determinism is impossible in principle once facts come from live systems: the credit bureau, the sanctions list, the payroll record all change, so the 'same case' never recurs. The objection confuses the evaluation with its inputs. Determinism is claimed of a function — this artifact applied to these recorded facts yields this outcome — not of the world. When the bureau's record changes, that is a new fact, and a new evaluation. What the architecture must guarantee is that the facts actually used are recorded with their provenance, so that the evaluation can be replayed against exactly what it saw rather than against what the source says today. Two limits close the argument. Determinism is not correctness: a deterministic artifact that encodes a rule wrongly is reliably wrong. And determinism across runtimes — 'any conforming runtime, today and years from now' — needs more than careful code; it needs a shared conformance suite of test vectors that independent implementations must reproduce. The reference implementation pins its own core this way, with a test requiring identical output across runs and rule identifiers derived from content rather than generated at random^[4]. Agreement between different implementations is a stronger property, and it can only be demonstrated once a second implementation exists.

• Where should a model sit relative to the authority layer?
• Is determinism achievable when facts arrive from external systems?
• What tolerance, if any, is acceptable in a governance outcome?
• Should money ever be compared as a floating-point number inside an authority artifact?
• What would two independent runtimes have to share before you would trust them to agree on every case?

No responses yet. Be the first to answer one of the questions above.

Audit one automated decision path for non-determinism.

1. 01List every input, including implicit ones such as time.
2. 02Mark any input that can change between runs.
3. 03Mark any step whose output is not a function of its inputs.
4. 04Propose how to fix or record each source of variance.
5. 05Check how the evaluator resolves two matching rules, and whether that order is specified or incidental.