# Veritas Protocol — Architecture Document

**Status:** Working draft v0.1 · *Editor:* Collaborative Fact-Checking Working Group · *Date:* April 2026

> *This document is the top-level architecture reference for the Veritas Protocol. It locks terminology across the working paper, the Mermaid system diagram, the published RFCs (`RFC-CPML-v0.1`, `RFC-FACTCHECK-v0.2`), and the four forthcoming RFCs (`RFC-VERITAS-CASCADE`, `RFC-VERITAS-VC`, `RFC-VERITAS-CPML-REGISTRY`, `RFC-VERITAS-MCP-GROUNDING`). It is the reference any contributor, reviewer, integrator, or external auditor reads first.*

---

## Status of this document

This is the **canonical architecture document** for Veritas Protocol v0.2. It supersedes architecture descriptions scattered across the working paper, the deck, and the brief; where this document and the working paper appear to diverge on a layer-boundary or naming question, this document is authoritative and the paper is to be brought into line.

This is a *working* draft. It will become a normative reference in v0.3, alongside the four forthcoming RFCs that compose the full normative spec stack.

## Abstract

Veritas Protocol v0.2 is a **hybrid chain-plus-federation substrate** for plural, cryptographically verifiable factual claims on the open web. The architecture combines five layers — sources of record, permissionless validators, an Ethereum-L2 chain layer, a federation of aggregators, and a consumer layer — with a **Consensus Profile Markup Language (CPML)** as the resolution device that determines which validators count for any given user. This document defines each layer, the interfaces between them, the on-chain registries, the cascade-event semantics, and the catalog of normative specifications that govern the system.

---

## 1 · Layer model

The protocol is organised into five horizontal layers. Each layer has a well-defined upstream and downstream interface; the layers are not implementations but *roles*, and the same physical service can fill multiple roles in early phases.

```
┌─────────────────────────────────────────────────────────────┐
│  L0 · SOURCES OF RECORD                                     │
│      Journals · courts · government · universities · obs.   │
└────────────────────────┬────────────────────────────────────┘
                         │ primary claims (DOI, URL, hash)
┌────────────────────────▼────────────────────────────────────┐
│  L1 · VALIDATORS · permissionless · mutually-hostile        │
│      Universities · newsrooms · religious traditions ·      │
│      dissident communities · state-aligned · research orgs  │
│      · sub-cultural groups                                  │
└────────────────────────┬────────────────────────────────────┘
                         │ signed attestations (JWS)
┌────────────────────────▼────────────────────────────────────┐
│  L2 · CHAIN LAYER · Ethereum L2 (Base)                      │
│      ┌──────────────┐ ┌──────────────┐ ┌──────────────┐     │
│      │ Attestation  │ │ Cascade      │ │ Validator    │     │
│      │ Registry     │ │ Event Log    │ │ Credential   │     │
│      │              │ │              │ │ Registry     │     │
│      └──────────────┘ └──────────────┘ └──────────────┘     │
└────────────────────────┬────────────────────────────────────┘
                         │ chain events (subscribe + reorg-aware feed)
┌────────────────────────▼────────────────────────────────────┐
│  L3 · FEDERATION LAYER · aggregators · edge cache           │
│      α · β · γ · δ · ε  (independently operated)            │
└────────────────────────┬────────────────────────────────────┘
                         │ composed verdict (per-CPML)
┌────────────────────────▼────────────────────────────────────┐
│  L4 · CONSUMER LAYER · user-owned profile composes verdict  │
│      Browser extension · MCP grounding · CPML profile file  │
└─────────────────────────────────────────────────────────────┘
```

The diagram above is also rendered as `assets/architecture-v0.2.svg` (Mermaid source at `assets/architecture-v0.2.mmd`) and embedded in the working paper as Figure 1.

### 1.1 L0 — Sources of record

Sources of record are external entities that issue **primary claims**: scientific journals (Nature, Science, PNAS, …), courts and legal record-keepers, government statistics offices, universities and research organisations, and verified primary observers. The protocol does *not* operate this layer; sources are external. Veritas merely provides identifiers (DOI, URL, content-hash) that allow validators to attest *about* the content these sources produce.

A source of record is identified by a **Decentralized Identifier (DID)** in normative documents. The paper currently uses `did:web:nature.com`, `did:web:scotus.gov`, etc. as illustrative examples. Specifying which DID methods are normative for L0 is part of `RFC-VERITAS-CASCADE` (forthcoming) — `did:web` alone is not sufficient for high-impact retraction events because of the DNS+ACME compromise vector.

### 1.2 L1 — Validators

