Built from one description
Every application we build starts as one description of the product, kept as data. The app's screens, routes, contracts and checks are derived from it, so they cannot drift apart. The studio itself is run by AI agents whose work must pass the same kind of gate.
From description to product
- 1
Describe
A product is written down once, as small records: the experiences a person moves through, the actions they can take, the routes those actions call, and the plans that decide who may do what.
- 2
Derive
From those records the build writes the navigation, the route table, the service contracts, the data sources and the assistant's tool list. Nothing derived is edited by hand.
- 3
Check
Every change rebuilds the derived files and compares them with the description. A hand edit, a missing file or a stale one stops the build and says why.
- 4
Build
Screens are composed from one design system and read their data through one interface, so a stand-in answers before a service exists and the real service replaces it without touching the app.
- 5
Publish
Documents, notes and this site go public through a gate that refuses anything internal by name. It never warns; it refuses.
What it is made of
Applications
The screens people use, on the web and on a phone, composed from the design system.
ProducesProducts such as The CollectiveDesign system
Tokens for colour, space and type, a component library, and one shell every application shares, in light and dark.
ProducesConsistent screensDerived files
Navigation, routes, service contracts, data sources and the assistant's tool list, written by the build.
ProducesNothing written by handThe description
Experiences, actions, routes, plans and permissions, as checked records.
ProducesOne source of truthServices and data
Services behind one interface, with a database that enforces who may see each row.
ProducesThe same rules at every layerDelivery
AI agent sessions that propose, build and prove each change against a gate, and a publisher that fails closed.
ProducesEvidence for every change
Four rules the build keeps
Each part owns its records
Calendar, directory, interests and finance each describe their own actions. The product puts them together; it does not redefine them.
One name per action
The button in the app, the permission check and the assistant's tool all use an action's one name, so they cannot drift apart.
Data behind one interface
Every screen asks its data three questions: what is listed, what one item holds, and what this person may do. A stand-in answers them before a service exists, and the real one is built to replace it without a change to the app.
Checked on every change
Generated files are rebuilt and compared on every change. A hand edit, a missing file or a stale one stops the build and says why.
The four pillars
One description
The product, written down once as checked records; everything else is derived from them.
Learn more → about One descriptionGenerated and checked
Nothing derived is written by hand, and a file that drifts stops the build.
Learn more → about Generated and checkedDesign system and data
One set of tokens and components, and one way for every screen to reach its data.
Learn more → about Design system and dataBuilt with agents
AI agent sessions build from a written plan against checks they cannot change.
Learn more → about Built with agents