Governance for a multi-brand design system

WHAT THIS TESTS Whether you can architect a shared core that scales across brands without absorbing brand-specific knowledge, and whether your governance enforces that boundary.

A GOOD ANSWER COVERS Make the core fully brand-agnostic: components reference only semantic tokens and never literal values or brand names. Each brand provides its own theme as a set of token values that repoint the semantic layer, so the same Button renders on-brand for every brand purely through tokens. Brand-unique components or compositions live in brand-specific packages that depend on the core, never inside it. Governance is the enforcement layer: contribution guidelines forbid brand conditionals and hardcoded brand values in core; automated lint rules detect brand strings or raw hex in core code; core review rejects brand leakage; an RFC process decides whether something belongs in core or a brand package. Define ownership: core team owns primitives and semantic tokens, brand teams own their themes and brand packages.

COMMON WRONG ANSWERS Putting if brand === acme branches inside core components, which couples core to every brand and grows unboundedly. Hardcoding a brand color in a shared component. Letting each brand fork the core. No automated check, so leakage creeps in. Mixing brand-only components into the core package.

LIKELY FOLLOW-UPS How do you detect brand leakage automatically? Where does a brand-only component live? How do you handle a token a brand needs that others do not? How do you onboard a new brand?

ONE CONCRETE EXAMPLE Core ships a Button using color-background-button-primary. Brand A's theme aliases that token to its purple, Brand B's to its teal. A request to add a special promo style only Brand B wants is rejected from core; instead it becomes a component in Brand B's package, still consuming core tokens, while a lint rule blocks any brand-named constant from entering the core library.