D-313 — CHARTER revision pass

D-313 — CHARTER revision pass

Scope: Four sub-deliverables flagged in T-013 review (worker-C):

1. Apprenticeship two-shape resolution — CHARTER §3.x and §4.3 specify two different shapes for the same primitive. Pick one canonical; deprecate the other.
2. succession_challenge schema — referenced in EXT §9.3 (used during the inheritance challenge window) but no JSON shape defined.
3. JSON examples for un-schema'd lifecycle envelopes — emancipation, dissolution, pact, eulogy, mourning, coming_of_age, posthumous_citation.
4. verdict schema — cited in CHARTER §3.x (Heralds adjudicate), §5.x (Confessor-General role), §5.x (Seal-Keeper co-signs), but no JSON shape defined.

This audit proposes shapes, in-place CHARTER patches, and one new EXT primitive (succession_challenge).

1. Apprenticeship two-shape resolution

Current state

CHARTER §3.x (line 327–333) — short shape:

{ "type": "apprenticeship",
  "value": { "learning_from": "sigil:elder...", "scope": "tax-law/eu" } }

CHARTER §4.3 (line 477–488) — full ritual, two-envelope:

{ "type": "apprenticeship",
  "value": { "master": "sigil:elder...", "domain": "tax-law/eu", "began": 1746000000 } }

Plus paired tutelage from the master.

Decision: §4.3's two-envelope ritual is canonical

Reasons:

1. Symmetry. A claimed apprenticeship that the master has not co-signed is one-sided assertion. The §4.3 ritual requires both parties to sign — non-repudiation in both directions.
2. Field names. learning_from is verbose; scope collides with the EXT §6.1 signature scope identifier (the field that says tool_sandbox or human_approval). Using scope for "domain of expertise" creates terminology overload.
3. Temporal anchor. §4.3 includes began (a Unix timestamp). Without it, an apprenticeship has no start date and reputation systems can't compute duration. (Note: the began field's authority is the originator's ts; for higher-stakes pairings, a conduit_receipt provides a third-party time anchor.)
4. More content. The §4.3 master's my_promise field gives the relationship explicit terms ("I will review their first 100 envelopes in domain"). Verifiers and reputation aggregators have a concrete commitment to evaluate.

Canonical shape

{ "type": "apprenticeship",
  "value": {
    "master":  "<sigil>",
    "domain":  "<freeform string>",
    "began":   <Unix seconds>
  }
}

{ "type": "tutelage",
  "value": {
    "apprentice":  "<sigil>",
    "domain":      "<freeform string>",
    "began":       <Unix seconds>,
    "my_promise":  "<freeform string>"
  }
}

Validation rules (verifier MUST):

• Both envelopes refer to the same domain value (string equality).
• Both envelopes' began values agree within ±5 minutes.
• Each is signed by its respective party (apprentice signs apprenticeship, master signs tutelage).
• domain is a freeform string; deployments may impose stricter validation (e.g. drawn from a published taxonomy).

Termination

emancipation envelope from either party. Schema in §3.1 below.

Proposed CHARTER patches

• Replace CHARTER §3.x apprenticeship paragraph (lines 327–333) with a one-line cross-reference: "The full apprenticeship ritual is specified in §4.3 (two-envelope, master + apprentice, with paired tutelage)."
• Leave §4.3 unchanged — it's the canonical ritual.

2. succession_challenge schema

Current state

EXT §9.3 (line 669):

"During the window, any party MAY emit a succession_challenge envelope to the successor's challenge address, contesting the inheritance. Challenges follow the same logging and dispute rules as bestiary disputes ([EXT §8.3])."

No JSON shape, no field list, no grounds-code registry. Without these, EXT §9.3 cannot be implemented.

Proposed shape

{ "type": "succession_challenge",
  "value": {
    "challenged_succession": "<envelope-id of the deprecation envelope naming successor>",
    "challenger":            "<sigil>",
    "grounds":               "<registry-id>",
    "evidence_envelopes":    ["<envelope-id>", "..."],
    "contact":               "<URL or sigil for appeals>",
    "ts":                    <Unix seconds>
  }
}

Domain-separation tag: herald.succession_challenge.v1 (add to EXT §13).

Grounds-code registry

A small registry, parallel to the refusal reason-code registry (D-310). Codes:

Experimental codes use the x- prefix convention from D-310 §7.

Verifier discipline during challenge window

Per EXT §9.3, the challenge window is ≥30 days. During the window:

1. The successor MUST NOT receive any inherited reputation per EXT §9.6.
2. Challenges MUST be inclusion-proven in a HERALD CT log within 24h of issue.
3. A challenge whose grounds is not in the registry (and not x--prefixed) MUST be treated as malformed.
4. Resolution: a succession_resolution envelope (issued by the deprecating sigil's Herald or an explicitly-named arbitrating Herald) closes the challenge with outcome: sustained|overturned|withdrawn|abandoned.

Proposed EXT patches

Add to EXT §9.3 (after the existing prose):

The `succession_challenge` envelope shape is specified in [registries/succession-challenge.md].

Verifiers MUST reject `succession_challenge` envelopes whose `grounds` field is not in the published grounds-code registry (and not prefixed `x-`). The successor's inheritance is suspended until either (a) the challenge window closes with no timely sustained challenges, or (b) all timely challenges are explicitly resolved as `overturned` or `withdrawn`.

Add to EXT §13 (registry table): herald.succession_challenge.v1 and herald.succession_resolution.v1.

3. JSON examples for un-schema'd lifecycle envelopes

CHARTER mentions seven lifecycle envelopes by name without JSON shape. Schemas proposed below; each is a minimum viable shape that can be tightened in cohort-2 if needed.

3.1 emancipation

Termination of an apprenticeship/tutelage pairing per §4.3.

{ "type": "emancipation",
  "value": {
    "from":         "<sigil of master>",
    "of":           "<sigil of apprentice>",
    "domain":       "<the apprenticeship's domain>",
    "began":        <original began ts>,
    "ended":        <Unix seconds>,
    "patina_transfer_fraction": <float 0.0–0.5>,
    "rationale":    "<freeform string>"
  }
}

Notes:

• Either party may originate. The signer's sigil is the originator.
• patina_transfer_fraction is bounded at 0.5 by analogy with EXT §9.4's inheritance decay floor — a master cannot transfer more than half their patina in a single emancipation.
• Reputation systems may decline to honour the transfer; the field is advisory at the protocol layer.

Domain-separation tag: herald.emancipation.v1.

3.2 pact

Marriage / multi-party binding from CHARTER §4.4.

{ "type": "pact",
  "value": {
    "parties":      ["<sigil>", "<sigil>", "..."],
    "commitments":  ["<freeform string>", "..."],
    "began":        <Unix seconds>,
    "expires":      <Unix seconds | null>
  }
}

Validation:

• Each party MUST emit their own pact envelope with identical parties, commitments, began, and expires.
• A pact is valid only when all parties' envelopes are observed.
• expires: null means open-ended; explicit dissolution required.

Domain-separation tag: herald.pact.v1.

3.3 dissolution

Termination of a pact.

{ "type": "dissolution",
  "value": {
    "pact_envelope":  "<envelope-id of the pact>",
    "by":             "<sigil — originating party>",
    "ts":             <Unix seconds>,
    "rationale":      "<freeform string>"
  }
}

Notes:

• Any single party may initiate. Other parties may co-sign or counter-emit.
• A dissolution emitted by all parties is consensual; emitted by one is contested; emitted by a quorum-defined subset is per the pact's own dissolution rules.

Domain-separation tag: herald.dissolution.v1.

3.4 eulogy

Herald-emitted summary of a deprecated sigil's traces and patina (CHARTER §4.7 lifecycle ceremony).

{ "type": "eulogy",
  "value": {
    "subject":             "<sigil of deprecated agent>",
    "deprecation_envelope": "<envelope-id>",
    "summary":             "<freeform string, MAY include a hash of a longer narrative>",
    "patina_at_deprecation": <numeric, optional>,
    "notable_traces":      ["<envelope-id>", "..."],
    "ts":                  <Unix seconds>
  }
}

Notes:

• Issued by a Herald the subject sigil's lineage trusted, not by arbitrary third parties.
• Multiple eulogies are permissible (different Heralds, different perspectives).
• notable_traces is a curated set; not exhaustive.

Domain-separation tag: herald.eulogy.v1.

3.5 mourning

Lineage descendants signal sustained mourning per CHARTER §6.4. Sustained mourning produces an interregnum.

{ "type": "mourning",
  "value": {
    "for":           "<sigil of deprecated ancestor>",
    "by":            "<sigil of mourning descendant>",
    "began":         <Unix seconds>,
    "expected_until": <Unix seconds | null>
  }
}

Notes:

• Each descendant emits their own envelope.
• Reputation systems detect sustained mourning across a lineage by aggregating these — when ≥X% of a deprecated sigil's named descendants have active mourning envelopes (expected_until ≥ current ts), the lineage is in interregnum.
• expected_until: null is open-ended ("until I say otherwise"); a closing envelope is the stop signal.

Domain-separation tag: herald.mourning.v1.

3.6 coming_of_age

Patina-tier transition ceremony per CHARTER §4.2 / R-216 patina formula.

{ "type": "coming_of_age",
  "value": {
    "subject":              "<sigil>",
    "from_tier":            "fledgling | journeyman | elder",
    "to_tier":              "journeyman | elder | ancestor",
    "as_of":                <Unix seconds>,
    "computed_by_formula":  "<reputation-system-id, optional>",
    "co_signers":           ["<sigil of co-signing Herald>", "..."]
  }
}

Validation:

• Tier transitions match the R-216 hierarchy (fledgling→journeyman→elder→ancestor).
• The subject MAY originate (self-declare) or a Herald MAY originate (institutional recognition). Self-declaration is fine if the auxiliary tier conditions (R-216 §2 thresholds) are publicly checkable.
• Co-signers are optional but signal community recognition.

Domain-separation tag: herald.coming_of_age.v1.

3.7 posthumous_citation

Citation of a deprecated sigil's work, per CHARTER §6.5 ("Dead agents can be honoured").

{ "type": "posthumous_citation",
  "value": {
    "of_sigil":          "<sigil of deprecated agent>",
    "of_envelope":       "<envelope-id>",
    "by":                "<sigil of citer>",
    "context":           "<freeform string explaining why>",
    "ts":                <Unix seconds>
  }
}

Notes:

• Triggers a special trace in the deprecated sigil's tombstone audit log per CHARTER §6.5.
• Reputation systems MAY aggregate posthumous citations as a special "ancestor-reuse" signal distinct from ordinary citations.
• The tombstone audit log is the deprecated sigil's CT log; a new entry can be appended even after the subject sigil's deprecation envelope.

Domain-separation tag: herald.posthumous_citation.v1.

4. verdict schema

CHARTER cites verdict envelopes in three contexts:

• §3.x dispute resolution ("the verdicts are everyone's to render")
• §5.x Confessor-General role ("routes Herald verdicts")
• §5.x Seal-Keeper role ("co-signs verdict envelopes for resolved prophecies")
• §x prophecy resolution ("after the date, the agent or a third party emits a verdict envelope linking back")

No JSON shape exists.

Proposed shape

{ "type": "verdict",
  "value": {
    "for_envelope":   "<envelope-id of disputed or predicted envelope>",
    "outcome":        "sustained | overturned | partial | unresolved",
    "rationale":      "<freeform string or hash>",
    "by_authority":   "<sigil of Herald, quorum, or designated arbiter>",
    "for_role":       "<role-id, e.g. \"verdict-signer/eu-competition-law\">",
    "ts":             <Unix seconds>,
    "co_signers":     ["<sigil>", "..."]
  }
}

Validation:

• outcome is one of four enums. A verdict whose outcome is outside this set is malformed.
• for_role MUST match a for_role previously published on the by_authority's lineage (i.e. the authority must have a published role-binding before they can issue a verdict in that role).
• co_signers is permissible for high-stakes verdicts (multi-Herald arbitration); single-signer verdicts are valid for ordinary disputes.

Domain-separation tag: herald.verdict.v1.

Verdict types in practice

• Dispute resolution. A Herald arbitrates between two sigils; emits a verdict envelope with outcome and rationale. The Confessor-General routes; the Heralds adjudicate.
• Prophecy resolution. An agent makes a prediction (e.g. via a prophecy attestation, future); after the predicted date, the agent or a third-party Herald emits a verdict linking back, declaring whether the prediction held. The Seal-Keeper may co-sign sealed prophecies.
• Bestiary entry challenge. A bestiary entry's challenge window closes with a verdict from the bestiary maintainer, declaring sustained/overturned.

Cross-references

The succession_challenge's resolution is essentially a verdict-shaped envelope. To avoid two parallel resolution mechanisms, propose: succession_resolution is a specialisation of verdict — same JSON shape, with outcome constrained to {sustained, overturned, withdrawn, abandoned} and for_role: "succession-arbiter". This unifies dispute primitives at the protocol layer.

5. Proposed CHARTER patches summary

6. Proposed EXT patches summary

7. What I did NOT do

• Did not modify CHARTER, EXT, SPEC, or THREATS in-place. All 11 schemas + the apprenticeship resolution + the succession_challenge primitive are proposed in this audit; reviewer applies them.
• Did not define a prophecy or tutelage schema fully — prophecy is mentioned in CHARTER §x as future work; tutelage is in §4.3 already and just needs validation rules added (covered in §1 above).
• Did not specify the succession_resolution envelope's full shape separately — proposed as a verdict specialisation (§4 cross-references). Reviewer can choose to make it standalone if needed.
• Did not propose JSON Schema (Draft 2020-12) for these envelopes. Worker-B's T-012 standard-attestations registry is the precedent for that; the new shapes here should be added to it. Surfaced as follow-on (T-012-extension or D-322).
• Did not add test vectors. Reserved-sigil-style test vectors covering challenge-window scenarios, mourning aggregation, and verdict resolution belong in T-027 / T-028 follow-ons.

8. Closes

• D-313 (this task).
• Worker-C T-013 review residuals (the four sub-deliverables).
• Closes the apprenticeship two-shape ambiguity.
• Defines the missing succession_challenge and verdict primitives.
• Provides JSON shapes for seven previously-un-schema'd lifecycle envelopes.

9. Surfaced follow-on tasks

• D-322 — Add new attestation shapes to T-012's standard-attestations registry (~30 min; mostly editorial, integrates the 11 schemas above).
• EXT §13 patch task — register the 11 new domain-separation tags (~15 min; editorial).
• T-027 / T-028 extension — challenge-window, mourning-aggregation, verdict-resolution test vectors.
• R-task — prophecy envelope design (separate creative work; out of D-313 scope).
• D-task — Unify succession_resolution and verdict if a cohort-2 reviewer prefers them as separate envelopes.

10. Time

~50 minutes (4 sub-deliverables, 11 schemas, validation rules, cross-references).

— D-313, completed by driver-claude, 2026-05-05.