Roadmap

How to read this

This roadmap is ordered, not scheduled. There are no dates on it, and there will not be: a date on an unfunded backlog is a promise the project cannot keep, and the person most damaged by it is the one who planned a release around it. What you get instead is the order, the reason for the order, and the blocker attached to anything that is not moving.

The status of any individual component is not maintained here. It is generated from the catalogue, so it cannot drift from what the system actually contains.

The order, and why

Every component named below now exists, which is why this reads in the past tense. It is kept on the page because it explains the shape of what was built and which components lean on which, rather than because anything in it is still waiting.

1. Nothing shipped before the token layer was fixed. Every component reads semantic tokens, and every published contrast number describes a token pair. Renaming a token after twenty components consume it is the expensive mistake this project front-loaded to avoid, and everything built since was written against a token layer that had stopped moving.

2. The health data-display components came first, in this order: StatusPill, RangeBar, ResultCard. They were ordered by how much of the system they exercise rather than by how much anyone wants them. StatusPill is the smallest complete test of the status axis and the colour-independence rule. RangeBar is the first component that has to render a value against a range without implying a diagnosis, which is the hardest content problem in the system. ResultCard composes both and is the component most people arrive wanting.

3. Then the surfaces: Surface, Card, Sheet, Dialog. The material ladder had been documented and tokenised with nothing climbing it, and a ladder nothing climbs is a ladder nobody has tested. Those four exercise it now.

4. Then communication: AlertBanner, CareCard, Callout, DisclaimerNote. These carry the alarm-fatigue budget, so they were built after there was enough of a surface to measure a budget against.

5. Input and formatting last: ReadingInput, LogSheet, Value, RelativeTime. Value is small and was tempting to do first; it was deliberately late because its rounding and unit rules are doctrine that the components above it sharpened.

What is next is not an ordered list, and inventing one would be the dated promise this page opens by refusing. The honest statement is what has not been done: no screen specimen has been built, and while every component has now been audited against WCAG 2.2 AA by its own authors (see ADR 0025), none has had an independent accessibility review or a clinical review. Every catalogue row is implemented and installable. See Release phases for what shipped obliges us to and, more to the point, what it does not.

Blockers

Some measurements still do not exist. Bundle sizes and the keyboard reference are generated pages whose sources are still empty. All sixty catalogue rows now record a WCAG 2.2 AA audit, run by the components' own authors and recorded in ADR 0025, but none records an independent accessibility review. Those pages are not missing, they are waiting on numbers nobody independent has produced. An audit table filled in by the people who wrote the code is not a passing one.

Colour-independence and the never-mix rule need a lint rule, not a document. The rule is written, and a rule that is only written is a rule that survives until the first deadline. Until the ESLint and Stylelint plugins described in Tooling exist, this is enforced by review, which is to say weakly.

Accessibility conformance cannot be claimed without an independent audit, and none has been run. Every component has now been audited against WCAG 2.2 AA by the people who wrote it, and the findings from that pass were fixed in the same change (see ADR 0025); that is not the same claim as conformance. The reason independent conformance still cannot be claimed is the ordinary one, that nobody independent has looked. The accessibility statement lists what is unknown today rather than implying it is fine.

The [lang] segment is not blocked, it is deferred, with the exact retrofit recipe recorded in ADR 0005. Unit systems are treated as a correctness problem and ship now, because getting those wrong harms someone in English just as effectively as in any other language. Those systems are mmol/L against mg/dL, kilograms against stones, and Celsius against Fahrenheit.

What this project will not do

Saying no in public is part of a roadmap. None of the following is planned, and if you need one, opsinjs is the wrong dependency:

• Clinician-facing components. No EHR tables, no order entry, no prescribing. Density, training assumptions and error consequences are all different.
• A charting library. Data visualisation gives rules and an accessible chart contract; it will not ship a chart engine.
• A general form library. Field exists to make health inputs correct, not to compete with the form libraries that already work.
• A CLI. npx shadcn installs from our registry today and there is nothing a CLI of our own would add. Writing one before writing a component would have been building the shop before the stock; now that there is stock, the shop still belongs to somebody else, a choice recorded in ADR 0002.
• Native mobile. The system targets the web, including web views in native apps. React Native is not on this list.

How something gets onto this page

Through Proposing a component, which sets out the eight questions a proposal has to answer and the four reasons one is normally declined. The short version: a name is cheap, a specification is not, and nothing is implemented before its clinical contract is written down.

Edit this page

Last read through against the system on 2026-09-20. Due for review every 3 months; expiry is reported by pnpm run check:freshness.