The short answer: store each rule once, as a record with a typed value, a sentence on its use and the files it governs. Draw the pages people read from those records, release them with a version number, and serve the same records to code and agents. Then nobody copies a hex code by hand, and nothing drifts.
How we made this: this is the argument behind how Artbucket stores guidelines, our product. The examples are Artbucket's own published brand, read from its public listing on 6 October 2026.
The brand book was made for one reader
For most of its life, a brand book had one reader: a designer, who read it once, kept it open in a tab and remembered the rest. A PDF suited that reader. It looked like the brand, it could be printed, and nobody needed to query it.
That reader now has company. A developer needs the colors as variables. A marketing tool needs the logo for a dark background. An agent writing a landing page needs the voice, the type scale, and the rule that the lime is "never a fill for large areas". None of them can read a layout. Each one gets a copy: tokens pasted into a repository, a logo downloaded into a folder, a summary pasted into a prompt. From that day, every copy ages on its own.
What "rules as data" means
Each rule becomes a record. Here is one of ours:
{
"key": "color.highlight",
"label": "Lime",
"type": "color",
"value": "#e1eea1",
"usage": "A highlight behind a word or a badge, never a fill for large areas."
}
Four things make it data rather than text:
- A stable key.
color.highlightis the same rule tomorrow, whatever its value. Code and pages point at the key, never copy the value. - A typed value. A color is a color, a font is a family with its files, a number has its unit (
logo.minSizeis24px). A tool can check it, convert it, or refuse it. - A usage sentence. The value alone is half a rule. "Never a fill for large areas" is the half people and agents get wrong.
- The files it governs.
logo.markWhitepoints atmark-white.svg. Replace the file, and every rule, page and portal that points at it follows.
Pages are drawn from the records
This is the part that removes drift. A guideline page doesn't contain "#e1eea1". It contains a palette section that shows color.highlight. Change the rule, and the page, the tokens, brand.json, llms.txt and the answer an agent gets all change with it, because there was only ever one copy.
It also turns the page from the source of truth into one view of it. The same rules render as a guideline site for people, as CSS or Tailwind variables for developers, as AdCP brand.json for advertising tools, and as Markdown for language models.
Rules change in releases, like code
A PDF has a date on the cover, at best. Records can have history. In Artbucket every edit is a draft; publishing makes a numbered release, with a note and a diff of what changed. Portals and public formats show only the release, so a half-finished edit never reaches a partner. Any version can be restored. Our own brand is at release 9 today, each one listed with its note on its public listing.
Teams that live in Git can go further and keep the rules as YAML in a repository: a pull request changes the brand, a check reviews it, and a merge releases it.
Context is a property of a rule, not a chapter
A brand book handles exceptions with chapters: "On dark backgrounds", "Social media". Records handle them with variants. color.primaryInk is #5b38f0 by default and #a592ff in the dark-background context. Ask for the rules in a context and you get one answer per key, the right one. Nobody has to know there was a chapter.
What it costs
Writing rules as records is more work up front than writing paragraphs. You have to decide what a rule is, name it, and say in one sentence when it applies. Some guidance doesn't fit a record well: a mood, a reference board, the story behind the mark. That still belongs on a page, next to the records, not instead of them.
The trade is worth it the first time a developer, a tool and an agent all ask for the logo on a dark background and get the same file.
Questions
Do we lose the designed brand book?
No. The pages people read are still designed, with sections, examples and do's and don'ts. They just read their values from the rules instead of holding their own copies.
Which formats should the rules come out in?
The ones your readers already use: CSS or Tailwind variables for developers, W3C design tokens for design tools, AdCP brand.json and llms.txt for agents, and a lossless JSON of every rule for anything else.
How do we start?
With the rules that cause the most mistakes: colors with their use, logo files with when each applies, typefaces, and a few lines on voice. Then see how to give agents your brand guidelines.