# RFC-FACTCHECK-v0.2 — Self-Claims Reporting Protocol **Status:** Working draft v0.2 · *Editor:* Collaborative Fact-Checking Working Group · *Date:* April 2026 > *This document specifies the `/factcheck.json` self-claims reporting protocol — the simplest entry-point to Veritas. Any website may publish a `/factcheck.json` file declaring the factual claims it makes, with provenance, verification status, and per-domain verdicts. Veritas aggregators ingest these declarations as a baseline layer; third-party validators may then cross-attest.* > > *This is the v0.2 specification, extending the original v0.1 spec at `homototus/veritas/SPEC.md`. v0.2 adds claim-hashing, plural per-domain verdicts, third-party-attestation references, and event-feed support.* --- ## Status of this document This is a working-paper draft. v0.1 of this protocol was published at `github.com/homototus/veritas/SPEC.md` (April 2026). v0.2 extends v0.1 with: - **Stable claim-hash identity** (cross-site claim matching) - **Per-domain verdicts** (`verdictsByDomain`) - **Third-party-attestation references** (`thirdPartyAttestations[]`) - **Event-feed mechanism** for retraction propagation - **Topic tagging** via SKOS concepts (cross-references RFC-CPML) v0.2 is **backwards-compatible** with v0.1 readers: a v0.1 reader may parse a v0.2 document and ignore the new fields without semantic loss. ## Abstract A self-claims reporting protocol allows any website to publish a structured, cryptographically-identifiable record of the factual claims it makes, the sources backing those claims, the verification status of each, and the identity of whoever performed the verification. The format extends [schema.org/ClaimReview], adds stable cross-site claim identity, and supports plural per-domain verdicts as specified in RFC-CPML-v0.1. The protocol is intentionally minimal. It does not require a blockchain, a foundation membership, or tooling beyond a static-file webserver. It works as the simplest on-ramp to the broader Veritas Protocol architecture: a website publishes its self-declared claims; third-party validators cross-attest; cascading retractions reach readers automatically. ## 1 · Overview A site participating in this protocol publishes two files at well-known paths: - `/factcheck.json` — machine-readable claim registry (this specification) - `/factcheck` (or `/transparency` or `/claims`) — human-readable rendering of the same data Discovery is via a `` tag in the site's ``: ```html ``` A v0.2-conformant reader (browser extension, AI agent, search-engine crawler, Veritas aggregator) recognises this link and consumes the document. ## 2 · Document structure A `/factcheck.json` document is JSON-LD with the following top-level structure: ```json { "@context": "https://schema.org", "@type": "ClaimReviewCollection", "url": "https://example.org/factcheck", "datePublished": "2026-04-25", "author": { "@type": "Organization", "name": "Example Organisation", "url": "https://example.org", "did": "did:web:example.org" }, "claims": [] } ``` Each entry in `claims` is a v0.2-extended ClaimReview record: ```json { "@type": "ClaimReview", "claimHash": "sha256:1aef...", "claimGroupId": "urn:claim:example.org:climate-2024-degraded-land", "claimText": "Bolivia has approximately 10 million hectares of degraded land.", "claimType": "FACT", "topic": "climate:land-degradation", "language": "en", "url": "https://example.org/research/climate-bolivia", "datePublished": "2026-04-12", "sources": [ { "claimHash": "sha256:upstream-1...", "uri": "https://example-source.org/study/bolivia-2023", "role": "primary-evidence" } ], "evidence": [ { "uri": "ipfs://bafy...", "contentHash": "sha256:e1..." } ], "method": "documentary-review", "checkerIdentity": { "name": "Jane Researcher", "did": "did:web:example.org:jane", "role": "Senior Researcher" }, "primaryVerdict": "SUPPORTED", "verdictsByDomain": { "scientific-default": { "verdict": "SUPPORTED", "validators": 3, "lastChecked": "2026-04-12" }, "journalism-default": { "verdict": "VERIFIED", "validators": 2, "lastChecked": "2026-04-15" } }, "thirdPartyAttestations": [ "https://factcheck-org.example/attestations/abc123.jws" ], "qualifications": "Estimate; 2023 measurement methodology has acknowledged uncertainty bounds of ±15%.", "disputeLog": [], "confidenceScore": 0.78 } ``` ## 3 · Required and optional fields ### 3.1 Required fields - `claimText` — exact text of the claim as it appears on the site. - `claimHash` — content-addressed hash; see § 4. - `claimType` — one of `FACT`, `OPINION`, `PROJECTION`, `ARGUMENT`. See § 5. - `url` — URL of the page where the claim appears. - `primaryVerdict` — one of the values in § 6. ### 3.2 Optional fields All other fields are OPTIONAL but RECOMMENDED. Specifically: - `claimGroupId` — stable identifier across editorial revisions (see § 4.2). - `topic` — SKOS-aligned topic concept (RFC-CPML § 6 vocabulary). - `language` — IETF BCP 47 language tag. - `sources[]` — upstream claim references. - `evidence[]` — content-addressed primary-source artefacts. - `method` — verification methodology description. - `checkerIdentity` — the person or system that performed the check. - `verdictsByDomain` — per-consensus-domain verdicts (see § 7). - `thirdPartyAttestations[]` — pointers to external validator attestations (see § 8). - `qualifications` — caveats to be displayed alongside the claim. - `disputeLog[]` — record of disputes raised against this claim. - `confidenceScore` — a value in [0, 1]. ## 4 · Claim hashing ### 4.1 Canonical-form hash The `claimHash` is computed as `"sha256:" + hex(SHA-256(canonical(claimText)))`, where `canonical()` applies the following normalisation: 1. Convert to NFKC Unicode normalisation form. 2. Lowercase all letters. 3. Replace any sequence of whitespace (including U+00A0, U+2000–U+200A, U+202F, U+205F, U+3000) with a single ASCII space. 4. Strip leading and trailing whitespace. 5. Remove zero-width joiners and non-printable characters. 6. Encode as UTF-8 byte sequence. This produces a stable hash across minor formatting variations. Two claims with semantically-identical text but different punctuation/case/whitespace MUST produce the same hash. ### 4.2 Claim groups For claims that undergo editorial revision (e.g., the same fact asserted with slightly different wording in a 2026 article and a 2027 update), authors SHOULD assign a stable `claimGroupId` so that downstream tools can track the claim across versions. The format is `urn:claim::`. When a claim is revised, the new version SHOULD include a `revises` field pointing to the prior claim hash, plus the same `claimGroupId`. ## 5 · Claim types ``` | Type | Description | |-------------|---------------------------------------------------------------------------| | FACT | Verifiable data point (number, date, measurement, identity, event). | | OPINION | Subjective judgment, value statement, interpretation. | | PROJECTION | Forward-looking estimate, prediction, scenario forecast. | | ARGUMENT | Logical reasoning chain — "if A then B" — not a single empirical claim. | ``` A claim's type SHOULD be declared honestly. Mis-typing (presenting an opinion as a fact) is a substantive editorial choice that aggregators MAY surface. ## 6 · Verdict values ``` | Value | Meaning | |-------------------|------------------------------------------------------------------------| | VERIFIED | Confirmed against an independent, authoritative primary source. | | SUPPORTED | Consistent with available evidence; not independently confirmed. | | QUALIFIED | True with caveats / conditions that significantly affect interpretation. | | UNVERIFIED | No verification attempted; no source available. | | DISPUTED | Actively contested by credible counter-evidence. | | RETRACTED | Withdrawn following retraction of upstream source(s) or new evidence. | | CASCADE_PENDING | An upstream source has been retracted or disputed; re-evaluation due. | ``` `primaryVerdict` is the verdict the site's author has chosen as the canonical answer. `verdictsByDomain` MAY override per-domain. ## 7 · Per-domain verdicts A v0.2-conformant document MAY include a `verdictsByDomain` field expressing the verdict under each named consensus domain (RFC-CPML § 4). Each entry is: ```json "": { "verdict": "", "validators": , "lastChecked": "", "rationale": "" } ``` When `verdictsByDomain` is present, downstream tools SHOULD prefer the per-domain verdict over `primaryVerdict` when composing a response under a specific user CPML. ## 8 · Third-party attestation references External validators (per Veritas Protocol § 5.3) may publish attestations over a claim hash. The `thirdPartyAttestations` field lists URLs (or content-addressed pointers) to such attestations. Each referenced attestation MUST be a JSON Web Signature [RFC 7515] over a Veritas Protocol attestation record. Aggregators verify these signatures client-side; the publishing site does not authenticate the attestation it merely references. This is the architectural bridge from the simple `/factcheck.json` self-declaration model to the full Veritas Protocol federated-validator model: a site publishes its self-claim; third-party validators cross-attest; the site's `/factcheck.json` lists the cross-attestations; aggregators stitch them together. ## 9 · Event-feed mechanism Sites participating in v0.2 SHOULD publish an event feed that downstream consumers can subscribe to for retraction-propagation purposes: `/factcheck/events.json` Format: a chronologically-ordered list of events of the form: ```json { "id": "evt:example.org:2026-04-25:001", "claimHash": "sha256:1aef...", "claimGroupId": "urn:claim:example.org:...", "type": "RETRACTED", "atomicEventTime": "2026-04-25T14:32:00Z", "rationale": "Upstream source X retracted; original claim no longer supported.", "supersededBy": "sha256:newclaim...", "signature": "..." } ``` Permitted `type` values: `PUBLISHED`, `UPDATED`, `RETRACTED`, `CASCADE_TRIGGERED`, `DISPUTED`, `RE_VERIFIED`. Subscribers (Veritas aggregators, browser extensions, downstream apps) poll the feed periodically OR subscribe via libp2p GossipSub topic `factcheck-events:`. ## 10 · Compliance and discovery A site declaring conformance with v0.2 of this specification MUST: 1. Publish `/factcheck.json` at the root of its primary HTTPS-served domain. 2. Include the `` discovery tag in its `` of pages making factual claims. 3. Update `datePublished` whenever the document changes. 4. Publish `/factcheck/events.json` for every claim revision or retraction event. 5. Make the document accessible via standard HTTPS (no authentication required for read access). A site MAY: - Sign the document via [W3C Data Integrity Proofs] for authenticity. - Publish a versioned history at `/factcheck/v.json`. - Cross-publish to IPFS or other content-addressed storage. ## 11 · Privacy and personal data `/factcheck.json` is publicly readable. Authors MUST NOT include personal data of third parties in `claimText`, `evidence`, or `thirdPartyAttestations` references unless that data is already public. For claims about individuals, the protocol respects the right to be forgotten (GDPR Article 17): owners MAY remove a claim from `/factcheck.json` and publish a corresponding `RETRACTED` event. The `claimHash` MAY remain in transparency logs (cryptographic hashes are not personal data per CNIL guidance), but the underlying `claimText` should not be stored on immutable infrastructure. ## 12 · Backward-compatibility with v0.1 A v0.1 reader (per `homototus/veritas/SPEC.md`) parsing a v0.2 document SHOULD: - Extract `claimText`, `url`, `primaryVerdict` (mapping from v0.2 `primaryVerdict` to v0.1 `status`). - Ignore `claimHash`, `claimGroupId`, `verdictsByDomain`, `thirdPartyAttestations`, `events`. - Continue functioning normally. A v0.2 reader parsing a v0.1 document SHOULD: - Compute `claimHash` from `claimText` per § 4.1 (so that even legacy claims acquire an identity). - Treat `status` as `primaryVerdict`. - Issue no warnings about missing v0.2 fields. ## 13 · Examples ### 13.1 Minimal v0.2 example ```json { "@context": "https://schema.org", "@type": "ClaimReviewCollection", "url": "https://example.org/factcheck", "datePublished": "2026-04-25", "author": { "@type": "Organization", "name": "Example Organisation" }, "claims": [ { "@type": "ClaimReview", "claimText": "We have served over one million customers since 2018.", "claimHash": "sha256:abcd1234...", "claimType": "FACT", "url": "https://example.org/about", "primaryVerdict": "SUPPORTED", "qualifications": "Internal CRM count; not externally audited." } ] } ``` ### 13.2 Full v0.2 example with per-domain verdicts and third-party attestations See § 2 for a representative full example. ## 14 · Open questions - **Topic vocabulary governance** — § 7 references SKOS topics from RFC-CPML; both specs depend on a maintained reference SKOS hierarchy. Maintainership is unresolved. - **Event-feed signing** — the `signature` field in event records MUST be specified more precisely (which DID, which crypto-suite, which canonical form). - **Cross-site claim-hash collision** — two semantically-different claims could produce the same canonical hash (extremely unlikely but possible). The `claimGroupId` partial-mitigation should be formalised. - **Retraction-cascade authentication** — RFC-VERITAS-CASCADE (forthcoming) specifies how a retraction is authenticated as originating from the source. ## 15 · References - [schema.org/ClaimReview] — https://schema.org/ClaimReview - [Veritas /factcheck v0.1] — github.com/homototus/veritas/SPEC.md - [RFC 7515] — JSON Web Signature. - [RFC 8259] — JSON. - [RFC 8785] — JSON Canonicalization Scheme. - [W3C Data Integrity Proofs] — https://www.w3.org/TR/vc-data-integrity/ - [RFC-CPML-v0.1] — Sibling specification; this document. ## 16 · Change history - **v0.1** — Original /factcheck protocol at homototus/veritas/SPEC.md. - **v0.2** — This document. Adds claim-hashing, per-domain verdicts, third-party attestation references, event feed, topic tagging. --- *Comments on this draft: see https://veritas-working-paper.pages.dev/#participate.*