Validators are entities that publish **signed attestations** about primary claims from L0. Validation is **permissionless** at the chain-write layer: any holder of a cryptographic identity can post a signed attestation. The protocol does not gatekeep validator participation — by design, it admits validators from communities that consider each other adversarial (state-aligned narratives, ideologically-opposed religious traditions, dissident communities, sub-cultural epistemic groups).

This is the *core design requirement*: a single foundation cannot credentialise validators neutrally across this range, so credentialing happens **post-hoc** at the federation and CPML layers, not pre-hoc at the write layer. See `RFC-VERITAS-VC` (forthcoming) for the verifiable-credential issuance flow used by validators that wish to opt into reputation networks.

The narrow set of operationally-incoherent or universally-criminal claim shapes refused at the write layer (chiefly: attestations verifying CSAM) is governed by `RFC-VERITAS-REFUSAL-LIST` (a concise document whose contents are versioned by the dispute panel).

### 1.3 L2 — Chain layer

The chain layer is an Ethereum Layer 2 rollup. Phase II prototypes on **Base** (the OP Stack rollup operated by Coinbase) with **Optimism** as a Phase III mirror. The chain layer hosts three normative on-chain registries:

#### 1.3.1 Attestation Registry

A content-addressed registry of signed attestations. Each entry binds a `claim_hash` (the canonicalised hash of the claim being attested), a `validator_did`, a `verdict`, a `consensus_domain`, optional `qualifications` (plain text), optional `evidence[]` (URI list), and a `timestamp`. Canonicalisation follows **JSON Canonicalization Scheme (JCS, RFC 8785)** for the attestation envelope and **URDNA2015 (W3C, May 2024)** for any embedded RDF / JSON-LD payload. See `RFC-FACTCHECK-v0.2` § 4.1 for the canonical-hash specification.

#### 1.3.2 Cascade Event Log

An append-only log of **cascade events**: retractions, corrections, supersession notices, and authority transfers. Each event references its source entity, its retraction type (`RETRACTED_BY_SOURCE` vs `RETRACTED_BY_ATTESTATION`), and the dependency graph it propagates through. Cascade semantics — including the velocity throttle, the source-authentication requirement, and the reversal SLA — are specified in `RFC-VERITAS-CASCADE` (forthcoming).

A `RETRACTED_BY_SOURCE` event requires a signature from the original-source authority (or a multi-sig from chapter convenors in the case of a forensic reversal of a forged retraction). A `RETRACTED_BY_ATTESTATION` event is a third-party dispute and does *not* propagate through the cascade graph.

#### 1.3.3 Validator Credential Registry

A registry of **verifiable credentials** issued to validators. Credentials follow **W3C Verifiable Credentials Data Model 2.0** (15 May 2025) and **W3C Decentralized Identifiers v1.0** (19 July 2022; v1.1 currently a Candidate Recommendation). Issuance flows, revocation, and status checking are specified in `RFC-VERITAS-VC` (forthcoming).

### 1.4 L3 — Federation layer

Aggregators independently subscribe to chain events, maintain edge-cached materialised views per consensus domain, and serve **composed verdicts** to consumers. There is no single canonical aggregator; a healthy federation has at least N=5 independently-operated aggregators across geographic and institutional jurisdictions to defend against eclipse attacks (`RFC-VERITAS-FEDERATION` is forthcoming for resync, reorg, and partition-handling specifications — captured as workstream W11).

Aggregators are the *fast path* for AI-grounding queries (target latency: tens of milliseconds). The chain layer is the *cold path* for settlement, permanent record, and economic flow.

### 1.5 L4 — Consumer layer

Consumers query aggregators with their **CPML** as a parameter; aggregators compose the per-consumer verdict from the plural attestation pool under the CPML's resolution rules. Three normative consumer modes are recognised in v0.2:

- **Browser extension** — reads a domain's `/factcheck.json` (per `RFC-FACTCHECK-v0.2`) plus the user's local CPML, surfaces verdicts inline.
- **MCP grounding adapter** — implements the `RFC-VERITAS-MCP-GROUNDING` interface (forthcoming, captured as workstream W8) for AI-laboratory integration. The adapter returns *plain-text-only* `rationale` and `qualifications` fields, with NFKC normalisation, homoglyph / bidi / zero-width filtering, and an explicit "untrusted validator-supplied text" frame in the response envelope (the IPI-safe contract).
- **CPML profile file** — the user-owned configuration file that determines which validators count for which topics, with what weights and what conflict-resolution rules.

---

## 2 · The Consensus Profile Markup Language (CPML)

CPML is the resolution device that distinguishes Veritas from any single-frame fact-checking system. It is specified in `RFC-CPML-v0.1`. Briefly:

