Capabilities
A capability is a power a surface declares when it needs to do something beyond render: fetch and hold data, keep a data model, route between the app’s pages, or react to what a visitor does.
Surface = Blocks + Capabilities. Blocks are the visual pieces; capabilities are what animates them.
The canonical four
There are exactly four. Names you may see elsewhere — auth, data,
state, seo, i18n, analytics, forms — are not capabilities; some
never existed and the rest were retired.
| ID | Responsibility |
|---|---|
platform/persistence | Fetching data and holding it — the surface’s data sources and initial state. |
platform/entities | The app’s data model: what a record looks like, and creating, reading, updating and deleting them. |
platform/navigation | Routing between the surfaces of an app. |
platform/interaction | Event-driven rules — attach triggers and actions to what happens on the surface. |
Appearance is not a capability. Theme and visual design are a separate kind of atom that a surface points at. See Composition.
Where they come from
Capabilities are not switches you flip one by one. They arrive with your plan: activating a plan installs the set of packs that plan carries, and the capabilities inside them become available to every surface in the World. Upgrading adds to the set; downgrading takes back what the lower plan does not carry, and upgrading again restores it.
Which capabilities your plan carries is a pricing question — see the pricing page.
Because they resolve per World, installing something new shows up in a live World within a few minutes, with nothing to redeploy.
Declaring one
You do not usually declare a capability by hand. Describe what the page has to do — “remember who signed up”, “list the bookings”, “go to the detail page” — and PhiCo puts the capability, and its configuration, into the Receipt it proposes.
See also
- Composition — how blocks and capabilities combine into a surface
- How it works — where capabilities sit in the pipeline