Extend category sets by appending, never by reassigning

What it is

Stable category assignment under growth preserves existing identity encodings by stable entity ID and gives a new category a new mapping from usable, discriminable candidates. “Append, never reassign” is the default for avoiding irrelevant relearning, not a demand that every new category appear last or a ban on versioned migration when capacity, accessibility, or semantic error forces change. Identity assignment and display order must remain separate: colours can persist while categories enter semantic order or sort by task.

Why it happens

Regenerating a palette from the current category array lets insertion, filtering, or sorting give old IDs new colours, leaving historical images and live views with competing bindings. Persistent assignment blocks that drift, but unused colours may collide against a background, a neighbor, or a reader's colour vision; blind appending eventually fails too. The goal is to preserve a semantic contract, not an array index, so capacity checks, conflict detection, and explicit migration are integral.

Studying it

Exercise the mapping state machine with category addition, deletion, renaming, merge, split, filtering, and sorting. Confirm that an old stable ID does not drift within a version and scope and that unknown categories resolve deterministically without collision. Compare append and wholesale reassignment with readers who know the old mapping, measuring old-category recognition, cross-version correspondence, and new-category discriminability. Palette studies should vary background, mark size, colour vision, and cardinality rather than memory alone.

Where it stops holding

Migration may beat appending when channel capacity is exhausted, new and old values cannot be separated, an old mapping violates safety or cultural semantics, a brand theme changes, or merge and split alter identity itself. Historical reports should not be silently recoloured; cross-version comparison needs a mapping version, direct labels, or a transition note. Temporary high-cardinality values need not occupy permanent slots and may be aggregated, assigned on demand, filtered, or tabulated, but fallback must not vary randomly by client.

Applying it

• Store stable ID→identity encoding separately from semantic or display order, so insertion, sorting, and localized labels cannot remap old entities.
• Before allocation, test candidates against target theme, background, size, adjacency, and colour vision. When no valid slot remains, aggregate, change channel, or begin migration instead of blindly appending.
• Give migration a new version, mapping diff, owner, scope, effective date, and legacy-asset policy. Use labels or notices while two mappings coexist.
• Combine state-machine and historical-snapshot tests for determinism with old- and new-user identification tasks for stability and new-category discriminability.

Related

• Same group: U1.11.1 The same entity keeps the same colour and position across a chart series · U1.11.2 Encoding that jumps between charts forces readers to relearn the legend · U1.11.3 Only charts sharing a scale can be compared on magnitude · U1.11.4 Pin the mapping in the data layer; never configure it chart by chart
• Adjacent: U1.09.5 Over the limit, aggregate categories instead of subdividing the encoding · U4.01.2 Group or aggregate when categories multiply
• Search terms: stable category assignment · palette migration · mapping version