Project
What opsinjs is as a project rather than as a library. Its scope, its promises, who maintains it, and where each of those is written down.
What this section is for
Everywhere else on this site is about building an interface. This section is about the thing you would be depending on: how much of it exists, what it promises, what it has already decided and cannot easily undo, and what happens when it changes under you.
Design systems are usually evasive about this. The pages that would answer "should I bet on this" are the state of the system, the versioning policy, and the list of decisions and their consequences. They are either absent or written as marketing. That is a bad trade in ordinary software and an unacceptable one in health software, where the team adopting a component library may have to justify that choice in a clinical safety case to somebody who was not in the room.
Start here
State of the system is the page to read first and the one to re-read before every upgrade. It is dated, it is deliberately blunt, and it says what exists, what is safe to build on, and what will break. If you read only one page in this section, read that one.
What is in this section
What exists and what is coming. State of the system for today; Roadmap for the ordered backlog, with blockers and without dates; Proposing a component for how something gets onto it.
What the labels promise. Release phases defines the
three statuses a component page and a catalogue row can carry, and says what each
one obliges us to. No other kind of page has one.
Versioning policy defines what counts as a breaking
change. The answer includes the rendered DOM, the data-* attributes and the
CSS custom properties, not only the JavaScript API.
Deprecations is the live list of what is going away.
How the documentation is kept honest. Docs freshness gives every page kind a review cadence and an owner, and expired pages are reported by CI rather than discovered by a reader.
Where to go with something. Community for questions, Security for a vulnerability, Official resources for the canonical domain, npm scope and registry URL. That is also how you tell this project from something impersonating it.
Why the system is like this. Decisions holds one record per architectural decision: the context, the choice, the alternatives, and the consequences we accepted. Changelog is the narrative of what actually shipped, and it says which changes are large enough to earn a written guide of their own.
What you may do with it. Licence and attribution covers both licences. The code is MIT, and the guidance prose is separately CC BY 4.0 so it can be quoted inside a regulatory document with a clear attribution path.
Scope, in one paragraph
opsinjs is a presentation layer for consumer- and patient-facing health screens: the interface a person uses to read their own numbers. It is not a clinical system, not a decision-support tool and not a medical device, and it takes no position on what any value means for any person. Thresholds, reference ranges and clinical wording belong to the product that ships it. The full statement, including the specific regulatory claims this project does not make, is Safety, scope and limitations.
Who maintains it
The opsinjs maintainers, working in the open. There is no company behind this project, no support contract, and no service-level agreement on an issue or a question. Community says what response you can reasonably expect and where each kind of message should go, and it says so in plain terms rather than implying a team that does not exist.
Decisions that change the shape of the system are recorded as decision records before they are implemented, including the ones that turned out to be wrong. That record is the closest thing this project has to governance, and it is public for the same reason the roadmap is: if you are being asked to depend on this, you are entitled to see the reasoning.
Last read through against the system on 2026-09-02. Due for review every 6 months; expiry is reported by pnpm run check:freshness.