Claim/Source Registry for Commercial Content

1) The problem: a hyperlink does not make a claim VERIFIED

A commercial page says “40% faster,” contains a shortened testimonial, and repeats a product limitation from vendor documentation. All three rows have links in a spreadsheet, yet the benchmark population is unclear, the original testimonial is not preserved, and the vendor page later changes. The missing control is not another URL. It is the connection between claim identity, source version, derivation, scope, reviewer and freshness.

2) COM-008 scope: the Claim/Source Registry, not SEO schema or provider routing

This lesson owns Commercial Claim-Source Registry v1. COM-007 owns Provider Routing and COM-009 owns SEO Page Schema. COM-008 does not automatically prove legal or scientific truth, grant publication authority, or treat an external link as permission to publish.

3) Mental model: Source Entity → Extraction Activity → Claim Derivation → Review → Typed State → Publication Gate

Do not store only a generic “source” column. Bind each claim to a versioned source_entity, record the generation_activity that extracted or transformed it, state the derivation relation, identify the responsible reviewer, and preserve a typed result. A broken link in this chain cannot be repaired by guessing a positive state.

4) FACT: PROV distinguishes Entity, Activity and Agent

W3C PROV models provenance with entities, activities and agents and provides relations for generation, usage and derivation. That separation lets us avoid treating the source document, the extraction/rewrite operation and the responsible actor as the same thing. PROV does not decide commercial-claim legality or truth thresholds for MAKNOW.

5) FACT: provenance is more than a URL

The PROV family supports derivation, collections and linking provenance descriptions. An auditable registry can therefore preserve source version, prior entity, derivation and supersession instead of overwriting history when a locator changes.

6) The 21-field registry contract

Each material claim records a stable claim_id, claim type/text/scope, source ID/locator/version, retrieval time, Entity/Activity/Agent, derivation relation, applicability boundary, freshness, review due, reviewer, verification result, dispute, supersession, publication state and evidence reference.

7) Separate claim identity from wording

Claim wording can change through shortening, localization or channel adaptation. If every rewrite becomes an unrelated record, lineage disappears. claim_id carries decision identity; claim_text records the current wording; supersedes_claim preserves replacement history.

8) A source locator is not a source version

A stable URL can show different content today than it did when a claim was reviewed. source_locator says where the source is reached; source_version or a captured retrieval state says what evidence was actually reviewed. A changed source must not inherit the prior VERIFIED state automatically.

9) Applicability boundary is part of the claim

“40% faster” is unsafe to generalize without its baseline, workload, population, region or test conditions. applicability_boundary defines how far the evidence can travel. Removing that boundary from a performance claim must move it out of VERIFIED and may leave only PARTIAL or HOLD.

10) Reviewer and verification result are separate evidence

A source proves that there is something to inspect, not that the claim is supported. A reviewer can record VERIFIED, PARTIAL, DISPUTED, STALE, REJECTED or HOLD, with visible evidence for the choice. Model confidence and citation count are not substitutes for review.

11) Freshness and review due add time to evidence

Some sources are foundational and stable; product documentation and policies can change quickly. freshness_class and review_due define when requalification is required. If the source changes materially after review or the due date passes, the safe state is STALE until review is repeated.

12) Preserve dispute and supersession instead of overwriting history

When reviewers disagree about support, keep dispute_reason. When a new claim replaces an old one, use supersedes_claim to retain lineage. Historical evidence may remain useful without making the superseded claim publishable.

13) Publication state is the final gate, not a synonym for verification

verification_result=VERIFIED matters, but publication must also respect freshness, applicability, dispute and local approval. Missing evidence or broken provenance never becomes publishable merely because a URL or AI-generated explanation exists.

14) Failure modes and correct states

• complete evidence, complete provenance, fresh source, clear support and no material dispute → VERIFIED
• support exists but scope/boundary is incomplete → PARTIAL
• current evidence materially conflicts with historical support or review → DISPUTED
• source/version or review is outdated and has not been rechecked → STALE
• the source does not support the claim → REJECTED
• decisive evidence or provenance is missing → HOLD

15) Lab and transfer: never overwrite an old state with a new source

The lab contains eight offline fixtures and 48 deterministic assertions. In transfer, a revised vendor page no longer contains a previously verified limitation. Preserve the historical source version, register the current source, re-review affected claims, and compute STALE, DISPUTED, HOLD or VERIFIED from current evidence instead of copying the baseline result.