designgov.md: governance for AI agents
DESIGN.md and a Taste Profile tell agents how things should look and feel. designgov.md is the contract for behavior, accessibility, and multi-brand rules agents must not violate.
Francois Brill
Designer + Builder
Oct 4, 2026
Last updated
You already have a DESIGN.md, or you are in the middle of writing one. The colors land. The type lands. Then an agent ships a delete control that looks like the primary action, a dropdown built from divs, or a second product painted in the parent palette because nobody wrote the exception. The file you have tells the agent how things should look. It does not tell the agent what it must not do.
designgov.md is that contract. It sits above DESIGN.md and above a Taste Profile. Visual and token docs say what exists. The governance file says which behaviors, accessibility rules, and brand boundaries an agent is not allowed to cross.
The format is open community work. Ken Griffin published it as designgov, a governance file meant to sit next to Google's DESIGN.md. We will not reprint the blank spec. Verify the current sections on that repo. This page is for a design-system lead or head of product who already has the look-and-feel files, and still watches agents violate accessibility, multi-brand rules, or interaction behavior.
People are asking how to govern a design system once agents write the UI. Format tutorials already cover DESIGN.md. Almost nobody explains the contract those agents still break. That is the job of this page.
DESIGN.md vs designgov.md
DESIGN.md is the visual and token source of truth. Google Labs / Stitch popularized the format: YAML for color, type, and spacing, prose for how to apply them. A Taste Profile, in Clearly's packaging, wraps that file with tokens, component specs, and voice so an agent cannot invent a nearby hex or a "Get started" the brand never says. The howto stays on that page. This one will not rebuild it.
designgov.md answers a different question. The colors can be right and the interaction can still be wrong.
| DESIGN.md and a Taste Profile | designgov.md | |
|---|---|---|
| Job | How it should look, and which tokens, specs, and voice to use | Which behavior, accessibility rules, and brand boundaries the agent must not violate |
| Lives | In the design-system folder, next to tokens and specs | A governance file the agent reads before it generates UI, beside DESIGN.md |
| Fails when | The agent invents a token, a radius, or a phrase you never wrote | The agent follows the palette and still ships a banned pattern, skips a review, or paints the wrong brand |
One split is enough to hold the difference. DESIGN.md can say which blue is primary. designgov.md says a primary action gets one clear verb, and it does not sit next to a destructive action without separation. Same screen. Different contract.
Point the agent at both. A file the session never opens is a suggestion. The load pattern is the one we already use for DESIGN.md: a short rule in CLAUDE.md or a Cursor rule that says read the governance file before generating UI. Do not paste the whole contract into always-on context. The model skims, then guesses. If you need the installable skill that scaffolds the folder, that write-up is Claude Code design skills. We will not copy the install steps here.
What belongs in the contract
Four jobs belong in the governance file. The token table does not.
Accessibility tiers. "WCAG 2.1 AA" is a target, not a contract. The open standard splits enforcement into three tiers. Tier 1 is what a machine can check and an agent should apply without asking: text contrast, an accessible name on every control, a focus ring that stays visible. Tier 2 is what automated checks miss and a person still has to sign: alt text that means something, pause controls on timed interactions, a reading order that matches the screen. Tier 3 is prohibited patterns that can pass a linter and still fail people using assistive technology. Drag-and-drop as the only way to reorder. Placeholder text as the only label. A custom dropdown built from divs. The agent applies tier 1, flags tier 2, and refuses tier 3. Confirm the current wording on the designgov repo. This page is not the spec.
Multi-brand boundaries. Acquired products are where "just point them at the parent DESIGN.md" does real damage. The standard treats brand architecture as three decisions, not a quality ranking. Fully aligned products take the parent file in full. Loosely aligned products may keep their own visual tokens, written down, while behavior and accessibility still apply. Independent products stay visually separate on purpose, with their own file, and still inherit those rules. Intentional divergence is documented. Anything that is not documented is drift. That is the line you point at when an agent restyles a subsidiary into the parent palette.
Behavioral rules. Which component does this job. What an interaction must always do. What it must never do. A destructive action gets a protocol: a trigger that is not styled as the happy path, a confirmation that states the consequence, a cancel that actually cancels. This is the layer people feel when two products from the same company teach two different ways to delete something. Color tokens cannot express it.
Escalation and human review. The file should say what the agent does when it is unsure. Identify the brand tier before generating UI. Use a component from the vocabulary. If nothing matches, flag it and do not invent one. Never implement a banned pattern because the prompt asked for it. Apply tier 1. Flag tier 2 in the diff so a person can review it before release. A comment that says the pattern is missing beats a plausible control nobody approved.
What stays out: the token table, the component API, and the voice doc that already live in the Taste Profile. Stuff those into designgov.md and you get the long-file failure again. The agent reads the top and misses the rule that mattered. Article 5 is where component contracts belong. Article 6 is where you reconcile a value that looks fine and fails contrast. Do not relocate those jobs into the governance file.
On-brand, and still wrong
A team had DESIGN.md and a real token file. An agent added "Remove member" styled as the primary button, immediately beside Save. Contrast passed. The color was in the palette. The behavior was not. A governance contract would have refused that placement and required a confirmation that says what happens to that person's access. The palette file had no opinion.
How this relates to Taste Profile
These are three layers. Teams keep collapsing them into one pitch, then wondering why the agent still ships a banned pattern in the right colors.
DESIGN.md is the visual contract. Taste Profile is Clearly's name for the in-repo package around it: tokens, specs, voice, and an optional skill, inside an AI-ready folder. It is preference and system packaging. It stops the agent inventing a look. It is not a hosted product called tasteprofile.io. Same two words. Different object.
AI UI brand governance is the process around that package. Stop reviewing outputs one by one. Load the system every session. Name an owner. Then choose scaffold, audit, or partner. That page is AI brand governance. Read it for the process. We will not replay it here.
designgov.md is the rule layer above both. A Taste Profile says how this product should look and sound. The governance file says which rules survive even when the look is allowed to differ: accessibility tiers, banned interactions, multi-brand boundaries, and when a human reviews before ship. You can have a strong Taste Profile and still have no contract for "never this." You can have a governance file and still need the Taste Profile so the agent knows which button variant "destructive" maps to in your repo.
Use them together. Do not pick one and call it governance.
The AI-ready design systems series is the map for the folder underneath, from why a stateless session needs a source of truth to the skill that loads it. This page assumes that work has started, and you have noticed the look-and-feel files do not constrain behavior.
Hallmarks of good governance for AI agents
Getting started is not a new tool. It is a file the next session is forced to read, with an owner, and with rules written so a model can obey them when no designer is in the chat.
The fundamentals show up in the same order, whether or not you adopt the open format:
One contract, loaded on purpose. The governance file lives in the repo next to DESIGN.md. CLAUDE.md or a Cursor rule points at it. Pasting rules into chat describes them for one session. The next session does not have that chat.
Rules a model can execute. "Be accessible" is a wish. "Apply tier 1 without asking. Flag tier 2 for a person. Refuse these patterns." is a contract. A never-do list and a destructive-action protocol beat a principle slide. If the agent cannot tell whether it complied, the rule is not done.
Brand boundaries that are decisions. Name what is shared, what may differ, and what stays shared even when the visuals diverge. An acquired product that serves a different market is a tier, if you wrote the tier down. Undocumented difference is drift. The agent will pick the parent brand unless the file says not to.
A person still owns the exceptions. Tier 2 exists because some checks are not automatable. Someone can say no, and someone updates the file after a rebrand or an acquisition. A design system without an owner becomes a suggestion library.
The agent is told not to invent. If the pattern is missing, flag it and ask. Invention is how governance dies in a stateless session. Training-set defaults are confident. They are not your product.
That is the practical version of design system governance for AI agents. The open format helps because it already separates tokens from behavior, accessibility, and brand architecture, and it ends with a short agent quick reference. You still fill it with your rules. The blank spec does not know that an acquired product must stay visually separate, or that delete requires a typed confirmation. Copy the structure. Write the decisions. Point the agent at the file. Keep the split: look in one file, rules in the other.
How Clearly fits
We build the system agents can read, and we will tell you when a file you can write this week is enough.
The AI-ready design systems series is the how: structure, tokens, specs, and the skill that loads them without stuffing CLAUDE.md. designgov.md is what you add when that layer exists and agents still violate behavior, accessibility, or brand boundaries. We do not sell a separate governance format. The open spec is free. Use it.
If the library is already a mess, start with a design system audit. Figma and production disagree. Tokens live in three places. A governance file on top of that drift just gives the agent a confident wrong answer. The audit is a mostly read-only readout and a path. We do not publish a standalone audit list price. The full build, when you already know you want an AI-ready system, is design systems for AI teams.
When the gap is the judgment, that is partner work. Which patterns are banned. Which brand may diverge. Who signs tier 2 before it ships. How the contract stays current after the next acquisition. Standard is $4,995/mo. Advanced is $7,495/mo. Pause or cancel. Confirm live plans on clearly.design before you buy. We will not invent a governance package on top of those plans.
If you can write the never-do list yourself and point Cursor at it this week, do that. Book a call when the hard part is still the decisions, not the filename. Either way, do not pretend the palette file is the contract.
Frequently asked questions
What is designgov.md and how does it differ from DESIGN.md?
What belongs in a governance contract versus visual and token docs?
How does designgov.md relate to Taste Profile and AI brand governance?
What are the hallmarks of good design-system governance for AI agents?
How does Clearly help with design system governance for AI agents?
Related Decision Guides
DESIGN.md and Taste Profile: Keep AI UI On Brand
DESIGN.md alone isn't enough for on-brand AI UI. Clearly's Taste Profile packages DESIGN.md, tokens, specs, and voice so agents stay on brand, plus when to scaffold vs partner.
AI UI Brand Governance: Stop Fixing Outputs One by One
Stop reactive per-output brand fixes. Clearly's Taste Profile + AI-ready folder is the root system that keeps Cursor and Claude Code UI on brand, plus when to audit or partner.
Claude Code Design Skills for Design Systems
Learn how to create Claude Code skills (SKILL.md) for design systems — install Clearly’s open design-system-scaffold skill, keep AI UI on brand, and know when to partner.