# RFC-CPML-v0.1 — Consensus Profile Markup Language

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

> *This document specifies the Consensus Profile Markup Language (CPML), a portable, signable file format that lets a reader, AI agent, or institution declare which validators and consensus domains they trust for which topics, with what weights and conflict-resolution rules. CPML is consumed by Veritas Protocol aggregators to compose per-consumer verdicts from the plural attestation pool.*

---

## Status of this document

This is a working-paper draft circulated for review. It is **not** an Internet-Engineering-Task-Force RFC. The format follows IETF conventions (RFC 2119 keywords, ABNF grammar, JSON-LD context registration) so the draft can be submitted upstream without restructuring.

A future formal track is anticipated through the **W3C Credentials Community Group** as an input document, with cross-references to **IETF SCITT** for the underlying transparency-log layer. Comments and proposed amendments are welcome — see § 14.

The CPML format described here is **informal** in its formal-semantics commitments. Section 8 specifies one of three formal-grounding paths under consideration. The path selected before v1.0 finalisation will replace § 8 with the chosen formal model.

## Abstract

A Consensus Profile Markup Language (CPML) document encodes the consensus preferences of a reader, AI agent, institution, or community. Aggregators in the Veritas Protocol consume CPML at query time to compose per-consumer responses from the plural attestation pool — selecting which validators count, which consensus domains to weight, and how to resolve conflicts between them.

CPML is JSON-LD with an explicit `@context` registered at `https://veritas-protocol.example/cpml/v0.1`. Documents are portable, shareable peer-to-peer, and optionally cryptographically signed by their owner. The format is designed for client-side processing: an aggregator can apply a CPML in sub-millisecond time, and the CPML itself never reaches centralised storage unless its owner explicitly publishes it.

## 1 · Introduction

### 1.1 Motivation

The Veritas Protocol's plural-verdict design records signed attestations from many validator institutions, scoped to named consensus domains. A claim may carry verdicts from `scientific-default`, `historical-academic-default`, `legal-jurisdiction-eu`, and several other domains simultaneously. The protocol does not pick a single verdict on behalf of consumers.

Consumers — readers, AI agents, browsers, downstream applications — therefore need a deterministic mechanism to compose a per-consumer verdict from the attestation pool. CPML is that mechanism.

### 1.2 Design principles

Three principles constrain the design.

**Principle 1 — User sovereignty.** The reader's signing key (or the implicit-anonymous-key of an unsigned profile) is the **sole authority** on which CPML applies. No third-party labelling-bureau may assert a profile on behalf of a user without explicit consent. This is a deliberate inversion of the W3C PICS 1996 architecture.

**Principle 2 — Local-first.** The default storage location is the user's device. Cloud-sync is opt-in per device. Sharing is opt-in per recipient. CPML is **never** required to be uploaded to centralised infrastructure.

**Principle 3 — Composability.** CPMLs may extend, fork, or compose. A user may declare "use the Working Group's published CPML and override these specific weights." A community may publish a starter CPML for members to subscribe to. CPML semantics MUST permit deterministic resolution of inheritance.

### 1.3 Conformance keywords

The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC 2119].

## 2 · Terminology

The following terms have specific meaning in this document:

- **Attestation** — a signed statement by a validator that a specific claim has a specific verdict under a specific consensus domain.
- **Consensus domain** — a named editorial frame (e.g. `scientific-default`, `journalism-default`, `legal-jurisdiction-eu`) under which validators issue verdicts.
- **CPML document** — a JSON-LD file conforming to this specification.
- **CPML owner** — the entity whose preferences the CPML expresses; identified by a Decentralized Identifier (DID) when signed, or anonymous when unsigned.
- **Validator** — an institution or party that issues signed attestations.
- **Aggregator** — a service that indexes attestation events from the protocol layer and serves CPML-composed read responses.
- **Resolver** — a client-side library implementing the CPML semantics defined in § 5 (and § 8).

## 3 · Document structure

A CPML document is a JSON-LD object with the following top-level structure:

```json
{
  "@context": "https://veritas-protocol.example/cpml/v0.1",
  "@type": "ConsensusProfile",
  "id": "urn:cpml:<ownerHandle>:<sequenceNumber>",
  "version": "0.1",
  "owner": {
    "@id": "did:web:example.org",
    "name": "Example Reader"
  },
  "issued": "2026-04-25T00:00:00Z",
  "expires": "2027-04-25T00:00:00Z",
  "domains": [],
  "validators": { "trust": [], "distrust": [] },
  "conflict": {},
  "display": {},
  "topics": {},
  "extends": [],
  "proof": {}
}
```

Every field MUST appear except `expires`, `extends`, and `proof`, which are OPTIONAL. The semantics of each field are specified in §§ 4–8.

### 3.1 `id`

A globally-unique identifier for this CPML document. Format: `urn:cpml:<owner-handle>:<sequence>`. The sequence number monotonically increases with each revision by the same owner.

### 3.2 `version`

CPML schema version. MUST be `"0.1"` for documents conforming to this specification.

### 3.3 `owner`

The CPML owner's identity. When signed (§ 9), the owner's DID MUST match the public key used for the `proof` field. When unsigned, `owner` MAY be `{"@id": "urn:cpml:anonymous"}` and `name` MAY be omitted.

### 3.4 `issued` / `expires`

ISO 8601 timestamps. `issued` is REQUIRED. `expires` is OPTIONAL; if absent, the CPML is valid until the owner publishes a successor with a higher sequence number.

## 4 · `domains` — consensus-domain subscription

Each entry in the `domains` array declares a subscribed consensus domain with weight and topic scope:

```json
{
  "name": "scientific-default",
  "weight": 1.0,
  "topics": ["science", "medicine", "climate"],
  "minValidators": 2,
  "minReputation": 0.5
}
```

- `name` (REQUIRED) — the domain identifier as registered in the Veritas Domain Registry. See [Veritas Domain Registry] (forthcoming reference).
- `weight` (REQUIRED) — a value in the range [0, 1]; the resolver SHOULD interpret as a relative-importance multiplier.
- `topics` (REQUIRED) — an array of SKOS-style topic concepts (see § 6) under which this domain applies. Empty array means "all topics."
- `minValidators` (OPTIONAL) — the minimum number of independent validators that must have attested in this domain for a verdict to count for the consumer.
- `minReputation` (OPTIONAL) — a floor on validator reputation (see § 7).

The same domain MAY appear with different `topics` and weights — for example, the same user may weight `scientific-default` highly for `topics: ["science"]` but lower for `topics: ["history"]`.

## 5 · `conflict` — composition rules

The `conflict` object specifies how the resolver composes a verdict when multiple subscribed domains return verdicts that disagree. Required field:

```json
"conflict": {
  "rule": "show-disagreement",
  "tiebreak": "highest-weight",
  "minValidatorsPerVerdict": 2
}
```

Permitted `rule` values:

- `"show-disagreement"` — return all verdicts with their domains, do not collapse.
- `"weighted-average"` — return a single composed verdict computed as a weighted average over `domains`.
- `"highest-weight-wins"` — return the verdict from the highest-weighted subscribed domain only.
- `"unanimous-or-disputed"` — return a verdict only if all subscribed domains agree; otherwise mark `DISPUTED`.

The `tiebreak` field applies when `rule` produces ambiguity. Permitted values: `"highest-weight"`, `"highest-validator-count"`, `"latest"`, `"oldest"`.

`minValidatorsPerVerdict` (OPTIONAL) is a floor on the number of validators required for a verdict to be surfaced at all.

## 6 · `topics` — SKOS topic mapping

The `topics` field defines the topic vocabulary used in `domains.topics` and `topics` (per-topic overrides). CPML uses **SKOS** (Simple Knowledge Organization System; W3C Recommendation 2009) as its topic vocabulary substrate.

A reference SKOS hierarchy is published at `https://veritas-protocol.example/topics/v0.1.skos`. Owners MAY extend the topic vocabulary with custom concepts; resolvers MUST handle unknown topics gracefully (treat as "no opinion").

Per-topic overrides may be specified inline:

```json
"topics": {
  "biology:genetic-engineering": {
    "domains": [
      { "name": "scientific-default", "weight": 1.0 },
      { "name": "ethics-bioethics-default", "weight": 0.7 }
    ]
  },
  "history:eastern-european-modern": {
    "conflict": { "rule": "show-disagreement" }
  }
}
```

A topic-override matches a claim if the claim's declared topic concept (per its `topic` field, see RFC-FACTCHECK) is a SKOS-narrower-or-equal of the override key.

## 7 · `validators` — explicit trust / distrust

