# RFC-VERITAS-CPML-REGISTRY-v0.1 — Canonical Consensus-Domain Registry

**Status:** Working draft v0.1 · *Workstream:* W6 (super-review-2026-04-25 V2-W2G § G1.1) · *Editor:* Collaborative Fact-Checking Working Group · *Date:* April 2026

> *This document specifies the canonical naming, registration, and migration of consensus-domain identifiers used in `RFC-CPML-v0.1` and the broader Veritas Protocol stack. It resolves the hyphen-lowercase vs CamelCase ambiguity that the V2 super-review identified as the single remaining v0.2 CRITICAL finding (G1.1).*

---

## Status of this document

This is a working-paper draft. It is not yet an Internet-Engineering-Task-Force RFC. Once stabilised in v0.3, it will be submitted upstream as a companion document to `RFC-CPML-v0.1` through the W3C Credentials Community Group.

Comments and proposed amendments are welcome. See § 9.

## Abstract

The Veritas Protocol's plural-verdict design records signed attestations scoped to named **consensus domains**. Two naming conventions co-exist in v0.2 working artefacts: a hyphen-lowercase form (`scientific-default`) used in `RFC-CPML-v0.1` examples, and a CamelCase path-style form (`cpml:ScientificConsensus/CochraneGRADE`) used in the Working Group's own published CPML instance. The V2 super-review (V2-W2G § G1.1) identified this as a CRITICAL spec contradiction: an aggregator implementing per the spec would match zero domains in the Working Group's own profile. This RFC selects the hyphen-lowercase form as the canonical convention, publishes the initial registered set of canonical domain names, defines the migration protocol from the CamelCase aliases, and specifies the governance for adding new domains.

This RFC normatively binds the **consensus-domain identifier** field used in `RFC-CPML-v0.1` § 4.1, `RFC-FACTCHECK-v0.2` § 5.2 (`verdictsByDomain`), and the L2 Attestation Registry's `consensus_domain` column described in `spec/ARCHITECTURE.md` § 1.3.1.

## 1 · Introduction

### 1.1 Motivation

`RFC-CPML-v0.1` § 4.1 introduces consensus domains as named scopes for verdict composition: a claim may carry verdicts from `scientific-default`, `historical-academic-default`, `legal-jurisdiction-eu`, and several other domains simultaneously, and the user's CPML decides which domains to include and at what weight. The spec text uses hyphen-lowercase identifiers consistently in its examples.

The Working Group's own published CPML instance (`profile/working-group-cpml.json`) instead uses identifiers of the shape `cpml:ScientificConsensus/CochraneGRADE`, `cpml:HumanDignityUDHRFrame`, `cpml:DefensiveDecentralizedTechFrame`. This shape was chosen by the Working Group editor when authoring the instance to express richer ontological structure (a path-style CamelCase identifier carries the parent frame and the qualification in one identifier). The CPML spec did not prescribe the form, so both conventions co-existed in v0.2.

The V2 super-review aggregator concluded (V2-W2G § G1.1):

> "An aggregator implementing per the spec would match zero domains in the Working Group's own profile. … `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."

This RFC discharges that obligation.

### 1.2 Scope

This document specifies:

- the **canonical naming convention** (§ 3),
- the **initial registered domain set** (§ 4),
- the **migration table** from the prior CamelCase aliases (§ 5),
- the **registration governance process** for adding new domains (§ 6),
- the **`@context` and JSON-LD encoding** of the registry (§ 7),
- **conformance requirements** for aggregators, CPML authors, and validators (§ 8).

Out of scope:
- The semantics of any individual consensus domain (left to the editorial bodies that define each domain).
- The composition algorithm that combines per-domain verdicts (specified in `RFC-CPML-v0.1` § 9).
- The validator-credential issuance that scopes a validator's right to attest within a domain (specified in `RFC-VERITAS-VC` forthcoming).

### 1.3 Terminology

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**, **SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **MAY**, and **OPTIONAL** are interpreted as in BCP 14 (RFC 2119, RFC 8174) when they appear in all capitals.

