One built, none submitted
Showcase
One thing has been built with opsinjs, and opsinjs built it. Nobody else has shipped anything yet, so there are no entries from other teams, and saying so is more useful than a grid of invented screenshots.
One thing opsinjs built itself, which is not an entry
It is named as opsinjs's own work rather than listed as an entry, deliberately. It clears none of the four tests below: nobody uses it, no team shipped it, and every figure in it is invented. It is here because a design system that has never assembled its own parts into a product has not finished arguing its case, and because the argument is more useful made in a running application than in another page of prose.
A diabetes medicines app
One page, four destinations, thirty-five components. It records the medicines somebody takes and reminds them at times they chose. It calculates no dose, changes no dose, and says nothing about what to do about a dose they did not take, and those three refusals are in the code rather than in a disclaimer. It carries neither colour axis, which is the finding rather than a gap.
No entries from other teams yet.
opsinjs has no published packages, and every implemented component has been audited against WCAG 2.2 AA by its own authors rather than independently reviewed: the API may change in any release without a deprecation cycle, neither an independent accessibility review nor a clinical review has taken place, and none of it is ready for a production health surface until a clinician signs it. Nothing can have shipped to real readers on that, so an entry on this page today would be a fiction. It would be a fiction on the page whose entire purpose is evidence.
Why the audit is author-run, not independent · What has to happen first
What an entry will have to show
Published while there was nothing to put on this page, so that the bar was not set by whoever asked first.
A real product with real readers
Shipped and reachable by somebody who is not on the team. Concept work, portfolio pieces and internal demos are interesting and belong somewhere else. The value of a showcase is that it is evidence the system survives contact with production.
A named team who agreed to appear
Health products have regulatory and commercial sensitivities that a marketing site does not get to decide on their behalf. Entries are opt-in, attributed, and removable on request without discussion.
Screens with the axes intact
A product that has themed opsinjs into a single-axis colour system is welcome to do so, because it is your product. It is still not an example of this system working. The showcase is a claim about the system, so the entry has to be one.
No patient data, ever
Screenshots use synthetic readings. Not a formality: a plausible blood-glucose series is identifying in combination with a date and a location, and a marketing page is exactly where that gets forgotten.
In the meantime
Beside the app above, the screen specimens are the other place to look. Each one is a whole-screen specification showing the two colour axes, the material ladder and the motion tokens working together rather than one component at a time. Most of them are specifications, and they say so, but together with the app they are the best available answer to “what does a system built this way actually look like”.
Building something with these ideas before the components exist is entirely possible, since the tokens and the doctrine are the substantial part. If you are doing that, say so on GitHub. The first entries here will come from people who did that.
You can also see the system applied to itself: the colour browser and the playground are drawn entirely from the token layer.