Across sixteen code-generating models, 5.2% of package names suggested by commercial models and 21.7% of those from open-source models point at software that does not exist. Correcting a hallucinated dependency costs an afternoon. Proving to an assessor, six months later, which approved requirement the generated code was working from costs considerably more.
This article covers what deterministic AI actually guarantees, why temperature zero does not deliver it, and where the control point belongs: on the requirement text, before a model generates anything against it.
What Is Deterministic AI?
A deterministic AI system returns the same output every time it receives the same input because it uses fixed rules and does not sample from a probability distribution. Symbolic, rule-based systems are the clearest example: we write the rules and hard-code them into a static program, so a failure traces back to the rule and inference step that produced it. A machine learning model is a different artifact: it generates an inference from input data, and its outputs may shift after retraining, data drift, sampling variation, or model updates.
Safety-critical standards were built around software whose behavior a reviewer can predict and trace. The Federal Aviation Administration (FAA) recognizes DO-178C as a means of compliance for airborne software. At Level A, its most critical assurance level, DO-178C sets a Modified Condition/Decision Coverage (MC/DC) objective: each condition must be shown to independently affect the decision’s outcome. A neural network resists that kind of line-by-line analysis, which is where machine learning and conventional development assurance stop fitting together.
A practical safety architecture can address that mismatch with deterministic controls around the AI component. A non-AI-based monitor can mirror the safety requirements of the component it watches, while back-up and supervisor functions enforce constraints and limits.
Why Can’t You Just Set the Temperature to Zero?
Temperature zero and fixed seeds improve consistency. They do not guarantee identical outputs across application programming interface (API) calls. Removing intentional sampling leaves every other source of variation in the inference environment untouched.
Floating-point arithmetic is not associative, so (a+b)+c can differ from a+(b+c) after rounding. Parallel hardware changes the order in which operations accumulate as input sizes, workloads, and execution conditions change. The same logical operation therefore produces small numerical differences, and those can alter which token is selected next during greedy decoding. Precision format, hardware configuration, and batch size all affect model accuracy, response length, and output stability.
The size of that effect is easy to underestimate. Across ten runs of five models configured for deterministic output, accuracy on eight common tasks varied by up to 15%, and the gap between the best and worst possible performance reached 70%. Model behavior behind an API also changes over time, and that longitudinal drift is a separate problem from run-to-run variation.
For a program under audit, the variation itself is not the cost. The cost is that a reviewer asking why a generated artifact says what it says has no reproducible run to point at.
Separate Deterministic Controls From Consistency Settings
Techniques marketed as deterministic AI split into two groups: one locks down a named property, the other only narrows the spread of large language model (LLM) outputs. The table sorts them by what each controls.
| Comparison attribute | Fixed seed plus temperature 0 | Constrained or grammar-based decoding | Neuro-symbolic verification | Retrieval-Augmented Generation (RAG) | Rule-based guardrail validators |
|---|---|---|---|---|---|
| Deterministic? | No | Format only | Logic checks only | No | For checked properties |
| What is guaranteed | Best-effort consistency | Output cannot violate the schema | Consistency of the verified properties | Source-cited grounding | Outputs that pass the defined rules |
| What still varies | Outputs may change with the backend or batch | The content inside the schema | The LLM-to-logic translation can fail | References do not validate every generated claim | Upstream generation stays probabilistic |
LLM content remains nondeterministic. Constrained decoding controls format and cannot guarantee reasoning quality. Rule-based components can deterministically check defined output properties through a grammar, a formal solver in a neuro-symbolic architecture, or a validator.
Reproducibility and correctness are separate targets, and an AI use policy should say so. A repeatable output that names a package which does not exist is still wrong, and an invented package name becomes a software supply-chain risk the moment an attacker registers it. Stable output establishes that the system behaved the same way twice, and nothing about whether what it produced is true.
What Auditors Expect From AI-Generated Engineering Records
An audit-ready process lets a reviewer reconstruct what the system did: select an event, rebuild it from the records, and attribute every action to the engineer, service account, pipeline, or agent responsible. That rebuild is the test an AI governance process has to pass.
The rebuild test expands a conventional audit trail with fields for AI configuration and human accountability. Required fields include:
- Model and data version: A defensible AI interaction record carries data version, model version, decision parameters, decision logic, input, output, timestamp, operator ID, and any risk flags triggered. Together they identify the configuration and the evidence behind the interaction.
- Human reviewer identity: For attributable review, an AI output entering a regulated electronic record should carry a reviewer identifier and review timestamp. Reviewer fields distinguish generated content from the human decision to accept it.
- Change records: A model update, a new use case, or a change of data source is a change to the system. It belongs in the same documented change process with impact reassessment as any other baselined change, with both the approval and the reassessment on the record.
Failing that test is not a documentation problem. The program cannot show which requirements its AI-assisted work was built against, at the moment someone with authority over market access asks.
Specific legal obligations vary by jurisdiction, system classification, and application date. The AI Omnibus has been in force since 27 July 2026, moving the application date to 2 August 2028 for AI built into products already covered by European Union (EU) product safety law, and to 2 December 2027 for the other high-risk categories. Whichever date applies, the governance process needs event records, technical documentation, human oversight, and retained logs.
Where Deterministic Checks Belong in Requirements Engineering
Deterministic checks belong at authoring, on the requirement text, before any model is asked to generate against it. Requirements quality is structural, not a matter of taste. Requirements-writing frameworks define characteristics, rules, attributes, and sentence patterns for well-formed requirements, and forms like the ubiquitous “The [system] shall [action]” and the unwanted-behaviour “If [condition], then the [system] shall [action]” are checkable by machine. Natural Language Processing (NLP) turns those quality checks into repeatable work before probabilistic generation or trace-link suggestions enter the workflow.
Ambiguity is what that check catches. When a requirement can be read two ways, the verification method becomes a matter of opinion, and a test engineer who cannot derive a clear pass/fail condition cannot close the verification loop. Suppose a systems engineer writes “the system shall process data quickly” and moves on. Three months later a test engineer looking for a pass/fail threshold finds none, the hardware team has read it as 500 ms, and the software team has designed for 50 ms.
AI-generated code raises the same problem one layer down. A model implementing a feature makes dozens of unstated decisions about timeouts, retry behavior, fallback states, error handling, and input bounds. Safety-critical development processes require those derived requirements to be defined and assessed, so the ambiguity has to be settled before generation instead of surfacing at integration.
How Jama Connect Supports Deterministic AI in Regulated Development
Jama Connect® provides the foundation that is the Product Context Layer for our engineering programs. The platform connects requirements, risks, tests, Systems Modeling Language (SysML) models, code, simulations, approvals, verification evidence, and change history into a governed system of record. The Traceability Information Model (TIM) at its center defines how those artifacts relate to one another, and auto-detects when a required downstream item is missing.
Traceability and its suspect triggers surface drift, and Live Traceability™ is the name for that approach. When requirements are properly linked, a change to an upstream item flags every downstream artifact that traces to it as suspect and raises a notification, so the change can be assessed and acted on: the engineer updates the artifact or clears the flag.
Suspect triggers fire only along links that exist, and AI Relationship Discovery helps find the ones still missing: the engineer defines which relationship suggestions to receive, Jama Connect queries the product library for potential related items, and a link is created only when the engineer accepts the suggestion. Of the five techniques in the table above, the validator is the one traceability supplies at the artifact level. Constrained decoding, neuro-symbolic checking, RAG grounding, and fixed seed plus temperature 0 stay with the generating tool, none of which a requirements platform supplies or replaces.
Jama Connect is a web-based requirements management and traceability platform for complex, regulated product development, and it applies the authoring check through Jama Intelligence, an add-on for Jama Connect Cloud. Jama Intelligence scores requirement text against 30 of the 40 International Council on Systems Engineering (INCOSE) rules and 6 Easy Approach to Requirements Syntax (EARS) syntax patterns, and returns a quality score before saving. A requested rewrite appears alongside the original, and the engineer accepts, modifies, or rejects it, with both the original text and the revision kept in the audit trail.
The same acceptance gate governs generation. Jama Intelligence drafts test cases with steps from one requirement, drafts can be regenerated with additional prompting, and the trace link is created only when the engineer accepts a draft. Work done by AI inside Jama Connect is versioned and documented as AI-generated, so the record shows what was produced, against which requirement, and who accepted it. Suspect links mark linked test cases for reassessment when the requirement changes.
The Model Context Protocol (MCP) Server shipped on 4 May 2026 with Jama Connect 9.35 for Cloud and Self-Hosted deployments, giving AI agents controlled access to those governed specifications. Coding agents working under spec-driven development (SDD) treat the approved specifications in Jama Connect as the authoritative source for implementation plans, tasks, code, and tests, and the specification stays active through development as the traceable basis for reviewing each output. An agent can still generate different code from the same specification on two runs, and SDD gives both runs one fixed, approved reference to be checked against.
Putting Deterministic AI to Work Before the Next Audit
Deterministic AI is not a switch inside a model. It is a set of controls placed where the input is still text a person wrote and can still be corrected. A schema the output cannot violate, a solver that checks a claim, a validator on the artifact, and a requirement that says one thing rather than two.
If engineers are already pasting requirements into a chat window and the quality team has no record of what came back or who approved it, the review workflow is worth testing against a real project structure. A project-level evaluation shows whether generated drafts stay tied to approved requirements, reviewer decisions, and later changes. Request a Jama Connect AI demo and evaluate it there.
Frequently Asked Questions About Deterministic AI
How should we document an LLM’s configuration for an audit?
The configuration record should be paired with a baseline of the requirements, relationships, and verification evidence affected by the interaction, captured as a point-in-time snapshot for comparison and audit reference. Comparing that baseline with a later project state shows whether items or relationships were added, removed, or modified after the AI-assisted step.
What is the difference between deterministic AI and explainable AI?
Deterministic AI repeats the same output for the same input; explainable AI shows why an output was produced. A system can be deterministic without being easy to interpret, or explainable without producing identical outputs on every run. Regulated oversight may call for both predictable controls and enough information for a reviewer to interpret the result.
Does the EU AI Act treat every AI engineering tool as high-risk?
No. The relevant assessment considers the system’s intended purpose, function, and role in a regulated product. Tools used only for non-safety support functions are treated differently from AI whose failure could endanger health or safety.
How does ISO/PAS 8800 handle AI in road vehicles?
Jama Software® has a walkthrough for automotive teams covering how ISO/PAS 8800:2024 tailors or extends ISO 26262 and ISO 21448, the Safety of the Intended Functionality (SOTIF) standard, to reach AI and machine learning malfunctions. The standard devotes a full clause to data, covering the dataset lifecycle from safety analysis and requirements development through verification, validation, and maintenance.
