Propose a domain protocol

The governance model already promises the fullest form of participation: a working group can join an existing taxonomy effort or start a new one where a field needs its own shared meaning. This page turns that promise into a repeatable path for the parties it names: organisations, implementers, and domain experts who need a shared meaning for their field. It covers how such a party proposes a domain taxonomy on top of the base protocol, the criteria the proposal meets, and the path from a first draft to a published v0.1. The first step is concrete: copy the proposal template and fill its domain sections. The rest of this page is the path that draft travels.

1. Lifecycle

A proposal moves through exactly three stages. Each stage has an explicit entry condition and an explicit exit condition, so a proposer and a reviewer both know which stage a proposal sits in and what closes it.

Stage 1: Draft

• Entry: a proposal starts from the proposal template and fills the domain sections for one field of work.
• Exit: the draft carries every required section of the template, cites the base protocol for each mechanism it relies on, restates no base-layer rule, and meets each acceptance criterion in Section 2. A draft that misses a section or fails a criterion stays in Draft.

Stage 2: Working-group review

• Entry: a complete draft enters public review in the working group. Review is open: any working-group member reads the draft, raises questions, and proposes changes.
• Exit: the working group reaches rough consensus that the draft fits the base protocol without forking its normative core, that its domain rules are interoperable, and that its provisional items are marked rather than hidden. A sustained normative objection holds the proposal in review; the steward judges whether an objection is sustained, and records that judgment in public.

Stage 3: Ratified v0.1

• Entry: the working group ratifies the reviewed draft as version 0.1.
• Exit: the taxonomy is published on the site under its own slug (Section 3) as a normative spec page, carrying a governance paragraph and a changelog, in the same shape as the two existing v0.1 specs. A later version re-enters at Stage 2.

Who ratifies in the interim

Until stewardship transfers, the maintainer acts as steward and ratifies the first taxonomies, keeping them coherent while participation forms. While membership is still small, the steward runs the Stage 2 review in the open and records objections and their resolution in public, so review stays transparent before a quorum of members exists. Ratification passes to the working group itself under the governance hand-over clause, once at least three parties are actively implementing the protocol, participating in working-group discussions, and ratifying taxonomy changes. Ratification confers publication on the register, not permission to build: every taxonomy is forkable, so a proposal the steward declines or delays can publish and win adoption independently. That check applies to the first maintainer as much as to anyone. This process introduces no ratifying body of its own; it points to the signed governance model.

2. Acceptance criteria

A reviewer answers yes or no to each item below. A proposal advances only when every answer is yes.

• Fits the base protocol. The taxonomy relies on the base protocol for every base-layer mechanism it uses (envelope, addressing, encryption, anchoring, verification, identity, register) and forks no part of the normative core.
• Restates nothing. The taxonomy references each base-protocol mechanism by section and reproduces none of them.
• Open and royalty-free. The taxonomy carries no fee, no registration requirement, and no restriction on implementing, forking, or running it, consistent with the open licence being finalised for the base protocol.
• Zero production claims. The taxonomy describes a specification and, where useful, a pilot or exploration. It names no live service, no adopter, and no operational deployment.
• Demonstrable field need. The proposal shows that its field needs its own shared meaning: that two independent implementations must agree on the domain object it defines in order to exchange and verify that object.
• Provisional items marked. Every item still open for technical review is tagged inline and collected in a provisional-items register, rather than presented as settled.

3. Register naming

Version 1 identifies each taxonomy by a slug, matching the two v0.1 taxonomies already written (/protocols/content-authenticity/, /protocols/fraud-signals/). A ratified taxonomy publishes at /protocols/<slug>/v0.1, and its overview page at /protocols/<slug> orients and links without repeating the spec. A slug reads as its field of work, which keeps the register legible while the number of taxonomies is small. Where two proposals address the same field, the working group resolves them into one taxonomy before ratification; a slug is assigned at ratification, so no proposal reserves a field in advance.

A numbered register (a short citable identifier per taxonomy, in the style long-running standards bodies use) is recorded here as a later option, to be revisited once external proposals exist and a stable citation handle earns its cost. Version 1 introduces no numbering.

4. Channel

A proposal reaches the working group through a form on the site's own domain. The form posts to a server endpoint on that domain, and the endpoint delivers the submission onward as email. No third-party form is embedded and no external script loads on the page, so the channel stays inside the zero-external-requests rule the site holds to. The form lives on the neutral protocol domain, and the submission path stays on that domain, so the channel itself carries the neutrality the standard claims. This page describes the pattern only; the delivery provider is an implementation detail.

A working-group sign-up form is already open on the governance page: an interested party can reach the maintainer there today and follow the standard as it forms. Formal proposals, where a completed draft enters review, open with the public launch, for two explicit reasons.

1. The neutral domain goes live with the public launch. The submission path belongs on the site's own neutral domain, and that domain arrives with the public launch. Until then, the site states honestly that proposals open with the public launch, and offers the spec and governance model to read in the meantime (the same pattern the governance page uses alongside its sign-up form).
2. The IPR and licence clause is unfinished (blocker). The base-protocol licence is being finalised. A third-party taxonomy submitted without a settled contribution clause is an unresolved IP question: the process cannot accept an outside proposal until a short contribution clause (by submitting, a contributor grants an open, royalty-free licence over the contribution) lands with the licence finalisation. This dependency rides with that finalisation and gates the whole channel.