Why the system is like this

Why it looks like this: the five attributes

The visual language is five oppositions, not five adjectives. Each was drawn from a real line in the research and built from a specific borrowed technique, and each one still has a consequence you can point at in the code. A visual decision with no attribute behind it is an invention, which is the rule design/concept/docs/concept.md has held since stage 06. The middle column is what the attribute became once it was code; the right column is where you can go and look at it.

The one place the attribute and the value disagree, and it is not an error

A5 says warm, and the ground is --canvas: #eef3f4, which leans slightly cool. That reads as a contradiction until you see where the warmth actually lives. The neutral was pushed a whisper toward the accent rather than toward beige, so that white cards read as paper on a desk instead of panels in an application; the warmth is carried by the voice, by the plain-language rows and by how rarely the accent is spent, not by the hue. Beige was refused by name in the taste, and a warm hue here would have walked straight into it. This is written down because it is exactly the kind of thing that gets quietly "fixed" a year later by someone who read the word warm and reached for the paint.

The taste, which is data too

Recorded from the founder on 2026-07-15 and kept next to the personas, so that a new prompt cannot reset it to the model default. Liked, one trait each: Monzo for plain-language character with one confident accent, Apple Card for radical clarity, Copilot Money for the calm of a well categorised view, Monarch for spending the accent only on the single most important action. Actively avoided: the reflex calm-fintech palette of mint, sage and beige, which is the first thing a model reaches for on the word calm; beige on its own, called out separately; red as an accent or an alert; rounded-everything with friendly blobs, which reads as a toy rather than as money software; and generated-looking cliche, the purple gradients and the glassmorphism. The four liked products do not all pull the same way, and the tension was resolved rather than averaged: Apple's clarity warmed toward Monzo and Monarch, Copilot's category colour taken onto a light canvas rather than its dark one.

What was borrowed, and what was refused

A reference is an input, not an output: one base, two single techniques lifted from two other products, and no wholesale clone anywhere. The refusals below are as load-bearing as the takings, and they are the reason this palette is not the one you would guess from the words "calm fintech". The full sourcing, with the persona line each technique relieves, is in design/concept/docs/references.md.

Four refusals, and they still bind

• no red Monzo's Hot Coral and every relative of it. The mechanism of one reserved accent was taken; the hue was not. Red is an alarm signal for this person, and the system has no role that could carry it
• no dark ground Copilot's midnight canvas as the product's ground. Calm-light is the trust environment; a dark finance UI reads as a serious tool for finance people, which is the position we are not taking
• no reflex palette Mint, sage, beige-and-terracotta. Guessable from the category, so it is a reflex rather than a decision, and it was discarded before the three directions were even drawn
• no stock art Tendd is data-first. The content layer is real brand marks, and the empty states carry a sentence rather than an illustration

The dark theme is not the refusal being broken, and it is worth saying out loud before someone finds it. Every role in this system is written twice, once in :root and once in [data-theme="dark"], so a dark theme demonstrably exists. What was refused is dark as the product's ground, the thing the anxious person meets on first open. A theme that a person chooses is a different object from a canvas chosen for them, and the pairing is what proves the palette is built out of roles rather than out of colours. See the stress test, which is the page that makes that argument in pixels.

The brand plate, and why the code outranks it

One dense toolkit plate was generated for Petrol and Paper as a record of the locked language, and this is the first page in the project that actually shows it. It is a record and not a source: the brand was found through three live HTML directions and locked from them, and the plate was rendered afterwards. Where the plate and the code disagree, the code wins, and here is exactly where they disagree today.

Where the values came from

Not one number in this system was chosen at the moment it was written into a stylesheet. Every value arrived by migration: it was decided once, and then it moved from file to file carrying its origin in a comment beside it. That is why the token file reads as it does, and why a comment there is not decoration: it is the last link back to where the value was picked, and it cannot be recovered from anywhere else once it is gone.

The plate is not a link in that chain, and the order is the point. A generated plate first and a product bent to fit it afterwards is the common way round; here the language was found live, locked, and only then recorded as a picture. It means the picture can go stale without anything downstream breaking, which is exactly what has happened to its monogram. Where a value actually lives today, with its measured contrast in both themes, is the colour page.

How to use it: four ways in

Four questions, four doors, and the fourth one is named separately on purpose. A person building a screen for the first time goes looking for permission, finds it, builds, and meets the prohibitions afterwards, when the screen already exists and changing it is expensive. So the prohibitions get their own door, at the same size as the other three.

And the order to ask them in

How to grow it

New goes into the system first and onto the screen second. That is the whole rule, and everything else is its consequence. A component means five things and four is not enough: the css in design/system/components/, a page here in design/kit/, a row in the registry in its own level group, a line in docs/inventory.md with its level, and an @import in index.css in its level group rather than at the end. A composition goes to design/system/patterns/, and only after a third screen has asked for it. A value goes to its level in tokens.css, by a named decision that says variable, value and why, with its origin beside it.

And a correction goes to the same places, never to the screen it was noticed on. A fix applied on one screen is a desync by definition, because the other screens carrying the same component did not get it. A contextual override is the same defect wearing a nicer name: .host .btn { font-size: 15px } is an undeclared variant, and the honest version is to declare the modifier in the component's own file and put the class in the markup. The rules in full, with the checks that catch a violation, are in Architecture; the six that travel with the code, because design/system/ can be lifted into another project whole, are in its own CLAUDE.md.

The system backlog

A system stays honest by writing down what it decided not to do. design/kit/docs/backlog.md is that file, and this section is its visible place. Its open rows have a second one since 2026-08-20: Open decisions gathers the 21 rows addressed to the founder, and the 3 business questions the plan census raised, into 24 questions with the measurement, the options and a recommendation under each. This section stays the account of what the backlog IS; that page is where it gets answered. It it was opened during the component rounds of stage 08, earlier than the schedule asked for, because findings were arriving faster than the steps that owned them and a finding with no home is a finding that gets lost.

60 rows, 23 closed and 37 open, and two dropped at verification. Fifty-four came out of stage 08 and sort into blockers, decisions that need a person, holes with the reason each was not filled, rows from the component rounds and from the control census, copy owned by Voice, and a last section naming what is deliberately not in the file so the next audit does not raise it again. The four below came from somewhere else, and that is why they are shown here: not from an audit of what already stands, but from the first product screen built out of the system after it was called finished.

The self-sufficiency test, 2026-08-13

Alerts and its three states were assembled from design/system/ alone: 44 distinct system classes across four pages, and 0 new CSS files, 0 new tokens, 0 new variants, 0 new lines of copy. Nothing was added to the system to make the screen fit, which is the rule the test runs under. What was missing is written down instead, and the rule against drawing it on the screen by hand is what makes the list mean anything.

The verification pass, 2026-08-13, and one row of it is structural

Two instruments again, Codex read-only over the source and a browser pass over the running pages, taken independently and merged with a "who found it" column. Twelve findings held and two were dropped at verification. Eleven of the twelve were one defect with eleven addresses, and that one is the row worth carrying into stage 13. The full merge, class by class, is on the proof page.