BC
Brad CodyAdministrator
Current product→Shared components and patterns
Reverse spec drafted

Status pills and semantic colours

Shared representation of state, priority, access, exceptions and completion across tables and records.

Observed routeShared componentFuture Spec 16 →
Current maturityReusable visual language without one visible semantic registry
Evidence confidenceVerified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

Pills and colours communicate Pipeline Stage, Task State, Priority, access, evidence and network conditions across cards and grids. The visual language is coherent, but taxonomy differences—such as Urgent existing in Task Builder but not Tasks filters—show that labels and colours are not yet governed from one semantic registry.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
LabelText accompanies pill colour in reviewed surfaces.Verified
ColourNeutral, gold, green, blue and other soft tones distinguish concepts.Verified
Semantic keyStable cross-surface registry is not visible.Inferred gap
FiltersAvailable labels may differ from builder values.Verified conflict

User journeys

Current flows

01

Render semantic status

  1. Resolve stable status key
  2. Apply domain registry label and token
  3. Render text/icon/colour
  4. Expose same option in filters and reports
  5. Preserve meaning when display label changes
Observed result

Visual pattern exists; registry enforcement is incomplete.

State model

Current and expected states

Default

Common pills render.

Custom label

Pipeline Stage labels may be editable.

Unknown/retired

Fallback behavior unverified.

High contrast

Not evidenced.

Product rules

Non-negotiable boundaries

  • Colour is never the only signal.
  • Stable semantic key is separate from label and colour.
  • Builders, forms, grids, filters, exports and reports share one registry.
  • Custom colours meet contrast standards.
  • Retired values remain renderable historically.
Dependencies
Design tokensSemantic registriesAccessibilityBuilders and gridsReporting

Known current limitations · 3 mapped

What is missing, broken or unverified

Future Spec 16 owns closure →
  1. No visible semantic registry.
  2. Priority conflict exists.
  3. Contrast, dark mode, printing and unknown-value behavior are unverified.

Future alignment

Required evolution

  • 01Create governed status and priority registries.
  • 02Add icon/pattern alternatives and contrast validation.
  • 03Reuse tokens in every portal and document output.

Current baseline

Acceptance record

  • Every state renders text plus accessible semantics.
  • All valid states are filterable.
  • Editable labels do not change system mappings.
  • Historical retired values remain intelligible.

Reverse-spec completeness

Documentation coverage

The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.

Purpose and user outcome

Documented

Roles and access

Documented

Routes and entry points

Documented

Page and component anatomy

Documented

Fields and displayed data

Documented

Primary actions

Documented

Forms and validation

Documented

States and transitions

Documented

Empty, loading and error states

Documented

Responsive behavior

Partial

Accessibility behavior

Partial

Activity and audit events

Partial

Data sources and persistence

Documented

Notifications and automation

Partial

Known defects and limitations

Documented

Reusable component dependencies

Documented

Future-spec conflicts

Partial

Visual and repository evidence

Deferred

Acceptance of current baseline

Documented
← Feature inventoryOpen Future Spec 16 →