Claim/Evidence Governance and Confidence

1. The real problem: many citations do not create valid confidence

A pipeline can accumulate citations, provenance, and signatures while still failing to identify what each claim precisely says and which evidence supports or contradicts that bounded claim. If confidence comes from source count or source prestige, a confident sentence can outlive its evidence or survive a version change. This lesson builds Claim–Evidence Ledger & Confidence Decision Record v1, where every claim has identity, scope, evidence links, freshness, contradiction state, and recheck triggers.

2. Make each claim an addressable unit

Give every claim a stable claim_id, bounded text, and explicit claim_scope. A broad statement such as “this feature works offline” is usually unsafe when the evidence only covers version v3.2 and one workflow. When evidence scope is narrower than claim scope, narrow the claim instead of stretching the evidence.

3. Source authority is not claim support

CON-001 decides which source is canonical and how an exact source version is bound. CON-002 consumes that binding but asks a different question: does this evidence support this exact bounded claim? An official source may be authoritative about a nearby topic without proving the current claim. Keep authority, relevance, and sufficiency separate.

4. PROV-O is lineage, not truth

PROV-O models provenance with Entity, Activity, Agent, and relations such as wasDerivedFrom. It is excellent for answering where evidence came from and how it was generated. Correct provenance alone does not establish that a human-readable claim is true, complete, or fit for reliance. Provenance is a required dimension, not a confidence shortcut.

5. C2PA provides provenance signals, not a truth verdict

C2PA combines assertions, claims, signatures, and content bindings in manifests, while validation provides tamper-evidence and trust signals. The specification deliberately avoids value judgments about whether provenance data is good, bad, or substantively true. Therefore c2pa_valid=true never means claim_supported=true by itself.

6. Record typed, directional evidence

For every evidence item record evidence_id, evidence_type, source_binding_ref, retrieved_at, review_due, provenance, and direction. Direction is explicit: supports, contradicts, or neutral/context. An item may support only one slice of a claim. Do not confuse topical relevance with support.

7. Support and contradiction can coexist

Claim governance must preserve opposing evidence instead of deleting whichever side is inconvenient. A deterministic test may support a bounded version claim while a newer release note contradicts broad wording. Keep both records, split or restrict the claim, and carry the contradiction into the current decision.

8. Freshness is a real clock

retrieved_at tells you when evidence was collected; reliance needs review_due or another explicit trigger. When decisive evidence becomes stale, former confidence must not survive automatically. Current status can become RESTRICTED_STALE or REQUALIFY while historical evidence and prior decisions remain auditable.

9. A confidence label needs an explicit rule

If you use LOW/MEDIUM/HIGH, define the semantics in advance: which evidence is required, how contradictions affect the label, how freshness participates, and which claim scope is covered. Do not write HIGH=0.93 unless an actual calibration method and calibration data exist. An ordinal label is not a probability.

10. Confidence basis must be inspectable

Store a confidence_basis that points to evidence IDs and explicit rules. Example: “HIGH only for scope=v3.2/offline-cache; E1 official version-bound + E2 fresh deterministic test; no active contradiction.” A reviewer must be able to audit the basis without hidden model reasoning.

11. Type the current claim state

Distinguish at least SUPPORTED_BOUNDED, RESTRICTED_SCOPE, RESTRICTED_STALE, RESTRICTED_CONFIDENCE, RESTRICTED_OR_UNSUPPORTED, and UNSUPPORTED. Do not coerce UNKNOWN into true or false. When a decisive binding is missing or evidence is insufficient, downstream systems need the exact restriction.

12. Preserve history; change current status

When new evidence contradicts a previous claim, do not delete or rewrite historical claim/evidence events. Update the current record with a new reason, timestamp, and recheck trigger. The audit trail should explain why reliance was allowed at T1 and restricted at T2.

13. Decision records need non-claims

A strong decision states not only what is supported, but what is not established. For example: “this ledger does not decide rights, approval validity, or release composition.” Explicit non-claims prevent confidence from leaking into CON-003 through CON-005.

14. Transfer: version changed, old evidence is no longer enough

Run the Bible transfer: keep the same claim family, let E2 expire after a version change, and add a fresh contradictory test. Do not copy the old decision. Recompute support, contradiction, freshness, and binding. Until new bounded evidence closes the gap, the claim remains RESTRICTED_OR_UNSUPPORTED.

15. Final artifact and reliance boundary

Claim–Evidence Ledger & Confidence Decision Record v1 records Claim ID/Text/Scope, Source Binding, Evidence IDs/Types, Support/Contradiction Links, Retrieved/Review Due, Freshness State, Confidence Label/Basis, Current Claim Status, Residual Uncertainty, Recheck Trigger, and Provenance. This lesson does not select source authority, decide rights, issue approvals, or assemble releases. It determines only what bounded reliance is defensible for this claim from the current evidence.