Deterministic AI vs. Generative AI Execution

Blog 3 of 7, The Enterprise Modernization Control Series: AI, Mainframes, and the New Standard for Production-Proven Transformation

Two blogs ago, we argued that AI has outrun the industry’s ability to prove its own output; modernization has become an evidence problem before it is a code problem. Last week, we showed how quickly “AI-powered” tooling thins out once you leave COBOL for Assembler, PL/I, Easytrieve, JCL, IMS, Db2, and GCOS 8.

This week, we go after the assumption underneath both of those arguments: that generative AI, on its own, is the modernization engine for the mission-critical transformations. It is not. The distinction enterprises need to internalize, before the next wave of AI modernization commitments gets signed, is the difference between AI-assisted generation and deterministic execution.

Two definitions matter:

• Generative AI produces output probabilistically. It samples from a distribution of plausible answers, which is precisely what makes it powerful for exploration, explanation, and acceleration and at the same time makes its output variable.
• Deterministic execution means the production transformation runs through a versioned, rules-based engine: the same input produces the same output every time, every rule that fired can be inspected, and the run itself generates the evidence.

Neither replaces the other. The argument of this blog is about where each belongs: generative AI belongs in acceleration; deterministic execution belongs in the production path.

Generative AI is genuinely useful. It is not, on its own, a certifiable production standard.

Generative models are excellent at explaining legacy code, summarizing business rules, scaffolding a first-pass conversion, and compressing discovery work that used to take analysts weeks into days. None of that is in dispute. What is in dispute is whether the same technology, used the same way, is fit to sit inside the production path of a mission-critical modernization; the place where a core banking ledger, a claims system, or a national payments switch is being replaced and every behavior of the new system must be explainable and reproducible on demand.

For assistance, variability is a feature. For production transformation, variability is the risk itself.

If an AI-generated transformation produces an incorrect interest calculation, claim outcome, payment rule, or batch-processing result, the issue is not simply whether the code compiles. The issue is whether the organization can explain why the behavior occurred, prove the scope of impact, and demonstrate that remediation has been applied consistently across the estate.

The obvious rebuttal is worth taking seriously: set the temperature to zero, pin the model version, seed the inference, and the output becomes reproducible. True, and insufficient. Reproducibility is not correctness, and it is not explainability. A pinned model that produces a wrong translation produces the same wrong translation every time. When that happens, there is no transformation rule to inspect, no versioned artifact to correct, and no systematic way to guarantee that the fix holds across ten million lines of code.

Pinning freezes behavior. It does not explain it.

Enterprises modernizing mission-critical systems are already running into three forms of generative variability:

• Prompt drift. Small changes in how a request is phrased produce materially different transformation output.
• Model-version drift. The same prompt, against an updated version of the same model, can produce a different result. Version pinning may defer this problem, but it does not eliminate it. Pinned models eventually age, vendors update platforms, and forced upgrades reopen prior assumptions.
• Cross-model drift. Swapping the underlying model, a routine event in a fast-moving AI market, can change the output again, often with no built-in explanation of why.

Any one of these is manageable in an assistant use case because a human is reading the output and applying judgment. None of them is acceptable when the output is production logic replacing a COBOL routine that has been settling transactions correctly for decades. If a regulator, an auditor, or your own change-control board asks why the modernized system behaves the way it does, “the model generated it” is not an answer that survives the conversation.

