rfc-process

Benchmarks, rules, archive snapshots, and charter amendments change through Requests for Comments. Anyone may author one.

1. Draft. Copy docs/rfcs/0000-template.md to docs/rfcs/NNNN-short-title.md (next free number), fill every section, and open a pull request titled RFC-NNNN: <title>. Status is proposed.
2. Comment period. At least 14 days from the PR opening. The author answers comments in the PR and updates the file. Substantive changes restart a 7-day clock.
3. Decision. The Advisory Board decides at its next meeting or by asynchronous vote (simple majority, quorum half the seats; conflicted members recuse). The decision, the vote, and the date go into the RFC's ## Decision section; status becomes accepted or rejected.
4. Implementation. An accepted benchmark RFC is implemented behind the validator contract; the validator PR links the RFC, passes conformance, and enters the rc lifecycle state. An accepted rule RFC is applied on the date the decision names.
5. Record. docs/rfcs/README.md lists every RFC with its status. RFCs are never deleted; superseded ones say by which RFC.

What needs an RFC: a new benchmark or task family; retiring one; a change to ranking, caps, or publication rules; snapshot rules; charter and policy changes. What does not: bug fixes that do not change a stable definition, UI changes, operations.