- **Consensus domain** — a named scope for verdict composition. A claim may carry distinct verdicts from multiple domains.
- **Canonical name** — the hyphen-lowercase identifier registered for a consensus domain, e.g. `scientific-default`.
- **Alias** — a deprecated CamelCase identifier that maps deterministically to a canonical name during the migration window.
- **Registry** — the published JSON-LD document at the protocol's well-known URL listing all registered canonical names with their metadata.

## 2 · Architecture context

The consensus-domain identifier is a primary key in three independent registries:

1. **L2 Attestation Registry** (`spec/ARCHITECTURE.md` § 1.3.1) — every attestation carries a `consensus_domain` field that scopes the verdict.
2. **CPML documents** (`RFC-CPML-v0.1` § 4.1) — every CPML's `domains[]` array contains identifiers that select which attestations the user trusts.
3. **factcheck.json instances** (`RFC-FACTCHECK-v0.2` § 5.2) — every claim's `verdictsByDomain` map keys verdicts by domain identifier.

For these three registries to interoperate, all three MUST use the same identifier form for the same domain. The hyphen-lowercase canonical form chosen here is the binding decision.

## 3 · Canonical naming convention

### 3.1 Decision

The canonical form for consensus-domain identifiers is **hyphen-lowercase** with no namespace prefix. Examples:

```
scientific-default
historical-academic-default
legal-jurisdiction-eu
software-engineering
journalism-default
ethics-bioethics-default
```

### 3.2 Rationale

The hyphen-lowercase form is selected over the alternative CamelCase path-style for the following reasons:

- **Consistent with `RFC-CPML-v0.1` examples**, which use this form throughout. Choosing this form does not require modifying the published CPML spec text.
- **Easier to parse**, more URL-safe, and avoids the `:` namespace-prefix ambiguity with CURIE syntax already used in JSON-LD `@context` declarations.
- **Lower-bandwidth** — no internal capitalisation rules to memorise; no parent-frame / qualifier separation that risks ambiguity when domains evolve.
- **Convention-aligned** with the way W3C SKOS, Wikidata, and similar registries pattern their identifiers.

The CamelCase path-style form was expressive but introduced parser ambiguity (was `cpml:ScientificConsensus/CochraneGRADE` one identifier or two?) and split-naming complexity that the hyphen-lowercase form avoids.

### 3.3 Lexical rules

A canonical consensus-domain identifier:

- MUST match the regex `^[a-z][a-z0-9]*(-[a-z0-9]+)*$`
- MUST be 4 to 64 octets long (inclusive)
- MUST consist solely of lowercase ASCII letters, digits, and hyphens
- MUST NOT begin or end with a hyphen
- MUST NOT contain consecutive hyphens
- MUST NOT collide with any value already in the canonical set

These rules are enforced by the registry's reference validator at registration time.

### 3.4 Suggested taxonomy convention

Beyond the hard lexical rules, the Working Group RECOMMENDS (but does not require) a taxonomy convention:

- Top-level domain identifiers use a single token: `scientific-default`, `journalism-default`, `legal-default`.
- Sub-domain identifiers use `<parent>-<modifier>` form: `scientific-default-cochrane-grade`, `historical-academic-default-revisionist`, `legal-jurisdiction-eu`.
- Per-jurisdiction modifiers use ISO 3166-1 alpha-2 lowercase: `legal-jurisdiction-de`, `legal-jurisdiction-us`, `journalism-jurisdiction-jp`.

This is RECOMMENDED, not REQUIRED — exact taxonomy choices remain editorial decisions of the registering bodies, subject to § 6 governance review.

## 4 · Initial registered domain set

The initial v0.3 registered set, in canonical hyphen-lowercase form, replacing the v0.2 CamelCase aliases used in `profile/working-group-cpml.json`:

