Where tokens come from
The same formats come from two places:
Both take
context: ?context=dark-background gives each rule’s version for
that context and the default of the rest. Without it, every rule’s default.
In the app, the brand’s Tokens and rules tab shows every format, and
Use this brand copies their addresses.
On BrandHub, file URLs inside an answer (font files, logos) are signed for a
day, and the answer itself may be cached for an hour: fetch it again rather
than keeping its URLs.
W3C design tokens
format=json is the Design Tokens Format
(DTCG 2025.10). Each rule’s dotted key is its path: color.primary is
{ "color": { "primary": { ... } } }.
A rule’s
usage becomes its $description.
color.primary and
color.primary.dark) nests the second inside the first, which DTCG readers
refuse: name one of them otherwise (color.primaryDark).
Token formats
Names follow keys:
logo.minClearSpace is --logo-min-clear-space in CSS.
Colors, numbers, fonts (family, size, weight and their files) and type
scales become tokens; a font’s files are loaded from Artbucket by
@font-face, with each file’s weight and style read from its name
(Inter-BoldItalic.woff2). A number is written as it is, without its
spec.unit.
DESIGN.md
format=designmd is a DESIGN.md
(Google Labs, version alpha), to keep at a repository’s root for coding
agents. It is the one format that carries guidance as well as values:
- Front matter:
colorsby their local name (color.primaryisprimary; when no color is named primary,primaryrefers to the first),typographyper face (family, size, weight),roundedfor number rules named like a radius (in px), andspacingfor ones named like a gap, margin or padding. - Prose: Overview (text and lists of any other group), Colors, Typography, Layout, Shapes, and Do’s and Don’ts, from lists whose key reads as a do or a don’t.
llms.txt
Every public brand on BrandHub has/{org}/{brand}/llms.txt: the brand in
words for an agent, with who listed it and whether that is verified, links to
its other files, its portal’s terms, and every rule by context, each with its
files. BrandHub’s own /llms.txt says how an agent finds a brand there, and
lists them.
A domain’s own /llms.txt is the first place the public
Brand Agent Score looks: link
your brand.json, your tokens and your MCP server from it.
rules.json
/{org}/{brand}/rules.json is the listing as data, lossless: the release,
who listed it, its versions, its portal and terms, and every rule with its
key, label, context, type, value, spec, usage and files, signed for a day.
MCP
/api/v1/mcp serves the same brand to agents that connect: brand_rules
for a context, get_theme, list_pages and get_page, and the rules and
pages as resources (artbucket://brands/{slug}/rules/{context}). See
MCP.
How BrandHub files are served
- Public brands only, from the latest release, or the one
@{n}names. - Keyless, with
Access-Control-Allow-Origin: *, cached up to an hour. - A community listing (its organization proved neither a domain nor a
GitHub account) answers with
X-Robots-Tag: noindex. - Each read but the badge’s is a pull, counted in Insights.