Reference ยท Modules & Roadmap

How module status works

Every card on the Modules page carries a status word and sometimes a percentage. This page explains exactly what those mean, where they come from, and what stops them from quietly going stale โ€” so you can judge how much weight to put on them.

Applies to /modules/ and every /modules/* detail page ยท system introduced 2026-07-12

Contents

Why this exists

Module and roadmap status used to live in several places at once โ€” the homepage, a prototype modules page, and six individually hand-written detail pages. They drifted. Several still said WARMING, LOCKED or COMING SOON for systems that had already fully shipped: the Burn Center, Governance, Community Events and the Transparency Center.

That is the failure this system exists to prevent. There is now one registry that every surface reads from, a fixed vocabulary it must use, and an automated check that fails if the registry contradicts itself.

The honest summary: status on this site is a claim we make about our own work. This page is how you check that the claim is disciplined rather than decorative.

The ten status words

A module can only ever carry one of these ten values โ€” never a vague word like "warming", "soon", "almost" or "in build".

StatusWhat it means
liveShipped, working, publicly reachable today.
betaWorking but not fully validated or rolled out โ€” for example an Android beta, or an iOS build that has not been verified.
partialSome real, documented sub-items are done and others are not. The card lists which.
ongoingNot a software deliverable at all โ€” a recurring activity.
plannedNamed in the roadmap, not started.
deferredNamed in the roadmap, intentionally not scheduled. Not cancelled โ€” see the Bridge section below.
blockedWaiting on an external dependency that does not exist yet.
retiredWas live, deliberately taken down.
historicalAn early concept superseded by something real. Kept as a record, not an active roadmap item.
internalReal and live, but architecture rather than a place you can visit. No card is shown for these.

"Live" vs "ongoing" โ€” a distinction we refuse to blur

A module's status describes the software. A separate flag marks whether the activity it enables is a recurring programme that never reaches "100%".

Governance is the clearest example: the voting software is fully shipped, so its status is live โ€” while individual proposals and votes are an ongoing programme, so it also carries an ongoing-operation flag. The Burn Center is the same shape: the software is finished, the burns continue.

A live module with ongoing activity is not an incomplete module. Conflating the two would let us either overstate finished software or understate a finished system because its programme continues โ€” so the registry keeps them as separate fields.

Where percentages come from

There are no arbitrary percentages here. If a number cannot be traced to a counted list of sub-items, it is left off entirely.

How the roadmap is mapped

Every phase of the original roadmap is reconciled, item by item, against what is real today. Each item is stated independently and linked to its module where one exists.

A phase is never flattened to "complete" while any of its items are not. Phase 5 is deliberately marked ongoing rather than complete, because the Cross-Chain Bridge is deferred and Platform v2 enhancements are not started โ€” even though Governance v1, inside that same phase, is fully complete.

The Cross-Chain Bridge decision

The Bridge is deferred. That word is doing precise work, so here is exactly what it means and does not mean.

On record, 2026-07-12: the Cross-Chain Bridge commitment is retained on the original roadmap. The commitment remains accepted, and implementation is intentionally postponed while WinLEW completes and operates its current community, governance, reward and transparency systems.

This one is guarded in code. Automated tests fail loudly if the Bridge is ever silently marked live or retired, deleted from the registry, dropped from the Phase 5 mapping, or flipped to "complete" or "removed from scope" without a new, separate, explicitly recorded decision.

What the validator catches

A validation step runs against the registry as part of the test suite. It fails โ€” loudly, blocking the change โ€” when any of the following is true:

That third-from-last check is the one that matters most to a reader: a module cannot claim to be live and link somewhere that does not exist.

One source, every page

The Modules page and the homepage's roadmap grid both fetch the same computed status payload at load time and render entirely from it โ€” the same approach the Governance, Partners and Events pages already use. Nothing is rewritten at runtime; the registry is only ever edited by a person, in source control, and every edit goes through the validation above.

The individual detail pages own their own longer explanations, screenshots and narrative. What they are not allowed to own is status, progress, route or dates โ€” those come from the registry alone, so the same claim cannot say two different things in two places.

Where to go next