Governance Principles
These principles guide every governance decision: RFC acceptance, version releases, certification criteria, and stewardship transitions. They complement — but do not replace — technical design principles in Core Design Principles and operational rules in RFC-007.
Process rules below use RFC 2119 keywords.
1. Open Evolution
The specification MUST evolve through public, documented processes. Substantive changes MUST enter via the RFC process with review periods visible to all participants.
- Draft RFCs SHOULD be published before implementation-dependent deployments at scale
- Rejected proposals SHOULD retain public rationale for future reference
- Emergency security fixes MAY follow an expedited path defined in Security Disclosure
Anti-pattern: Normative behavior defined only in a vendor's private integration guide.
2. Technical Merit
Decisions MUST prioritize technical merit, interoperability evidence, and conformance impact over brand affiliation, revenue share, or participant size.
Evaluation criteria SHOULD include:
| Criterion | Question |
|---|---|
| Correctness | Does the proposal satisfy stated use cases without contradictions? |
| Interoperability | Do at least two independent implementations benefit? |
| Security | What is the threat model delta? (SRG review) |
| Privacy | Does data minimization hold? |
| Complexity | Is the simplest sufficient design chosen? |
| Evidence | Are there test vectors, pilots, or formal analysis? |
3. Compatibility First
Backward compatibility SHOULD be preserved across minor and patch releases. Breaking changes MUST follow the Breaking Changes Policy and MUST NOT appear in Stable RFCs without a major version or explicit deprecation cycle.
Implementers SHOULD treat RFC-010 Versioning as binding for schema and API evolution.
4. Implementation Neutrality
The specification MUST NOT mandate a single vendor stack, cloud region, programming language, or reference codebase. Normative text MAY include non-binding examples; examples MUST NOT be the only definition of required behavior.
- Conformance MUST be evaluated against behavior, not source code similarity
- Reference implementations MAY exist but MUST NOT confer exclusive rights (see Reference Implementation Policy)
5. Security Responsibility
Security is a collective obligation spanning spec authors, implementers, and operators.
| Role | Responsibility |
|---|---|
| Working Group / SRG | Threat models, normative controls, coordinated disclosure |
| Implementers | Secure defaults, patch SLAs, production hardening |
| Operators | Incident response, audit, subject notification where required |
| Researchers | Responsible reporting per Security Disclosure |
Security regressions in Stable RFCs MUST be remediated; cosmetic issues MAY wait for scheduled releases.
6. Community Participation
Governance MUST provide meaningful participation paths for implementers, researchers, civil-society advocates, and institutional users — not only founding stewards.
- Contribution mechanics are defined in Community Participation and Contribution Process
- Decision records SHOULD be public unless restricted for security or personal data
- Working Group meetings SHOULD publish minutes and agendas
Requirement: No fee MAY be required to submit RFC drafts or participate in public review.
7. Long-Term Stability
Institutions integrate trust infrastructure over years. Governance MUST optimize for predictable lifecycles:
| Mechanism | Purpose |
|---|---|
| RFC status ladder | Draft → Stable with explicit semantics |
| Deprecation timelines | Minimum notice before Retired |
| Conformance versioning | Certificates bind to spec version |
| Stewardship roadmap | Transition to independent foundation (Ecosystem Roadmap) |
Short-term expedience MUST NOT override documented deprecation commitments without Working Group supermajority and public notice.
Principle hierarchy
When principles conflict, resolve in this order:
- Subject safety and security (including privacy)
- Compatibility commitments already published as Stable
- Technical merit and interoperability
- Open evolution and community participation
- Implementation convenience