| Canonical name | Brief | Editorial steward |
|---|---|---|
| `scientific-default` | Mainstream-academic scientific consensus on empirical questions; reviewer pool drawn from credentialed academic institutions and peer-reviewed publishers. | Veritas Foundation Science Council |
| `scientific-default-cochrane-grade` | Sub-domain restricting to Cochrane systematic-review and GRADE-graded evidence for biomedical questions. | Cochrane-affiliated reviewers + foundation oversight |
| `scientific-default-academy-consensus` | Sub-domain restricting to claims that hold consensus across at least three independent national academies. | National-academy delegates + foundation oversight |
| `scientific-default-ipcc` | Sub-domain restricting to IPCC-aligned climate-science consensus. | IPCC-affiliated reviewers |
| `scientific-default-peer-review-mainstream` | Sub-domain encompassing the broader peer-reviewed-mainstream pool without the Cochrane / academy-consensus filters. | Peer-reviewed publishers + foundation oversight |
| `historical-academic-default` | Mainstream-academic historical scholarship; reviewer pool drawn from credentialed history departments and peer-reviewed historical journals. | Foundation Historical Studies Steward |
| `historical-academic-revisionist` | Historical scholarship in the revisionist tradition (within academic norms); kept editorially distinct from `default` to surface scholarly disagreement honestly without collapsing it into a single verdict. | Revisionist-tradition academic editors |
| `journalism-default` | Mainstream-journalism editorial standards; reviewer pool drawn from publications adhering to IFCN-aligned editorial codes. | IFCN-aligned editors + foundation oversight |
| `legal-jurisdiction-eu` | Legal claims scoped to European Union law and EU-court rulings. | EU-law Bar Association reviewers |
| `legal-jurisdiction-us` | Legal claims scoped to United States law and US-court rulings. | US-law Bar Association reviewers |
| `software-engineering` | Software-engineering technical consensus; reviewer pool drawn from open-source maintainers, IETF / W3C participants, and credentialed engineering academics. | Open-source maintainers + foundation oversight |
| `cosmopolitan-pluralism` | Cross-cultural pluralism frame: claims about multiculturalism, diversity, cosmopolitan ethics; explicitly admits multiple traditions. | Foundation Ethics Steward |
| `human-dignity-udhr` | Claims anchored to the Universal Declaration of Human Rights and adjacent UN instruments. | Foundation Ethics Steward |
| `evidence-based-progress` | Claims about social progress measured against empirical evidence (life expectancy, child mortality, literacy, etc.). | Foundation Ethics Steward + Statistics Council |
| `defensive-decentralized-tech` | Claims about decentralised technology design (d/acc-anchored); explicitly admits the engineering-pragmatic tradition. | Foundation Tech Steward |
| `philosophy-academic` | Claims in academic philosophy; reviewer pool drawn from credentialed philosophy departments. | Foundation Philosophy Steward |
| `religious-comparative-academic` | Claims about religious traditions, scoped to comparative-religion academic scholarship; explicitly does NOT adjudicate theological truth. | Foundation Religious Studies Steward |
| `ethics-bioethics-default` | Mainstream bioethics consensus; reviewer pool drawn from peer-reviewed bioethics journals and credentialed bioethics committees. | Foundation Bioethics Steward |
| `culture-and-arts` | Claims about cultural and artistic facts (provenance, attribution, historical context). | Foundation Cultural Steward |
| `earth-sciences` | Claims about Earth-science consensus (geology, climate, oceanography). | Foundation Earth Sciences Steward |
| `health-and-medicine` | Claims about clinical medicine and public health; complementary to `scientific-default-cochrane-grade` for general-medicine questions. | Foundation Health Steward |
| `media-and-journalism` | Claims about media-and-journalism practice (NOT about claims reported BY journalists — that is `journalism-default`). | Foundation Media Studies Steward |

This set is the **v0.3 initial registry**. Subsequent registrations follow § 6.

## 5 · Migration table (v0.2 → v0.3)

The migration is a one-way mapping from the v0.2 CamelCase aliases (used in `profile/working-group-cpml.json` and any other v0.2 instance) to the canonical v0.3 hyphen-lowercase identifiers.

