Ownership, status, versioning and quality

Component lifecycle

Proposed → Experimental → Approved → Core → (Legacy / Deprecated). A component enters the approved system only when its purpose, use rules, anatomy, variants, accessibility, responsive behaviour, implementation type, status and owner are documented.

Status definitions

Contribution model

Propose → Prototype → Review → Document → Approve → Release → Evaluate. A proposal must identify the recurring need, existing options already considered, proposed anatomy, accessibility implications, likely reuse and ownership cost — before any code is written.

Ownership

One person may hold several roles during early stages — the responsibilities must still be named, not assumed to happen automatically. No formal system owner has been confirmed yet (see Open decisions).

Versioning

Token changes are major versions and require a visual regression check across everything. Component additions are minor versions, affecting only what adopts them. Binding fixes are patches. Never silently overwrite a stylesheet a published course already depends on — release a new immutable version.

Accessibility claim wording

Source-of-truth hierarchy

The umbrella publication decides what the system is. Platform guides decide how it's implemented. Production code governs the current rendered implementation and must be reconciled with documentation at release. This live catalogue demonstrates the current approved system — see Overview for the full document family.

Audit findings (July 2026, this release)

Findings from reconciling the six source documents against the production CSS, the supplied screenshots and the supplied HTML source examples.

• Undocumented shipped component. .isq-self-assessment (14 classes) exists in the production CSS and renders in the live Child Protection course, but appeared in none of the six governing documents. A first specification has been drafted for this release from the CSS and a supplied screenshot — see Self-assessment. It ships as Course-specific pending verification against real exported markup.
• Course-specific comparisons bypass the shared component. The live course's "Significant harm / Parent test" flip cards and "Able / Willing" comparison use bespoke, inline-styled markup (.isq-test-cards, .isq-able-willing) with locally redefined tokens (e.g. a gold value of #D9A928, distinct from the shared --isq-yellow: #FFC72A) rather than the shared .isq-role-split component. This is exactly the drift Document 2's "do not duplicate shared CSS" rule exists to prevent — flagged for migration, not fixed silently.
• Status vocabulary mismatch. Document 2 labels the Divider component "Restricted," a status outside the seven confirmed in Document 1's lifecycle model. Folded into Experimental here, matching Document 1's own component-audit note.
• Naming instability. Document 1's own audit flags .isq-role-split as "confirm naming." This catalogue settles on Role split, matching the CSS class.
• Missing class-index entries. .isq-band, .isq-grid/--two/--three and .isq-process are named as primitives in Document 2's prose but were absent from its technical class index. Corrected in this catalogue's component data.
• Colour-value drift between sibling documents. The Connect & Learn 2027 blueprint's indicative palette (e.g. Positive #1E6B45, Negative #A03232) differs slightly from the production Rise CSS (--isq-success: #266141, --isq-error: #A22B2A). This site renders the CSS values as the current source of truth; the blueprint's figures remain explicitly indicative-only.

Open decisions