Use as much as you need

Airframe doesn’t replace your UI kit. It can sit underneath it.

Use Airframe directly, or use it as the visual foundation for your existing components. Take as much or as little as you need.

The model

Layer	Owns
Airframe	Tokens, structure, visual language and CSS patterns
Your UI kit	Framework wrappers, behaviour and product-specific widgets
Your app	Pages, features and product logic

Your kit should use Airframe, not compete with it.

A <my-button> should be an Airframe button with your framework behaviour. Not a second button system with its own colours, spacing and visual rules.

Choose your depth

Tokens Use Airframe’s --af-* tokens with your brand.

Structure Use af-stack, af-inline, af-grid. Viewport chrome is a shell (af-app).

Patterns Use Airframe’s production-ready CSS patterns such as af-btn, af-card and af-input.

Wrappers Wrap Airframe patterns in your existing <my-button>, <my-card> and other components. React wrappers.

Mixing depths is fine. Two visual systems isn’t.

This is adoption: how much of Airframe you take. It is not the construction model. Structure → Patterns → Blocks → Blueprints is how interfaces are composed. Introduction.

One source of truth

Map your existing tokens to --af-* once, then let Airframe own the visual language.

:root {
  --af-base-primary: var(--color-primary);
}

Keep legacy tokens as aliases while you migrate. Don’t create a second palette.

Keep your behaviour

Airframe handles the surface. Your UI kit can handle behaviour Airframe doesn’t own:

• Toast services
• Modal focus management
• Sidebar state
• Routing
• Dependency injection
• Product-specific widgets

The principle is simple:

Airframe owns how it looks. Your kit owns how it behaves.

For AI and teams

Give agents the same rules:

• Prefer a close block or blueprint, then a catalog pattern, then a structure class.
• Use Airframe structure instead of inventing new arrangement classes.
• Use your UI kit when a wrapper exists.
• Don’t recreate af-btn / af-card with utilities.
• Don’t create a second palette or structure system.
• Don’t hard-code colours, fonts, or radii when a --af-* token exists.
• Keep kit-specific CSS for behaviour Airframe doesn’t provide.

This gives humans and AI the same contract.

Adopt incrementally

You don’t need to rewrite your application.

1. Add Airframe.
2. Map your tokens.
3. Replace arrangement utilities with Airframe structure.
4. Point one component at an Airframe pattern.
5. Repeat and remove the duplicate CSS as you go.

Start with one surface. Prove the split works. Then expand.

Airframe is the visual language. Use it directly, or put your UI kit on top.