| v0.2 alias (deprecated) | v0.3 canonical |
|---|---|
| `cpml:ScientificConsensus/CochraneGRADE` | `scientific-default-cochrane-grade` |
| `cpml:ScientificConsensus/AcademyConsensus` | `scientific-default-academy-consensus` |
| `cpml:ScientificConsensus/IPCC` | `scientific-default-ipcc` |
| `cpml:ScientificConsensus/PeerReviewMainstream` | `scientific-default-peer-review-mainstream` |
| `cpml:HistoricalAcademicMainstream` | `historical-academic-default` |
| `cpml:HistoricalAcademicRevisionist` | `historical-academic-revisionist` |
| `cpml:JournalismMainstream` | `journalism-default` |
| `cpml:CosmopolitanPluralismFrame` | `cosmopolitan-pluralism` |
| `cpml:HumanDignityUDHRFrame` | `human-dignity-udhr` |
| `cpml:EvidenceBasedProgressFrame` | `evidence-based-progress` |
| `cpml:DefensiveDecentralizedTechFrame` | `defensive-decentralized-tech` |
| `cpml:PhilosophyAcademic` | `philosophy-academic` |
| `cpml:ReligiousComparativeAcademic` | `religious-comparative-academic` |

### 5.1 Migration window

A six-month migration window beginning at v0.3 publication is established. During the window:

- Aggregators MUST accept BOTH the v0.2 alias and the v0.3 canonical form, and MUST treat them as identical for verdict composition.
- CPML authors SHOULD migrate their `domains[]` arrays to the canonical form.
- factcheck.json publishers SHOULD migrate their `verdictsByDomain` map keys.
- The Working Group's own `profile/working-group-cpml.json` instance MUST be migrated to canonical form before the v0.3 publication date.

After the migration window, the v0.2 aliases are removed from the registry's normative set. Aggregators MAY continue to accept them as a courtesy but are not required to.

### 5.2 Migration tooling

The Veritas Foundation publishes a reference migration utility (`veritas-cpml-migrate`) that takes a v0.2 CPML or factcheck.json document and produces the v0.3-canonical form. The utility is available before v0.3 publication so that early adopters can migrate before the deadline.

## 6 · Registration governance

### 6.1 Adding a new domain

A new consensus-domain identifier MAY be added to the registry through the following process:

1. **Proposal submission** — a registration proposal is submitted to the Veritas Foundation. The proposal MUST include: the proposed canonical name (compliant with § 3.3 lexical rules); a one-paragraph editorial brief defining the domain's scope; a proposed editorial steward; a public-comment URL; the proposer's contact information.
2. **Editorial review** — the foundation's editorial board verifies the proposal: lexical compliance, non-collision, editorial-brief clarity, steward identification.
3. **Public-comment window** — the proposal is published for 30 days of public comment on the foundation's transparency channel.
4. **Dispute-panel review** — at the end of the comment window, the dispute panel reviews comments and votes. Approval requires simple majority for non-controversial domains, supermajority (7-of-9) for domains that would create or affect a politically- or religiously-sensitive scope.
5. **Registry update** — approved proposals are added to the registry document with a new revision number; registry consumers MUST refresh.

### 6.2 Renaming or retiring a domain

Renaming an existing canonical name is generally NOT ALLOWED — it would break every CPML and factcheck.json that references the old name. Exceptions require dispute-panel supermajority and a six-month migration window from the prior name to the new name.

Retiring a domain (removing it from the canonical set) requires dispute-panel supermajority and a public-comment window. Retired domains are marked `retired` in the registry but their identifiers continue to resolve so that historic attestations remain interpretable.

### 6.3 Steward changes

Editorial-steward changes (e.g., a new institutional steward replacing a prior one) follow a lighter process: simple majority of the dispute panel after a 14-day public-comment window. Steward changes do not affect the canonical name itself.

## 7 · Registry document encoding

The registry is published as a JSON-LD document at the well-known URL `https://veritas-protocol.example/registry/cpml-domains/v0.3.jsonld`. Consumers fetch the document and cache it; the document carries a freshness-policy header that aggregators MUST honour.

Document shape:

