brand.md is an open standard for AI-executable brand identity. It sits at the root of any project and gives AI tools structured brand context they can act on, not just reference. Unlike a PDF, a portal, or a Figma file, brand.md is built for the AI systems that are now generating the majority of creative output like copy, images, code, design and need brand guidelines in a form they can actually execute.

Every AI tool in your stack is already reading context files. Cursor reads CLAUDE.md. Claude Code reads README.md. Coding assistants pick up llms.txt. The pattern is established: structured files at the root of a project give AI tools the context they need to work intelligently rather than generically.

What's been missing from this stack is the brand context layer. The file that tells AI not just how to build things, but what the brand is, its voice, its colour identity, its visual personality, and crucially, the reasoning behind every decision.

That file is brand.md.

Why Do Existing Brand Formats Fail AI?

This is the AI Semantics Gap in its most concrete form.

Every brand has guidelines. Most are stored in PDFs, Figma files, or platforms like Frontify, Notion and Standards. These formats work for human readers. A designer opens the guidelines, reads them, applies judgment, and produces something on-brand. The human is the translation layer between documentation and execution.

The problem is that AI tools aren't human. They can read the text in a brand guidelines portal, but reading isn't execution. Consider something as simple as a colour.

Your brand guidelines specify #184F35 as your primary green. A human designer reads that and knows exactly what to do. An image generator reads the same value and sees an arbitrary string of characters. Hex codes have almost no semantic weight in an image model's training data. The generator defaults to whatever green it associates most strongly with the surrounding prompt.

Now consider the same colour specified as "dark British racing green, deep forest tone, muted and natural, never to be confused with hunter green which reads too warm." That description has dense training data associations. The generator executes the colour with precision.

The same gap exists for every brand element. Voice adjectives like "warm and conversational" aren't verifiable by an LLM. Font names without classification context produce generic results. Photography direction described as "authentic and human-centred" generates stock photography.

Brand guidelines were designed for human readers. brand.md is designed for AI systems.

What Does the Semantics Layer Actually Add?

Every element in a brand.md file has two layers. The first is the definition layer what every brand document already has. The second is the semantics layer what AI needs to execute it.

For colour, the definition layer is the hex code. The semantics layer adds the nearest established colour name (what image generators actually recognise), perceptual descriptors, mood associations, image generation prompt fragments, and explicit anti-confusions, the colours AI defaults to that are close but wrong.

For voice, the semantics layer is more complex than most brand documents acknowledge. A well-structured brand.md voice system has three distinct layers that every AI export must contain:

The Precision Layer carries exact, machine-verifiable values. Not adjectives — booleans, numbers, and arrays. contractions: true. max_sentence_words: 22. banned: ["leverage", "synergy", "seamless"]. These are the highest-reliability inputs for AI because they're self-verifiable. An LLM can check whether it used contractions. It cannot check whether it sounds "warm."

The Semantic Layer carries AI-optimised descriptions that transform those variables into something executable. A brand analogy "a designer or strategist quietly naming a deeper shift before the rest of the market catches up" gives the model a character to inhabit, not a trait list to approximate. Scored tone samples with why_mechanical and why_semantic annotations show the model what 5-out-of-5 looks like and why, plus what 1-out-of-5 looks like and why. Point-of-view anchors prevent consensus-opinion drift, the failure mode where AI generates the most statistically likely position on any topic rather than the brand's actual stance.

The Relationship Layer carries dependencies and selection logic. A base voice position on four universal dimensions (formal/casual, serious/funny, respectful/irreverent, matter-of-fact/enthusiastic), with per-channel overrides that inherit from the base unless explicitly set. Social pushes casual slightly higher. UI copy enforces sentences under 10 words and minimises personality. Long-form allows extended analogies. Email enforces one idea per message. Each channel behaves differently without losing the base voice.

The channel delta system means the brand's voice isn't one paragraph with a do/don't list. It's a structured inheritance model that produces different but consistent outputs across every context.

What Makes brand.md Different from Just Better Documentation?

This is where most explanations stop. But semantics alone isn't what makes brand.md work at system level. The architecture that makes it genuinely machine-queryable is the relationship layer, the "because" architecture.

Brand identity is fundamentally about narrative. Visual expression, verbal identity, and motion are not categories in a document. They're actors, backgrounds, lighting in a story the brand is telling. The premise of that story governs every decision. And in brand.md, every decision traces back to that premise through an explicit reasoning chain.

In the Sameness identity system, each design decision stores three things: the decision itself, the exact system block key it governs (color.aesthetics, typography.typeface, voice.identity), and a because statement that traces that decision back to the founding premise.

