This document publishes the governance policy whose authoritative source is the standards track charter § Governance; in any conflict, the charter governs. It is a companion republication: the policy is settled (decided in ADR 0006 §7 and stated in the charter § Governance), published here as a standalone normative project document so adopters read it directly.
The bulk of each section below is verbatim from the charter § Governance (standards-track.md § Governance). Four kinds of departure are unavoidable when the text is lifted out of its charter context, and are LABELED as such — never disguised as verbatim:
- Deictic resolution — the charter's "see below" is resolved to an explicit link (the referent only follows physically inside the charter).
- Intro rationale carried — the charter § Governance opening rationale is carried here as this document's own opening.
- Cross-source composite (§ Errata channel) — the charter splits one policy fact across § Governance and the evolution contract; this section stitches them and cites both.
- Facts vs. identifiers (§ Deprecation policy) — the deprecation window NUMBERS are carried
here as policy facts, while the authoritative prose and conformance-traced
REQ1-EVO-*requirement identifiers stay cross-referenced to the evolution contract (single-sourced).
Why governance is published now
Published now, while the project is single-maintainer, because publishing the policy is the credibility step and the policy is what makes single-maintainer tolerable to adopters (standards-track.md § Governance, opening rationale — carried verbatim; departure 2).
Change classes
Editorial (errata; never verdict-changing) · clarifying (minor version; additive docs/cases only) · byte-distinct sibling proof profile (breaking pre-1.0 package release, public ADR, independent normative/corpus/API identity) · existing-profile wire or verification behavior (contract-major only, with a public ADR). (standards-track.md § Governance; amended by ADR 0027.)
Byte-distinct sibling proof profiles
A sibling proof profile is permitted only when a new signed protected typ gives its artifacts a
machine-visible identity, every existing profile rejects those bytes, and no byte accepted by an
existing profile changes meaning or verdict. It has its own public namespace, normative
specification, stable requirement namespace, conformance corpus identity, registry entry, and
independent implementations. Every shipped SDK implements its relevant verification surface before
release. Its first publication is a breaking pre-1.0 package release (0.x.0) with immutable source,
package, corpus, and real-substrate evidence.
This class does not create an open extension mechanism: there is no runtime profile registry, negotiation, inference, fallback, or best-effort parsing. Every future sibling is another numbered public ADR and closed corpus. Any change to an existing profile's accepted bytes, claims, algorithms, bounds, suite, or verdicts remains contract-major work. The complete decision and rejection tests are in ADR 0027.
Change control
Every product-shaping decision lands as a numbered public ADR. Once at least two independent external implementations pass the conformance corpus, contract-major ADRs gain a published comment window of no fewer than thirty days and a change-control group with implementer representation. The hand-off criterion to a formal standards body is adoption, not ceremony: when a venue (see the charter § Venue strategy) accepts the work, that venue's process supersedes this one. (standards-track.md:204-208, verbatim except for departure 1 — the charter's "see below" is resolved to an explicit link to the charter § Venue strategy.)
Errata channel
docs/errata.md is the numbered errata registry; each entry names affected versions and
its corpus impact, and the no-verdict-flip invariant is checked at review
(standards-track.md:209-211, the charter § Governance errata bullet,
verbatim). No erratum may flip an existing profile's corpus verdict — any change that would
alter such an accept/reject outcome is by definition a contract-major change and follows the
evolution contract, never this registry. A sibling proof profile is not an erratum and cannot
reclassify an existing case (the no-verdict-flip invariant, stated in the evolution contract as
REQ1-EVO-no-verdict-flip, standards-track.md:66-69).
(This section is a composite — departure 3: the charter splits the errata fact across § Governance
:207-209, the registry + "checked at review," and the evolution contract :64-67, the "any change…
contract-major" gloss. Both sources are cited.)
Deprecation policy
A contract-major enters deprecation only after its successor has a published normative profile, a
published conformance corpus, and at least two independent implementations passing that corpus.
The deprecation window is published at announcement and is never shorter than twelve months,
except for a security contract-major (§ Security policy below); during the window, conforming
verifier deployments support both majors in parallel. Sunset of a major is a deployment decision
after the published window, never a silent library change.
(standards-track.md:56-65 — the window numbers are policy FACTS, carried
here per departure 4.) The authoritative deprecation prose and the conformance-traced requirement
identifiers (REQ1-EVO-deprecation-prerequisites, -window-minimum,
-parallel-support-during-window, -sunset-is-deployment-decision) live in the charter § evolution
contract (standards-track.md § Parallel-version support and
deprecation, :52-69) and are not duplicated here; the charter explicitly names that text "the
authoritative one" for deprecation (standards-track.md:213).
Security policy
SECURITY.md governs vulnerability intake; a vulnerability whose fix would change a verdict is handled as a contract-major security release with an accelerated overlap window — published at announcement and set proportional to the vulnerability's severity, exempt from the twelve-month deprecation minimum (charter § The evolution contract), yet still a published, deployment-decided sunset, not a flag-day — never as a silent verdict change. (standards-track.md:214-218, the charter § Governance security-policy bullet, verbatim except the deictic "above (§ The evolution contract)" resolved to a cross-doc link — departure 1.) SECURITY.md cross-references this section (rather than restating the rule) so the verdict-change rule lives in one place.
Errata registry posture
The errata registry at docs/errata.md is live — it is the operational
no-verdict-flip governance instrument, with a numbered entry and per-entry corpus impact. It
currently carries Erratum 1, the correction for the v1 all selector's three recognized member
sets (ADR 0021). New errata follow the § Errata channel no-verdict-flip process above. (This
statement is this document's own framing of the registry's operational posture, not a charter
extract — labeled as such.)