#Implementation status

The documentation describes Flux v1 as specified by the sealed design plans, written in the present tense throughout: every page states the designed behavior of the language, not a snapshot of a build. This page is the one place that separates the two: what is implemented today from what is sealed design still being built. Every other page describes the design in the present tense; this is the ledger that records how much of it runs.

New here? Start with Guide §1 — What is Flux? →

#What “as specified” means

A Flux page reads as though the whole system exists, because the design is complete and sealed: the grammar, the kinds, the four planes, the FDK surface and the capability model are all fully specified, and the docs describe them as the properties they are designed to have. That is a deliberate choice, not an overstatement — the alternative, hedging every sealed feature with “not yet”, would bury the design under scaffolding and tell a reader nothing durable.

Maturity is tracked here, in one predictable place, so the rest of the site can describe the design without hedging every sentence. The language core and its ANALYSIS-plane surface are implemented; the remaining planes and the FDK pillars are sealed designs being built in a frozen order, collections first. Where the design itself weighs something and holds it back — a rollout that follows v1, a seam kept open and inert, an alternative evaluated and set aside — the page that reaches it explains the decision there, in prose, the way concurrency explains why it does not chunk stateless sub-graphs.

#Status at a glance

This is the canonical status table; no other page restates it.

What is implemented is verifiable as such: two engines agreeing byte for byte, and server-side replay re-linking the exact pinned closure, are properties the built core already carries — see Packages & distribution and Guarantees. “Sealed design; implementation staged” means the plan is frozen and the behavior on every page is the behavior being built to.

#Where the design holds something back

A sealed design is not uniformly finished-and-waiting. Three shapes of held-back thing recur across the site, and each is explained where it arises rather than flagged with a badge:

• A rollout that follows v1. The mechanism is built; what remains is deploying it. The public registry is the clearest case — the packaging, the content-address pinning, the transitive capability aggregation and the verification are all implemented, and what follows is standing up the place where strangers publish to strangers. A readable version layer over the author/package coordinate — a human writes “at least 1.2”, a tool resolves it by minimal version selection to a pinned hash — is the same shape: finished mechanism, deployment a later step. Packages & distribution works both through.
• A seam kept open and inert. A name is carried in the grammar or the ABI so nothing has to change to admit a feature later, but it governs no behavior today. The reduction node class is one: its rule is written and enforced before the first operation that needs it, and binds the moment that class has a member.
• An alternative evaluated and set aside. The design considered it, the cost model or the workload ruled against it, and the page says why. Chunked data-parallelism over stateless sub-graphs is the worked example — weighed and not adopted, for the reasons given in full there.

None of these reaches the reader as an open future option. Either the behavior is part of the design and the page states it in the present tense, or the design made a decision and the page explains it.

The site’s wider notation — kinds in code style, verbatim error codes such as [ErrDim] and [ErrCapDenied], the numbered invariants I1–I7 and amendment rules A1–A15 — is catalogued in Conventions & notation.

#See also

• Conventions & notation — the full notation catalogue.
• Packages & distribution — the registry and version overlay, worked through.
• FDK overview — the pillars, the frozen build order, and the capability model.
• Guarantees — what the implemented core promises, and how each promise is machine-checked.
• The map — every page, and the path through them.