Flat Storybook lists feel productive. Every squad adds a "small variant." Two years later you have seven buttons, three card patterns, and onboarding that takes a month because nobody knows what's canonical.
You don't have architecture, you have a junk drawer.
Four layers
Primitives: token-bound, no business logic. Button, input, surface, typography.
Compositions: patterns built from primitives. Form row, page header, empty state shell.
Features: product-specific UI built from the system. Belongs in product repos or a clearly labeled feature layer, not mixed into primitives.
Governance: what can enter each layer, who approves, how versioning works.
Design engineers draw the boundaries
My job is often drawing lines so squads don't fork. Engineers reuse. Designers extend through contribution, not through "just this once" gray buttons that live for five years.
In audits, I map where teams actually build today vs where the architecture says they should. The gap is usually governance, not talent.
Adoption is the architecture test
A mediocre system that's adopted beats a beautiful one that's ignored. Architecture serves adoption, clear layers, clear docs, clear PR path for new patterns.
If everything lives in one list, you can't govern. Split the layers first, then scale.