Colour System Profile

Status: normative implementation template

Version: 0.1

Use this record to commission, generate, review and release a product colour system. It operationalises HIF-COL-* and Colour and Theming. Delete instructional text only after every required field has an answer or a recorded exception.

1. Identity and authority

2. Context before colour

Record:

• primary audiences, tasks and environments;
• supported platforms, display classes and output media;
• safety, legal, accessibility and brand constraints;
• content density and expected duration of viewing;
• ambient-light and glare conditions that materially affect use;
• meanings already established by domain or platform convention;
• meanings that MUST remain distinguishable without colour.

2.1 Required semantic roles

List the roles before entering any colour value.

Add every product-specific role. Do not use a colour name as the meaning.

3. Expression and restraint policy

This section prevents uncontrolled saturation from becoming the visual system. It is a product-specific constraint, not a universal 60–30–10 formula.

High-chroma candidates require a named role. If two unrelated areas compete at the same emphasis level, reduce area, chroma or prominence before adding another colour.

4. Source colours and rights

A brand colour is an input constraint, not an automatic interface foreground, background or status colour. Record any protected spot-colour or reproduction tolerance separately from screen values.

5. Colour-space and gamut contract

Every enhanced token MUST resolve to an approved baseline value.

6. Generation contract

The generator MUST treat palette construction as a constrained optimisation problem.

6.1 Hard constraints

• every required token exists and resolves without a cycle;
• every required colour is valid in its declared space;
• baseline values are in gamut or use the declared deterministic mapping;
• required rendered pairs meet their declared WCAG 2.2 contrast threshold;
• consequential meaning has a sufficient non-colour cue;
• required states and data series remain distinguishable;
• user colour and forced-colour modes retain structure and operation;
• forbidden semantic collisions do not occur.

A candidate failing any hard constraint is rejected, regardless of its aesthetic score.

6.2 Soft objectives

Rank and weight the objectives for this product:

Soft scores MUST NOT compensate for a failed hard constraint.

6.3 Reproducibility inputs

profile_id:
profile_version:
generator:
  name:
  version:
  source_revision:
working_space: oklch
baseline_gamut: srgb
enhanced_gamut:
seeds: []
lightness_targets: []
chroma_policy:
hue_policy:
neutral_policy:
contrast_pairs: []
distinction_constraints: []
rounding:
random_seed: null

The same inputs and implementation version MUST produce the same released values.

7. Primitive-scale output

For each family, record anchors, monotonic direction, permitted hue drift, chroma envelope and intended uses.

Primitive scales are implementation material. Product components MUST consume semantic or component tokens.

8. Required pair matrix

Record the rendered foreground, background and applicable threshold. Add every state, not only the default component.

Opacity, gradients, images, video, blending and overlays MUST be composited before the pair is evaluated.

9. Modes and state matrices

Complete independently for:

• light scheme;
• dark scheme;
• increased or reduced contrast where supported;
• forced system colours;
• brand variants;
• baseline and enhanced gamut;
• platform variants;
• data-visualisation schemes.

For every interactive role include rest, hover, active, focus-visible, selected, disabled, read-only, invalid, busy and applicable combined states.

10. Token delivery

Use the Design Tokens Community Group 2025.10 colour format for interchange unless a recorded platform constraint requires another representation.

{
  "colour": {
    "semantic": {
      "text-primary": {
        "$type": "color",
        "$description": "Primary readable content on the base surface.",
        "$value": "{colour.primitive.neutral-90}"
      }
    }
  }
}

Generated platform exports MUST retain a source-map to the canonical semantic token and profile version. Ungoverned colour literals fail release.

11. Evaluation record

11.1 Automated evidence

• syntax, precision, range and gamut;
• complete and acyclic token graph;
• all required contrast pairs;
• monotonicity and declared perceptual spacing;
• state and mode coverage;
• baseline/enhanced fallback equivalence;
• colour-vision transformations as diagnostics;
• asset profiles and provenance.

11.2 Rendered and human evidence

• real components and representative content;
• light, dark and forced user palettes;
• glare, low luminance and representative devices;
• greyscale and relevant colour-vision variation;
• focus, selection, status and combined states;
• comprehension without colour names;
• charts at actual mark size;
• print proof where applicable.

12. Exceptions and residual risk

An exception MUST NOT be hidden by regenerating a prettier palette or changing the scoring weights after review.

13. Release decision

The released profile, generator version, canonical tokens and evidence MUST be versioned together.