```jsonld
{
  "@context": "https://veritas-protocol.example/cpml-registry/v0.1",
  "@type": "ConsensusDomainRegistry",
  "version": "0.3.0",
  "publishedAt": "2026-04-28T00:00:00Z",
  "validUntil": "2027-04-28T00:00:00Z",
  "registrySigners": [
    "did:plc:foundation-registry-key-2026"
  ],
  "domains": [
    {
      "@type": "ConsensusDomain",
      "canonicalName": "scientific-default",
      "brief": "Mainstream-academic scientific consensus on empirical questions; reviewer pool drawn from credentialed academic institutions and peer-reviewed publishers.",
      "steward": "did:plc:foundation-science-council",
      "registeredAt": "2026-04-28T00:00:00Z",
      "aliases": []
    },
    {
      "@type": "ConsensusDomain",
      "canonicalName": "scientific-default-cochrane-grade",
      "brief": "Sub-domain restricting to Cochrane systematic-review and GRADE-graded evidence for biomedical questions.",
      "steward": "did:plc:cochrane-affiliated",
      "registeredAt": "2026-04-28T00:00:00Z",
      "aliases": ["cpml:ScientificConsensus/CochraneGRADE"]
    }
  ]
}
```

The `aliases[]` field carries the v0.2 CamelCase alias (or aliases) that map to this canonical name during the migration window.

The registry document itself MUST be signed by the foundation's registry-signing key. Aggregators MUST verify the signature before consuming the registry.

## 8 · Conformance requirements

### 8.1 Aggregators

Aggregators MUST:

- Refresh the registry document at least every 24 hours.
- Reject CPML documents and factcheck.json instances that reference identifiers not in the registry's canonical or alias set.
- Treat aliases and their canonical names as identical for verdict-composition purposes during the migration window.
- After the migration window, accept only canonical names; reject aliases (or accept them with a deprecation warning to the consumer).

### 8.2 CPML authors

CPML authors MUST:

- Use canonical hyphen-lowercase identifiers in `domains[]` arrays.
- Migrate v0.2 CamelCase aliases to canonical names within the migration window.
- Use the migration utility `veritas-cpml-migrate` if migrating multiple documents.

### 8.3 Validators

Validators MUST:

- Use canonical names in the `consensus_domain` field of attestations recorded on the L2 Attestation Registry.
- Hold a verifiable credential (per `RFC-VERITAS-VC` forthcoming) that authorises attestations within the specific domain. A credential for `scientific-default-cochrane-grade` does NOT authorise attestations in `legal-jurisdiction-eu`.

### 8.4 Test corpus

The Veritas Foundation publishes a test corpus including:

- a v0.2 CPML and a v0.3 CPML for each registered domain,
- correctly-failing examples (lexically invalid identifiers, non-existent canonical names, expired aliases),
- the migration utility's expected outputs for each input.

Implementations claiming conformance MUST pass the corpus.

## 9 · Comments and amendments

This document is a working draft. Comments are welcomed via the contact form on the brief. The v0.3 finalisation pass will incorporate accepted amendments. Significant scope amendments (adding or retiring a domain that crosses politically-sensitive boundaries) trigger an additional dispute-panel review.

## 10 · References

- `spec/ARCHITECTURE.md` § 2.1 (frame-naming convention) and § 6.3 (this RFC's stub).
- `spec/cpml/RFC-CPML-v0.1.md` § 4.1 (domain identifier field).
- `spec/factcheck/RFC-FACTCHECK-v0.2.md` § 5.2 (`verdictsByDomain` field).
- `spec/cascade/RFC-VERITAS-CASCADE-v0.1.md` (cascade events use canonical domain identifiers in `eventType` payload metadata).
- `super-review-2026-04-25-v2/V2-W2G-spec.md` § G1.1 — the audit finding this RFC closes.
- `profile/working-group-cpml.json` — the v0.2 instance to be migrated under § 5.
- W3C SKOS — registry-naming conventions.
- IETF RFC 5234 — ABNF (used in § 3.3 lexical-rules regex).

---

*Drafted as workstream W6 deliverable for v0.3, closing super-review V2-W2G § G1.1. Cross-referenced from `spec/ARCHITECTURE.md` and `critical-review/V0.3-PLAN.md`. Comments welcome. — Collaborative Fact-Checking Working Group, April 2026.*