One design system, one way to reach data
Every application is composed from the same tokens and components, and every screen asks its data the same three questions. That is what makes a new product fast to build and consistent to use.
Tokens, components, one shell
Colour, space, type and motion are tokens: named values the components use and the applications never override. A component library builds on them, from buttons and cards to the shell that frames every application, in light and dark. This site is built from the same library.
Responsive by default
Components are designed for a phone first and grow into tablet and desktop layouts. Touch targets, contrast and keyboard access belong to the components, not to each screen.
Three questions every screen asks
What is listed?
A screen asks for the list it shows, with its filters and its order, and nothing about where the list comes from.
What does one item hold?
The detail a person opens is one record with its fields, the same whether a stand-in or a service answers.
What may this person do?
The actions a screen offers come from the description's permissions, so a button appears only when the person may press it.
A stand-in first, the real service after
Each screen reads through one interface. A stand-in answers it with sample data before any service exists, so screens are built and reviewed early. The real service is built to the same interface and replaces the stand-in without a change to the application.
Rules enforced at the data
Services keep their data in a relational database that enforces who may see each row, so the permission in the description is also the permission at the table.
Next
Built with agents
AI agent sessions build from a written plan against checks they cannot change.
Learn more → about Built with agentsOne description
The product, written down once as checked records; everything else is derived from them.
Learn more → about One description