- CPML documents are **JSON-LD** with an explicit `@context` registered at the protocol's namespace.
- Documents are **portable, shareable, optionally signed** by their owner.
- Documents are **local-first**: a CPML never reaches centralised storage unless the owner explicitly publishes it.
- Aggregators apply CPMLs in **sub-millisecond time** at query time.

CPMLs encode three things: (a) which **consensus domains** the user trusts, (b) which **validators** within each domain count for them, and (c) the **conflict-resolution rule** for cases where attestations disagree.

### 2.1 The frame-naming convention

Two naming conventions for consensus domains co-exist in v0.2 — this is the single remaining v0.3 CRITICAL issue per the V2 super-review (G1.1):

- **Hyphen-lowercase** (RFC examples): `scientific-default`, `historical-academic-default`, `legal-jurisdiction-eu`.
- **CamelCase path-style** (Working Group instance): `cpml:ScientificConsensus/CochraneGRADE`, `cpml:HumanDignityUDHRFrame`.

`RFC-VERITAS-CPML-REGISTRY` (forthcoming, workstream W6) will pick one convention, publish the registry of canonical domain names, and migrate the working-group instance to match the spec. Until that lands, integrators MUST treat the two conventions as equivalent at parse time and SHOULD prefer hyphen-lowercase for new authoring.

---

## 3 · Specification stack

The full normative specification stack consists of seven RFCs, of which two are published (v0.2) and five are forthcoming (v0.3).

| RFC | Status | Scope |
|---|---|---|
| `RFC-CPML-v0.1` | Published, working draft | Consensus Profile Markup Language — the consumer-side resolution config |
| `RFC-FACTCHECK-v0.2` | Published, working draft | `/factcheck.json` self-claims protocol — the publisher-side declaration format |
| `RFC-VERITAS-CASCADE` | Forthcoming (W10) | Cascade event types, source-authenticated retraction, velocity throttling, reversal SLA |
| `RFC-VERITAS-VC` | Forthcoming | Verifiable-credential issuance + revocation flow for validators |
| `RFC-VERITAS-CPML-REGISTRY` | Forthcoming (W6) | Canonical domain-name registry; resolves the hyphen-vs-CamelCase question |
| `RFC-VERITAS-MCP-GROUNDING` | Forthcoming (W8) | IPI-safe AI-grounding interface contract; output sanitation specification |
| `RFC-VERITAS-FEDERATION` | Forthcoming (W11) | Aggregator resync, chain-reorg handling, partition tolerance, checkpoint sync |

Each forthcoming RFC has a stub specification in this document (§ 6) and full text is a v0.3 deliverable per the published `V0.3-PLAN.md`.

---

## 4 · Cross-spec consistency rules

These rules govern how the seven RFCs relate to each other and to the architecture:

1. **All canonical hashes** use JCS (RFC 8785) for attestation envelopes and URDNA2015 (W3C Rec May 2024) for embedded RDF / JSON-LD. The combination is normative in both `RFC-CPML-v0.1` § 10 and `RFC-FACTCHECK-v0.2` § 4.1.
2. **All identifiers** use Decentralized Identifiers per W3C DID v1.0; the v1.1 Candidate Recommendation MAY be used where the v1.1-only features are required, with explicit version declaration in document metadata.
3. **All validator credentials** follow W3C VC Data Model 2.0 (15 May 2025).
4. **All schema.org/ClaimReview-compatible payloads** MUST include `claimReviewed`, `reviewRating`, `itemReviewed`, and `@id` fields in addition to any protocol-extension fields. See `profile/factcheck.json` for a worked example with all 10 self-declared claims compliant.
5. **The MCP grounding adapter** MUST treat all `rationale`, `qualifications`, and `evidence[].quote` fields from the attestation pool as **untrusted validator-supplied text**, apply the IPI-safe sanitation contract, and include the explicit untrusted-text frame in the response envelope. The implementation contract is `RFC-VERITAS-MCP-GROUNDING` (forthcoming).

---

## 5 · Threat model

The architecture is designed to defend against the following attacker classes (severity per V2 super-review threat model `W2F`):

