Docs · Component library
Component library
Experiences aren't freeform HTML — they compose from a governed catalog.
Every org graph is seeded with a component library: platform organisms as ui_component DataObjects, indexed so builders (human or IDE agent) pick from the catalog instead of inventing one-off markup.
The organisms
Fifteen platform organisms ship today:
| Organism | Renders |
|---|---|
navbar / site-footer | Navigation chrome |
hero-section | Hero with headline, lead, CTAs |
section / stack | Layout containers |
feature-grid | Feature cards |
stats-row | Stat strip |
pricing-table | Pricing grid |
testimonials | Testimonial row |
cta-band | Call-to-action band |
form-organism | A workflow's collect step as a form slot |
table | Data table |
metric-grid | KPI tiles |
activity-feed | Event/activity stream |
empty-state | Guided empty state |
Beneath organisms sit ~30 component kinds (shell, nav, hero, form_slot, metric_grid, data_table, intake_workbench, …) that the Experience renderer understands natively.
How builders use it
When a page instance uses an organism kind, it cites the library component it came from (libraryComponentId). That bind is what makes the library governance rather than convention:
- The library drift scan files an Issue for any organism that doesn't cite its library source.
- Heal can bind an orphaned component back to the library (a tier-0, programmatic fix).
- The brand scan catches raw hex and off-kit styling that bypasses design tokens.
The result: an agent building at 2am composes from the same catalog your design team governs — and the graph can prove it.
See Issues & drift for the scans, and Experiences for how pages compose.