---
title: "Project"
description: "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."
url: "https://opsinjs.pensievelabs.org/project"
source: "https://opsinjs.pensievelabs.org/project.md"
section: "Project"
kind: "project"
reviewed: "2026-09-02"
reviewer: "engineering"
aliases: ["about the project", "governance", "who maintains opsinjs"]
---

> Elements written as `<PascalCase … />` 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.

<PageTemplate kind="project" />

## What this section is for [#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 [#start-here]

[State of the system](./state-of-the-system.mdx) 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-is-in-this-section]

**What exists and what is coming.** [State of the system](./state-of-the-system.mdx)
for today; [Roadmap](./roadmap.mdx) for the ordered backlog, with blockers and
without dates;
[Proposing a component](../handbook/contributing/proposing-a-component.mdx) for
how something gets onto it.

**What the labels promise.** [Release phases](./release-phases.mdx) 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](./versioning-policy.mdx) 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](./deprecations.mdx) is the live list of what is going away.

**How the documentation is kept honest.** [Docs freshness](./docs-freshness.mdx)
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](./community.mdx) for questions,
[Security](./security.mdx) for a vulnerability, [Official resources](./official-resources.mdx)
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](./decisions/index.mdx) holds one
record per architectural decision: the context, the choice, the alternatives, and
the consequences we accepted. [Changelog](./changelog/index.mdx) 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](./licence-and-attribution.mdx)
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 [#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](../start/safety-scope-and-limitations.mdx).

## Who maintains it [#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](./community.mdx) 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](./decisions/index.mdx) 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.

<LastUpdated />

<Reviewed />