To be precise: no regulator mandates deterministic code generation. Regulations and Frameworks (like the EU’s Digital Operational Resilience Act require something more practical: traceability, testing evidence, accountable change control and demonstrable operational resilience from financial entities and their critical technology providers. Human developers are not deterministic either, and their work passes audits every day, because change control wraps it in an evidence trail.

The problem is scale. Human-speed change control cannot wrap machine-speed transformation. When an engine is converting millions of lines of code, the only way to produce audit-grade evidence at the same speed is for the pipeline itself to generate it. A deterministic engine turns the question; “why does the modernized system behave this way”, into a lookup: this rule, this version, this input, this approval.

A generative-only engine turns the same question into a research project. Determinism is not the regulatory requirement. It is the only economically scalable way to meet the requirement.

Part of the gap is simply training data. General-purpose LLMs are trained overwhelmingly on public code, public documentation, and public discussion, which is one reason COBOL, the most widely taught and discussed legacy language, is the language every AI modernization demo features.

Coverage falls off fast in Assembler, PL/I, Easytrieve, Telon, and the other platform-specific dialects that were never meaningfully public in the first place.

A model trained on public repositories has no exposure to a bank’s specific copybooks, an insurer’s proprietary rating engine, or the operational quirks baked into decades of undocumented production changes. Domain-specific, production-trained models can close much of that gap by improving upon comprehension, classification, business-rule extraction, code mapping, and first-pass transformation. But even the best-trained model is still, structurally, a generative one.

The industry’s real unlock is not simply a better model. It is putting a deterministic execution layer around the model.

The pattern enterprise buyers should demand is simple: AI assists comprehension. Deterministic execution performs the transformation. Validation proves the result.

Generative AI should be used where variability is acceptable and human judgment is present (discovery, documentation, business-rule extraction, and first-draft transformation). The actual production execution should then move through deterministic pipelines that behave same way on every run, are fully traceable, and produce evidence as a byproduct of running rather than as a report assembled afterward.

That is a fundamentally different architecture from generation plus review, however sophisticated the review may be. It is the line that quietly separates a modernization tool from a modernization platform.

Here is the strongest objection to everything above, and it deserves a direct answer. If rigorous automated validation reconciles old-system and new-system behavior transaction by transaction until equivalence is proven, why does it matter how the code was generated? Would generative AI plus strong validation not be enough?

Validation is indeed the arbiter of correctness; nothing about determinism changes that. What determinism changes is what happens when validation fails, which at enterprise scale it always will. With a deterministic engine, a validation failure can be traced to a specific transformation rule. Fix the rule once, version it, regenerate, and every affected artifact is corrected identically. Validation cycles converge because the correction path is systematic.

With generative output, every failure risks becoming a bespoke artifact. Each fix may require manual interpretation. Each regeneration risks introducing new variance elsewhere. Validation then becomes a permanent whack-a-mole tax.

Validation proves the output. Determinism is what makes the proof converge instead of churn.

The same evidence logic applies to people. “We have human-in-the-loop” is one of the most overused claims in enterprise AI and one of the least specified. Engineered HITL means defined checkpoints, named approvers, recorded decisions, exception handling, and a pipeline that will not promote an artifact unless the approval trail is intact. Aspirational HITL means a human could look at the output if they wanted to.

From a vendor’s marketing page, the two seem to be indistinguishable, which is exactly why the evidence trail, not the promise, has to be the differentiator.

The pressure is not theoretical. Enterprise capital is rapidly flowing into AI-driven transformation and the expectation is no longer pilot-stage output. Buyers are looking for production-grade returns. The workloads in scope are the ones enterprises can least afford to get wrong: the mainframe estates that mission-critical core transaction processing, operational workflows and business-critical data movement. And regulations, such as DORA, have converted traceability from a best practice into a supervisory expectation.

This creates a difficult combination: Capital at scale, workloads that cannot fail, and regulators demanding proof rather than confidence. Generic generative AI, used alone, cannot meet that bar. It was never built to.

If a vendor claims production-grade AI modernization, these five questions separate architecture from marketing:

1. Repeatability: Run the same transformation twice on the same input. Is the output byte-identical? Show it, live.
2. Traceability: When transformed code is wrong, what is the fix path: a prompt adjustment, or a versioned change to an inspectable rule that corrects every affected artifact?
3. Model change control: What happens to in-flight and completed work when the underlying model version changes?
4. Approval evidence: Pick any artifact promoted to production. Show the complete approval trail: who reviewed it, when, and what they decided.
5. Validation evidence: Show validation evidence generated by the pipeline itself during the run, not a report assembled after the fact.

A platform built on deterministic execution can answer all five in minutes with evidence. A generation-first toolchain cannot even answer the first two, if at all.

AI vendors, hyperscalers, and GSIs can all generate modernization artifacts today; that capability is commoditizing by the quarter. The scarce asset is the deterministic production layer that takes AI acceleration and makes it certifiable, with the evidence to prove it.

This is the architecture mLogica built, deliberately, before it became fashionable.

LIBER*M executes mainframe transformation through a deterministic, rules-based engine: the same input produces the same output on every run, every rule that fired is inspectable, and when a correction is needed it is made once, versioned, and applied consistently across the entire estate.

STAR*M brings the same discipline to distributed database migration, and TRAK*M closes the loop with automated validation and post-cutover control that generates audit-grade evidence as a byproduct of the run itself. Generative AI accelerates the work; the deterministic pipeline certifies it.

Ask any vendor the five questions above.

We answer all five in the first meeting, live, because the platform was engineered that way.

Next in this series we go one layer deeper into the data tier, where many modernization programs quietly fail before the code layer ever gets the blame.

Interest trigger: Anyone can generate modernization artifacts. The scarce asset is the deterministic production layer that makes them provable.