Consider two actual decisions from Sameness's own brand.md:

"Dark mode" governs color.aesthetics. Because: "Sameness is infrastructure, not a showroom. The dark canvas signals the engine room where data is structured and decisions are encoded."

"Serif headlines" governs typography.typeface. Because: "Choosing a serif is a deliberate departure from typical AI tool aesthetics representing the enduring truth that great brands are fundamentally human-led."

These aren't descriptions. They're graph edges. An AI querying color.aesthetics doesn't just get the hex values, it also gets the reasoning chain that explains why those values exist. It can traverse from a design token back to the brand premise in a single query. The knowledge graph is real and traversable, not a metaphor.

This distinction matters enormously for AI execution. A token without a reasoning chain can be applied or misapplied without the AI knowing the difference. A token with a reasoning chain gives the AI the context to make the right call in edge cases, situations the guidelines didn't anticipate but the reasoning can cover.

How Does DTCG Architecture Maintain Data Hygiene?

brand.md uses W3C Design Token Community Group (DTCG) standards at the foundation layer. This isn't a formatting preference. It's a data hygiene mechanism.

Every token in the system traces back to a Foundation primitive. The Foundation layer defines the raw values, the full colour palette, the type scale, the spacing units. The Semantic token layer sits above it and maps those primitives to usage-intent rules. color.brand.primary doesn't store a hex value directly, it references color.base.green.700 from the Foundation, and adds the usage rules on top.

The result is that no free values exist in the system. Every element has lineage. When an AI queries a colour, it gets the value, the Foundation reference, and the semantic rules in one addressable object. When the brand evolves and the primary colour changes, updating one Foundation token propagates the change through every Semantic token that references it.

This is the difference between a brand.md that works and one that slowly accumulates inconsistencies. Data hygiene isn't procedural, it's structural.

How Is brand.md Different from design.md?

design.md has been gaining significant attention. Google, Vercel, and other major players have adopted it. Coding assistants use it to understand UI patterns, component libraries, and interaction states. It's genuinely useful.

brand.md and design.md are different layers of the same stack. Neither replaces the other.

design.md is the UI execution layer. It tells AI how to build: which components to use, how to apply spacing, what interaction patterns are standard.

brand.md is the brand context layer. It tells AI what the brand is: its voice, its colour identity, its visual personality, the reasoning behind every decision that design.md executes.

brand.md is upstream:

An AI that has design.md but not brand.md can build technically correct interfaces that feel off-brand. An AI that has brand.md but not design.md understands the brand's identity but lacks the implementation specifics. Both working together give AI the full picture.

The important distinction: design.md can be inferred from a website. A developer can analyse a company's UI, extract the component patterns, and write a reasonably accurate design.md. Brand identity doesn't work that way. A website is one channel of a brand. Scraping it gives you surface values without the strategic decisions behind them. The only legitimate brand.md comes from inside the brand itself, authored by people who know why the decisions were made.

A scraped brand.md would be costume, not identity.

What a complete brand context layer actually contains ->

Where Does brand.md Sit in the AI Context File Stack?

The emerging standard for AI context files is a five-layer stack, each file answering a different question:

1. llms.txt: Discovery. Tells AI crawlers and assistants what the site is about and where to find key content.

2. brand.md: Brand context. What the brand is. Voice, colour, typography, imagery, personality, decision logic, and the reasoning chain that connects every element to the founding premise.

3. design.md: UI execution. How to build. Components, spacing, interaction patterns, design system specifics.

4. skills.md: Task procedures. How to do specific things.

5. CLAUDE.md: Project overrides. Session-specific instructions that modify behaviour for a particular context.

brand.md sits at the second layer, downstream of discovery, upstream of execution. Every AI tool that builds or creates anything for the brand needs it.

brand.md Is the Format Every AI Tool Is Missing

The adoption of context files across AI workflows is not slowing down. Cursor, Claude Code, Copilot, and every major coding assistant now read context files at session start.

What's been missing is the brand context layer. Not just a semantics layer, a brand context layer that carries semantics, relationships, data lineage, reasoning chains, and the narrative logic that makes visual, verbal, and motion expressions of the same coherent brand rather than three separate style guides that happen to use the same logo.

Brand guidelines were designed for human readers who apply judgment. brand.md is designed for AI systems that execute at scale. Every session starts with the same brand context. Every generation happens within the same defined boundaries. Consistency stops depending on whoever happened to write the prompt that day.

Every tool is already reading context files. The brand context layer has been missing from the stack.

brand.md is that layer. See the full brand.md specification and how to implement it ->