Design systems as capability catalogs, not component libraries

A component library tells a developer which button to render. It does not tell an AI agent whether that button should exist on a given screen, what action it authorizes, what confirmation it requires, or what happens when the action fails. The gap between "here is a styled component" and "here is what this interface is allowed to do" is where most design systems stop — and where AI-generated interfaces break. A design system capability catalog closes that gap by encoding intent, constraints, and permitted behavior alongside the visual primitives.

AI breaks component-only design systems

Component libraries define appearance: color tokens, spacing scales, typography ramps, variant props. They answer the question "what does this look like?" with precision. They do not answer "when should this appear?", "what data does it require?", "what permissions must the user hold?", or "what happens if the operation fails?"

When a human developer composes a screen, these answers live in tribal knowledge, design reviews, and unwritten conventions. When an AI agent composes a screen, those answers do not exist unless the system encodes them explicitly. An agent generating a form cannot infer that a payment method collection requires PCI-compliant field isolation, specific error copy for declined cards, and a confirmation step — unless the design system declares that "collect payment method" is a capability with those constraints attached.

The failure mode is not ugly UI. It is unsafe, inaccessible, or misleading UI. An AI that generates a destructive action without a confirmation dialog has not violated a style guide. It has violated a behavioral constraint that was never formalized.

A design system capability catalog describes intent, not just appearance

A capability is a unit of product behavior that the interface is allowed to express. It sits above components and below features. Where a component says "render a modal with these props," a capability says "request user confirmation before an irreversible action, using a modal with an explicit cancel path, accessible focus trap, and audit-grade action copy."

The distinction matters because a capability encodes:

• Intent — what product goal this UI serves (collect consent, confirm deletion, request escalation).
• Constraints — what must be true for this UI to appear (user permissions, data state, feature flag).
• Composition rules — which components and patterns are approved for this intent, and which are forbidden.
• Accessibility contract — what ARIA roles, focus behavior, keyboard interactions, and screen reader announcements the capability requires regardless of visual implementation.
• Error and recovery states — what happens when the happy path fails, including fallback copy and retry behavior.

A capability catalog makes these declarations machine-readable. An AI agent or a code generator querying the catalog receives not just a list of components but a semantic contract describing what the interface is allowed to do, under what conditions, with what safeguards.

Constraints are the design system's real product

Most design system teams measure success by adoption rate and component coverage. The industry average tells the story: only about one in five design systems reaches 80% adoption coverage, and for five consecutive years, driving adoption has ranked as the top challenge. The missing insight is that adoption stalls not because components are poorly built, but because the system fails to encode the constraints that make components safe to use without supervision.

A constraint catalog transforms the design system from a styling layer into a governance layer:

The capability layer is what makes a design system useful to AI agents, code generators, and junior developers who lack the tribal knowledge to compose interfaces safely. Without it, the system is a palette — aesthetically consistent but semantically empty.

Consider the difference in practice. A component library offers a Button with a variant="destructive" prop. A capability catalog declares that destructive actions require a confirmation step, names the approved confirmation pattern, mandates that the button copy include the resource being affected, and specifies the ARIA live region announcement that fires when the action completes. The developer using the component library must remember all of this — or skip it. The developer (or agent) consuming the capability catalog cannot skip it without failing validation.

Accessibility must be encoded, not remembered

Analysis of 158 public design systems reveals a stark pattern: 89% ship code examples, but only 21% document accessibility requirements. The remaining 79% rely on developers remembering to add ARIA attributes, manage focus, handle keyboard navigation, and provide screen reader announcements — requirements that are invisible in a component preview but critical in production.

A capability catalog changes this by attaching accessibility contracts to each capability declaration:

const capability = {
  id: "confirm-destructive-action",
  intent: "Request explicit user confirmation before an irreversible operation",
  components: ["ConfirmationDialog", "DestructiveButton"],
  accessibility: {
    focusTrap: true,
    initialFocus: "cancel-button",
    ariaLabelledBy: "dialog-title",
    keyboardDismiss: "Escape",
    screenReaderAnnouncement: "Confirmation required: {action description}",
  },
  constraints: {
    requiresPermission: "write",
    requiresExplicitCancel: true,
    destructiveActionCopy: "must name the resource being deleted",
  },
  errorStates: {
    networkFailure: "Show inline retry with original context preserved",
    permissionRevoked: "Redirect to access-denied view",
  },
}

