In a fictional review, the source says encrypted exports are for Enterprise, the answer says every paid plan, and both links would open just fine.
- I split the answer into four claims. Only one holds: the feature exists within the Enterprise docs. Every paid plan is unsupported, this customer can use it now is unverified, and the agent may enable it has no authority behind it.
- Documentation cannot prove execution. The API supports deletion and the record was deleted need different evidence, and the second needs an observation of the actual system state.
- I'd let a verifier return insufficient or conflicting evidence instead of forcing true or false, because a failed search proves little and missing logs can't establish success. The paired test for the verifier itself is proposed, not run.
Read the full article: The Sources Are Real. The Answer Is Wrong.
This summary was written with AI assistance (Claude) from the full article at https://www.orbytlabs.ai/blog/a-citation-is-not-a-fact-check.
Top comments (2)
the 'insufficient evidence' return is the part most verifiers skip. forcing true or false is how you get confident wrong answers that still have working links
Agreed, Hiten. And it has a twin failure that’s just as quiet: a verifier that returns “insufficient” for everything never gets caught either, because it’s never technically wrong.
That’s why the test I proposed is paired. Every defective answer sits next to a correctly scoped one, and the verifier fails if it approves the bad one or rejects the good one. Refusing both isn’t caution. It’s a verifier that can’t approve anything.
Abstention also isn’t free. It hands the claim to a person. So I’d track human review minutes per accepted answer and queue age alongside precision, and if the queue outgrows review capacity, narrow what the system answers rather than lower the bar.
Honest status: the paired test is designed, not run yet.