28 — Deterministic Data Grounding

Concept overview

Deterministic data grounding connects model output to authoritative evidence through explicit validation. The model may explain facts, but exact totals, dates, identifiers, and eligibility predicates should come from verified records and deterministic code. Retrieval relevance alone does not establish that a passage supports a particular claim.

Separate evidence acquisition, calculation, and narrative generation. Preserve source versions and distinguish observed facts from interpretation. A claim can be grounded in a document that is itself outdated or wrong, so source authority and freshness must be checked independently from whether the answer faithfully repeats the retrieved text.

Why it matters in production

Proof of concept

A prototype can require citations for important claims and compare generated numbers with source records. Include conflicting and stale documents in evaluation.

Production

Production uses typed fact objects, deterministic calculations, claim-to-source mappings, and explicit unknown values. Unsupported required facts should block publication or appear as unresolved.

Enterprise scale

At scale, source snapshots and lineage make answers reproducible across changing systems. Track unsupported claims and stale evidence separately because they require different remediation.

Architecture components

Authoritative data adapter

Retrieves verified records with version, timestamp, and ownership information.

Fact schema

Represents exact values, units, identifiers, uncertainty, and evidence references.

Calculation service

Performs arithmetic and business predicates using tested deterministic logic.

Claim validator

Checks whether generated statements are supported by the selected facts and calculations.

Evidence renderer

Presents citations and freshness indicators suitable for the answer's audience.

The architecture, mapped

flowchart LR
 S["Authoritative records"] --> F["Typed verified facts"]
 F --> C["Deterministic calculations"]
 F --> N["Narrative generator"]
 C --> N
 N --> V["Claim and value validation"]
 F --> V
 C --> V
 V --> A["Evidence-backed explanation"]

Runtime flow

1. 1

   Identify required facts

   Translate the question into explicit data requirements and acceptable source authorities.

2. 2

   Acquire evidence

   Retrieve authorized records and pin relevant versions or observation times.

3. 3

   Normalize values

   Resolve units, currencies, identifiers, and missing-data semantics before computation.

4. 4

   Compute exactly

   Use deterministic logic for totals, comparisons, and policy predicates.

5. 5

   Generate explanation

   Provide the model with typed facts and prohibit filling unresolved fields from memory.

6. 6

   Validate claims

   Check numbers and references, expose uncertainty, and publish only the supported result.

Explaining a commercial electricity bill

Energy retail · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

An energy retailer receives questions about usage, tariff changes, and adjustments on complex commercial bills.

The problem

A fluent assistant may recompute totals incorrectly or cite a tariff that was not effective during the billing period.

Agent requirement

The assistant must explain the bill using the actual meter readings, tariff version, and billing-engine calculations.

Architecture

Data adapters retrieve the invoice snapshot and effective tariff; deterministic code verifies line totals before narrative generation.

Runtime

• A customer asks why charges increased; the system separates consumption changes, tariff changes, and adjustments using recorded values.
• The generated explanation references each component and identifies any missing meter evidence rather than estimating it silently.

Failure scenario

If invoice and tariff versions conflict, publication pauses for reconciliation with the billing system.

Operational impact

Measure numeric mismatch, unsupported claims, stale-source use, and resolution quality. Grounding supports explanation but does not independently prove the billing source is correct.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Asking the model to calculate authoritative totals

Use tested calculation services.

Treating citation presence as proof

Verify actual support and source authority.

Replacing missing values with plausible estimates

Preserve unknown values unless estimation is explicitly requested.

When to choose this pattern

Choose it when

• Answers contain exact business values or consequential facts.
• Authoritative records and source versions are available.
• Users need evidence they can inspect and reproduce.

Avoid it when

• The task is explicitly creative without factual claims.
• No acceptable evidence source exists for the requested assertion.
• The architecture promises certainty beyond source reliability.

Architecture checklist

• Define acceptable authorities for each fact.
• Preserve units and source versions.
• Compute exact values outside the model.
• Validate claim-to-evidence support.
• Expose missing and conflicting facts.
• Test stale and contradictory source records.

Related concepts

• 20 — Deterministic Output Stripping
• 31 — LLM Evaluation Frameworks (TruLens/Ragas)
• 38 — Data Lineage Tracking
• 40 — Explainable AI (XAI)
• 65 — Re-ranking (Cohere/Cross-Encoders)

Primary references

• Ragas: faithfulness evaluation
• TruLens: the RAG triad