---
title: "Roadmap"
description: "The public backlog is ordered, shows its blockers, and deliberately has no dates."
url: "https://opsinjs.pensievelabs.org/project/roadmap"
source: "https://opsinjs.pensievelabs.org/project/roadmap.md"
section: "Project"
kind: "project"
reviewed: "2026-09-20"
reviewer: "engineering"
aliases: ["backlog", "what is next", "when will X ship"]
---
> Elements written as `` below are opsinjs documentation
> components. Their attributes are the content: the values they render are
> generated from `tokens/*.json` and `registry/catalogue.ts` and are
> published separately at https://opsinjs.pensievelabs.org/r/index.json and under the Reference
> section.
> Nothing is missing from this page. The data simply does not live in
> the prose.
## How to read this [#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 [#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](./decisions/0025-the-audit-is-author-run.mdx)),
none has had an independent accessibility review or a clinical review. Every
catalogue row is implemented and installable. See [Release phases](./release-phases.mdx)
for what `shipped` obliges us to and, more to the point, what it does not.
## Blockers [#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](./decisions/0025-the-audit-is-author-run.mdx), 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](../handbook/tooling/index.mdx) 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](./decisions/0025-the-audit-is-author-run.mdx)); 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](../accessibility/accessibility-statement.mdx) 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](./decisions/0005-no-lang-segment-yet.mdx). 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 [#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](../foundations/data-visualisation/index.mdx)
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](./decisions/0002-shadcn-registry-distribution.mdx).
* **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 [#how-something-gets-onto-this-page]
Through
[Proposing a component](../handbook/contributing/proposing-a-component.mdx),
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.