```json
"validators": {
  "trust": [
    "did:web:royalsociety.org",
    "did:web:reuters-fact-check.com"
  ],
  "distrust": [
    "did:web:known-disinformation-actor.example"
  ],
  "reputation": "use-aggregator-default"
}
```

- `trust` — explicit list of validator DIDs whose attestations MUST be surfaced when relevant, regardless of their reputation score.
- `distrust` — explicit list of validator DIDs whose attestations MUST NOT be surfaced.
- `reputation` — the reputation algorithm to apply. Default value `"use-aggregator-default"` defers to the aggregator's published reputation algorithm. Custom value `"eigentrust:v0.1"` selects a specific algorithm; aggregators MAY refuse to honour custom algorithms they do not implement.

## 8 · `display` — rendering preferences

```json
"display": {
  "show_falsified": "suppress",
  "show_contested": "surface-honestly",
  "show_unsupported": "flag",
  "show_retraction_pending": "mark-with-warning",
  "surprising_opposite_view": "daily",
  "minimum_attestation_age_days": 7
}
```

- `show_falsified`: `"suppress"` | `"flag"` | `"show-with-warning"` (default `"suppress"`).
- `show_contested`: `"surface-honestly"` | `"hide"` (default `"surface-honestly"`).
- `show_unsupported`: `"flag"` | `"surface-as-is"` (default `"flag"`).
- `show_retraction_pending`: `"mark-with-warning"` | `"suppress"` (default `"mark-with-warning"`).
- `surprising_opposite_view`: `"daily"` | `"weekly"` | `"monthly"` | `"never"` (default `"weekly"`). The aggregator surfaces a high-quality claim from outside the user's subscribed domains at this cadence, as a deliberate echo-chamber-counter.
- `minimum_attestation_age_days` (OPTIONAL) — minimum age in days before an attestation is surfaced; defends against rapid-cascade weaponisation.

## 9 · Formal semantics

CPML's formal-grounding path is under selection. Three options are documented:

**Path A — Value-based Argumentation Framework audiences (Bench-Capon 2003 + Amgoud–Vesic 2011).** CPML expresses a `value-ordering` over arguments; conflict resolution by Dung-style extension semantics (preferred / stable / grounded). Substantial formal work. Reference resolver in development at [reference-impl-vaf-cpml] (forthcoming).

**Path B — Probabilistic-logic preference network.** CPML expresses a Bayesian network over claim-truth-likelihood given consensus-domain agreement. Conflict resolution by marginalisation. Comparable to recent academic work on "trust networks for collective inference" (specific references forthcoming).

**Path C — Engineering-pragmatic.** CPML's semantics are defined operationally by the reference resolver in this document; no claim to a specific formal framework. Path C is the path of v0.1; a future v1.0 SHOULD select Path A or Path B if a defensible implementation exists.

This document specifies Path C operational semantics in the rest of § 9.

### 9.1 Operational semantics

Given a CPML `P` and a set of attestation events `E` returned by the aggregator for a claim `C`:

1. **Filter by domain subscription.** Retain events `e ∈ E` such that `e.domain ∈ P.domains[*].name`.
2. **Filter by topic.** For each retained event, find the deepest matching topic in `P.topics`. If no match, fall back to `P.domains[*]`.
3. **Filter by validator policy.** Remove events from validators in `P.validators.distrust`. Force-include events from validators in `P.validators.trust` regardless of reputation.
4. **Apply minimum-validators / minimum-reputation thresholds** per § 4.
5. **Apply minimum-attestation-age** per § 8.
6. **Compose verdict** per `P.conflict.rule`.
7. **Apply display preferences** per § 8.

Resolvers SHOULD process this pipeline in approximately constant time per claim (after caching of the validator-reputation table).

## 10 · Cryptographic signing

CPML documents MAY be cryptographically signed by their owner. When signed:

```json
"proof": {
  "type": "DataIntegrityProof",
  "cryptosuite": "eddsa-jcs-2022",
  "created": "2026-04-25T00:00:00Z",
  "verificationMethod": "did:web:example.org#keys-1",
  "proofPurpose": "assertionMethod",
  "proofValue": "z58DAdFfa9SkqZMVPxAQpic7..."
}
```

The proof MUST be a Data Integrity Proof per [W3C Verifiable Credentials Data Integrity 1.0]. Canonicalisation of the unsigned document MUST follow JSON Canonicalization Scheme (JCS) [RFC 8785].

