Rethinking design systems as scalable architecture

The current discourse stops short

Design systems aren’t failing because teams over-engineered them. They’re failing because we systematized appearance and left meaning implicit.

Two critiques dominate the design system conversation right now. Both are correct. Neither goes far enough.

One camp argues systems have become too rigid. Token fatigue. Variant explosion. The sense that primary-on-secondary-hover-disabled has crossed from precision into parody. Teams feel the bureaucracy. What was meant to accelerate work now feels like bloat.

The other camp argues we’re too focused on tokens at the expense of deeper architectural thinking. Nathan Curtis recently cautioned that the community solves token problems that are already well-understood while avoiding thornier challenges. The advice is sound, stop perfecting tokens and tackle the harder structural work.

But I’d push further. Component architecture isn’t the missing layer either.

Both critiques are pointing at real pain. Token fatigue is real. Governance gaps are real. But they’re symptoms of the same underlying failure: we built rigor at the visual layer and left the semantic layer ad hoc.

A mature design system today can tell you this card uses spacing-lg and this badge has tone: warning. It cannot tell you this is an Organization in a churned state, that available actions depend on the viewer's role, or that this entity belongs to a parent that constrains what transfers are allowed.

That’s not a token problem. It’s not a component architecture problem. It’s an entirely missing layer.

That missing layer is not abstract. It’s structural. And understanding where it lives, helps contextualize the last decade of design system decisions.

Rigor at the wrong altitude

This isn’t a failure of discipline. It’s a failure of target.

Design systems became precise in the layer we knew how to govern. Tokens are enumerable. Components are testable. Variants are diffable. We built tooling, linting, automation, and review processes around the things we could see and measure.

Semantic structure resists that. Objects, states, permissions, and relationships don’t fit cleanly into a Figma library or a Storybook instance. They cross boundaries: design, engineering, product, policy. They require decisions that feel like someone else’s job.

So we deferred them. We let meaning stay implicit, resolved at runtime, scattered across codebases, documented in tribal knowledge or not at all.

Token adoption hit 84% not because tokens are hard but because they’re tractable. The frontier isn’t more tokens. It’s the layer we’ve been avoiding because it’s genuinely harder to systematize.

OODS as a semantic layer

OODS Foundry does not replace your component library or your tokens.

It sits between them and your shipped UI, providing a semantic layer your teams already reason about but have not encoded.

The stack is simple:

• Design tokens define visual language
• OODS defines semantic structure through objects, traits, and composition rules
• Components render those objects in context

This is not a new source of truth. It is a way to make existing truth explicit.

OODS does not invent meaning. It forces teams to encode the meaning they already rely on, meaning that currently lives in scattered code, documentation, and people’s heads.

That shift changes what the system is responsible for. It stops being a catalog of parts and starts acting like infrastructure.

Objects and traits define product reality

Objects are the nouns of your product.

OODS starts with five canonical ones: User, Organization, Product, Transaction, and Relationship. Each object is defined once and carries schema, states, allowed actions, and constraints.

Traits are reusable capabilities that objects compose. Stateful introduces lifecycle and transitions. Ownerable defines ownership models and transfer rules. Authable handles permissions and entitlements. Addressable models locations with roles. Taggable supports constrained or open classification.

object: Organization
traits:
  - lifecycle/Stateful
    parameters:
      states: [prospect, onboarding, active, churned]
  - structural/Ownerable
    parameters:
      ownerTypes: [parent_organization, reseller, platform]
      allowTransfer: true
  - core/Authable
  - core/Addressable
    parameters:
      roles: [headquarters, office, warehouse, branch]
  - behavioral/Taggable
    parameters:
      allowedTags: [enterprise, smb, nonprofit, startup, strategic]

The Organization is not a component.

It is a composition of capabilities that can render as a list item, a detail view, an admin surface, an automation target, or an agent interface depending on context.

That distinction matters. It separates what the product is from how it happens to appear on screen.

Relationships as first-class objects

Most systems treat relationships as foreign keys and distribute their implications across application code. A user belongs to an organization, so somewhere there’s a user.organization_id. What that membership means, who can see it, what permissions it grants, whether it's provisional or confirmed, who created it and why, gets scattered across services, resolved at runtime, and documented nowhere the design system can reach.

