Evidence-based hallucination detection at AWS, Collibra

You must now establish which hallucination detection method your workflow actually uses, validate its performance independently in your own domain, and layer it with human review and source checking rather than treating any single tool as sufficient.

The prompt is an analysis of 29 September 2026 of evidence-based hallucination detection at runtime, which argues that detection systems are shifting from general model assessment towards runtime verification that breaks answers into individual claims and tests them against external sources or formal policy rules. The analysis examines implementations from AWS, Collibra and TrustScale, showing four distinct method families. In our assessment, this represents a material change in how organisations can operationalise hallucination detection, but the absence of independent domain-specific evaluation means you cannot rely on vendor accuracy claims alone.

What does hallucination detection actually measure?

Hallucination detection is not a single measurement. It can test whether an answer is faithful to its source documents, whether it aligns with an organisation's formal policy rules, or whether it corresponds to external reality. These three do not coincide. An answer can be faithful to a faulty source document. It can be factually correct but in conflict with policy. It can comply with policy but diverge from verifiable fact. Anyone deploying a detector must therefore know which of these three the system actually checks, because the failure modes differ fundamentally.

The AWS announcement on Automated Reasoning checks in Amazon Bedrock Guardrails focuses on policy compliance through formal logic. That is something distinct from checking against broader reality. The system tests generative answers against customer-defined policy, flags policy-related hallucination risk and provides verifiable explanations. For work with sensitive information, this offers an additional checkable step: answers are tested against explicit policy with documented reasoning. That does not replace source checking or human review.

Which method families are in use?

Hallucination detection systems can be organised into four working families, each with a structural dependency that can undermine the detection:

• Policy-based formal logic — tests answers against explicit rules defined by the organisation, with verifiable explanations of compliance or breach.
• Source document retrieval and matching — compares generated claims against documents the system has access to, flagging unsupported statements.
• External knowledge base verification — checks claims against structured external data sources or APIs, requiring real-time connectivity and source reliability.
• Semantic consistency and contradiction detection — identifies internal logical inconsistencies within the answer itself, without reference to external sources.

Each family depends on the quality of its foundation. Policy-based systems fail when policies are incomplete or poorly specified. Retrieval systems fail when source documents are absent, outdated or themselves unreliable. Knowledge base systems fail when the external source is unavailable or incorrect. Consistency detection fails when an internally coherent answer happens to be factually wrong. You must understand which of these your chosen system relies on, because that determines where it will fail.

What do vendor accuracy claims actually show?

The published accuracy figures from TrustScale, Collibra and others are vendor claims. They have not been independently validated in domain-specific testing. TrustScale cites figures about accuracy and speed. Collibra's survey figures have been presented by the vendor itself. In our assessment, the most important open question is how these systems perform in independent tests within your specific domain and data environment. As long as independent validation is missing, a high score on a vendor test remains a weak foundation for business-critical deployment.

How should you structure hallucination detection in practice?

The practical approach is a layered workflow, not a single product. You should be able to demonstrate the following controls:

1. Identify which detection method your workflow uses — document whether you are checking policy compliance, source fidelity, external knowledge consistency or internal coherence, and why that method fits your use case.
2. Validate performance in your own domain — run the detector against test cases drawn from your actual data and decision context, not vendor benchmarks, and measure false positive and false negative rates.
3. Document the quality and currency of your sources — if the detector relies on external sources, APIs or knowledge bases, establish how you will monitor their accuracy and update frequency.
4. Layer detection with human review — define which outputs require human verification before use, based on the stakes of the decision and the detector's performance in your domain.
5. Monitor detector performance over time — track whether accuracy remains stable as models, data and sources change, and establish triggers for re-validation.
6. Bound agent actions at runtime — if you are deploying agents, restrict what actions they can take based on detected hallucination risk, rather than relying on detection alone.

What can tools do and what remains your responsibility?

The product developments at AWS, Collibra and TrustScale make hallucination detection concretely runtime- and evidence-based. That is a genuine gain over earlier approaches that relied on general model assessment. But the absence of independent domain-specific evaluation remains a structural risk. Organisations must set up their own validation and monitoring processes alongside the tools on offer, not instead of them. No tool can substitute for understanding what it actually measures, testing it in your own context, and maintaining human oversight of decisions that matter. The vendor's accuracy claim is a starting point for your own evaluation, not a substitute for it.