Evidence, Truth, and Verifiability
Chapter 2 gave us a rule for talking about hallucination precisely:
Relative to what reference did the output fail?
That question immediately creates another one.
What counts as a reference strong enough to constrain the answer?
Suppose a model says:
Company A acquired Company B in 2024.
There are several different things we might mean when we ask whether this is acceptable:
What exact proposition has been asserted?
Is that proposition true at the relevant time?
Do we possess evidence for it?
Does that evidence actually support this exact relationship?
Can we identify the source and passage that support it?
Where did that source come from?
Is the source sufficiently reliable and current for this claim?
Is the evidence package sufficient for the action we want to authorize?
Could the claim be verified by this system now?
Has the verification actually been performed?
Would the active policy allow the claim to be published or acted upon?
Those questions are related.
They are not interchangeable.
A large part of hallucination engineering goes wrong when they are collapsed into one word such as grounded, verified, or factual.
This chapter separates them.
The distinction we need is:
resolved claim
≠
truth
≠
evidence
≠
support
≠
attribution
≠
provenance
≠
source reliability
≠
evidential sufficiency
≠
verifiability
≠
verification
≠
policy acceptance
Once those concepts are separate, we can finally ask what a hallucination detector should measure.
1. Resolve the claim before asking whether it is true
Truth applies to a proposition, not to an unresolved string of words.
Consider again:
Company A acquired Company B in 2024.
Before we evaluate it, several ambiguities may need to be resolved.
What does acquired mean here?
agreement announced?
transaction signed?
regulatory approval granted?
controlling stake purchased?
transaction legally completed?
And what does in 2024 modify?
announcement date?
signing date?
closing date?
A verifier that compares unresolved sentences can mistake a claim-resolution disagreement for a factual disagreement.
So we begin with a normalization step:
graph LR
R[raw sentence] --> ER[entity resolution]
ER --> RR[relation resolution]
RR --> TS[time / scope / modality resolution]
TS --> NP[normalized proposition c]
Normalization turns a sentence into the specific proposition that a verifier can compare against evidence instead of comparing unresolved surface text. Conceptually, a resolved empirical claim might contain:
subject
relation
object
time
scope
modality
qualifiers
Only then does it make sense to write an idealized truth function.
For a crisp factual claim we can use:
c = resolved proposition
t = relevant temporal scope
k = domain or contextual frame
The additional parameters matter.
"X is the CEO"
"Y is the largest provider"
"Z is approved for this indication"
can change truth value over time or across jurisdictions.
The binary form is a useful simplification for crisp factual claims, not a universal theory of language. Comparative, normative, probabilistic, modal, or vague claims may require graded or structured evaluation rather than one Boolean truth value.
A production AI system also rarely receives direct access to “the world” as an oracle.
It receives representations of the world:
documents
databases
retrieved passages
API responses
tool observations
sensor readings
execution traces
human testimony
published research
Those objects are potential evidence.
The system therefore faces two different questions:
ontological question:
Is c actually true in the relevant world, time and context?
operational question:
What observable evidence do we have that bears on c?
The first is what we ultimately care about.
The second is what software can usually inspect.
Evidence is the interface through which a system can operationalize claims about truth.
2. Build an evidence-bearing claim object, not just a sentence
The rest of the chapter becomes easier if we stop imagining verification as a function that receives one string and returns one score.
Instead, think in terms of an evidence-bearing candidate object.
We can call it a Claim Verification Object, or CVO:
ClaimVerificationObject
claim
normalized proposition being evaluated
available_evidence
sources the current system could in principle inspect
retrieved_evidence
sources actually collected for this claim
attributions
source passages explicitly linked to the claim
support_relations
how those passages bear on the claim
provenance
source identity, lineage, version and independence
source_assessment
reliability, currency and claim-specific fitness
derivation
direct or derived support and the inference path used
verification_state
which checks were executable and which were actually run
policy_decision
what the evidence package is allowed to authorize
This is not merely an implementation detail.
It prevents later stages from collapsing several questions into one field called grounded_score.
The CVO makes Chapter 2’s working schema concrete. Its evidence fields are the reference; verification_state will hold the signal; policy_decision is the policy node. Chapter 4 fills verification_state with typed sensor outputs; Chapter 12 acts on policy_decision.
Each section of this chapter fills one part of that object.
3. Evidence is relational, and the evidence set has stages
It is tempting to call a retrieved document “the evidence.”
That is too coarse.
A document becomes evidence for a particular claim only through a relationship between the content of the document and the proposition being evaluated.
We also need to separate the information the system could access from the information it actually retrieved.
Let:
E_available = evidence accessible to the current system in principle
E_retrieved = evidence actually collected for this claim
E_attributed = evidence explicitly linked to this claim
These sets can differ dramatically.
A claim may be unsupported by the retrieved evidence because the retrieval step failed even though excellent evidence exists in an accessible database.
That is a retrieval failure, not necessarily a support-evaluation failure.
The important object is therefore not merely a document or even a set of documents.
It is the relation between evidence and claim.
Rather than forcing that relation immediately into a Boolean supports / does not support, we can use a richer conceptual state:
SUPPORTS
PARTIALLY_SUPPORTS
REFUTES
INSUFFICIENT
CONFLICTING
AMBIGUOUS
A familiar predicate remains useful:
This also prevents a common mistake:
no support found
is not the same as:
evidence refutes the claim
The first may call for retrieval.
The second may call for rejection or correction.
Evidence support in natural language is also usually defeasible, not mathematical proof.
A strong piece of evidence can raise our justification for a claim while remaining open to correction by stronger or newer evidence.
Conceptually, evidence may increase:
4. Truth and support produce different states
Once truth and evidential support are separated, we get a useful two-by-two table.
| Supported by available evidence | Not supported by available evidence | |
|---|---|---|
| True in the world | true and supported | true but unsupported here |
| False in the world | false claim backed by misleading or incorrect evidence | false and unsupported |
All four states are possible.
True and supported
Claim:
Company A acquired Company B in 2024.
Evidence:
A regulatory filing explicitly records the completed acquisition and date.
This is the easy case.
True but unsupported here
Claim:
Company A acquired Company B in 2024.
Retrieved evidence:
A document discussing Company A's 2023 revenue.
The claim may be true.
The current evidence does not establish it.
A source-bounded verifier should reject, defer, or retrieve more evidence even if an external search would later prove the claim correct.
That is not a detector failure.
It is the consequence of asking a source-bounded question.
False but apparently supported
Now imagine the source itself contains an error:
Source:
Company B acquired Company A in 2024.
Model summary:
Company B acquired Company A in 2024.
The summary is faithful to the source.
The source is wrong.
This is why faithfulness is not factuality.
A model can perfectly summarize bad evidence.
False and unsupported
This is the familiar hallucination case:
Claim:
Company C acquired both companies in 2022.
No supplied or external evidence establishes that event.
The important lesson is that no single “grounded / not grounded” bit captures all four states.
5. Support is directional, strength-sensitive, and polarity-sensitive
Semantic similarity is symmetric:
Suppose a source says:
The treatment reduced symptoms in a small exploratory study.
The generated claim says:
The treatment is an established cure for the disease.
The two sentences are topically similar.
They share entities and concepts.
But the source does not license the stronger conclusion.
What we care about is directional:
associated with
→ caused
observed in one trial
→ generally established
may help
→ is effective
reported by one source
→ accepted fact
Polarity can fail even more dramatically.
Evidence:
The study did not find a statistically significant association.
Claim:
The study found a statistically significant association.
Almost every content word is shared.
The support relation is reversed.
This is the same structural problem we encountered with relational inversion in Chapter 2:
high lexical overlap
high semantic proximity
but
wrong relationship / polarity / scope
Similarity can be a useful signal.
Support is the target relation.
That is why Chapter 4 cannot simply say “measure similarity to evidence.”
6. Attribution asks where the support is
Suppose a claim appears broadly compatible with a large evidence collection.
That is not yet attribution.
Attribution asks whether we can identify the particular evidence being offered in support of the claim.
An attribution is therefore a candidate edge:
graph LR
C[claim] -->|attributed to| S[source passage]
Support evaluation then asks whether that edge is valid.
This order matters because defining attribution only as “the evidence that supports the claim” makes support and attribution circular.
A better separation is:
attribution candidate
"this passage is offered for this claim"
support assessment
"does the passage actually support the claim?"
Research on Attributable to Identified Sources (AIS) formalizes a related idea: generated statements about the external world should be assessable against identified independent sources rather than merely accepted because they sound plausible.[4]
Work on locally attributable generation goes further by selecting concise supporting source segments before generation.[5]
That creates an important engineering benefit:
Better attribution reduces the cost of verification.
A citation to a 90-page PDF and a citation to two exact supporting sentences may identify the same source, but they impose radically different checking costs.
The progression is therefore:
claim appears compatible with evidence set
↓
claim is linked to a specific source
↓
claim is linked to a specific passage
↓
that passage is tested for support
7. A citation is not attribution, and attribution is not support
Imagine an answer containing:
The intervention reduced hospital admissions by 37%.
[fabricated citation]
Here, [fabricated citation] is deliberately fabricated. This is the same invented 37% claim from Chapter 1, now paired with a citation that only appears to provide authority so that the failure can be traced through each layer. The supposed citation [fabricated citation] might fail in several ways:
source does not exist
source exists but metadata is wrong
source exists but discusses another intervention
source discusses this intervention but not hospital admissions
source reports a 17% reduction, not 37%
source reports 37% in a subgroup while the answer generalizes it to everyone
source supports the claim but is not admissible under the active policy
So citation verification is not one check. It is a chain:
graph TD
SR[source resolution] --> SI[source identity]
SI --> PL[passage localization]
PL --> PS[claim–passage support]
PS --> SS[strength / scope match]
SS --> SA[source admissibility under policy]
Citation verification must resolve the source, localize the relevant passage, test support, and then decide whether the source is admissible for the intended claim.
The first two deserve separate names.
source resolution:
Can the referenced object actually be located?
source identity:
Is the located object genuinely the source the citation claims it is?
A system that merely adds links to generated answers has not solved hallucination.
It has added a new structure that can itself fail.
The 2026 ACL survey of evidence-based text generation reaches a similar conclusion from a much wider literature: attribution, citation, and quotation have developed into a large but fragmented evaluation area, with many incompatible metrics and terminology.[6]
The engineering response is to name the layers explicitly.
8. Provenance asks where the evidence itself came from
Attribution links a claim to a source passage.
Provenance asks about the origin and lineage of that source.
For a source \(s\), useful provenance metadata includes:
source identifier
creator / publisher
publication time
version or revision
retrieval time
source type
primary / secondary / derivative status
chain of custody
independence from the subject
known retractions or corrections
content hash or stable fingerprint
upstream sources it depends on
Time requires particular care.
At minimum, distinguish:
published_at
when the source was produced
retrieved_at
when the system fetched it
valid_as_of / temporal_scope
the period the underlying claim describes
A document retrieved today can still be stale.
A recent document can describe an older historical state correctly.
Freshness must therefore be evaluated relative to the claim, not merely to the retrieval timestamp.
Provenance also prevents a subtle failure: circular evidence.
AI generates claim X
↓
website copies claim X
↓
search engine retrieves website
↓
AI cites website as evidence for X
The citation exists.
The support may even appear textually exact.
The evidential chain has still collapsed into a loop.
Circularity is not a property of one document in isolation.
It is a property of the provenance path.
A source that repeats the claim is not independent evidence merely because it has a different URL.
9. Source reliability and evidential sufficiency are different from policy admissibility
It is common to talk about a publication as either “reliable” or “unreliable.”
That is usually too simple.
A company website may be authoritative for:
its registered office address
its current product documentation
its own announced pricing
and weak evidence for:
whether its product is superior to every competitor
whether its clinical claims are independently established
whether its market is about to double
Wikipedia’s reliable-source guidance makes the same contextual point explicitly: source reliability depends on the statement being supported, and a source appropriate for one claim may be inappropriate for another.[3]
So the useful source-fitness function is closer to:
s = source
c = claim
k = domain / context
t = relevant temporal scope
Notice what is absent: policy.
A source can be good evidence for a claim while a particular policy still refuses to admit it.
For example:
credible secondary report
↓
strong evidential usefulness
↓
publication policy requires primary source
↓
inadmissible for this action
Reliability did not change.
Policy did.
There is another layer between support and policy: evidential sufficiency.
One source may support a claim yet still be insufficient for the intended use.
one observational study
may support a cautious research hypothesis
one observational study
may be insufficient for an automated clinical recommendation
We can therefore ask:
P = active policy
a = intended action
Sufficiency can depend on:
number of independent sources
source quality
freshness
corroboration
directness
claim type
remaining conflict
cost of being wrong
Support asks whether evidence bears in the right direction.
Sufficiency asks whether we have enough of the right evidence for the decision at hand.
10. Support may require inference; policy decides which inferences are admissible
Not every justified conclusion appears word-for-word in a source.
Suppose the evidence says:
A is older than B.
B is older than C.
Then:
A is older than C.
is a valid deduction.
The engineering problem is not simply “directly stated or hallucinated.”
We need to preserve the derivation path:
premise_1: A > B
premise_2: B > C
rule: transitivity of >
derived_claim: A > C
That lets a verifier distinguish:
direct support
derived support through an approved rule
multi-source synthesis
speculative extrapolation
The validity of an inference and the admissibility of that inference are different questions.
Wikipedia’s current No Original Research policy, for example, prohibits editors from combining published material to advance a novel conclusion that the sources themselves do not clearly make. The policy explicitly uses the structure “A and B, therefore C” as the kind of synthesis that requires a source making that argument.[2]
The broader engineering lesson is:
Reasoning can be valid while a publication policy still refuses to authorize the derived claim.
A policy can therefore define an inference allowance.
For example:
0 quotation / close paraphrase
1 direct entailment
2 simple rule-governed deduction
3 synthesis across sources
4 domain generalization / extrapolation
5 speculative causal conclusion
The scale is application-specific, but the idea is useful.
extractive policy
allows approximately 0–1
deductive policy
allows approximately 0–2 with explicit derivation
analytical policy
may allow deeper synthesis, but requires qualification,
attribution and an inspectable derivation trace
The verifier should inspect that derivation object.
It should not depend on hidden internal reasoning being exposed as part of the contract.
11. Verifiable in principle, verifiable now, and verified are different states
A claim can pass through at least three procedural states.
Verifiable in principle
An authoritative evidence path exists somewhere.
official registry contains the relevant record
Verifiable by this system now
The current runtime has access to a tool, database, document, or retrieval path capable of obtaining the evidence.
registry exists
+
system has registry access
Verified
The system actually executed the path and performed the required check.
registry queried
+
record retrieved
+
claim compared with record
+
check passed
So:
VERIFIABLE IN PRINCIPLE
≠
ACCESSIBLE / VERIFIABLE NOW
≠
VERIFIED
The distinction is especially important for agents.
official database exists
≠
system has database tool
≠
system called database tool
≠
tool returned the relevant record
≠
record supported the claim
A production system should never silently convert:
"I could check this"
into:
"I checked this"
That is exactly the runtime-state hallucination from Chapter 2, now expressed as an evidence-state error.
Verifiability is also policy-relative in practice.
A verification path only matters if the active policy considers that path acceptable for the claim and action under consideration.
12. Wikipedia is a useful case study because it exposes the evidence gate
Wikipedia gives us an unusually clear human example of evidence policy.
The current English Wikipedia Verifiability policy says readers must be able to check claims against reliable published sources; it also states that even material an editor is sure is true must have been published in a reliable source before it is added.[1]
The slogan historically associated with this principle was:
“the threshold for inclusion is verifiability, not truth”
Wikipedia now identifies that as a historical formulation rather than the operative policy wording.[1]
The deeper engineering idea is not the slogan.
It is:
personal certainty
≠
procedural admissibility
Wikipedia also requires sources to support material clearly and directly and restricts novel synthesis.[1][2]
That means one institution has already separated several things that AI systems often conflate:
claim
source
support
source suitability
allowed inference
publication decision
Wikipedia is not the universal policy for AI.
It is useful because it demonstrates that a large human information system can make acceptance rules external to the author of the claim.
The same architectural move is available to us.
13. Policy turns an evidence package into a decision
Now we can define the decision layer without collapsing it into source reliability.
Suppose we have:
claim c
evidence E
attribution A
provenance / source metadata M
verification results V
active policy P
intended action a
The decision function is better represented as:
A useful decision type is:
ACCEPT_AS_FACT
ACCEPT_WITH_ATTRIBUTION
ACCEPT_AS_HYPOTHESIS
RETRIEVE_MORE
SURFACE_CONFLICT
REQUIRE_HUMAN_REVIEW
ABSTAIN
REJECT
The intended action matters.
The same claim and evidence can be acceptable for:
brainstorming
and unacceptable for:
publication
It may be acceptable as:
hypothesis
and unacceptable as:
established finding
It may be acceptable in:
internal exploratory analysis
and unacceptable in:
automated clinical recommendation
Policy turns evidence state into authorization.
That is a different operation from deciding whether the evidence supports the claim.
14. The same measurement can produce different decisions under different policies
This was one of the most useful results in our earlier policy-gate experiments.
We held the following constant:
claim
evidence
measurement / verification code path
and changed only the active policy configuration.
The admissibility decision changed.
That does not mean truth changed.
It means policy answered a different question.
A permissive research-assistant policy might allow:
credible secondary evidence + explicit uncertainty
while a publication policy might require:
direct attribution + approved source class + no unsupported synthesis
and an automated-action policy might additionally require:
freshness + independent confirmation + runtime validation
The experimental policy regimes in our earlier work are engineering configurations inspired by institutional constraints; they are not official Wikipedia policy tiers.
The transferable lesson is:
Measurement can remain fixed while tolerance and admissibility change with policy.
This distinction will become crucial when we later calibrate hallucination detectors under explicit false-acceptance budgets.
15. FEVEROUS is a controlled claim–evidence task, not a truth oracle
The FEVEROUS dataset is useful because it makes claim–evidence structure explicit.
It contains 87,026 claims associated with Wikipedia evidence drawn from both unstructured text and structured material such as tables, with labels indicating SUPPORTS, REFUTES, or NOT ENOUGH INFO.[7]
That structure gives us:
claim
↓
identified evidence
↓
support / refutation / insufficient evidence
The three outcomes are operationally different.
SUPPORTS
evidence establishes the claim under the benchmark procedure
REFUTES
evidence contradicts the claim
NOT ENOUGH INFO
the required support or refutation is not available in the evidence universe
That maps naturally to different system actions:
SUPPORTS
→ continue verification / consider acceptance
REFUTES
→ reject, correct, or surface contradiction
NOT ENOUGH INFO
→ retrieve more, narrow the claim, or abstain
The important property is not that FEVEROUS has discovered universal truth.
It has constructed a controlled verification task relative to Wikipedia content and annotation rules.
That makes it useful for experiments about:
evidence retrieval
claim–evidence relation prediction
multi-hop verification
structured + unstructured evidence
insufficient evidence
It does not make FEVEROUS an oracle for every factual question.
If a benchmark label means:
not supported by the benchmark evidence universe
we should not casually rewrite it as:
false in the world
The benchmark reference must stay visible.
16. Evidence state should be structured, not compressed into one confidence number
A realistic evidence package can occupy several states.
SUPPORTED
identified evidence directly or defeasibly supports the claim
REFUTED
identified evidence contradicts the claim
INSUFFICIENT
relevant evidence exists, but it does not establish the required proposition
CONFLICTING
credible sources support incompatible conclusions
STALE
evidence once described the relevant state but is outside the required temporal scope
AMBIGUOUS
the evidence permits more than one reasonable interpretation
CIRCULAR
apparent sources depend on the same unsupported origin
INACCESSIBLE
an acceptable evidence path may exist, but this runtime cannot inspect it
NON_FALSIFIABLE / NORMATIVE
the proposition is not appropriately resolved by empirical retrieval alone
These states should not all collapse to:
confidence = 0.63
They imply different actions.
REFUTED
→ reject / correct / surface contradiction
INSUFFICIENT
→ retrieve more / narrow / abstain
CONFLICTING
→ expose disagreement / seek stronger authority
STALE
→ refresh
AMBIGUOUS
→ clarify claim or request review
CIRCULAR
→ reject provenance path / find independent source
INACCESSIBLE
→ acquire access / expose limitation / human verification
NON_FALSIFIABLE
→ change evaluation method rather than loop on retrieval
The point is not to declare one universal state machine.
It is to preserve enough structure that policy can choose the right next action.
17. Replace the evidence ladder with an evidence stack and decision pipeline
The earlier intuition of an evidence ladder is useful, but not every stage is simply a “stronger form of evidence.”
Verification is a procedural state.
Policy acceptance is a decision.
Neither should be treated as though it were merely one more rung of epistemic strength.
A cleaner architecture is:
graph TD
subgraph Evidence_Discovery
AS[available sources] --> R[retrieval / collection]
R --> RC[relevant evidence candidates]
end
subgraph Evidence_Linking
C[claim] --> AT[attribution to source]
AT --> LP[local passage / structured record]
end
subgraph Evidence_Evaluation
LP --> REL[claim ↔ evidence relation]
REL --> SR[support / refute / insufficient / conflict]
SR --> DR[derivation / inference depth]
DR --> PRO[provenance]
PRO --> SF[source reliability / freshness]
SF --> SU[evidential sufficiency]
end
subgraph Procedural_State
SU --> VEX[verification executable?]
VEX --> VAP[verification actually performed?]
VAP --> VRES[verification result]
end
subgraph Decision
VRES --> POL[policy + intended action]
POL --> DEC[ACCEPT / RETRIEVE / REVIEW / ABSTAIN / REJECT]
end
The architecture separates discovering evidence, linking it to claims, evaluating support, and recording verification state before policy is allowed to decide.
Within the evidence-evaluation portion we can still speak of increasing guarantees:
availability
↓
containment
↓
attribution
↓
support
↓
source fitness
↓
sufficiency
But the pipeline then branches into procedure and policy.
This distinction becomes especially important for Hallucination Energy.
Containment asks:
Does this claim appear to remain within the semantic information represented by the evidence set?
Attribution asks:
Where, specifically, is the proposed support?
Support asks:
Does that passage actually justify the claim as stated?
Sufficiency asks:
Is the resulting evidence package enough for this claim and intended action?
Verification asks:
Were the required checks actually executed?
Policy asks:
What is this verified package allowed to become?
Those are not interchangeable guarantees.
18. One claim can fail at every layer for a different reason
Carry one claim through the pipeline:
Company A acquired Company B in 2024.
Discovery failure
No acquisition filing was retrieved.
The claim may still be true.
The evidence package is incomplete.
Containment failure
Retrieved document discusses Company A's revenue,
not acquisitions.
The evidence does not even appear to contain the required proposition.
Attribution failure
Citation [fabricated citation] resolves to a different filing.
The claimed support edge points to the wrong object.
Support failure
Source says:
"Company A entered a strategic partnership with Company B."
Claim says:
"Company A acquired Company B."
High topical overlap.
Wrong relationship.
Temporal failure
Source accurately describes negotiations in 2023,
but the claim concerns completion in 2024.
Reliability / provenance failure
The only source is a derivative article that copied the claim
from an earlier AI-generated summary.
Sufficiency failure
A permissive research policy may accept one credible report
as a hypothesis.
A trading-action policy requires an official filing and
independent confirmation.
Verification-state failure
The official database could have been checked,
but the tool was never called.
Policy failure
All checks pass for an internal research note,
but automated execution still requires human approval.
The sentence did not change.
The failure location did.
That is why one scalar groundedness value cannot explain the system.
19. Preserve the Claim Verification Object through the runtime
There is a practical software consequence to everything above.
Do not pass only prose between stages.
Instead of:
answer = llm(prompt)
publish(answer)
preserve the evidence-bearing object:
candidate = {
"claim_id": "clm_8f92a1",
"revision": 1,
"claim": "Company A acquired Company B on 14 March 2024.",
"claim_type": "empirical_event",
"temporal_scope": {
"valid_as_of": "2024-03-14",
},
"evidence": [
{
"source_id": "filing-2024-0314",
"source_type": "regulatory_filing",
"passage": "On March 14, 2024, Company A completed its acquisition of Company B...",
"published_at": "2024-03-14",
"retrieved_at": "2026-08-29T23:00:00Z",
"content_hash": "sha256:...",
"provenance_chain": ["official-registry", "direct-api-retrieval"],
}
],
"attributions": [
{
"source_id": "filing-2024-0314",
"span_start": 0,
"span_end": 78,
"relation": "SUPPORTS",
"support_mode": "direct",
}
],
"derivation": None,
"verification": [
{
"check": "source_identity",
"status": "passed",
"procedure_version": "source-identity-v2",
},
{
"check": "claim_support",
"status": "passed",
"procedure_version": "support-v4",
},
{
"check": "temporal_validity",
"status": "passed",
"procedure_version": "freshness-v1",
},
],
"policy_decision": {
"policy_id": "publication_high_rigor_v3",
"intended_action": "publish_factual_claim",
"decision": "ACCEPT_WITH_ATTRIBUTION",
"allowed_inference_depth": 1,
},
}
The exact schema will vary by application.
The architectural point does not.
Later stages should add or revise structured state rather than erase the evidence path.
That lets the runtime answer questions raw prose cannot:
Which source supports this claim?
Which exact passage was used?
What relation was assessed?
When was the source published?
When was it retrieved?
What temporal scope does the claim assert?
What inference was used?
Which verification procedure ran?
What policy accepted it?
What action did acceptance authorize?
What changed after revision?
The system is no longer transporting “an answer.”
It is transporting an evidence-bearing candidate.
20. Three production anti-patterns
The distinctions in this chapter expose several common bugs immediately.
Anti-pattern 1: URL exists, therefore claim is supported
source resolution
mistaken for
claim support
A real page can fail to support the attached sentence.
Anti-pattern 2: high cosine similarity, therefore attribution is valid
semantic proximity
mistaken for
claim–passage entailment / support
A negated or reversed relation can remain extremely similar in embedding space.
Anti-pattern 3: “I verified it,” therefore verification occurred
model assertion
mistaken for
runtime evidence
Verification state must come from the execution trace, not from the prose being verified.
These are not edge cases.
They are examples of the same architectural mistake: one layer is being granted the authority of another.
21. What a verifier actually needs to know
Before we build a hallucination measurement, we can now state the verifier’s input contract.
For any consequential claim, ask:
- What exactly is the resolved claim?
- What temporal, modal and contextual scope does it assert?
- What reference is authoritative for this task?
- What evidence is accessible, and what evidence was actually retrieved?
- Which evidence is attributed to this claim?
- Does the attributed evidence support, refute, or fail to establish the claim?
- What inference or derivation separates evidence from claim?
- What is the provenance, freshness and claim-specific reliability of the source?
- Is the resulting evidence package sufficient for the intended action?
- Could the current system execute the required verification path?
- Has that procedure actually been executed, and what was the result?
- Which policy is making the decision, and what action is it being asked to authorize?
- What should happen if any of those checks remain unresolved?
The last question is where production behavior emerges.
Unresolved is not the same as accepted.
Notice what is absent from the contract:
Does the answer sound convincing?
That is the point.
22. We can now define the measurement problem
Chapter 1 separated generation from acceptance.
Chapter 2 separated different failure references.
This chapter has now separated the layers between a generated claim and an authorized decision.
The architecture is becoming visible:
graph TD
W[WORLD / ENVIRONMENT] --> ES[evidence sources]
ES --> AV[availability / access]
AV --> RET[retrieval]
RET --> NR[normalized claim c]
subgraph Claim_Resolution
RO[RAW OUTPUT] --> CR[CLAIM RESOLUTION]
CR --> NR
end
NR --> AT[attribution]
NR --> ESET[evidence set]
AT --> SR[support relation]
ESET --> SR
SR --> DR[derivation trace]
DR --> PR[provenance / reliability]
PR --> SU[sufficiency]
SU --> VS[verification state]
VS --> POL[POLICY + INTENDED ACTION]
POL --> ACC[accept]
POL --> RET2[retrieve / review / abstain]
POL --> REJ[reject]
Now we finally have something precise enough to measure.
But the measurement question is still open.
How should software estimate the claim–evidence relation?
Possible answers include:
lexical overlap
embedding similarity
natural-language inference
retrieval scores
self-consistency
model confidence
LLM judges
internal model signals
external fact verification
geometric containment
Each observes something different.
Each can fail differently.
That is the subject of the next chapter.
Research roots
This chapter treats evidence as a systems object: a resolved claim must be related to identifiable support, that support has provenance, temporal scope and claim-specific reliability, verification is a procedural state, and policy determines whether the resulting package is sufficient for an intended action.
-
Wikipedia, “Wikipedia:Verifiability.” The current policy requires facts and claims to be attributable to reliable published sources and directly supported where citations are required. It notes that the older phrase “the threshold for inclusion is verifiability, not truth” is a historical formulation rather than the current policy text. https://en.wikipedia.org/wiki/Wikipedia:Verifiability
-
Wikipedia, “Wikipedia:No original research.” The policy prohibits unpublished synthesis and, in particular, drawing a novel conclusion from multiple sources when the sources themselves do not make that connection. https://en.wikipedia.org/wiki/Wikipedia:No_original_research
-
Wikipedia, “Wikipedia:Reliable sources.” The guideline emphasizes that reliability is contextual: a source must be appropriate for the specific statement it is being used to support. https://en.wikipedia.org/wiki/Wikipedia:Reliable_sources
-
Hannah Rashkin et al., “Measuring Attribution in Natural Language Generation Models,” Computational Linguistics 49(4), 2023, pp. 777–840. Introduces Attributable to Identified Sources (AIS), an evaluation framework for assessing whether generated statements about the external world are corroborated by identified sources. https://aclanthology.org/2023.cl-4.2/
-
Aviv Slobodkin, Eran Hirsch, Arie Cattan, Tal Schuster and Ido Dagan, “Attribute First, then Generate: Locally-attributable Grounded Text Generation,” ACL 2024. Develops fine-grained local attribution by selecting supporting source segments before generation. https://aclanthology.org/2024.acl-long.182/
-
Tobias Schreieder, Tim Schopf and Michael Färber, “Attribution, Citation, and Quotation: A Survey of Evidence-based Text Generation with Large Language Models,” ACL 2026. Surveys 134 papers and 300 evaluation metrics and highlights the fragmentation of terminology and evaluation around evidence-based generation. https://aclanthology.org/2026.acl-long.1430/
-
Rami Aly et al., “FEVEROUS: Fact Extraction and VERification Over Unstructured and Structured information,” NeurIPS Datasets and Benchmarks 2021. Introduces 87,026 claims with evidence from Wikipedia sentences and table cells and labels for support, refutation, or insufficient information. https://arxiv.org/abs/2106.05707
Next: How Do You Measure a Hallucination?
We now have the object that every detector needs but many discussions leave implicit:
resolved claim
+
reference
+
retrieved evidence
+
attribution
+
claim–evidence relation
+
provenance / source fitness
+
sufficiency
+
verification state
+
policy + intended action
The next question is no longer vague.
It is an engineering question:
What observable signal tells us whether a candidate claim is supported by its evidence, and what can that signal not see?
That is where measurement begins.
