a generated answer can be articulate, detailed, and completely wrong. when that answer becomes a diagnosis, a financial figure, or a legal conclusion, the quality of the writing is a poor measure of the quality of the decision.
this is why i care about deterministic intelligence in business: auditability. whether a result is right or wrong, i want to be able to reconstruct how the system produced it. which data went in? which transformation was applied? which version of the model ran? which rule turned its output into a decision?
how right or wrong a learned result is starts with how you train the model. the data, labels, fitting method, and objective all matter. testing it on unseen cases tells you whether that learning holds up. determinism gives you a way to reproduce the computation and investigate the result.
an impressive demonstration does not establish that a system works on the next patient, the next accounting period, or the next jurisdiction. a business needs to understand the inputs, the computation, the uncertainty, and the conditions under which the system fails. it also needs someone accountable for what happens next.
llms have useful roles in that process. but the ability to produce a convincing explanation should never, by itself, grant a model authority over a consequential decision.
the first distinction is between repeatability and correctness. a deterministic computation returns the same result when its inputs and relevant execution conditions are fixed. for a predictive model, we might write:
here, $x$ is the input, $\theta$ is the fitted model, and $v$ represents the versioned preprocessing, configuration, and execution environment. reproducing a result requires preserving those conditions. reproducing the fitting process also requires controlling the training data, splits, randomness, and numerical operations.
that matters when someone challenges a decision six months later. you need the input snapshot or a governed reference to it, the preprocessing and model versions, the configuration, the actual output, and the decision record. those records must be retained under the organization's access, privacy, and retention controls.
determinism makes that audit trail more useful because replaying the computation can check the recorded result. it does not create the records automatically or make an opaque model intrinsically explainable. even a stochastic system can be audited from a sufficiently complete record; reproducibility adds the ability to rerun the computation and compare it directly.
repeatability does not establish whether the answer was right. a rounding defect can produce the same incorrect invoice every time. a model trained on biased or unsuitable data can reproduce its mistakes perfectly. the advantage is that a team can investigate a stable result, examine the data and training choices behind it, and compare a corrected version against the original.
i want to know how the answer was produced, whether it holds up, and what needs to change when it doesn't.
ordinary multilayer perceptrons, or mlps, can have deterministic inference too. stochastic training does not make every subsequent prediction random. even an llm can use greedy decoding instead of sampling. whether an entire deployment is reproducible depends on its implementation and operating conditions; a temperature setting alone does not establish that contract. pytorch's reproducibility guidance explains the platform and implementation limits, while hugging face's decoding documentation distinguishes greedy selection from sampling.
the business requirement is therefore broader than determinism: a reproducible computation, evidence that it performs its intended task, and controls over how its output is used.
language generation adds a different failure mode. an llm can produce false statements, unsupported reasoning, and citations that appear to justify an incorrect answer. a confident explanation can make an error harder for a reader to notice. nist identifies this behavior as confabulation and specifically describes its risks in consequential decision making. nist's generative ai risk profile.
retrieval, tool use, and output validation can improve a system substantially. they still need evaluation as a complete workflow. retrieving the right document does not guarantee that the generated explanation preserves its qualifications. calling a calculator does not guarantee that the model selected the correct inputs or accounting rule.
this is why i separate the result from the prose used to explain it. the recorded computation and supporting evidence should remain authoritative even if an llm helps someone understand them.
healthcare makes the consequences immediate. an ekg, also called an ecg, is a measured physiological signal. a proposed diagnostic workflow has to handle signal quality, missing information, patient context, and the cost of different errors. a missed finding and an unnecessary escalation do not have interchangeable consequences. a plausible paragraph about a waveform establishes none of those properties.
the same issue applies when a customer-facing chatbot receives a description of symptoms. the person may omit relevant history, describe something ambiguously, or misunderstand a follow-up question. a general-purpose llm's answer is not sufficient evidence to diagnose that person or reassure them that nothing serious is happening. i would require validation for the specific clinical use, defined escalation behavior, and appropriate clinical oversight before relying on such a workflow.
this does not mean that ai cannot assist with ecg interpretation. task-specific medical ai already exists. the fda describes clearances of two ai-enabled ecg software functions supported by validation using records from multiple clinical sites. that is evidence about particular devices and their intended uses, not a blanket endorsement of chatbot diagnosis. fda: real-world evidence in medical device decisions.
the standard should attach to the clinical task and the deployed system. that applies whether the model is an llm, an mlp, or acuity.
finance exposes another distinction: calculating a result and predicting an outcome are different jobs. an invoice total should come from the relevant records, explicit arithmetic, and the applicable rounding rules. reconciliation should identify what matched, what did not, and which source records support that conclusion. these are often ordinary software problems.
a forecast is different. future demand, credit losses, and market returns involve uncertainty. a deterministic forecasting model can make a repeatable prediction that turns out to be wrong. it needs validation that reflects how it will be used, including time-aware evaluation where appropriate, meaningful baselines, and monitoring as conditions change. a model's explanation cannot substitute for that evidence.
financial audits add a further requirement: conclusions have to be supported by evidence and the relevant audit procedures. an llm-generated explanation of why an account looks reasonable is not, by itself, audit evidence for that balance. document search, extraction, and drafting may assist the work; responsibility for the conclusion stays with the audit process and its accountable professionals. the pcaob's staff observations on generative ai in audits describe both potential applications and the need to address reliability, supervision, and verification.
regulators do not treat generative ai as an exemption from existing responsibilities. finra's notice 24-09 identifies potential uses while reminding member firms that their obligations still apply. for traditional quantitative and non-generative models, the federal reserve's 2026 model risk guidance emphasizes validation, monitoring, and limitations. that guidance expressly excludes generative and agentic ai from its scope; it should not be presented as an llm approval standard.
legal analysis presents a similar problem with a different kind of evidence. a citation has to exist, support the proposition, and apply to the actual matter. jurisdiction, dates, procedural posture, and subsequent developments can change the answer. fluent legal language does not establish any of them.
an llm can help locate material, summarize it, or draft an argument for review. treating its output as a final legal conclusion without checking the underlying authorities is a much larger step. the american bar association's formal opinion 512 discusses accuracy review, competence, confidentiality, and supervision when lawyers use generative ai. the applicable duties remain the lawyer's responsibility.
an mlp is not a universal substitute for that work either. a model that classifies documents or estimates a defined outcome has a narrower task than interpreting law and advising a client. those boundaries matter just as much when evaluating a new architecture.
many business problems do not require language generation in the first place. organizations need to reconcile records, apply eligibility rules, classify transactions, forecast workloads, and detect unusual patterns. adding a conversational interface does not change the underlying computational task.
for structured prediction, a well-designed mlp is a serious option. so are linear models, boosted trees, and other task-specific methods. for some problems, the strongest starting point is a database query or an explicit rule. i want a team to establish those baselines before accepting the complexity of a large generative system.
there is research worth looking at here. realmlp reports competitive classification and regression results on tabular benchmarks. the newer tabarena benchmark shows how much model rankings depend on data, validation, tuning budgets, and ensembling. there are credible alternatives to evaluate before reaching for an llm.
my starting points would look like this:
| business task | starting point to evaluate |
|---|---|
| invoice totals and reconciliation | versioned arithmetic, database operations, and explicit rules |
| structured classification or scoring | linear models, trees, an mlp, or another bounded predictive model |
| demand or loss forecasting | an evaluated forecasting model with uncertainty and monitoring |
| ecg analysis | a clinically validated signal-analysis workflow for a defined use |
| legal research and drafting | authoritative sources, retrieval tools, and qualified review |
| explaining an established result | an optional llm grounded in the recorded result and evidence |
these are starting points for evaluation, not automatic deployment decisions. the least complicated approach that meets the actual requirements deserves serious consideration.
that thinking is behind acuity. i'm building it as an alternative to conventional mlps for structured supervised learning, with deterministic behavior as a design priority. the objective is to learn the relationship between defined inputs and a target, and make the quality of that learned relationship something a user can examine. the benefit i am pursuing is an auditable learning process: a result whose inputs, model, evaluation, and execution can be tied together.
the current public demo fits each uploaded dataset afresh and supports both regression and classification. it exposes held-out performance and a shuffled-target control, with split-conformal prediction intervals for regression. the v0.0.6 release notes describe deterministic routing through the adaptive learning pipeline. these are concrete capabilities and design choices that can be examined, rather than inferred from the fluency of an answer.
each piece of evidence answers a different question. held-out evaluation measures performance on observations excluded from fitting. a shuffled-target control challenges whether the reported performance reflects a learnable relationship. neither, on its own, proves that the data is representative, that every form of leakage has been excluded, or that a model will remain reliable after deployment. if model selection uses validation results, a separate untouched evaluation is still needed to estimate final performance honestly.
regression intervals also have a precise interpretation. a nominal 90% split-conformal interval targets coverage across future observations under the method's assumptions, including the relevant exchangeability conditions. it does not promise that every individual case has a 90% guarantee, that every subgroup has that coverage, or that coverage survives arbitrary distribution shift. those intervals are not classification confidence guarantees. angelopoulos and bates: an introduction to conformal prediction.
deterministic routing is likewise one part of reproducibility. a complete claim has to cover preprocessing, fitting, prediction, versioning, and the supported execution environment. the public demo discards uploads and fitted models after responding; a production audit workflow would need an explicit, governed retention and replay design. a results dossier is useful evidence, but it is not automatically the complete audit record.
replacing an mlp also has to earn its place in a comparison: predictive quality, calibration, latency, memory, stability, and operating cost on representative data under comparable conditions.
this is why i'm interested in healthcare, fintech, and legal technology. these markets need reproducibility, measurable performance, and accountability. acuity has to earn its place through evidence for the specific task, including clinical validation or other applicable requirements. auditability is a reason to pursue that work. accuracy is something we have to demonstrate.
the architecture i want businesses to evaluate puts those responsibilities in explicit places. this diagram shows where the result, its records, and the review belong:
flowchart TD
a["business request"] --> b["validated inputs and defined task"]
b --> c["versioned rules or validated predictive model"]
c --> d["recorded result, uncertainty and evidence"]
d --> e["policy checks and required human review"]
d -. "optional" .-> g["llm explanation grounded in the evidence"]
g --> e
e --> f["authorized business action"]
the language layer can make a system easier to use. the computational layer must still establish the result, and the review process must establish whether acting on it is appropriate. an explanation should remain traceable to the evidence it describes.
i use llms, and i see real value in them. i also want businesses to stop treating a convincing answer as the end of an engineering process.
when an answer has consequences, i want more than a prediction. i want a record that lets a team reproduce it, evaluate it, challenge the data and training behind it, and establish who authorized its use. those are the questions i want acuity and every system i build to withstand.