Roadmap

This is where the project's own tracking is published rather than summarized: the roadmaps the work is actually planned against, as they are written.

They are working documents, not announcements. They carry version numbers, maturity levels and open proposals, and they are updated as things move — so they show what is unfinished as plainly as what is done. That is the reason to publish them.

Three domains appear here, because a roadmap is for what is moving. The fourth — the core protocol — is deliberately the one that is not.

How progress is tracked

Every artifact — a spec, an extension, an SDK convention — sits at a maturity level and carries a trajectory. The two are independent: the level says how far something has got, the trajectory says whether it is currently moving.

Trajectory is the orthogonal axis: stable, active, or volatile / pre-review.

The levels are a ladder of evidence, not a schedule. Nothing here carries a date, because the gate is a measurement rather than a deadline. M6 is reachable only by the core protocol — extensions and conventions are opt-in, so "every language re-derived it" is not a meaningful bar for them, and each domain's honest ceiling differs. Read a level against its own domain.

The core protocol, and why it has no roadmap here

The core protocol is the mandatory floor — the wire format, the type system, the identity / capability / dispatch core, and the basic tree operations. It sits at the top of the ladder across the board, and holding it still is the point rather than a pause: every peer that interoperates does so by agreeing on it, so change there is expensive in a way that change above it is not. What is published is a preview rather than a frozen 1.0, and the remaining work is review and challenge in the open, not features.

Its state is therefore a measurement, not a plan, and it is published as one:

• The specification — the floor itself, in full.
• Keystone and the conformance matrix — the same specification re-derived across more than forty languages, with each peer's current gate result, known gaps and the oracle commit it was measured against. That is what "where the core stands" means, and it is re-measured rather than restated.

Where the three moving domains stand

• Extensions — the optional capability layer, and the domain that spans the whole ladder. More than two dozen specs have landed, with more in proposal; a stable v1 set is validated by conformance vectors, while the network and resolution family is still converging. This is where the design space above core is actually being explored.
• SDK — the binding layer: cross-implementation conventions for operation names, result shapes and dispatch ergonomics, so the SDKs feel alike without one API being mandated. Sits at M2 by design — these are conventions, and their gate is cross-implementation agreement rather than the protocol conformance gate.
• Applications — the L5 conventions that let independent front-ends render the same content the same way. The youngest domain, and explicitly format-only: a convention defines bytes and type vocabulary, never application logic or interface.

Reading them honestly

A landed spec is not a shipped feature. M2 means the contract exists and is binding on anyone implementing it. Whether an implementation exists, and whether implementations agree, are the levels above it.

Proposals are not commitments. Items at M0 and M1 are written down so they can be argued with. Some will not survive that.

These are the working documents. They are reproduced as their teams maintain them, minus the internal routing headers that only tell one team which other team owns a file. Nothing in the substance is reworded here.