When an AI agent composes this capability, it cannot skip the focus trap. It cannot default focus to the destructive button. It cannot omit the keyboard dismiss path. The constraints are not documentation — they are the interface contract.

Frontend architecture becomes a design governance layer

The shift from component library to capability catalog has architectural consequences. The design system is no longer a dependency that ships styled React components. It becomes a registry that exposes machine-readable metadata alongside the implementation.

A registry-first architecture separates three concerns:

1. The registry — a structured catalog of capabilities, their constraints, approved components, and accessibility contracts. Queryable by AI agents, code generators, linters, and documentation tools.
2. The implementation — the actual React (or framework-specific) components that satisfy the registry's contracts. These still live in a package, still use tokens, still render to the DOM.
3. The validation layer — lint rules, CI checks, and runtime assertions that verify composed interfaces comply with the registry's constraints. A form that collects payment information but omits the PCI-required field isolation fails validation before it reaches production.

This architecture makes design systems useful to AI in the same way that type systems make code useful to compilers. The registry describes what is valid. The implementation provides what is possible. The validation layer enforces the boundary between the two.

The approach aligns with how teams already manage trust calibration in AI-generated interfaces: the system defines guardrails that prevent AI output from exceeding its authorized scope, then lets the agent compose freely within those bounds.

How does a design system capability catalog differ from a component library?

Practical distinctions emerge when teams evaluate whether their current system is ready for AI-composed interfaces.

Does a capability catalog replace components?

A capability catalog does not replace components — it layers above them. Components remain the rendering primitives. Capabilities describe when and how those components may be composed, under which constraints, and with what mandatory behavior. A team can adopt capability descriptions incrementally, starting with the highest-risk product intents (payment, deletion, permission changes) and expanding as coverage matures.

What makes a capability machine-readable for AI agents?

A capability must declare its intent in natural language, list approved components, specify accessibility requirements as structured contracts (not prose documentation), define error and recovery states, and expose constraint predicates that an agent can evaluate before composing. JSON Schema, TypeScript interfaces, or registry APIs all work — the format matters less than the completeness of the contract.

How do constraints prevent AI from generating unsafe UI?

Constraints act as pre-composition validation rules. Before an AI agent renders a "collect payment method" capability, it checks whether PCI-compliant field isolation is present, whether error copy for declined cards exists, and whether the confirmation step is included. Missing constraints block generation the same way a failing type check blocks compilation — the interface cannot be composed until the contract is satisfied.

The opposing view: capability catalogs overcomplicate design systems

A common argument holds that design systems already struggle with adoption at the component level — adding a capability layer introduces abstraction that teams will not use. If only 22% of systems reach high coverage with components alone, the argument goes, adding intent declarations and machine-readable contracts will make the system heavier, slower to maintain, and harder to justify to leadership.

The argument identifies a real risk: premature abstraction. A team with ten components and no AI-composed interfaces does not need a capability catalog. But the argument misses why adoption stalls in the first place. Systems fail not because they are too complex, but because they provide components without context — the developer still needs to figure out when, why, and how to use them. A capability catalog is the context layer. It answers the questions that missing documentation never did, in a format that both humans and machines can consume.

Key takeaways

• A component library defines appearance; a design system capability catalog defines allowed behavior, intent, and constraints.
• AI agents cannot infer accessibility, permissions, or error handling from component props alone — these must be declared as machine-readable contracts.
• Capability declarations layer above components, not replace them — start with the highest-risk product intents and expand incrementally.
• Only 21% of analyzed design systems document accessibility — encoding it as a contract in the capability layer closes the gap for both humans and machines.
• Frontend architecture must split into registry (what is valid), implementation (what is possible), and validation (what is enforced).
• The constraint catalog is what makes a design system ready for AI-composed interfaces — without it, the system only governs aesthetics.

Conclusion

The design system that only describes how things look is already behind. AI agents compose UI today — generating forms, suggesting workflows, adapting layouts. Every interface composed without explicit constraints is a liability waiting for a user to encounter a missing confirmation dialog, an inaccessible modal, or a destructive action without a recovery path. The next design system investment is not more components. It is the semantic layer that tells any composer — human or machine — what the interface is allowed to do, under what conditions, and what must never be skipped.