# 04 — CPML: Consensus Profile Markup Language

> *A user-owned, machine-readable description of which consensus frames you trust for which topics, under what weights, with what conflict-resolution rules. The layer where plural verdicts become personal.*

## Why CPML

The plural-verdict architecture leaves a problem: when a claim has verdicts from multiple consensus domains — say, `scientific-default: supported` and `religious-traditional: disputed` — the protocol does not pick one. It records both. The consumer must compose a response.

Options for where composition happens:

1. **Aggregator decides** — one editorial policy per aggregator. Problem: collapses plurality back to single verdict at the aggregator layer.
2. **Client decides with ad-hoc rules** — every app and AI agent writes its own composition logic. Problem: fragmented, non-portable, politically inconsistent.
3. **User decides via a structured profile** — a Consensus Profile Markup Language (CPML) file that encodes the user's trust in named consensus domains, with rules for conflict resolution. Portable, inspectable, shareable, editable.

CPML is option 3. The user (or AI agent, or institution) authors a CPML; the protocol honours it; different CPMLs produce different composed verdicts for the same claim.

## Design

### Shape

A CPML is a JSON-LD document (or TOML; format is open) with four sections:

```jsonc
{
  "@context": "https://veritas-protocol.example/cpml/v0.1",
  "@type": "ConsensusProfile",
  "version": "1",

  // 1. Domains the profile subscribes to, with weights and topic scope
  "domains": [
    {
      "name": "scientific-default",
      "weight": 1.0,
      "topics": ["science", "medicine", "climate", "technology"]
    },
    {
      "name": "historical-academic-default",
      "weight": 1.0,
      "topics": ["history"]
    },
    {
      "name": "orthodox-jewish-traditional",
      "weight": 0.7,
      "topics": ["ethics", "religion", "family-law"]
    }
  ],

  // 2. Validator-level overrides (trust / distrust specific validators)
  "validators": {
    "trust": ["did:web:royalsociety.org", "did:web:nber.org"],
    "distrust": ["did:web:badactor.example"]
  },

  // 3. Conflict-resolution rule when domains disagree
  "conflict": {
    "rule": "show-disagreement",   // "pick-highest-weight" | "weighted-score" | "show-disagreement"
    "min_validators_per_verdict": 2
  },

  // 4. Filter and display preferences
  "display": {
    "show_falsified": "suppress",
    "show_contested": "surface-honestly",
    "show_unsupported": "flag",
    "show_retraction_pending": "mark-with-warning",
    "surprising_opposite_view": "daily"
  }
}
```

### Operations

- **Resolve a claim** — given a claim hash and a CPML, fetch attestations for subscribed domains, apply weights, apply conflict rule, return composed verdict + metadata.
- **Edit a CPML** — a consumer-side editor lets users tune weights, add/remove domains, adjust conflict rules.
- **Share a CPML** — export as a file; share via URL, email, or social. CPMLs are shareable identities.
- **Fork a CPML** — take someone else's CPML as a starting point and modify it.
- **Verify a CPML** — optionally sign a CPML with the user's DID so others can verify it is authentic.

### Starter CPMLs

Most users will not author CPMLs from scratch. The foundation publishes a small number of named starter CPMLs, each with a published editorial rationale:

- `cpml:minimal-evidence` — weights only evidence-first domains; minimal politics; maximal uncertainty.
- `cpml:scientific-first` — scientific-default highest; all other domains lower; opposite-view surfacing daily.
- `cpml:journalism-mainstream` — journalism-default + scientific-default; surfaces disagreement cross-domain.
- `cpml:academic-plural` — explicitly weights multiple academic traditions including minority or heterodox ones; conflict-resolution surfaces disagreement.

Users select one at onboarding and modify. Third parties publish their own starter CPMLs — conspiracy-research, religious-traditions, political-orientations. No foundation approval required; users opt into them explicitly.

### Privacy

CPMLs are local-first. Stored in the user's browser, app, or device. Uploaded to cloud only on explicit opt-in, for cross-device sync or sharing. The protocol never requires centralised CPML hosting. Aggregators can receive a CPML as part of a query (`POST /v1/check?cpml=...`) but should not retain it beyond the request.

### Signature and attestation

A user may optionally sign their CPML with their DID. Signed CPMLs can be shared as portable identities — "here is my public consensus profile" — and third parties can verify the signature. Unsigned CPMLs are also valid; the anonymous case is the default.

## Critical analysis

**1 — The starter CPML is the default; most users never edit it.** The starter CPML becomes a political object. Response: publish 4–6 starter CPMLs with materially different editorial stances, and require onboarding users to *choose* among them (not accept an automatic default). Document each starter's rationale publicly.

**2 — CPML editing is too much friction for general users.** Response: the consensus-quiz MVP (`07-quiz-mvp.md`) does the heavy lifting of initial CPML authorship. Users answer 10–20 questions; a CPML is generated. Ongoing refinement is low-friction (one question / day; toggle specific weights).

**3 — CPML can be weaponised to create filter bubbles.** Users will pick CPMLs that confirm their priors; plural verdicts collapse back to single-frame inside their chosen bubble. Response: CPMLs include an explicit `surprising_opposite_view` field. Default CPMLs set it to "daily." UX surfaces calibrated disagreement. This is not a technical fix — it is a design commitment to forcing some exposure.

**4 — A signed CPML is a political identifier.** Signing "this is my public consensus profile" makes the user's epistemic commitments legible to adversaries. In some jurisdictions, this is risky. Response: signing is strictly opt-in; default is anonymous; UX warns users clearly what signed public CPMLs imply.

**5 — CPMLs fragment; no two users have exactly the same profile.** Aggregators cannot cache compositions by CPML. Response: aggregators cache per-domain attestations (the expensive part) and apply CPML at the edge in milliseconds. Composition per unique CPML is cheap.

**6 — CPML specification becomes a contested standard.** Other projects may propose competing schemas (e.g., a W3C working group). Response: use W3C Verifiable Credentials / JSON-LD semantics wherever possible so CPML is discoverable and interoperable. Propose CPML as a W3C Community Group input document early in Phase I.

**7 — CPMLs reveal the user's political orientation to every aggregator they query.** Response: aggregators receive CPMLs only when the client requires composition; clients can also do composition locally, in which case aggregators see only per-domain queries. The protocol supports both modes.

**8 — Default weights are themselves editorial decisions.** Response: yes, and they must be transparent. Each starter CPML publishes its rationale. The foundation is openly accountable for its starter-CPML editorial choices; this is a political fact the design names, not one it hides.

## Related work (to be enriched by sage and scout agents)

- **Political Compass, 8values, YourMorals.org** — existing tools for eliciting political / moral profiles. Methodology and critiques.
- **Moral Foundations Theory (Haidt & Graham)** — five-factor model for moral intuitions; candidate dimensions for CPML starter profiles.
- **Semantic-web personal preference vocabularies** — FOAF, SKOS, W3C profile data formats.
- **Argumentation-framework preferences** — Amgoud & Cayrol on preference-based argumentation.
- **Recommender-system explicit-preference work** — Herlocker et al on explainable recommendation.
- **Existing filter / moderation tools** — AT Proto labeller subscription, NewsGuard, AllSides — tools that already let users express domain trust.

## Open questions

- Should the foundation publish starter CPMLs in English only, or multi-language from day one? Language affects which domains feel "native" to a user.
- How does CPML handle claims without any applicable domain? (User's CPML has no domain that covers the topic.) Fallback behaviour?
- Should aggregators publish *suggested CPML edits* based on user behaviour, or is that a filter-bubble reinforcement mechanism to avoid?
- How should CPMLs handle domain *extinction* (a chartered domain is dissolved or has no active validators)? Auto-remove? Prompt user?
- Is there a canonical "CPML quality score" that helps users understand whether their CPML is well-calibrated, or is that itself political?

## What we'd build

- **`cpml-spec`** — formal specification document (submit as W3C CG input).
- **`cpml-resolver`** — client-side TypeScript / Go / Python library that takes a CPML and a claim, fetches the attestations, applies the conflict rule, returns composed verdict.
- **`cpml-editor`** — UI component for tuning a CPML (weights, domain toggles, conflict rules).
- **`cpml-exporter-importer`** — portable CPML file format; export / import / share / fork.
- **Starter CPMLs** — 4–6 foundation-published CPMLs with documented rationale.
- **`cpml-registry`** — open registry of third-party starter CPMLs (conspiracy-research, religious-traditions, political, sub-cultural). Users discover and opt in.
- **`cpml-diff-tool`** — compare two CPMLs; show where they agree and disagree; useful for matchmaking and for understanding frame distance.