How the standard evolves

1Phase 1 — maintainer-led (current)#

In plain terms: a standard is a promise that the rules won't change under you. This page explains who keeps that promise today, how changes happen in the open, and the exact moment control gets shared.

The LeanCTX maintainers steward the specification. Every change is public: issue → RFC → review → merge, with written rationale. This is honest about where the project is — a draft standard with one reference implementation — instead of simulating a committee that does not exist yet.

2Phase 2 — shared governance#

The moment two or more independent implementations (different codebases, different organizations) pass conformance, governance moves to a steering group: one seat per conforming implementation plus one maintainer seat. Decisions by lazy consensus, escalation by majority vote.

This trigger is a commitment, not an aspiration — it is the point where the standard stops being ours.

3RFC process#

1. Open an issue describing the problem, not the solution.
2. Submit an RFC: motivation, design, alternatives considered, migration impact, security considerations.
3. Stages: draft → review (≥ 14 days public) → accepted / rejected.
4. Accepted RFCs land in the specification with a changelog entry; taxonomy additions land in the type registries.

The process, the template and the index of all proposals live at /rfcs/ — the first draft (RFC 0001, ZIP container) is open for comments there. Proposals start as issues on the reference repository: github.com/yvgude/lean-ctx.

4Versioning policy#

• Within a major version: additive only — new optional fields, new registry entries.
• Taxonomies are registries: node and edge types are never removed, only deprecated. A deprecated entry survives at least one full release before removal can even be proposed.
• Breaking changes require a new major version and a written migration path (as v1 → v2 documents its mapping table).
• Drafts (-draft) carry no stability promise.
• Published documents never change retroactively. Errata are appended, never silently merged.

5Conformance and the name#

"CTXPKG-conformant" may only be claimed for implementations meeting the conformance checklist for the version in question. The CTXPKG name and any future badge are reserved for that use.

6Roadmap#

Horizon	Milestone
Shipped	v2 spec + schemas + registry protocol documented; golden-file conformance vectors; second reader (@ctxpkg/verify, TypeScript); pack verify conformance tooling in the reference CLI; public per-version trust reports on the hosted registry
Now	RFC 0001: ZIP container (v2.1) open for comments; second-implementation outreach
Next	First external RFC accepted; conformance self-certification registry
Phase 2	Independent implementation passes conformance → steering group forms