Constraint
In a product about grid tariffs and remuneration, a plausible-but-wrong euro figure is worse than no answer, a user could act on it.
Options considered
- Let the model compute and cite, rejected: fluent arithmetic is still hallucinated arithmetic.
- Let it compute, then verify, rejected: still trusts the model's number by default.
- A deterministic engine computes every number from the law, the model only extracts typed inputs and narrates the result, chosen.
Decision
Numbers come from the moteur-remuneration engine (40 C#↔Python parity vectors, CI-gated); the model extracts parameters and presents the computed figure, cited to the engine.
What it costs
Every computable quantity needs a coded formula and its parity test, so new number-questions are engineering work, not prompt tweaks, and a question outside the engine's coverage is refused rather than estimated.
How I'd know I was wrong
If the engine's coverage stays narrow enough that the product refuses ordinary money questions more often than it answers them, I bought correctness at the cost of usefulness, and a user refused twice goes and asks a general chatbot, which will happily invent the number. That is a failure this design causes, not one it prevents. The measurement is the refusal rate on number questions; if it climbs and stays there, the deterministic-only rule is too strict and needs a cited-estimate tier under it.
Verify
The tariff engine + its 40 parity vectors · a live "165 €/MWh (10 kWc / 2019)" trace · the once-caught wiring gap, where the engine was advertised to the model and never called (grep "Remuneration\." returned nothing in the experts), the reason "the engine exists" and "the engine is on the path" are checked separately.