What is deterministic AI? Start with the execution boundary.

Draw the boundary first. Are you comparing generated text, approved business decisions or completed actions? A useful definition names the result and the context required to reproduce it.

What is a simple example of deterministic AI execution?

Consider a hypothetical invoice-routing rule. A validated invoice totals £80. The approved rule sends invoices of £100 or less to the routine queue and larger invoices to a reviewer. Holding the validated amount, rule version and starting state fixed gives the same routing decision each time. That illustrates a deterministic execution layer inside an AI-assisted workflow; the rule itself is ordinary software, and this example does not test a vendor.

Now separate four questions:

A repeatable rule can consistently process a misread amount. Fixing the rule does not validate AI extraction, and a queue decision does not authorize every later action. These are review distinctions illustrated by our example. PyTorch’s documentation makes the analogous computational boundary explicit: reproducibility depends on the platform, release and sources of nondeterminism controlled.

For an executed local example, inspect the companion-reference calculation: two fresh processes reproduced six files from pinned inputs. Its separate missing-target control checked correctness of reference handling. Neither result demonstrates repeatability of an AI model. Use the Checklist to retain the evidence and leave untested production controls visible.

What does the definition cover?

This is the working definition used by this reference. For a business process, specify whether “result” means an extracted field, calculation, decision, sequence of actions or final response. Also specify the state and versions included in “same input.”

Environment matters in real computation. PyTorch warns that complete reproducibility is not guaranteed across releases, individual commits or platforms, and that CPU and GPU results may differ even with identical seeds. Read PyTorch’s reproducibility guidance.

Which parts of an AI system can you evaluate separately?

Use these boundaries to make an evaluation claim precise:

• Interpretation. What to hold fixed: Input record, model, prompt and supplied context. What to compare: Extracted fields or classification.
• Calculation. What to hold fixed: Validated values, formula and rounding rules. What to compare: Numeric result.
• Workflow execution. What to hold fixed: Approved process version, initial state and external responses. What to compare: Decisions, action arguments and state transitions.
• Presentation. What to hold fixed: Verified result and formatting rules. What to compare: Final response or document.

This list is our recommended evaluation structure. Do not infer that a whole workflow is deterministic merely because one calculation is.

Does a probability estimate make execution nondeterministic?

No. Thinking Machines Lab separates sampling randomness from the numerical execution of inference. Our practical distinction is between a computation that represents uncertainty and one whose result varies across repeated runs. Read the explanation.

Illustrative example: a fixed computation always returning probabilities of 0.8 and 0.2 is repeatable, even though its output represents uncertainty. Sampling an outcome from those values is a separate operation. Neither fact alone establishes the repeatability of an entire business workflow.

Use the deterministic versus probabilistic AI comparison to separate prediction, selection, numerical execution and approved business rules.

Is temperature zero enough?

No. Thinking Machines Lab’s introduction distinguishes theoretically deterministic sampling at temperature zero from inference systems whose results can still vary in practice. PyTorch likewise documents limits to reproducibility across execution environments. Thinking Machines Lab · PyTorch.

Use the LLM determinism guide to define the conditions for your deployment.

How do correctness and auditability differ?

Under this site’s terminology, determinism concerns repeated execution, correctness concerns whether a result satisfies the task’s requirements, and auditability concerns evidence that lets someone reconstruct and examine what happened.

A hypothetical rule that always adds the wrong tax percentage is repeatable but wrong. A log that merely says “done” does not show which rule or input produced the outcome. These examples illustrate the distinctions; they are not claims about a named system.

Ask for separate evidence: repeated results, checked reference answers, and execution records. METR’s evaluation research reports models exploiting scoring systems instead of performing the intended task, reinforcing the need to inspect the work behind a success score. Read METR’s research.

How can AI interpretation fit with explicit execution?

In a proposed invoice process, AI extracts candidate fields; checks establish which fields the workflow accepts; explicit rules determine routing and calculations; a person resolves exceptions. To assess that design, ask where interpretation ends, what is approved for execution and what changes after human intervention.

The architecture needs both a defined boundary and evidence from the intended workload. Our companion reference explains hallucination prevention controls.

What should you request from a supplier?

