Status colors and category colors need their own separate territory or one will bleed into the other

What it is

A product runs two colour systems side by side: semantic colours for status and action (red/yellow/green, success/warning/failure), and data palettes for quantity and category. Without a boundary, one colour on one screen carries two meanings — red is both "failed" and "East China region" — and readers cannot tell which system the red in front of them belongs to. Territorial separation does not forbid coexistence; it assigns each hue a residence: where it may appear and what it may mean.

Why it happens

Colour meaning is context-driven, but readers cannot rebuild context at every glance: the green of a dashboard status light and the green of category three in an adjacent chart get associated within a 100-millisecond fixation, legend not consulted. Territorial separation eliminates cross-system collision — semantic colours confined to the component layer (status dots, alert bars, buttons), data palettes confined to the chart layer, the two hue sets disjoint or overlapping only where the data's meaning runs the same way. With the boundary fixed, context no longer needs rebuilding: red-yellow-green means status, chart palettes mean quantity, and the two channels stop bleeding into each other.

Where it stops holding

The cost of separation is a tighter hue budget: with red/green/yellow/blue reserved, fewer hues remain for data, and many-category charts hit the discriminability ceiling sooner — a worthwhile trade of choice for interpretive certainty, but a real one. Perfect disjointness is sometimes impossible (brand colour appearing on both sides, status colour required inside chart annotations); the workable compromise is "same hue, different lightness" rather than "same hue, same lightness," with position and form aiding the split. Territorial rules must live in a document and ride design review — otherwise every new chart quietly erodes the border.

Applying it

• Keep a colour residence register: every semantic colour value and its permitted locations, every data palette value and its permitted component types — neither list crosses the line.
• Check new chart components against the register: collisions get a recolour or a lightness shift, and any exception is recorded with its rationale.
• Verification: screenshot the status area and the chart area of one interface and lay their colour lists side by side; any pair sharing a value while meaning different things is a violation to remediate one by one.

Related

• Same group: U4.06.1 Semantic colours override the palette's neutral meaning · U4.06.2 Semantic direction varies by culture and industry; up/down colouring is the example · U4.06.4 Brand colours entering the data palette break perceptual uniformity · U4.06.5 Semantic colour needs a text label to be judged on its own
• Nearby: U4.01.2 Too many categories means grouping or aggregation · U4.05.5 Verify alternatives at design time, not after feedback
• Search terms: colour governance · semantic colour scope · design system colour