Zero-tolerance for hallucinations: how our platform makes AI trustworthy for business

Short version: We don’t let AI guess. For factual queries (balances, usage, invoices), our platform runs several models in parallel, all reading the same system of record. We compare structured values, not prose. If results align, we answer. If not, we re-check; if still unclear, we escalate to a human. That’s what we mean by zero-tolerance.

The method (plain English)

1. Grounded tool-callsEvery answer comes from your own systems (CRM, billing, ledger, data warehouse), not the open web.

2. Multi-model consensusThree independent models fetch and parse the same record. They return JSON like:{amount_cents, currency, as_of_timestamp, account_id}

3. Normalisation & rulesWe normalise with code (not LLMs): currency → minor units; timestamps → ISO; units → canonical (kWh, not MWh); rounding rules are explicit.

4. Referee & retries if models disagree, a referee step decides: formatting vs real mismatch. We re-read a snapshot (record_version, as_of). Still divergent? Escalate with full context.

Typical outcomes with 80% single-model accuracy:

Same-wrong rate (g)	Final error rate	Wrong per 1,000,000
0.01 (well-engineered parsing)	0.000178%	~2
0.05	0.00436%	~44
0.10	0.0170%	~170

In practice: for a utility with 1,000,000 balance/usage queries, we expect ~2–170 wrong answers, not tens of thousands you’d see with a single model.

What this means in the real world

• Trustworthy by design: if models disagree, we don’t bluff; we verify or escalate.

• Fast enough for CX: over 90% of queries settle in two passes or fewer.

• Auditable: every answer links to an API snapshot, normalisation rules, and the consensus decision.
  

Where this can still fail (and how we mitigate)

1. Bad source data (the system of record is wrong)

   • Mitigation: recompute balances from ledger; invariants (opening + charges − payments = closing); data-quality alerts.

2. Correlated parsing errors

   • Mitigation: deterministic normalisation (cents, ISO time, units); schema validation before consensus.

3. Staleness/race conditions

   • Mitigation: versioned, snapshot reads; if versions differ, re-read or lock a snapshot.

4. Identity & authorisation

   • Mitigation: strong auth/MFA, strict scoping of tool-calls to account_id, consent logging.

5. Prompt/tool injection

   • Mitigation: allow-listed, parameterised tools; never let free text touch IDs/SQL; sanitise inputs.

6. Privacy & retention

   • Mitigation: field-level masking in logs, minimal vendor sharing, no model training on your customer data, clear retention limits.

7. Latency & cost

   • Mitigation: use consensus only for high-stakes intents (balances, entitlements); cache immutable lookups.

Proof you can audit

When we pilot, we publish a concise Proof Pack:

• Headlines: wrong answers per 100k queries (factual only), escalation rate, median/P95 latency, cost per resolved query.

• Redacted examples: input → tool payload → three model outputs → referee decision.

• Controls: snapshot/version tags, normalisation code, and audit logs.

• Optional third-party spot check for extra credibility.

Ask for the “Truth Quorum Proof Pack” and we’ll share a one-pager with the results.

What we mean by “zero-tolerance”

Not a promise of perfection. It’s a process promise:

• We never ship a factual answer that hasn’t been verified across models against your system of record.

• If verification fails, we abstain and escalate — rather than hallucinate.

Want the deep dive?

If you’d like a live walkthrough with your data model, DM me and we’ll set it up.