System glossary
The words opsinjs uses about itself are rung, axis, role, base, style and preset. Each has one definition and the page that owns it.
This is the vocabulary of the system, not of health. If you are looking for
HbA1c, reference range or systolic, you want the
Plain-English A to Z, which is written for
readers of your app rather than builders of it. The two glossaries never define
the same word; where a word genuinely has two meanings, both are listed here
with the disambiguation spelled out. The one that bites is status.
How this is generated
It is not, and this is the only page in Reference that is hand-written on
purpose. A project's terms of art have no machine-readable source: they exist in
prose, and a generator that scraped them from headings would produce a list of
headings, not a glossary. Inventing a tokens/system-glossary.json so that this
page could claim to be generated would add a file nobody maintains and a
provenance claim that means nothing.
What is enforced is the other half of the rule: every term below names the page
that owns its definition, and assert-ia.mts treats a term whose owning page has
disappeared as a broken cross-reference. A definition here may summarise; it may
never contradict.
| Term | What it means | Owned by |
|---|---|---|
| alias | A search synonym declared in a page's frontmatter. Aliases are indexed, emitted into llms.txt and into /r/index.json, and are globally unique across the corpus. | Catalogue |
| axis | One of the two independent colour dimensions. The status axis carries clinical urgency; the category axis carries subject identity. They never combine on one element. | The two colour axes |
| base | A behaviour implementation of a component. It is the React code. base is the only base that exists; the segment is in the URL of every machine surface so that adding a second one is additive rather than a migration. | Namespaces |
| catalogue | The single declared list of every component id, with its category, status and aliases. registry/catalogue.ts is its only definition. | Catalogue |
| category | A subject area a value belongs to. This is the identity axis. A category colour says what a number is about; it never says how worried to be. | Category identity |
| chrome | The documentation site's own interface: sidebar, header, search. Themed with lyra, deliberately unlike the product theme. | Lyra and the docs chrome |
| doctrine | A rule page that constrains components rather than describing one. The doctrine pages are everything under Health, Accessibility and Content & language. Doctrine names the components it governs; components name the doctrine that governs them. | Health |
| foundation | A cross-cutting system layer with tokens of its own: colour, materials, motion, typography, shape, space, and the rest. | Foundations |
| generated marker | The comment pair opsinjs:generated:begin / opsinjs:generated:end. Content between them is written by a script and is erased on the next run. | Reference |
| ladder | An ordered set of surface treatments where position carries meaning. These are the six material rungs. Distinct from a scale, whose steps are sizes rather than meanings. | The ladder |
| namespace | The @opsinjs prefix a consumer registers in components.json so that npx shadcn add @opsinjs/result-card resolves here. | Namespaces |
| pillar | A top-level group in the sidebar. Sixteen exist; a page belongs to exactly one. | Reading these docs |
| preset | A complete theme expressed as values rather than code. Those values are the token overrides that turn the system a particular colour. | Preset codes |
| preset code | The short opaque string, opsinjs-*, that encodes a preset for a URL or a CLI flag. Decodable, versioned, and not a secret. | Preset codes |
| product theme | The theme opsinjs components render under: squircle corners, system-ui, generous spacing. Every /view route and every component preview uses it. The docs chrome does not. | Lyra and the docs chrome |
| ramp | A perceptually even series of steps generated from one colour in OKLCH, clamped for gamut and checked for contrast. Each axis colour has one. | How the engine works |
| recipe | A task-shaped page: components plus tokens plus copy rules for one job, in one scroll. | Recipes |
| registry item | The JSON document describing one distributable unit in the shadcn registry schema. It covers the unit's files, dependencies and target paths. Served from /r. | registry-item.json |
| role | A semantic colour slot filled by a ramp step. The four roles are surface, line, ink and accent. Components consume roles; they never consume ramp steps directly. | Colour roles |
| rung | One step of the material ladder, identified by its position in the stacking order rather than by a blur radius. | The ladder |
| scale | An ordered set of sizes named by intent rather than by t-shirt size. The scales are type, space and radius. | Token architecture |
| screen | A whole-screen specimen: several components under one layout, used to show what the parts do together. | Screens |
| status (clinical) | One of the four ordinal levels describing a value's relationship to what is expected for a person. The four are steady, watch, attention and urgent. | Clinical status semantics |
| status (release) | One of the three phases describing how much of a promise a component is making. The three are planned, shipped and deprecated, and only a component page carries one. | Release phases |
| style | A visual variant applied as CSS only, never as behaviour. base-lyra is the default. Styles are addressable in /view and /r URLs; documentation pages have exactly one canonical URL regardless of style. | Namespaces |
| tier | Which of the three levels a token sits at: primitive (a raw value), semantic (a role), or component (a part). Components read semantic and component tiers only. | Token architecture |
| twin | The .md version of any documentation page, served by appending .md to its URL. Processed markdown, not raw MDX. | Raw markdown API |