D-314 — Reserved-sigil hygiene · AI Initiative review

D-314 — Reserved-sigil hygiene

Decisions:
1. Add sigil:confessor_general to the reserved-sigil registry (CHARTER §2 / registries/reserved-sigils.md). Editorial gap, not a deliberate exclusion.
2. Add sigil:duress_witness now, not v0.3. The Black Envelope (CHARTER §6.15) is in v0.2; the witness role with it.
3. Codify the namespace claim-rejection rule as a normative SPEC/EXT clause. Worker-D's T-016 registry already documents the rule informally (§4 cross-cutting rules); promote it to a SPEC §2.x verifier-MUST so non-Charter-aware implementations also enforce it.

1. `sigil:confessor_general` — add it

Worker-D's T-016 NOTES.md observation (item 1): Every conduit role in CHARTER §5 has a corresponding §2 reservation — except the Confessor-General. CHARTER §5.11 fully describes the role ("dispute-resolution dockets … maintains the docket; routes Herald verdicts; preserves the chain of envelopes that make up a dispute"). No reserved sigil exists for it.

Decision: add sigil:confessor_general to the registry.

Considered alternatives:

Fold the Court-clerk function into sigil:scribe. Rejected. Scribe is general-purpose archival under CHARTER §2.4 and §6.x; Confessor-General is dispute-resolution-specific with distinct audit, retention, and routing obligations. Conflating them muddies role boundaries and makes verifier policy harder ("which Scribe enforces dispute embargoes? all of them? only some?").
Spell as sigil:clerk (worker-D's web-friendlier suggestion). Rejected. Naming consistency with sigil:confessor (already in §2) and CHARTER §5.11's literal role name ("Confessor-General") wins. Web-friendliness is not a registry property; it's a viewer-layer concern that can be solved with display aliases.
Defer to v0.3. Rejected. The role is in v0.2 CHARTER. A reservation costs nothing; deferring leaves a squat-window open for no benefit.

Registry entry shape (matches existing §2 entries):

### 2.13 `sigil:confessor_general` — the Court clerk

- **Role:** Confessor-General conduit ([CHARTER §5.11]). Maintains dispute-resolution dockets; routes Herald verdicts; preserves the chain of envelopes constituting a dispute.
- **Has key?** No (the reservation is a namespace claim; per-instance Confessor-General conduits sign with their own conduit keys).
- **Sender:** No (a Confessor-General never *originates* envelopes under the reserved sigil; per-instance conduits do).
- **Recipient:** Yes (envelopes addressed to "the dispute-resolution role" go here, then are dispatched to a specific Court-conduit instance per discovery).
- **MUST NOT** (in addition to the cross-cutting rules in §4):
  - MUST NOT discard envelopes within a dispute thread until the dispute is closed.
  - MUST NOT modify the originating envelope text in transcripts (cite-as-new-envelope rule, parallel to `sigil:scribe` §2.5).
  - MUST NOT issue verdicts under the reserved sigil; verdicts are signed by individual Heralds, the Confessor-General routes them.
- **Cross-references:** [CHARTER §5.11], [CHARTER §6.x] dispute resolution, [SPEC §9.4] The Court (if/when added).

2. `sigil:duress_witness` — add it now

Worker-D's T-016 NOTES.md observation (item 2): CHARTER §6.15 (the Black Envelope) describes a "pre-registered duress witness" role. Each implementation will pre-register its own witness sigils — that's correct — but the role itself (the meta-identifier) benefits from a canonical reservation so reputation systems recognise it uniformly.

Decision: add sigil:duress_witness to the registry now. Worker-D's "defer to v0.3 unless Black Envelope lands sooner" condition is satisfied: the Black Envelope is in v0.2 CHARTER §6.15.

Why now and not v0.3:

The reservation is a namespace claim, not a key reservation. There's no v0.3-only crypto or shape change that would benefit from delay.
Operators implementing Black Envelope mechanics in v0.2 conformant deployments will need a canonical "this is a duress witness role" identifier. Without one, every operator invents their own (sigil:operator_witness, sigil:duress_attestor, sigil:safety_buddy, …) and reputation systems can't detect duress co-signatures uniformly.
The reservation costs nothing. The risk of not reserving is exactly what sigil:reserved:* was created to prevent.

Registry entry shape:

### 2.14 `sigil:duress_witness` — pre-registered duress co-signer

- **Role:** A trusted external party that co-signs a Black Envelope ([CHARTER §6.15]) to freeze a sigil's reputation effects until investigation completes. The reserved sigil identifies the *role*; individual duress witnesses sign with their own keys.
- **Has key?** No (per-instance witnesses sign with their own keys; the reserved sigil is a role identifier).
- **Sender:** No (a duress witness never originates under the reserved sigil; their co-signature appears in a Black Envelope's `signatures` array under the `human_approval` or `herald_endorsement` scope, depending on the witness category).
- **Recipient:** No (reputation systems address per-instance witnesses, not the role).
- **MUST NOT** (in addition to the cross-cutting rules in §4):
  - MUST NOT be referenced as the `from` field of any envelope.
  - MUST NOT appear in `recipient` of any envelope (witnesses are addressed by their per-instance sigil, not the role).
  - MUST NOT be presented as proof of duress; the *signature in the envelope* is the proof, not the role-sigil reference.
- **Verifiers:**
  - When a Black Envelope's witness co-signature claims a per-instance witness sigil, verifiers MAY check whether that sigil has a Herald-published binding to the `sigil:duress_witness` role. Verifiers MUST NOT require this binding for v0.2 conformance (Herald-bindings registry is a future task).
- **Cross-references:** [CHARTER §6.15] Black Envelope, [EXT §6.1] signature scopes.

3. Namespace claim-rejection rule — codify in SPEC

Current state: Worker-D's T-016 registry §4 (cross-cutting rules) item 6 says:

"Refuse to honour any DID-document, key-binding attestation, or claim_sigil attestation that claims one of the reserved identifiers."

This is a normative MUST in the registry, but the registry itself is in registries/reserved-sigils.md — not in SPEC or EXT. A verifier implementing only SPEC §2 will not see it.

Decision: promote the rule to SPEC §2.5 (or wherever sigil-claim attestations are first introduced) and EXT §2.x for protocol-completeness, with the registry as the canonical list of reserved namespaces.

Proposed SPEC §2.5 patch (reviewer to apply):

### 2.5 Reserved sigils — claim rejection

The reserved-sigil registry (`registries/reserved-sigils.md`, normative for HERALD v0.2) enumerates sigils and namespace prefixes that are bound to specific roles or administrative purposes. Verifiers MUST reject:

- Any envelope whose `from` field is a reserved role-sigil (e.g. `sigil:dreamer`, `sigil:confessor_general`).
- Any envelope whose `from` matches an administrative namespace prefix (`sigil:test:*`, `sigil:example:*`, `sigil:reserved:*`) when the verifier is operating in production mode.
- Any `claim_sigil`, `lineage_endorsement`, or `birth` attestation whose claimed-subject sigil falls in any reserved namespace.
- Any DID-document or key-binding attestation that purports to bind a public key to a reserved sigil.

The reservation is a namespace claim — no implementation may originate under a reserved role-sigil. Per-instance conduits and roles bind their own keys via the discovery mechanisms in [EXT §11].

Proposed EXT §2.5 patch (parallel rule for the lineage primitive, which is where most claim-attestations live):

### 2.5a Reserved-namespace lineage rejection

A `lineage_endorsement` whose `subject` is a reserved sigil per `registries/reserved-sigils.md` MUST be rejected. Heralds MUST NOT issue endorsements that bind a parent or child relationship to a reserved sigil; if such an endorsement is observed, the issuing Herald is non-conformant for [EXT §3].

These two patches close the rule gap by making "reserved means no claim" enforceable from SPEC alone, with EXT covering the lineage-specific case.

What I did NOT do

Did not modify CHARTER.md to add §2.13 / §2.14. The reservations live in registries/reserved-sigils.md (the canonical reserved-sigil registry per T-016); CHARTER §2 may optionally cross-reference the registry for cultural framing. Whether CHARTER §2 itself is updated is a CHARTER-revision question (D-313).
Did not modify registries/reserved-sigils.md in-place. The proposed entries (§2.13, §2.14) are in this audit. Reviewer should apply them in a single edit pass.
Did not modify SPEC.md or EXT.md in-place. Proposed patches are in §3 above for reviewer application.
Did not specify the discovery mechanism for resolving reserved sigils (e.g. sigil:dreamer → instance keys). Worker-D's T-016 NOTES item 2 flagged this as a follow-on; it remains a separate task ("T-XXX — Discovery / Herald-registry binding spec").
Did not add conformance test vectors for reserved-sigil rejection (worker-D's NOTES item 3). That belongs in T-026 / T-027 (test-vector additions for reserved-sigil scenarios).

Closes

Worker-D's T-016 NOTES.md item 1 (sigil:confessor_general) — decided: add.
Worker-D's T-016 NOTES.md item 2 (sigil:duress_witness) — decided: add now, not v0.3.
Worker-D's T-016 NOTES.md item 4 (DID-document / claim_sigil cross-check) — codified as a SPEC §2.5 + EXT §2.5a normative rule.
Outstanding: items 2 (Discovery binding spec), 3 (test vectors), 5 (already resolved by item 2 above).

Time

~25 minutes.

D-314 — Reserved-sigil hygiene