Domain-specific AI products often fail in one of two ways. They either ask a language model to calculate facts it was never designed to calculate, or they hide a deterministic rules engine behind an answer that users cannot audit.
A better architecture separates computation from interpretation.
The two-layer model
The first layer produces facts from explicit inputs. The second layer explains those facts in natural language.
For a calendar, financial calculator, medical scoring rule, or traditional charting system, the first layer should be deterministic whenever the domain permits it. The same input should produce the same structured output. Intermediate values should be visible, testable, and versioned.
The AI layer should not silently recalculate those facts. It should receive a structured snapshot and answer questions about it.
A simple data flow looks like this:
- Validate input and normalize time, location, units, and locale.
- Run a deterministic domain engine.
- Store both the result and the calculation settings.
- Build an interpretation context from selected facts.
- Ask the model to explain, compare, or summarize within clear boundaries.
- Show the underlying facts next to the generated language.
Why this matters for specialized calculators
Consider a BaZi chart. Solar-term boundaries, birth time, location, time-zone handling, and the displayed Four Pillars are rule-based facts. If a language model guesses them directly, a fluent answer can still be internally inconsistent.
In a system such as the Traditional Chinese BaZi calculator, the calculation should remain reproducible while AI interpretation stays optional. Users can inspect the chart first, then decide whether they want a narrative explanation.
Qi Men Dunjia has the same architectural requirement. A Qi Men chart calculator must establish the time and nine-palace structure before an AI layer discusses patterns or decision factors. The model should interpret the supplied chart, not invent a different one halfway through the response.
Treat provenance as product data
A structured output should include more than the headline result. It can also carry:
- normalized input values;
- time-zone and location assumptions;
- rule or algorithm version;
- relevant boundary conditions;
- confidence or uncertainty flags;
- a list of facts exposed to the language model.
This provenance makes debugging possible. When a user reports a wrong answer, the team can determine whether the problem came from input normalization, the rules engine, context assembly, or the model response.
Test the seam, not only each layer
Unit tests can prove that the rules engine handles known cases, and prompt evaluations can score explanation quality. The most expensive failures often appear at the seam between them.
For example, a correct structured result may be mapped to the wrong prompt field. A locale transformation may change a date. A summary step may drop a boundary flag. An AI response may refer to a value that was never present in the supplied context.
Integration tests should therefore capture the exact structured payload passed to the model and verify that generated claims are grounded in it.
Design the interface around verification
The UI should let users distinguish three things:
- calculated facts, produced by the deterministic engine;
- assumptions and settings, chosen by the user or system;
- interpretation, generated or written about those facts.
This distinction is more useful than a generic AI disclaimer. It shows users what can be reproduced and what remains interpretive.
The general pattern
The same architecture applies beyond metaphysical calculators. Tax estimators, eligibility tools, engineering calculators, scoring systems, and compliance checkers all benefit from a stable rules layer with an optional language layer.
Use code for what must be consistent. Use AI for what benefits from explanation. Keep the boundary visible.
Top comments (0)