Governance & Change Control

HexEntry needs governance so the standard can scale without breaking consistency. This page defines how changes are proposed, reviewed, and versioned.

Versioning

Major: changes that modify the meaning of setups/confirmations or invalidate historical stats.

Minor: additive clarifications, new examples, UI improvements that do not change rules.

Patch: typo fixes and formatting only.

RFC process

1) Proposal

Write a short RFC: problem, proposed change, affected codes, and migration impact.

2) Review

Review must answer: Does it reduce ambiguity? Is it coach‑judgeable? Does it preserve statistics?

3) Decision

Approve / reject / revise. If approved, update documentation and bump version.

4) Rollout

Communicate the change, update checklists, and define the “effective date”.

Changelog discipline

Every rule change must include:

What changed (exact text or rule)
Why (the failure mode it fixes)
Which codes are impacted (setup / HXC / errors)
Impact on historical stats (none / partial / full)

Non‑negotiable governance rules

No change that increases discretionary interpretation.
No “special cases” added ad‑hoc without an RFC.
Every setup must remain exactly 5 confirmations (kill‑switch integrity).