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

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 Profiledesigngov.md
JobHow it should look, and which tokens, specs, and voice to useWhich behavior, accessibility rules, and brand boundaries the agent must not violate
LivesIn the design-system folder, next to tokens and specsA governance file the agent reads before it generates UI, beside DESIGN.md
Fails whenThe agent invents a token, a radius, or a phrase you never wroteThe 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?
designgov.md is a governance contract AI coding agents can read before they generate UI. DESIGN.md (and a Taste Profile wrapped around it) tells agents how things should look and feel: tokens, type, spacing, component specs, voice. designgov.md is the layer above that. It covers behavior, accessibility tiers, and multi-brand boundaries agents must not violate. The open format is community work at https://github.com/kenallangriffin/designgov. Verify the current sections there. The DESIGN.md howto stays at https://clearly.design/resources/design-md.
What belongs in a governance contract versus visual and token docs?
Put accessibility tiers, multi-brand boundaries, forbidden interaction patterns, and escalation rules in the governance contract. Tier 1 is what an agent can apply and a linter can check (contrast, accessible names, a visible focus ring). Tier 2 is what still needs a human (meaningful alt text, pause controls, reading order). Tier 3 is prohibited patterns that can pass automated checks and still fail people using assistive technology. Multi-brand rules say what is shared, what may look different on purpose, and what is drift until someone documents it. Behavioral rules cover which component does which job, what an interaction must never do, and how a destructive action is confirmed. Visual tokens, component APIs, and voice stay in DESIGN.md and the Taste Profile. Do not paste the whole spec into this file.
How does designgov.md relate to Taste Profile and AI brand governance?
They are different layers. Clearly's Taste Profile is the in-repo package agents read so they cannot invent a look: DESIGN.md, tokens, component specs, voice, and an optional skill. AI UI brand governance is the process around that package: stop fixing outputs one by one, load the system every session, then choose scaffold, audit, or partner. That process lives at https://clearly.design/resources/ai-brand-governance. designgov.md is the rule layer above both. Taste Profile says how the product should look and sound. The governance file says which rules still apply when the look is allowed to differ, and when a human has to review before something ships.
What are the hallmarks of good design-system governance for AI agents?
A file in the repo that the next session is forced to read, with an owner. Rules a model can execute, not a sentence that says be accessible. Brand boundaries written as decisions: what is shared, what may diverge, and what stays shared even when the visuals do not. A human path for the checks automation misses. And an explicit instruction not to invent a pattern when the contract is silent. Those are the fundamentals, whether you adopt the open designgov format or write the same sections yourself. The blank file will not know which of your products may look different on purpose.
How does Clearly help with design system governance for AI agents?
We build AI-ready design systems: the folder, tokens, specs, and DESIGN.md an agent can read every session. The map is https://clearly.design/series/ai-ready-design-systems. If the library is already a mess, start with a design system audit at https://clearly.design/projects/design-system-audit. We do not publish a standalone audit list price. When the gap is encoding the rules and keeping them current, that is partner work. Public pricing only: Standard $4,995/mo and Advanced $7,495/mo. Pause or cancel. Confirm live plans on https://clearly.design/ before you buy.

Need a governance contract, not another token file?

We'll tell you honestly whether DESIGN.md and a Taste Profile are enough, or whether behavior, accessibility tiers, and multi-brand rules need a partner.