architecture-options

Density architecture options worksheet

This worksheet translates the five evidence-based models into decision prompts. The models are descriptive; the worksheet does not score an option before PDS-specific evidence is collected.

Evaluation criteria

Assess each candidate against:

• preservation of one governed component identity
• ability to establish a coherent product default
• sanctioned coexistence of densities
• separation from color, component size, responsive behavior, and modality
• Figma discoverability and inheritance clarity
• code implementation and Figma/code parity
• component-specific clamps and exclusions
• accessibility and localization constraints
• migration effort from current PDS bindings
• testing and maintenance surface

Evidence-based options

Model	Density decision enters at	Public examples	Coexistence pattern	PDS question to answer
Curated contextual scale	Context selects coordinated scale tokens	Adobe Spectrum	Scoped context plus explicit component size	Should one inherited context coordinate geometry across most components?
Numeric theme with clamps	Theme density value resolves component maps	Angular Material	Global, selector-scoped, or component-generated CSS	Does PDS benefit from numeric steps, or would curated semantic modes be clearer?
Application policy and semantic remapping	Product/user policy activates alternate semantic aliases	SAP Fiori, Salesforce Lightning	Broad application policy with constrained exceptions	Who owns the default, and what mixing policy is permitted?
Explicit component size	Consumer selects geometry on each component	IBM Carbon, Microsoft Fluent	Component and region level	Is explicit local control sufficient, or is a coherent product default required?
Component-local compact modifier	Selected components remap their own metrics	PatternFly	Opt-in component level	Which information-heavy components need a compact control independent of product context?

The token-model analysis contains strengths, tradeoffs, design/developer consumption, and accessibility implications for each model.

Hybrid pilot already proposed

The current PDS proposal combines:

• an inherited density-semantic context for participating metrics
• explicit component size as an independent axis
• approved local controls for tables, lists, and similar information-heavy patterns
• deliberate non-participation or constraints for selected surfaces

Two Figma binding structures remain to be compared during the pilot:

1. One shared density-semantic collection consumed by component metrics.
2. Component-specific density collections similar to the List Item collection visible in the Uber demo.

Working comparison

Complete this table with evidence from the component and Figma audits. Use unknown rather than guessing.

Criterion	Shared density semantics	Component-specific collections	Explicit component controls only
Product-level default
Local coexistence
Figma mode discoverability
Number of author controls
Cross-component consistency
Component clamps/exclusions
Code parity
Migration effort
Accessibility governance
Test-matrix impact

Outcome

• Selected pilot structure:
• Why it was selected:
• Evidence used:
• Alternatives retained for comparison:
• Conditions that would invalidate the selection:
• Unresolved questions: