How the interface system assembles every page from modules

Ask five people to make one web page each and you will probably get five kinds of button, five heading sizes and five ideas of what "important" means. Each page looks fine on its own; together they don't look like one company.

With AI making pages, the problem gets sharper. AI is fast, but each time it may "invent" a little something: a slightly different corner radius, a colour that never appeared before, a line of text it filled in itself. The faster it goes, the faster things drift.

This post explains how our interface system deals with that. We don't hand-make pages. We settle the content first, then assemble each page layer by layer from modules that have already been approved.

Approved content first, then the page

The first step in making a page isn't drawing a layout; it's settling the content. What this page says, which numbers it uses, which image it shows: a person reviews and approves these first. Only then does assembly begin.

The order matters. If content and layout change at the same time, discussions get tangled: is the wording wrong, or the layout? Fix the content first, and every later step only has to answer one question: which modules present this confirmed content most clearly.

From one constitution to a full set of rules

Modules don't appear out of nowhere. They come from a top-down set of rules, which we split into four layers.

• Constitution: a few commitments that rarely change, such as "clarity matters more than flourish" and "everyone should be able to read it".
• Principles: the commitments as sentences you can judge right or wrong, such as "one screen has one primary action".
• Specs: concrete values and behaviour, such as colour, type size, spacing, and how a component looks in each state.
• Roles: the components actually used, such as buttons, cards and headers, each a combination of specs.

The benefit of this structure is that you can always ask why a button looks the way it does. Which spec is it based on? Which principle is that spec for? Which commitment does the principle protect? And when someone wants to change a detail, it is easy to see how far the change will spread.

Many domains, one shared set of modules

A company has many kinds of pages: quotes, projects, knowledge, outward communication, growth analysis. Their content differs, but what they need underneath is very similar: a header, a few content cards, a data table, a form, and a card for people to make a decision.

So we don't build a separate set of components for each domain. Every domain shares one plane of modules. A restaurant has many dishes, but the knives, pans and base sauces in the kitchen are shared. Each dish tastes different, yet the quality coming out of the kitchen is consistent.

When a shared module improves, say a data table becomes easier to read on a phone, every page using it benefits at once. No domain has to fix it separately.

Registered and versioned, so every page can be rebuilt

Every module is registered: its name, its current version, and the specs it follows. When a page is assembled, it also records which modules it used and which version of each.

That might sound like extra admin, but it solves a real problem. When someone asks six months later why a page looks the way it does, we don't answer from memory; we look it up. And when something needs fixing, the same record lets us rebuild exactly the same page and change only what needs changing.

A good system doesn't make every page the same. It lets every page say where it came from.

When the rules need to change

Rules aren't fixed forever once written. After a while we may find a grey that's hard to read in sunlight, or a card that's too cramped on a small screen. What changes then isn't one page; it's that spec or that module.

A change creates a new version, and the old version isn't erased. Pages already live still record the version they were built with, so they can always be rebuilt as they were. Moving to the new version is a visible decision that can be discussed, not something you discover one day when the whole site has changed.

Before an upgrade, the system first lists which pages use the module, so people can see how wide the impact is. Small fixes can be upgraded together; larger changes go in batches, each checked before the next.

That's also why we insist on changing things from the top down. If someone quietly adjusts a colour on one page, the change never reaches the specs. Next time the page is assembled it disappears or, worse, it stays behind as an exception nobody remembers the reason for. Put the change back into the rules, and it becomes part of the whole system.

Why this keeps the brand consistent and lets AI compose safely

Once a page is split into approved content plus registered modules, the AI's job becomes clear: it picks and combines; it doesn't invent. It can't create a new colour on the spot, because colours exist only in the specs. It can't rewrite the text, because the content is already settled.

Before a finished page is published, it is checked against the specs once more. If it passes, it goes live; if not, it goes back with the reason. Speed and consistency stop pulling against each other: AI can assemble many pages quickly, and every one of them is still the same brand.

• For people: approve the content and the check results, without watching every pixel.
• For the AI: the building blocks are limited and clear, so there is less room for mistakes.
• For the brand: improve a module once and every page gets better.

In short

• People approve the content first; then the page is assembled.
• One constitution grows into principles, specs and roles, and every component can be traced to its source.
• Many domains share one plane of modules.
• Modules are registered and versioned, so every page can be rebuilt; the AI composes, it doesn't invent.