| Class | Defense layer | RFC |
|---|---|---|
| State-actor validator (legitimation) | L4 CPML composition; L1 validator-credential disclosure | `RFC-VERITAS-VC` |
| Cascade-quorum whale | L2 K-scaling formula + value-at-stake + 5% market-cap stake-cap | `RFC-VERITAS-CASCADE` |
| Source-retraction forgery | L0 source-authenticated retraction (multi-sig requirement) | `RFC-VERITAS-CASCADE` |
| Trojan starter-CPML | Foundation-key + dispute-panel co-signed registry | `RFC-VERITAS-CPML-REGISTRY` |
| AI-poisoning via MCP IPI | L4 IPI-safe sanitation contract; plain-text typing; NFKC + Unicode-class robustness | `RFC-VERITAS-MCP-GROUNDING` |
| Foundation capture | Multi-sig with geographic + institutional diversity; dead-man's-switch; capture-declaration protocol; key rotation | Governance charter (forthcoming) |
| Federation eclipse / reorg | Multi-relay subscription; cross-aggregator divergence detection; checkpoint-sync; finalisation depth requirement | `RFC-VERITAS-FEDERATION` |
| Diagram-driven recon (A12) | Topology obfuscation: aggregator identities not advertised in published diagrams or docs | This document |

The full per-attack analysis is in `critical-review/super-review-2026-04-25-v2/V2-W2F-threat-model.md`.

---

## 6 · Forthcoming RFC stubs

The following stubs commit to scope, deliverables, and dependencies for the five forthcoming RFCs. Full normative text is a v0.3 deliverable.

### 6.1 `RFC-VERITAS-CASCADE` (Workstream W10)

**Scope.** Cascade-event types, source-authenticated retraction, velocity throttling, and reversal SLA.

**Deliverables.**

1. Event-type enum: `RETRACTED_BY_SOURCE`, `RETRACTED_BY_ATTESTATION`, `CORRECTED_BY_SOURCE`, `SUPERSEDED_BY_REVISION`, `AUTHORITY_TRANSFERRED`.
2. Source-authentication requirement: a `RETRACTED_BY_SOURCE` event MUST be signed by the original-source authority's DID and MUST include a transparency-log inclusion proof. Single-DID signing alone is insufficient for high-impact retractions: the event MUST also be co-signed by N-of-M chapter convenors above a published financial-impact threshold.
3. Velocity throttle: `RETRACTED_BY_SOURCE` events propagate through the cascade graph at a rate-limited frequency; high-authority sources require N-block confirmation lag before fan-out.
4. Reversal SLA: forged retractions can be reversed by multi-sig from chapter convenors plus transparency-log inclusion; published procedural commitment to a defined detection-to-reversal window (target: 4 hours).
5. DID-method hardening: `did:web` is acceptable only when paired with HSM-backed signing keys, DNSSEC, and Certificate Transparency monitoring. Alternative methods (`did:plc`, `did:ion`) are RECOMMENDED for high-authority sources.

### 6.2 `RFC-VERITAS-VC` (forthcoming)

**Scope.** Verifiable-credential issuance, revocation, and status checking for validators.

**Deliverables.**

1. Issuer profile: trusted institutional issuers (chapter foundations, accredited credentialing bodies) and self-issued validators.
2. Credential schema: domain-scoped attestation rights (e.g., a credential for `scientific-default` does not authorise attestations in `legal-jurisdiction-eu`).
3. Revocation: status-list 2021 (W3C) for compact revocation checking.
4. Lifecycle: issuance, renewal, revocation, recovery from compromised key.

### 6.3 `RFC-VERITAS-CPML-REGISTRY` (Workstream W6)

**Scope.** Canonical domain-name registry; the resolution of the hyphen-vs-CamelCase question.

**Deliverables.**

1. Registry format: JSON-LD with `@context` registered at the protocol's namespace.
2. Canonical naming decision (hyphen-lowercase recommended): `scientific-default`, `historical-academic-default`, `legal-jurisdiction-eu`, `software-engineering`, etc.
3. Migration path: a one-way mapping from CamelCase aliases to canonical names for a transition period.
4. Governance: domain additions require dispute-panel review with public-comment window.

### 6.4 `RFC-VERITAS-MCP-GROUNDING` (Workstream W8)

**Scope.** IPI-safe AI-grounding interface contract.

**Deliverables.**

1. Output sanitation specification: length limits per field; markup stripping; NFKC normalisation; homoglyph, bidi, zero-width-character filtering.
2. Plain-text typing: `rationale`, `qualifications`, and `evidence[].quote` are typed as plain-text-only — no embedded HTML, no Markdown rendering, no JSON-encoded sub-structure that AI parsers might unpack.
3. Untrusted-text frame: response envelope explicitly marks validator-supplied text with a frame markers that cooperative AI consumers can use to scope-down instruction-execution privileges.
4. Adversarial test suite: a published corpus of IPI test vectors; conformance test for any MCP adapter implementation.
5. Canonical-hash robustness: `RFC-FACTCHECK-v0.2` § 4.1 amended to include NFKC normalisation in the canonical-hash pipeline.