OODS treats Relationship itself as an object.

object: Relationship
schema:
  relationship_type:
    enum: [membership, ownership, follows, depends_on, references]
  direction:
    enum: [unidirectional, bidirectional]
  strength:
    enum: [low, medium, high]
  origin_source:
    enum: [manual, ingestion, analytics, integration]
traits:
  - lifecycle/Stateful
    parameters:
      states: [proposed, active, paused, completed, terminated]
  - structural/Ownerable
  - behavioral/Taggable

A membership can be proposed (invited, not yet accepted) or active (confirmed) or paused (suspended employee who might return). The system knows the difference, and the UI can reflect it without custom logic per surface.

Provenance travels with the relationship. Was this connection created manually by an admin, inferred by analytics, or synced from an external integration? That matters for trust signals, audit trails, and whether the relationship can be edited or only observed.

When the system understands relationships explicitly, interfaces that surface them stop being one-off builds. Org charts, permission panels, team rosters, and audit trails become different contexts rendering the same underlying structure. The relationship object carries the meaning; the context determines how it appears.

Multi-brand without variant explosion

Multi-brand theming is usually treated as a component problem. Teams duplicate libraries, fork systems, or create parallel variant trees. Brand B needs a different button radius, so now you maintain two button components. Brand C needs a different status palette, so now you maintain three badge systems. The multiplication compounds until “multi-brand support” means “multiple design systems with a shared ancestry and diverging futures.”

OODS approaches it differently: brand is a context, not a fork.

Each brand owns its token sources. Brand A defines its palette, type scale, and semantic mappings in one location. Brand B defines its own. But the objects and traits remain unchanged. An Organization is still an Organization. Stateful still means lifecycle states and transitions. The semantic layer doesn’t branch.

Brand selection flows through a single attribute on the document root. CSS scopes remap the token layers to theme tokens, system tokens, component tokens without touching component code. The same StatusBadge component, rendering the same churned state from the same Organization object, resolves to Brand A's visual language or Brand B's depending on context.

Brand A: churned → muted gray, "Churned" label, archive icon
Brand B: churned → deep red, "Lost" label, warning icon

Same object. Same trait. Same state. Different expression.

The approach requires guardrails. Brand-bleed — where Brand A tokens leak into Brand B contexts — is a real failure mode. OODS runs lint checks that catch cross-brand imports before they ship. Visual regression tests run per-brand baselines, so drift between brands surfaces as an explicit diff rather than a silent inconsistency discovered in production.

One semantic definition. Multiple visual expressions. No variant explosion.

The new contract opportunity

The cost is coordination.

Teams have to decide what their objects are, what states they can be in, and what ownership and permissions actually mean. That work surfaces disagreement that was previously hidden in ad-hoc implementations.

What it delivers is a vocabulary aligned with how the business thinks. Less duplication of logic across UI and code. A surface agents can read instead of reverse-engineer. Governance focused on meaning rather than endless visual variants.

When objects and traits become explicit, teams gain something rare: a shared structure they can reason about, extend, and debate deliberately. Product reality becomes something you can version, test, and evolve rather than reinterpret on every screen.

One contract, many consumers

Accessibility tools and AI agents share a constraint. They try to understand interfaces without seeing them.

Color alone does not communicate danger. Layout alone does not communicate intent.

OODS makes meaning explicit. Objects carry semantic types. States map to labels, tokens, and icons. Actions declare constraints and consequences. Context is marked rather than inferred.

The same contract serves humans using assistive technology, agents proposing or generating UI, and teams maintaining coherence over time.

Systems scale when their contracts are clear.

APIs scale because contracts are explicit. Type systems scale because constraints surface early. Infrastructure as code scales because state is declared rather than procedured. Databases scale because relationships are explicit and enforced.

Atomic design gave us a visual contract: these atoms compose into these molecules. That contract held for over a decade because it matched the constraint we were solving — visual consistency across teams at scale.

But the constraint has shifted. Multi-brand, multi-consumer, multi-context — these are semantic problems that the visual contract can’t absorb. You can’t solve “same object, different brand expression” with more button variants. You can’t solve “a screen reader or an AI agent needs to understand intent” with better color tokens.

Design systems don’t become scalable by perfecting their components. They become scalable when they take responsibility for the contracts that govern how products actually work.