Why Domain Logic Should Run Before Generative AI

Generative AI becomes more useful when it is asked to explain rather than calculate. Many consumer applications combine facts that should be exact with language that can vary, from eligibility decisions and time conversions to financial totals and domain-specific charts. When one model is expected to infer the inputs, apply the rules, calculate the result, and explain it in a single prompt, a fluent answer can hide the source of an error. A cleaner architecture runs domain logic first and gives the model a verified result to explain. 

The product risk starts before the prompt 

A language model is designed to generate a likely continuation from context. That makes it strong at summarization, comparison, translation, and adapting an explanation to a reader, but those strengths do not turn it into a contractual calculation engine. A prompt can describe a tax rule, a date convention, or an eligibility policy, yet the model may omit a branch, use a stale assumption, or produce a plausible value that was never calculated. 

This distinction matters even in low-stakes consumer products. A wrong number or date may not cause immediate physical harm, but it can still break trust because the user cannot tell whether the underlying result is wrong or only the explanation. The NIST AI Risk Management Framework places validity and reliability at the base of trustworthy AI and treats transparency and accountability as properties that cut across the system, not as optional wording added at the end. 

Separate evidence from narrative 

The most useful design boundary is between the part that determines what is true under the product rules and the part that explains what those results may mean. The first part should be ordinary software whenever the rules are expressible: parsers, calculators, policy engines, databases, and versioned lookup tables. The second part can use a language model to organize the evidence, explain trade-offs, answer follow-up questions, and adjust tone or reading level. 

 Give the model a machine readable contract 

The handoff between calculation and generation should be a small, explicit evidence object rather than a long block of prose. Useful fields include the normalized input, calculation version, result facts, assumptions, warnings, and source identifiers. The contract should state which values are authoritative and which fields are descriptive so the model is not forced to infer the difference. 

A good contract also makes change visible. If a time-zone database, pricing rule, scoring method, or other dependency changes, the calculation version should change with it. Teams can then reproduce an old result, compare two versions, and avoid silently rewriting stored outputs after a rules update. 

Validate at both sides of the handoff 

Validation before generation catches malformed inputs, unsupported combinations, impossible dates, missing units, and incomplete engine output. It should fail with a specific message or a safe fallback rather than letting the model repair the problem by guessing. The application can still offer a helpful explanation, but that explanation should identify the missing fact and tell the user how to proceed. 

Validation after generation asks a different question: did the response stay inside the evidence contract? Numbers, dates, labels, and causal claims can be checked against the structured result, while unsupported statements can be rejected or regenerated. Requiring structured model output helps with parsing, but a valid schema does not prove that the values inside it are supported. 

Treat uncertainty as data 

Many systems hide uncertainty until the language model reaches for a confident sentence. The better approach is to represent uncertainty before the model sees the result. A missing time, an approximate location, an expired data source, or a disputed convention should be carried as a first-class field with an allowed response policy. 

The model can then explain how that uncertainty changes the interpretation. It may present a range, compare two rule conventions, or ask for one missing input. This preserves the model’s conversational value without allowing it to manufacture precision that the calculation layer does not possess. 

Test each layer for the failure it owns 

Unit tests should cover the domain engine with boundary cases and known reference examples. Contract tests should confirm that required evidence fields survive the handoff unchanged. Prompt regression tests should check whether the model explains the same evidence consistently enough for the product, and end-to-end tests should confirm that the user sees the right warning, fallback, and next action. 

This separation also shortens incident investigation. When a user reports a wrong result, the team can compare the original input, engine output, evidence object, model response, and rendered interface. Without those boundaries, every problem looks like a model problem, even when the actual fault is stale data, parsing, or presentation. 

Monitor the handoff instead of only the model 

Teams often track latency, token cost, and provider errors while missing the quality signals that matter to the product. More useful measures include rejected evidence bundles, unsupported-fact detections, fallback frequency, missing-input rates, calculation-version changes, and user corrections. These metrics reveal whether the architecture is becoming more reliable, not merely whether the model endpoint returned successfully. 

Logs should keep the minimum evidence needed for diagnosis and respect the sensitivity of user inputs. Provenance can often be represented with version identifiers, hashes, and bounded metadata instead of copying every private field into a general-purpose log. Clear retention and access rules are part of the architecture because operational visibility and privacy must be designed together. 

Know where the pattern earns its cost 

A separate domain engine is not necessary for every conversational feature. It earns its cost when a product contains rules that can be specified, outcomes that users expect to repeat, or facts that should remain stable when prompts and models change. Pricing, schedules, eligibility, compatibility, measurements, and regulated or safety-related guidance are common examples. 

The pattern also improves product iteration. Teams can change the voice, model, or explanation format without changing the underlying result, and they can update the calculation engine without rewriting every conversational surface. That modularity reduces the boundary erosion and hidden dependencies described in research on technical debt in production machine-learning systems. 

A practical first implementation 

Start with the highest-risk value currently produced inside a prompt. Move that value into a deterministic function, record its inputs and rule version, and pass the result to the model in a compact schema. Add one pre-generation validation, one post-generation traceability check, and a small regression set built from real boundary cases. 

The first version does not need a large platform. The goal is to establish an architectural promise: calculations are produced by the component that can be tested as calculations, while the language model is responsible for explanation. Once that promise is visible in code and telemetry, the same boundary can be extended to the next fragile part of the product. 

References 

National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework 1.0 

National Institute of Standards and Technology, Generative Artificial Intelligence Profile 

Sculley and colleagues, Hidden Technical Debt in Machine Learning Systems