§3 How a change is proposed

Any change starts as a GitHub issue or a pull request — the same entry points CONTRIBUTING.md describes for the reference pipeline. What differs on the standards track is what has to happen before it is implemented.

3.1 Editorial vs. normative

• Editorial: does not change which records are valid, which requirement level binds, or what a VERxxx code means — a typo fix, a prose clarification, a non-normative note. Ships as a patch/errata item under VERSIONING.md §2.1 and gets a row in the errata ledger (docs/standards/VER-1.0-errata.md, per CONTRIBUTING.md rule 5). It does not require a new ADR unless it reopens a question an existing ADR already decided.
• Normative: changes the set of valid records, a schema constraint, a requirement level, a code's meaning or severity, or anything else VERSIONING.md §2 gates at minor or major. This **requires an ADR before implementation** — CONTRIBUTING.md, "Decisions go in an ADR": a field's meaning, a requirement level, a versioning rule, or a validator's strictness is decided in docs/adr/ first. Shipping code that assumes an answer is how a decision gets made without being decided, and that is the one thing this process exists to prevent.

3.2 The ADR convention

An ADR is docs/adr/ADR-NNNN-kebab-slug.md, following the convention already in use for ADR-0001 through ADR-0008 and stated in full in CONTRIBUTING.md ("Decisions go in an ADR"): the five sections, the Proposed / Accepted / Rejected / Superseded by ADR-NNNN status vocabulary, qualified status lines for a partial acceptance. This document does not restate that convention — it only requires that a normative change (§3.1) use it.

The VERxxx conformance-code registry is append-only under ADR-0003: never renumbered, never reused, severity tightened only at a profile minor version and only once the requirement a code judges has itself become normative for the records it judges. Read ADR-0003 before proposing a code change; this document does not restate its mechanism.

3.3 What may never change

VERSIONING.md §3 (and its quick-reference table, §8) is the authority; this document only points at it. A published release directory, once tagged (§3.3 step 4), is never modified, replaced, or deleted — including editing a RELEASE.md digest to match a file that changed (§3.2). A schema $id, once published, is never reused or redirected to different bytes (§3.1). A VERxxx code, once assigned, is never renumbered or reused (ADR-0003). cpnp_version does not move within VER 1.x — any change to CPNP-1 is VER 2.0 (§4). A proposal that requires any of these is not one this process can accept at any decision level: it is 2.0 material, or it is not material at all.