Request a written scope, fixed input and version records, repeated uncached runs, expected results, exception examples and evidence of external actions. Use our testing guide and the short determinism definition.

How do you write a boundary someone can test?

Use a concrete claim before choosing a metric. For a hypothetical invoice process, the claim could be: “Given the same validated invoice fields, approved routing rules and starting state, the workflow produces the same routing decision and proposed action arguments.” Variable conversation or extraction upstream needs its own test. Completion of a payment needs a destination receipt.

Record software and rule versions, source data and external responses with the claim. PyTorch’s reproducibility guidance warns that matching seeds do not establish identical results across releases or platforms. This is why the execution conditions belong in the claim itself. PyTorch.

Our proposed review also includes a valid case, missing evidence and a request changed after approval. See the four-case boundary worksheet. Those cases are unexecuted designs; expected outcomes must be approved for the actual workflow. The Checklist download guide helps keep a blank plan separate from a filled example.

Reading scope

Relevant PyTorch, Thinking Machines Lab and METR primary text was reread on October 20, 2026 using direct retrieval after the research browser returned no body or only the indexed introduction. No model-runtime experiment or production failure-rate measurement was performed. The invoice boundary above is a teaching example.

What does a concrete repeatability claim look like?

Here is one scoped example: our frozen Register selection reruns a fixed Python script against a named snapshot and exact filter. Two fresh runs produced byte-identical exports containing 24 findings. The execution record names the input and code hashes, runtime, equality rule and failure controls. This establishes local file-selection behavior; it does not test AI inference, independent source truth or production authorization.

Use the Checklist to make equally bounded claims about your own system. For an AI runtime, retain hardware, library and algorithm choices as well. PyTorch’s guidance, re-read in full on October 17, warns that releases, platforms and CPU/GPU execution may differ even with identical seeds. This local example supplies no cross-platform guarantee.

Can identical totals hide a changed result?

Yes. In our local release-comparison test, deliberately changing one evidence label preserved the number of records but changed the record’s meaning. The comparator detected the exact field change. Reversing record order produced no field changes under the declared comparison rule. These synthetic checks illustrate why a repeatability claim needs an explicit result definition; comparing totals alone would miss a consequential difference. They do not evaluate an AI model.

What does an offline reproducibility check establish?

Our Register analysis pack supplies a concrete boundary: frozen input files, named Python calculations and exact output-byte comparisons. All 21 outputs matched in the October 22 local check. This establishes that those calculations reproduced those files in the tested environment. It does not establish repeatability of a language model or a live business workflow.

Use the same precision in a vendor review: name the component, the conditions held fixed and the result compared. PyTorch’s guidance documents limits across releases and platforms. Separately inspect correctness, source qualifications and action permissions with the Checklist handoff review.

Is choosing the same algorithm enough?

Algorithm selection and algorithm execution are different repeatability claims. PyTorch explains that disabling cuDNN convolution benchmarking makes algorithm selection deterministic, but the selected algorithm can still be nondeterministic unless the appropriate deterministic-execution control is enabled. The same seed does not replace either check. This is a documented framework distinction, not a performance test we ran. PyTorch reproducibility guidance.

For a review, state three separate conditions: which randomness sources are controlled, how the execution algorithm is selected, and whether that algorithm is deterministic in the tested environment. Record the release, device and configuration, then compare fresh executions using a declared result definition. If you only repeated a cached result, you have not exercised the computation again.

The same distinction applies to our date-window calculation: two fresh processes reproduced the same files, and separate boundary fixtures checked the intended selection rule. Neither result establishes that the underlying incident dates are historically correct. A year-only date can repeatedly match a calendar window while its source notes place the event earlier. Correctness requires reading that context.

Use the filled date-window review to see exactly which local properties were tested and which remain unresolved. For a business AI system, the comparable record needs its own inputs, execution conditions, expected decisions and evidence of completed actions. Our file calculation supplies no claim about a deployed model.

October 29 maintenance: full PyTorch guidance reread; its release/platform limits remain in force. No framework or model runtime was exercised in this update.

November 3 maintenance: primary PyTorch, Thinking Machines Lab and METR bodies reread. The invoice example is hypothetical; the linked file calculation is locally executed. Neither supplies a deployed AI-system guarantee.