### 6.5 `RFC-VERITAS-FEDERATION` (Workstream W11)

**Scope.** Aggregator resync, chain-reorg handling, partition tolerance, checkpoint sync.

**Deliverables.**

1. Finalisation-depth requirement: 64 blocks on Base / Optimism for definitive cascade fan-out.
2. Reorg handling: rollback procedure for cached aggregations referencing reorged events.
3. Federation-eclipse defense: multi-relay subscription requirement; cross-aggregator divergence detection; user-facing freshness indicator.
4. Checkpoint-sync: daily Merkle-root snapshots attested by N aggregators; new aggregators bootstrap from a recent checkpoint.
5. Resync flow: disconnected-aggregator catch-up protocol; consistency check against checkpoint; published staleness window.

---

## 7 · Naming conventions

The following naming conventions are normative across all Veritas Protocol artefacts (paper, RFCs, instances, code, diagrams):

- **Layer references** use `L0` … `L4` with the role names in this document.
- **Registries** use the exact strings `Attestation Registry`, `Cascade Event Log`, `Validator Credential Registry`.
- **Cascade events** use `UPPER_SNAKE_CASE` (e.g., `RETRACTED_BY_SOURCE`).
- **Consensus-domain identifiers** use hyphen-lowercase (e.g., `scientific-default`); the CamelCase form is a transitional alias.
- **DIDs** use lowercase (e.g., `did:web:example.org`).
- **Workstream identifiers** use `W` + integer (e.g., `W8`).
- **Severity labels** in reviews use the V2 scoreboard convention: `S0` BLOCK-PUBLISH, `S1` HIGH, `S2` MEDIUM, `S3` LOW.

---

## 8 · Reference diagrams + assets

| Asset | Path | Purpose |
|---|---|---|
| Mermaid source | `assets/architecture-v0.2.mmd` | Canonical diagram source; deterministic, version-controlled |
| Mermaid SVG | `assets/architecture-v0.2.svg` | Rendered SVG embedded in landing § 2, paper Figure 1, ELI5 paper § 3 |
| Mermaid PNG | `assets/architecture-v0.2.png` | High-resolution PNG (2400×1800, scale ×2) for slide decks and print |
| Stylised rendering | `assets/architecture-v0.2-rendered.png` | Companion AI-generated rendering via OpenRouter / Gemini 2.5 image (illustrative; minor label artifacts) |

---

## 9 · Architecture appendix A · Consumer-product surfaces (B2C)

The Veritas Protocol architecture is *infrastructure*. Consumer-facing products are built on top of it. This appendix catalogues product surfaces along two axes: (i) the layer they primarily consume, and (ii) whether they require the full protocol (chain + federation + validators in operation) or can ship as **pre-protocol products** that bootstrap demand and dataset before the chain layer is live.

### 9.1 Pre-protocol products (Phase I or independent — ship without chain)

