Why Deterministic Computation Matters in AI-Mediated Decisions

01

Two different requirements

Language models are genuinely useful for a class of tasks that institutional decision-making is full of: interpretation, extraction, classification, synthesis, proposing options, and identifying where a document is ambiguous.

Those tasks share a property. None of them has a single correct answer, and a competent human would produce a somewhat different output each time without being wrong.

A calculation with a defined correct result is a different kind of task. A discounted cash flow, a covenant test, a debt service coverage ratio, a capital charge: each has a specification, and the specification determines the answer. Being approximately right is not a lesser version of being right. It is a different outcome.

The difficulty is that a model will attempt both with the same fluency, and its output carries no reliable signal about which of the two it has just done.

There is direct evidence that the second case is not merely theoretical. Dziri et al. evaluated transformer models on compositional tasks including multi-digit multiplication, and found accuracy degrading sharply as the required computation graph grew; GPT-4 reached 59% on three-digit by three-digit multiplication. Their interpretation is that models reduce multi-step reasoning to matching against computation patterns seen during training rather than executing the procedure.

The argument here does not rest on that particular gap staying open. It may well close. The result illustrates a broader engineering problem: fluent model output does not itself guarantee faithful execution of a specified procedure, and the output carries no signal indicating whether it did. Where a procedure defines an authoritative result, handing execution to a deterministic runtime provides a stronger control boundary than trusting that a capable model followed the procedure correctly this time.

That division of labour already has an established form in the literature. Program-aided approaches have the model read the problem and emit a program, then hand execution to an interpreter. The model interprets; the runtime computes.

02

Reproducibility

For a material calculation, the requirement is stronger than accuracy. It is reproducibility: the same inputs, the same model definition and the same version should produce the same result, on any run, for any party.

The computing research community formalised this vocabulary for related reasons. ACM's artifact badging distinguishes repeatability (the same team, the same setup), reproducibility (a different team, using the author's own artefacts) and replicability (a different team, a different implementation). Institutional decisions need at least the middle case: a reviewer, an auditor or a counterparty must be able to obtain the same figure from the same stated inputs, without depending on the original author's machine or the original author's session.

Reproducibility is what makes six things possible.

Review

a reviewer can check a number rather than a narrative about a number.

Validation

an automated rule can test the result, because the result is stable.

Audit

a figure can be reproduced years later from the recorded inputs and the recorded version.

Dispute resolution

two parties can agree on what the model says before arguing about whether the model is right.

Model comparison

a change in output can be attributed to a change in inputs or a change in the model, because only one of them moved.

Reconstruction

a decision record can carry a calculation by reference — inputs plus version — rather than by transcription.

Probabilistic generation supports none of these reliably on its own. Even with sampling disabled, model output is not guaranteed to be stable across serving infrastructure, batching or version updates, and production model versions and serving environments may change on timescales far shorter than the life of an institutional decision.

03

Interpretation versus execution

The distinction we propose is not that AI is unreliable. It is a division of responsibility between two things that are good at different jobs.

In each pair the model does what it is good at — reading, proposing, explaining — and the deterministic runtime does the thing that has a defined correct answer. What matters is that the boundary is enforced by the software rather than observed by convention. A model asked for a number will produce one.

04

A proposed control boundary

Inversiq's working position is a four-part boundary.

AI interprets and orchestrates

it reads, assembles context, proposes and explains.

Deterministic software calculates

versioned, typed execution produces every material figure and every validation result.

Governance controls

policy, review state and thresholds decide what may become authoritative.

Humans retain authority

named people approve, and any autonomy is delegated by them and bounded by policy.

We put this forward as one architecture that satisfies the requirements in sections 01 and 02, not as the only one. There are reasonable alternatives: a model that emits a verified program for each calculation, formal verification of generated code, or explicit statistical bounds on acceptable deviation. We have not shown that this partition outperforms them, and this note makes no such claim. What we do argue is that some boundary is required, and that leaving it to prompt design leaves it undefined.

One property of this particular boundary is worth stating. It does not loosen as models improve. A more capable model interprets more, proposes better and explains more clearly. None of those improvements changes whether the official number should come from a versioned calculation.

05

A worked example

A lease contains a break option with a notice period and an indexed rent step. Four steps, in order.

1. 01

   Interpretation

   an AI component reads the clause and proposes structured data: option type, exercise window, notice requirement, index, step date, floor and cap.

2. 02

   Validation

   a rule checks the proposal for internal consistency and completeness, and a reviewer confirms or corrects the interpretation. Both the proposal and the correction are recorded.

3. 03

   Computation

   a versioned financial model takes the confirmed structure as input and calculates the cash-flow consequence: the effect on net operating income, on the exit assumption, and on the return.

4. 04

   Record

   the model's inputs, version and output become part of the decision state, alongside the provenance of the clause and the identity of the reviewer.

The AI never produced a number that mattered. It produced an interpretation, which a human confirmed, which a deterministic model consumed.

The structure generalises beyond real estate because the joints recur: an ambiguous source document, a structured interpretation that benefits from human confirmation, a calculation with a defined answer, and a record that has to survive longer than any of the systems involved. A clinical protocol, a procurement scoring rule and a covenant test share that shape.

06

Open research questions

The boundary above raises more questions than it settles.

1. 01

   Which calculations require strict determinism?

   Materiality is the obvious criterion. It may not be the right one — contestability and reversibility plausibly matter more.

2. 02

   Where is probabilistic computation acceptable?

   Ranking, prioritisation and triage arguably do not need determinism at all. Where exactly does that stop?

3. 03

   How should uncertainty in extracted inputs propagate?

   A deterministic model given an uncertain input returns a precise answer to an imprecise question. What should such a model receive, and what should it return?

4. 04

   How should model versioning interact with decision records?

   A calculation engine will change. What obligation does that create toward decisions already taken under a previous version?

5. 05

   Can agents select tools without becoming the source of the calculation?

   Tool selection is itself a probabilistic act with material consequences. What constrains it, and what records it?