← Back to News

Determinism in the age of AI

Perspective

Determinism in the age of AI

AI for the business functions where a probable answer is not an answer

Herman Weintraub, CEO  ·  September 2026

TL;DR

Large language models produce the most plausible answer. In a quarterly close, an audit, or a filing to a regulator, plausible is not a standard. The fix is not a stronger model but a division of labor – the model translates the question, the database calculates the answer, and a person reads the query in between. That is how Exponam Analyst Intelligence is built.

A number in a quarterly close must be right. An audit result; a reconciliation; an analysis to a regulator; a computation of clinical trial data – these can never include “probably.” A result that is correct 98 times in 100 is not a result. It is an uncertainty that someone must verify or risk non-compliance, criminal liability, or worse. The very work with which AI is tasked has become a liability.

This is the state of AI today in enterprise data. The problem isn’t model strength. It is that large language models produce the most plausible next token. For many functions, plausible is enough. For the work of the analyst – it is not.

A fifty-year-old problem


The difficulty of connecting non-technical people with their own data is older than most practitioners today. Ted Codd, inventor of the relational model, published a paper in 1974 on the “casual user” and the barriers between that person and the database. The problem has two halves, reliability and access. SQL resolved the reliability half. A query does what it says, does the same thing every time, and can be read by anyone who knows the language. Access remained a problem. Most people who need data cannot write SQL.

Subsequent decades have brought successive solutions for access. Query builders, reporting tools, cubes, BI platforms, dashboards, and semantic layers each moved the boundary, and each imposed a cost – a modeling team, a backlog, a definition of the business fixed by whoever built the layer. The analyst in Excel has spent fifty years waiting for someone else to intermediate and provide a result.

Enter the chat-style AI. For the first time, an analyst can ask a question in her own words and receive an answer. We’ve finally resolved the issue of access. Except, we’ve re-introduced reliability uncertainty.

Wrong without warning


On academic benchmarks, natural-language-to-SQL systems report execution accuracy in the high eighties and low nineties. Work published at EDBT 2026 puts the state of the art on realistic sets in the high seventies to low eighties. Public-benchmark success rests on models having seen public schemas in training; private enterprise schemas defeat them.

The rate is not the problem. The silence is. A wrong query that fails to run gets caught. A wrong query that runs and returns a plausible number does not. That is why the argument does not soften when a vendor reports 95 percent, or 98. A step that is silently wrong one time in fifty is a control failure the user cannot see.

Prompting does not fix this. Temperature zero does not make a model deterministic, and it does not make wrong queries right; it makes the same wrong query more likely to return next time. And a wrong query will always return a wrong answer.

The rate is not the problem. The silence is.

A category error, not an engineering shortfall


A body of research known as neurosymbolic AI – neural networks for learning and language, symbolic systems for logic and calculation – argues for neural components where language is the job and symbolic components where soundness is the job. Handing deterministic work to a probabilistic system produces failures that are not bugs but design consequences. Neither a better prompt nor a stronger model removes them. It is a category error. A deterministic step must execute exactly as specified. A probabilistic step interprets that which was never fully specified. Translating an English sentence into a question about data is the latter. Running that question against a database, the former. The two should not be performed by the same component.

The model translates. The database calculates. And because the artifact is a query rather than a chat turn, a person can read it, keep it, rerun it, and audit it.

What it looks like built


This is the architecture of Exponam Analyst Intelligence. It is a spectrum, not a feature.

At one end is natural-language query. The analyst asks in plain English. The model does one bounded thing: it writes SQL. The SQL, with a plain-language explanation, appears in a scratchpad before it runs. She reads it, adjusts it if needed, and runs it on her firm’s Databricks or Snowflake engine under her firm’s access controls. Every number that lands in the workbook is tied to a visible query that reproduces it on demand. The translation step is probabilistic, and it can still err. What changes is that the error is an artifact on the screen rather than a number in a cell. A person can catch it – in the SQL or in the explanation – and the catch is a routine edit rather than a forensic exercise.

Mid-spectrum is direct SQL with administrator-curated shared workspaces. There is no model in this path. A data administrator writes and validates the queries upon which the business relies – the revenue-by-segment definition, the intercompany extract, the cohort – and publishes them to a shared workspace. Analysts run them. The same SQL runs on the same engine and returns the same result, for everyone, until the administrator changes it. This is, functionally, a lightweight semantic layer. dbt Labs’ April 2026 benchmark found that for questions a well-modeled governed layer covers, accuracy approaches 100 percent, because the query is generated deterministically. In a curated workspace there is no model at all. The accountable party is a named person with a reviewable artifact. That is what an auditor means by a control.

At the far end of the spectrum is the visual data builder over Delta Sharing. Point, click, filter, import. No model, no SQL, no SQL engine, and no platform compute. The builder is available on Databricks. There is no probabilistic surface because there is nothing to translate; the analyst is selecting rows, not describing them.

The three paths run in one add-in under one governance posture, and the analyst chooses along the spectrum by what the task can tolerate. Exploratory work goes to natural language. The number that goes in the filing goes to a curated query. The routine pull goes to the builder.

The probabilistic step itself can be kept inside the firm’s perimeter. Exponam runs the translation on a local model, and nothing – question, schema, or tokens – leaves the network. Or it runs on a commercial model the firm has already contracted, which receives schema metadata and never a row. For regulated firms, the one non-deterministic component in the stack is also the one that runs entirely within the firm’s tenant.

The model translates. The database calculates.

Still room to fail


The architecture makes translation errors inspectable and correctable. It cannot eliminate them. An analyst who runs a natural-language query without reading the SQL or its explanation has only the reliability of the model.

A division of labor, not a dial


The industry treats usability and reliability in data access as a dial, with SQL at one end and chat at the other. The literature of the last three years and the Exponam product say something different. The intersection of the two is not a compromise point on a line. It is a division of labor: the AI model does the part it is good at, the database does the part it is good at, and a person sits at the seam with the query in front of her.

For business functions where a probable answer is not an answer, that is what determinism in the age of AI looks like. And it is what we built.

Leave a Reply