Proposal template

# [Taxonomy name]. A domain taxonomy on the base protocol, version 0.1

*This is the proposal skeleton for a new domain taxonomy on the base protocol. The sections mirror the structure of the two v0.1 taxonomies already written, with two deliberate structural choices: roles and the relationship to the base protocol each get a standalone section (one existing spec does the same; the other folds actors into its glossary and keeps the relationship as a subsection). A draft that fills each section reads, from day one, like the existing specs. The descriptive guidance under each heading says what the section fixes; a draft replaces it with domain content, fills the bracketed placeholders, and keeps the section order.*

> Status: Draft, pending technical review
> Version: 0.1
> Date: [ISO date]
> Site location: `/protocols/<slug>/v0.1` (the normative spec page; the overview page at `/protocols/<slug>` orients and links, and does not repeat this content)
> Relationship: a domain taxonomy on the base protocol (see Section 3)
> Initiator and first maintainer: [the proposing party or working group]. The initiator is not the owner.

## Abstract

The abstract states in one paragraph which data the taxonomy shares and what that data means. It names the single domain object the taxonomy fixes, and it confirms that the taxonomy references the base protocol for every mechanism it uses and restates none of them. Where a first application appears, the abstract frames it as a pilot or exploration, never as a live service.

## 1. Scope and field

### 1.1 What this taxonomy is

The scope section names the field of work and defines the domain object the taxonomy fixes. The taxonomy fixes only the domain meaning that two independent implementations must agree on to exchange and verify that object, and nothing more.

### 1.2 What this taxonomy is not

The non-goals section states the boundaries. The taxonomy is a domain agreement above the base layer, so it introduces no envelope, addressing scheme, encryption model, anchoring mechanism, register, or key derivation of its own; each of those belongs to the base protocol and is used by reference. The taxonomy is a specification rather than a product, a live service, or a directory, and it carries no threat model or security analysis.

### 1.3 First application (optional)

Where a first application illustrates the taxonomy, this section describes it functionally and as a pilot or exploration. The taxonomy names no live or operational service and no branded instance.

## 2. Terminology and conventions

### 2.1 Normative key words

The key words 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 and RFC 8174, and only when they appear in capital letters.

### 2.2 Citation of open standards

The taxonomy inherits the base protocol's open-standard citations by reference and does not restate them. Any domain-specific open standard is cited neutrally, the way one cites an RFC, naming the published standard the mechanism rests on and which any party may implement.

### 2.3 Glossary

The glossary defines only domain terms. Terms already defined by the base protocol keep their base-protocol meaning and are not redefined here.

| Term | Definition |
|---|---|
| [domain term] | [definition] |

## 3. Relationship to the base protocol

The taxonomy adds no base-layer rule. The table maps each base-protocol mechanism the taxonomy depends on (its shared dependencies) to the base-protocol section that supplies it. That section is the normative source, and this document does not repeat it. A row appears only for a mechanism the taxonomy actually uses.

| This taxonomy relies on | Base-protocol section (`/protocols/data-sharing/v0.1`) |
|---|---|
| [record shape and canonical encoding] | Section 3.1 |
| [addressing and discovery] | Section 3.2 |
| [per-field encryption, commitment, placement] | Section 3.3 |
| [anchoring and independently verifiable proof] | Section 3.4 |
| [verification and replay semantics] | Section 3.5 |
| [identity, delegation, and mandates] | Section 3.6 |
| [register and discovery] | Section 4 |
| [conformance machinery] | Section 6 |
| [governance, licence, and hand-over] | Section 7 |

**Rule.** An implementation of this taxonomy MUST be a conforming implementation of the base protocol (Section 6) before it adds the domain rules below.

## 4. Roles

This section defines each functional role the taxonomy needs, as a distinct functional role in the sense of the base protocol. It states what each role holds, submits, or receives, and the separation guarantees between roles. Each role acts under a scoped, time-bounded, revocable mandate where it signs or receives, and the separation guarantees hold even where one legal entity holds more than one role.

| Role | What it holds, submits, or receives |
|---|---|
| [role name] | [responsibility and boundary] |

## 5. Taxonomy definitions (normative core)

The normative core fixes the domain rules. For each domain object and mechanism the taxonomy adds, this section states the domain meaning, references the base-protocol section that supplies the underlying mechanism, and ends with an explicit Rules list using the RFC 2119 key words. The taxonomy re-derives no base-protocol mechanism. Any item still open for technical review is tagged inline as [PREFIX-n] and collected in Section 9.

### 5.1 [First domain rule]

[The domain meaning of this rule and the base-protocol section it rests on.]

**Rules.**

- [A MUST, SHOULD, or MAY rule, each testable by a reviewer.]

## 6. Conformance

An implementation is conformant when it conforms to the base protocol for every mechanism the taxonomy references (Section 6 of the base protocol) and it demonstrates the domain rules of Section 5. The table maps each domain requirement to its rule and to the base-protocol section it inherits. Test-vector suites are named, not embedded; the byte-level machinery is the base protocol's.

| # | An implementation MUST demonstrate | Maps to | Inherits from base protocol |
|---|---|---|---|
| 1 | [domain requirement] | 5.x | Section x |

Conformance levels inherit the base protocol's: a MUST rule is required for interoperability in this domain, a SHOULD rule is recommended and its absence is justified, and a MAY rule is optional. An implementation states which SHOULD and MAY provisions it supports.

## 7. Governance

No single party owns this taxonomy. The taxonomy is developed in a public working group anyone may join, and it is published under the open, royalty-free licence being finalised for the base protocol, with no registration requirement and no fee. The initiator is not the owner; the maintainer role is temporary and transferable, and stewardship passes to the working group under the base protocol's hand-over clause once at least three parties are actively implementing the protocol, participating in working-group discussions, and ratifying taxonomy changes. Versions are explicit and forkable. The full governance model, the licence, and the hand-over conditions are documented at `/governance` rather than restated here.

## 8. Versioning and changelog

This is version 0.1, status Draft, pending technical review. Future versions are proposed and ratified through the public working group. Versions remain explicit, so adopters choose when to move.

### Changelog

- **v0.1 ([date])** [What this initial version fixes.]

## 9. Provisional-items register

The provisional-items register collects every item still open for technical review. Each item is tagged inline at its point of use in Section 5 and listed here with its topic, why it is provisional, and how this version handles it. A distinct [PREFIX-n] numbering keeps these items from colliding with the base protocol's own items.

| Item | Topic | Provisional because | Handling in this version |
|---|---|---|---|
| [PREFIX-1] | [topic] | [reason] | [how this version handles it] |