ADR-0007 Density: independent collection, not a theme axis
#Context
The system needs at least two working densities: the default SaaS case reads best comfortable, and supervisor and monitoring surfaces earn their keep compact. The undecided question is where density lives in the token architecture — as additional modes on the theme axis, or as its own collection orthogonal to it. The ramp generator and the Phase 2 spacing and type work cannot start until this is settled, because the answer decides whether spatial tokens are authored once per density or once per theme-density pairing.
#Decision
Density is an independent collection with two enumerated modes, comfortable and compact, orthogonal to the theme axis. The orthogonality is earned, not asserted: theme resolves the chromatic and emission token set, density resolves the spatial set — spacing, type scale steps, target sizes — and the two sets are disjoint. A Scope declares one density and its children inherit it without override, as the composition contracts already require. The one interaction between the axes is handled by the existing theme-capability mechanism: field-day mandates larger targets and heavier weights, so in field-day a declared compact resolves as comfortable — a documented clamp enforced at build time, not a forbidden cell. Spatial semantic tokens resolve in both densities from Phase 2 onward, no partial modes, for the same reason ADR-003 forbids partial themes.
#Rejected options
Density as a theme axis (eight resolved themes). One axis, one resolution mechanism, superficially simpler. Rejected because it welds two disjoint token sets to a single selector: every theme edit would drag the spatial set into review and every density edit would drag the chromatic set, and the theme-completeness check doubles its surface for cells that differ only in tokens the theme never touches. ADR-003 rejected a matrix with incoherent cells; this would rebuild one.
Per-component density props. Maximum flexibility per instance. Rejected because it repeals the density-coherence contract: a Scope declares one density precisely because mixed density inside a region is the fastest way to make an instrument panel look accidental. A prop that lets any child diverge makes the contract unenforceable.
Single density. Halves the spatial test surface and defers the question. Rejected because the two named markets pull opposite directions — one density fails either the SaaS default or the monitoring surfaces, and retrofitting a second density later is the spatial version of retrofitting a theme, which ADR-003 already names as the reliable way to rot a token architecture.
Continuous density scaling (a multiplier instead of modes). The most flexible shape. Rejected on the same ground as ADR-0006's user-selectable hue: receipts require enumerable configurations, and a continuous parameter makes the checked surface unbounded. Two modes ship receipts; a dial ships a disclaimer.
#Consequences
The Figma Density collection is confirmed as its own collection with modes comfortable and compact, resolving independently of Theme. Phase 2 authors every spatial semantic token in both densities from the start. The enforcement table gains a density-completeness check — token diff across densities for the spatial set — mirroring theme completeness; the density-coherence rule already lives in the composition lint and is unchanged. The field-day clamp is recorded in the theme-capability contract and is machine-checked from Phase 3. The ramp generator is unaffected in its chromatic path; the spacing and type generators take density as an enumerated input.