These products consume only L0 (sources of record) and L4 (the user's CPML or equivalent local profile). They do not require the chain layer to exist; they can ship as v1 standalone products and migrate to consume chain attestations once L1–L3 land.

| Product | What it does | Why ship now (without protocol) |
|---|---|---|
| **Veritas Quiz** | A 10-question consensus quiz that produces a starter CPML for the user | Viral-loop on-ramp; builds CPML dataset before any chain attestations exist; produces shareable result graphic |
| **CPML Compass** | "My consensus" + "similar people" + "suggested sources" + "opposite view" — a self-knowledge product about one's own epistemic profile | Consumer-grade product; uses the user's own quiz output + a small foundation-curated validator set; chain integration is additive later |
| **Echo-chamber Meter** | Quantifies how narrow the user's news-source CPML is vs population baselines; suggests broadening reads | Standalone analytics product; consumes RSS/Twitter/social feeds; feeds the foundation's understanding of CPML population shapes |
| **Source Reputation Viewer** | Browser extension or website: shows any publication's track record (retraction count, correction frequency, citation lifecycle, peer-review status) | Existing data sources (Retraction Watch, Crossref, OpenCitations) are sufficient; ships as standalone tool |
| **Citation Chase** | Given any claim or news article, chase the citation chain backward to primary sources; flag broken links and retracted upstream papers | Uses Crossref + Wikidata + Retraction Watch; standalone product; later upgrades to consume chain cascade-event log |
| **News Diet Tracker** | Personal-finance-style "diet" tracker for one's information consumption: which validators dominate your reads, which are missing | Local-first analytics; no chain dependency |
| **Scientific Consensus Widget** | Embeddable JavaScript widget that pulls live consensus on any topic from Wikipedia + Cochrane + GRADE; embed in any blog / news site / document | Uses existing curated sources; widget API stabilises early; later upgrades to consume chain attestations |
| **Receipts** | Paste a tweet or a screenshot → get a "receipt" PDF with provenance breakdown (sources, validators, contradictions, retractions) | Analyser uses LLM + existing data sources; ships independently; viral on social media |
| **Verified-by Badge** | A badge service for journalists / bloggers to embed CPML-style verification snippets next to their claims | Pre-protocol: badge points to a foundation-curated validator set; post-protocol: chain attestations |
| **AI Hallucination Filter** | Browser extension that flags AI-generated text whose claims lack provenance; works against ChatGPT, Claude, Gemini outputs | Pre-protocol: uses existing fact-check APIs + public ClaimReview data; post-protocol: chain attestations + MCP grounding adapter |
| **ClaimCard** | Generate a printable PDF "fact card" for any claim — with all attesting validators, contradicting validators, primary sources, retractions, and topical context | Pre-protocol: foundation-curated; post-protocol: chain-backed |

### 9.2 Protocol-native products (Phase II onward — require chain + federation)

These products consume the full L1–L4 stack and ship after the chain attestation registry, federation aggregators, and CPML composition are operational.

| Product | What it does | Layer(s) consumed |
|---|---|---|
| **Veritas Browser Extension** | Reads a domain's `/factcheck.json` + the user's CPML; surfaces verdicts inline as the user reads the web | L4 (full stack) |
| **Veritas Compass v2** | The protocol-native compass: per-user consensus profile, per-domain verdicts, similar-people graph weighted by chain reputation, suggested-sources from cross-aggregator divergence detection | L1 + L3 + L4 |
| **MCP Grounding Adapter** | OpenAPI- / MCP-compatible service that any AI-laboratory can plug into Claude / GPT / Gemini grounding pipelines | L1 + L3, exposes IPI-safe contract |
| **Investigation Marketplace** | Client-facing site for commissioning investigations: pay, watch the investigation team form, follow progress, get receipts | L1 (validators bid) + treasury contracts |
| **Validator Credential Wallet** | Mobile + web wallet for institutional validators: hold credentials, sign attestations, manage reputation, claim service-fee earnings | L1 + L2 |
| **Cite-Chain** | Academic citation graph viewer with retraction propagation: click any paper to see its cascade-event status, every downstream paper that depends on it, and live reputation of all attesting validators | L0 + L1 + L2 |
| **Chapter Console** | Per-country administration portal for chapters: jurisdiction-specific filter management, dispute-panel coordination, regulator interface | Chapter governance + L1 + L2 |
| **Foundation Treasury Dashboard** | Public dashboard showing treasury holdings, validator-side compensation flows, investigation-market clearance volumes, Path-1..6 economic flows | Chain treasury contracts |
| **Newsroom Verification Suite** | Journalist-facing toolkit: import a draft article, get all claims auto-extracted, see which are corroborated and by whom, attach attestations before publishing | L0 + L1 + publisher API |
| **Educational Publisher Plugin** | Textbook / coursework plugin: every claim auto-linked to live consensus state; updates if a claim becomes contested or retracted | L1 + L3 + publisher API |
| **AI-Lab Grounding Pilot** | The named first AI-laboratory integration — Claude or Mistral or another — with measured hallucination-reduction benchmark | Full L1–L4; the load-bearing economic pilot |

### 9.3 Sequencing recommendation

The natural product sequence (informally) is:

1. **Veritas Quiz** ships first (Phase I, pre-protocol). Quiz produces the dataset that calibrates CPML semantics; viral loop bootstraps user base.
2. **CPML Compass** + **Echo-chamber Meter** + **Source Reputation Viewer** ship as a Phase I product family from the same foundation team.
3. **AI Hallucination Filter** ships as a pre-protocol Chrome extension; serves as the demand-side proof for AI-laboratory Path-5 economics.
4. **Browser extension** + **MCP grounding adapter** ship at Phase II as the protocol-native flagship.
5. **Investigation Marketplace** ships at Phase II once treasury contracts and validator-side compensation flows are operational.
6. The remaining surfaces ship at Phase III as the chapter framework matures and country-specific chapters open.

Investment-mapping: Path 1 (verification centres) and Path 4 (CPML application layer) directly fund the Phase I products. Path 5 (anti-hallucination plugins) directly funds the AI Hallucination Filter and pre-protocol products. See `/investment/` for the six investment paths and unit economics.

---

## 10 · Architecture appendix B · Patentable mechanisms

The following technical mechanisms are candidate filings for the **defensive patent portfolio** described in `/investment/` Path 6. Each represents a specific, novel technical implementation; each requires a freedom-to-operate prior-art search before drafting; the portfolio across all of them — not any single filing — is the operational thesis.

The defensive-only licensing scheme (Open Invention Network model, Patent Pledge, Defensive Patent License, or W3C Royalty-Free Patent Policy) is described in `/investment/` Path 6.

### Filed-or-likely-filed (high novelty, specific implementation)

**P1. Cascading falsification through dependency graphs.**
Method for automatic propagation of retraction events through claim-dependency graphs at chain-anchor velocity. Specific implementation: signed `RETRACTED_BY_SOURCE` events traverse a dependency edge-set computed from prior attestations, applying a velocity-throttle function and N-block confirmation lag. Distinguishes from existing scientific-retraction-notification systems (Retraction Watch, Crossref) by operating on a *plural-validator* attestation pool with on-chain settlement. Specification: `RFC-VERITAS-CASCADE` § 3.

**P2. Source-authenticated retraction protocol.**
Method for distinguishing retractions originating from the source-of-record authority versus third-party disputes; multi-signature requirement above a financial-impact threshold; reversal SLA for forged retractions via chapter-convenor multi-sig. Specifically novel: the *bidirectional* mechanism (forging a retraction is a temporary attack; the protocol publishes a procedural commitment to detection-to-reversal time bounds). Specification: `RFC-VERITAS-CASCADE` § 4–6.

**P3. K-scaling cascade-quorum with value-at-stake and market-cap stake-cap.**
Method for sizing cascade-event quorum requirements as a function of the financial impact of the affected claims (value-at-stake); and capping any single validator's stake at 5% of network market cap to defeat whale attacks. Specifically distinct from existing oracle-quorum mechanisms (UMA, Chainlink) by being *adaptive* to claim-impact rather than fixed-quorum. Specification: `RFC-VERITAS-CASCADE` § 7.

**P4. Tiered-enforcement architecture for content judgments.**
Three-tier system (protocol-write tier / validator-credential tier / user-CPML tier) for the contested space of "harmful content judgments." The protocol-write tier refuses only operationally-incoherent or universally-criminal claim shapes (canonically: CSAM-verification attestations); topical judgments live above. Specifically novel: the *layered separation* with each tier's enforcement bound by a different governance principle. Specification: `RFC-FACTCHECK-v0.2` § 6 + this document § 1.2.

**P5. CPML composition algorithm with VAF-audience semantics.**
Method for client-side composition of per-consumer verdicts from a plural attestation pool, parameterised by a user-owned profile expressing ordinal value-orderings, conflict-resolution rules, and per-domain validator weights. Operates in sub-millisecond time at query time. Specifically novel: the *sub-millisecond client-side composition* of plural attestations under a user-owned profile, with VAF-consistent formal semantics under one of three formal-grounding paths. Specification: `RFC-CPML-v0.1` § 9.

**P6. Foundation-key-signed CPML registry with dispute-panel co-signature.**
Method for distributing trusted starter-CPMLs without exposing the registry to single-key compromise; foundation key + dispute-panel multi-sig requirement; key-rotation on board transitions; dead-man's-switch for capture detection. Specifically novel as a *governance-recovery primitive* embedded in the cryptographic distribution mechanism. Specification: `RFC-VERITAS-CPML-REGISTRY` (forthcoming) + governance charter.

**P7. IPI-safe AI-grounding interface contract.**
Method for embedding signed-attestation `rationale` and `qualifications` text into AI-laboratory grounding pipelines without exposing the language model to indirect-prompt-injection attacks via the rationale field. Specifically novel: the *output-sanitation contract with explicit untrusted-text frame*, plain-text typing, NFKC normalisation, homoglyph / bidi / zero-width filtering, and a published adversarial test suite for conformance. Specification: `RFC-VERITAS-MCP-GROUNDING` § 4.

**P8. Cross-validator reputation composition under EigenTrust-family algorithms applied to plural-frame validators.**
Method for computing per-domain validator reputation across mutually-hostile validator cohorts without forcing a single global ordering. Specifically novel: the *domain-scoped* reputation math (a validator can be simultaneously high-reputation in `scientific-default` and zero-reputation in `legal-jurisdiction-eu`) computed from cross-attestation agreement signals.

**P9. Investigation-market matching with reputation-weighted auto-assignment, anti-collusion enforcement, and jurisdictional-diversity requirements.**
Method for routing investigation commissions to qualified validators, with anti-collusion enforcement via prior-shared-attestation analysis, jurisdictional-diversity requirements (cannot quorum from one country), and reputation-floor thresholds. Specifically distinct from existing prediction-market and dispute-resolution patents by being *investigation-commissioning* rather than outcome-prediction.

**P10. Federation-aggregator divergence detection with consumer-facing freshness indicator.**
Method for detecting when a subset of federation aggregators is serving stale or inconsistent data, with a user-visible freshness indicator and an automatic switchover to multi-relay subscription. Specifically novel: the *consumer-visible* divergence signal, coupled with the protocol-level multi-relay requirement.

### Possibly-filed (lower individual probability, useful as portfolio depth)

**P11. Schema.org/ClaimReview extension with plural-verdict + cascade-event semantics.**
Specific JSON-LD profile extending schema.org/ClaimReview with `verdictsByDomain` and `cascadeEventLog` fields, while remaining backward-compatible with Google's Fact Check Tools.

**P12. Per-country chapter-framework for jurisdictional filter sovereignty.**
Method for an open protocol to comply simultaneously with mutually-conflicting national content laws (German Holocaust-denial law vs US First Amendment vs Singapore POFMA, etc.) by partitioning the filter layer per chapter while sharing the underlying attestation pool.

**P13. Self-claims `/factcheck.json` declaration format.**
Specific schema and discoverability mechanism for sites to publish first-party factual self-claims, with claim-hash identity, per-domain verdicts, third-party-attestation references, and an event-feed mechanism for retraction propagation. (`RFC-FACTCHECK-v0.2`.)

### Not-filed (open-standards / prior-art / non-patentable)

The following are *not* candidates for filing because they are open standards, prior art, or non-patentable subject matter:

- Use of blockchain or Ethereum L2 generally
- Use of digital signatures / public-key cryptography
- Use of W3C Verifiable Credentials, DIDs, JCS, URDNA2015
- Use of schema.org / JSON-LD
- The general concept of fact-checking
- The general concept of consensus or epistemic communities
- The general concept of plural verdicts

### Filing strategy

Estimated portfolio size: **10–20 filings** (P1–P13 plus 5–7 follow-on continuations) across United States (USPTO), European Union (Unitary Patent), Japan (JPO), and China (CNIPA). The filing window is constrained by the EPC Article 54 absolute-novelty rule with only the narrow Article 55 exceptions; the working paper has been publicly disclosed since April 2026, so material disclosed in v0.2 may have already begun losing patentability in EPO-bound jurisdictions outside the Article 55 exceptions. The 35 U.S.C. § 102(b)(1) 12-month grace period in the United States expires in April 2027 for v0.2 disclosures.

Per `/investment/` Path 6, the foundation files defensively and commits the portfolio to a defensive-only license under one of the established frameworks (OIN, Patent Pledge, Defensive Patent License, or W3C Royalty-Free Patent Policy). The investor return shape is *foundation-equity-equivalent* (board seat, governance influence) plus the option of a "patent participation certificate" tied to enforcement-driven income from non-aligned commercial users.

Estimated cost: ~$50K–$120K per US patent (life of portfolio), ~$60K–$140K per EU unitary patent. Total portfolio cost: ~$2M for a 10–20-filing portfolio across the four jurisdictions.

---

## 11 · References

- Working paper: `paper/VERITAS-PROTOCOL-WHITEPAPER.md`
- CPML specification: `spec/cpml/RFC-CPML-v0.1.md`
- factcheck.json specification: `spec/factcheck/RFC-FACTCHECK-v0.2.md`
- Working Group's own CPML: `profile/working-group-cpml.json`
- Working Group's own factcheck.json: `profile/factcheck.json`
- v0.3 plan with workstreams W1–W11: `critical-review/V0.3-PLAN.md`
- V1 super-review master: `critical-review/super-review-2026-04-25/SUPER-REVIEW.md`
- V2 super-review master: `critical-review/super-review-2026-04-25-v2/SUPER-REVIEW-V2-2026-04-25.md`
- Investment paths (1–6): `investment/index.html`
- Architecture diagram: `assets/architecture-v0.2.{mmd,svg,png}`

---

## 12 · Comments and contributions

This document is a working draft. Comments, proposed amendments, and corrections are welcome through the contact form on the brief, or as pull requests against the `homototus/veritas-protocol` repository. The v0.3 publication will incorporate accepted amendments alongside the five forthcoming RFCs.

---

*Drafted as the canonical architecture reference for v0.2.2 (post-V2-super-review hotfixes) and the v0.3 spec stack. Cross-referenced from `paper/`, `critical-review/V0.3-PLAN.md`, and the Mermaid architecture source. Editorial conventions follow the working-paper voice. — Collaborative Fact-Checking Working Group, April 2026.*