Probabilistic and deterministic: where interpretation ends and decision begins

In short. A probabilistic system interprets an input and produces a plausible output, drawn from a distribution of possible answers. A deterministic system applies known rules and returns the same result on every run. Most projects that stall put the model where a rule belonged, or write rules where the input is too varied for any rule to cover it. The useful boundary runs like this: the probabilistic side interprets and proposes, the deterministic side computes and decides.

The distinction isn't academic. It changes how the architecture is designed, how quality is measured, what oversight costs and what can be demonstrated in an audit.

Two machines with different properties

Property	Deterministic	Probabilistic
Input	Structured, expected fields	Free text, documents, speech
Output	One, always the same	One among many plausible ones
Repeatability	Total	Partial, varies with version and parameters
Error	A defect in the rule, locatable	Statistical, reducible but never zero
Verification	Tests on known cases, run at each release	Continuous sampling of real outputs
Explanation	The rule itself	Indirect reconstruction, never complete
Marginal cost	Close to zero	Proportional to volume and length

The repeatability row weighs most in regulated organisations. A deterministic check run today and in six months on the same input returns the same outcome, which makes it possible to demonstrate how a decision was reached. A model updated by its provider can change behaviour without anyone touching your system.

Where the probabilistic side works well

The model fits when the input is varied and the mapping between input and answer cannot be written in advance. Three families of task recur across sectors.

Extraction from unstructured documents: reading a contract, a report, a supplier letter and pulling out fields a person would otherwise read by hand. Classification of requests in natural language, where the same intent arrives written a hundred different ways. Summarising and drafting, where the output is material a person reviews before use.

In all three the output is a proposal. Someone or something downstream decides whether to accept it, and that something is often a rule.

When the outcome has to be identical every time

When the result must be identical on every run, when it produces a direct legal or economic effect, when it has to be reconstructable years later.

Calculating an amount, a tax, a penalty. Applying an authorisation threshold. Verifying that a document contains the fields a regulation requires. Checking consistency between two systems. Assigning an entitlement or a benefit against written criteria.

A language model adding numbers can get them wrong, and the problem isn't the frequency of the error, it is that the error is unpredictable and the result can differ between two runs. No amount of instruction removes that property, because it follows from the way the system generates its answer.

The model interprets, the rule decides

The architecture that works in most enterprise cases puts the two worlds in sequence, model upstream and rules downstream.

Stage	Nature	Example on a document flow
Intake	Deterministic	The file arrives and is registered with an identifier
Interpretation	Probabilistic	The model extracts fields from the document
Validation	Deterministic	Formats, ranges, consistency with master data, totals recomputed
Enrichment	Deterministic	Reference data comes from internal systems, not from the model
Decision	Deterministic	Thresholds and authorisation rules
Exception	Human	Cases validation rejects go to a person

The enrichment row deserves a note. A model shouldn't remember a customer balance or an item's stock level, because that data lives in a system and changes hourly. The model extracts the item code, the system returns the current stock.

This separation has a direct effect on oversight cost. The probabilistic part needs continuous sampling, while the deterministic part is verified by a test suite running at each release, so moving as much logic as possible to the second side cuts the recurring workload.

Abstention as a design requirement

A model that always answers is dangerous inside an operational flow, because it produces an output even when the information isn't there.

The behaviour to specify at design time is different: below a confidence threshold the system stops and hands the case to a person. That means defining the threshold, measuring how many cases end in abstention and treating that number as a project indicator rather than a failure.

Handling sixty per cent of cases with a one per cent residual error beats ninety per cent with ten, because the second generates a correction load that eats the benefit and, in sensitive activities, a risk somebody will have to explain.

How each side is measured

The two parts need different instruments, and confusing them is a common mistake.

The deterministic side is measured by test coverage: how many rule conditions are covered by an automated test, and how often the suite passes. It is ordinary software engineering work.

The probabilistic side instead needs a labelled sample and three numbers: the share of correct outputs, the share of cases where the system abstained, and the share of errors caught by downstream validation. The last number is the most useful, because it says how much the rules are protecting the process from the model's mistakes.

One construction rule applies to that sample. It has to be refreshed when the mix of real cases changes, otherwise it measures a world that no longer exists, and it has to be stored with the model version used, because without that a comparison between two measurements means nothing.

What changes for documentation and audit

Where everything is deterministic, the system is described by its rules, and that description is also the explanation of its behaviour.

A system containing a model needs more: the model version and the date it changed, the system instructions in force, the abstention criteria, the evaluation results on the sample, the downstream controls, and the record of decisions taken. That package becomes mandatory when the system falls under Annex III of the AI Act, and stays useful when it doesn't, because it is the only way to answer a challenge months later.

One practical consequence is worth anticipating. The more logic sits on the deterministic side, the less documentation surface remains on the probabilistic one, which cuts both compliance cost and the time it takes to respond to an inspection.

The errors that recur

The first is putting the model at the decision point because the demo worked. An assistant proposing an amount is useful, an assistant approving it moves risk onto a component that doesn't guarantee the same outcome twice.

The second is using rules where the input is irreducible. A flow of natural-language requests isn't covered by a keyword taxonomy, and every attempt grows a tree of exceptions nobody maintains.

The third is not measuring the probabilistic part, relying on user impressions instead. Impressions move with the mood of the period and with recent cases, and they won't reveal whether a provider update shifted behaviour.

The fourth is letting the model serve as memory. Operational data has to come from the systems that hold it, and the model has to be treated as an interpreter of text rather than an archive.

Where to start

The framing on choosing where to start is in how to choose the first use case, while data preparation is covered in data readiness and data governance for AI.

On why a system reasons or guesses, and the role of knowledge structures, see ontologies and infrastructure.

For system classification, which changes how much documentation is required, see AI systems risk classification.

To work out which part of your processes belongs on rules and which on a model you can book an assessment session.