Signed CPMLs MAY be published publicly (e.g. shared on a website). Aggregators receiving a signed CPML SHOULD verify the signature; verification MUST happen client-side or in a fully-trusted aggregator runtime.

## 11 · Inheritance (`extends`)

A CPML MAY declare inheritance from one or more parent CPMLs:

```json
"extends": [
  "https://veritas-protocol.example/profile/working-group-cpml-v0.1.json"
]
```

When inheritance is declared, the resolver applies the parent CPMLs first (in order), then overlays the current CPML's fields. Conflicts are resolved by last-wins semantics for non-array fields; array fields (`domains`, `validators.trust`, `validators.distrust`) are merged with deduplication.

Cyclic inheritance MUST be rejected. Resolvers SHOULD enforce a maximum inheritance depth (RECOMMENDED: 4).

## 12 · Privacy and data-handling

CPML documents are local-first by design. The following operational guidance applies:

- Aggregators SHOULD accept CPMLs as part of a single query without retaining them beyond the request lifecycle.
- Aggregators MUST NOT log full CPML content. Logs MAY include the CPML `id` and a content hash.
- A CPML containing PII (e.g. `owner.name`, validator-trust list revealing the user's intellectual-political alignment) is sensitive data under GDPR. Owners SHOULD prefer anonymous CPMLs unless explicit signing is intended.
- Sharing a signed CPML implies consent to public observation of the contained preferences.

## 13 · Reference vocabulary

The reference SKOS topic vocabulary is published at:

`https://veritas-protocol.example/topics/v0.1.skos`

Top-level concepts:

- `science` (with narrower: `physics`, `biology`, `chemistry`, `earth-sciences`, `medicine`, `climate`, `psychology`, `social-sciences`)
- `history` (with narrower: `ancient`, `medieval`, `modern`, `regional-`*)
- `economics`
- `politics-and-policy`
- `law` (with narrower: `legal-jurisdiction-`*)
- `philosophy-and-ethics`
- `religion-and-spirituality`
- `culture-and-arts`
- `technology` (with narrower: `software`, `ai`, `cryptography`, `engineering`)
- `health-and-medicine` (cross-listed with `science:medicine`)
- `media-and-journalism`

Owners MAY extend with custom topics; canonical extensions are coordinated through the Veritas Working Group registry.

## 14 · Open questions

This document leaves the following open:

- **Formal semantics path.** § 9 documents three options. Path selection requires philosophy + formal-methods consultation; expected resolution in the v0.3 working paper.
- **Reputation algorithm.** § 7 defers to aggregator default. A canonical reference algorithm (likely an EigenTrust variant) is named in the working paper but not yet specified.
- **Validator-credential issuance.** CPML references validator DIDs; the credentialing process (W3C Verifiable Credentials) is specified separately in RFC-VERITAS-VC (forthcoming).
- **Discovery / registry of starter CPMLs.** A canonical signed registry is required to defeat the "trojan starter-CPML via SEO" attack (sentinel §6.1). RFC-VERITAS-CPML-REGISTRY (forthcoming).
- **Topic-vocabulary governance.** The reference SKOS hierarchy at `/topics/v0.1.skos` requires a maintainer body; possibly hosted at the Working Group registry.

## 15 · References

- [RFC 2119] — Key words for use in RFCs to Indicate Requirement Levels.
- [RFC 8785] — JSON Canonicalization Scheme (JCS).
- [W3C Verifiable Credentials Data Integrity 1.0] — https://www.w3.org/TR/vc-data-integrity/
- [W3C Decentralized Identifiers (DIDs) v1.1] — https://www.w3.org/TR/did-1.1/
- [W3C SKOS Reference] — https://www.w3.org/TR/skos-reference/
- [JSON-LD 1.1] — https://www.w3.org/TR/json-ld11/
- [Bench-Capon 2003] — Bench-Capon, T. *Persuasion in Practical Argument Using Value-based Argumentation Frameworks*. J. Logic Computation 13(3), 2003.
- [Amgoud-Vesic 2011] — Amgoud, L., & Vesic, S. *A new approach for preference-based argumentation frameworks*. Annals of Mathematics and Artificial Intelligence 63, 2011.

## 16 · Change history

- **v0.1** — Initial working draft (April 2026). Path C operational semantics; Path A and Path B documented as candidates.

---

*Comments on this draft: see the contact form at https://veritas-working-paper.pages.dev/#participate or the public repository at github.com/homototus/veritas-protocol.*