Every organization shipping LLM-powered features in 2026 has the same quiet problem.
Marketing has a brand book. It’s a PDF, maybe a Notion page. It says things like “warm but professional,” “active voice,” “avoid hype words.” It was written for humans — designers, copywriters, freelancers — who read it once a year, internalize it, and apply it by feel.
Engineering is shipping LLM features into the product. Customer support automation. Sales reply drafting. Documentation generation. Marketing copy assistance. Each feature is talking to the same kind of foundation model with a different prompt and a different sense of what “on-brand” means.
The outputs drift. The chatbot uses “synergy.” The auto-drafter sounds breathless. The doc tool flattens everything into the same generic explainer tone. Legal flags one of them in a customer-facing surface. A reviewer manually fixes the worst examples. The problem comes back the next week, in a different feature, in a different drift direction.
That’s the loop most LLM-adopting orgs are quietly stuck in. Brand voice as a 2026 problem isn’t a creative problem. It’s a coordination problem. Every LLM surface in the company is making the same kinds of mistakes independently, and there’s no machine-readable thing the surfaces can all be pointed at.
We built that thing for our own use, and earlier this month we published it open source.
This is the post about what we shipped, what it is, and why we open-sourced it rather than keeping it as a private advantage.
What we shipped
Two public repositories under the gramatr org:
gramatr/brand-spec — the specification. A machine-readable format for describing a brand: its voice, its tone, its tabu list, its preferred terminology, the behavioral directives it expects every LLM-powered surface to follow. It’s designed to be consumed by any LLM workflow that can read structured input — not just by gramatr.
gramatr/brand-spec-validator — a TypeScript reference validator. Run any brand-spec document through it; get back normalized output, validation errors, or a clean pass. Reference-grade. Forkable.
Both repositories are public, open-source licensed, and adoptable without any commercial relationship with gramatr. If you want to use the spec inside your own LLM workflow — your own retrieval pipeline, your own custom assistant, your own anything-that-talks-to-a-foundation-model — you can. We don’t gate it. We don’t license it commercially. We don’t ask for attribution beyond what the open-source license calls for.
The spec and the validator are the public artifacts. Everything that matters for adopting brand-spec is in those two repositories.
What problem the spec solves
If you’ve ever tried to make an LLM stay on-brand across more than one feature, you’ve felt the problem the spec is solving.
A brand book is unstructured prose. An LLM reads prose well, but it reads it inferentially — it picks up a feel for the brand and then drifts in whatever direction the prompt pushes it. Two engineers write two different prompts for two different features. The brand book is in both prompts. The outputs sound like two different companies.
What the brand-spec adds is structure. Voice attributes, tabu terms, preferred terminology, and behavioral directives all become structured fields the validator can check and an LLM workflow can consume.
When that structured spec gets passed to the LLM workflow as input, the model doesn’t have to infer. It has the brand in a form it can apply deterministically. The drift problem becomes a configuration problem: the brand changes once, in the spec, and propagates to every feature that consumes the spec.
This is the same pattern that turned “documentation” into OpenAPI specs in the 2010s — taking a thing humans used to read informally and giving it a machine-readable representation that systems could enforce.
A brand book is to a brand-spec as Postman docs are to an OpenAPI definition. Both have a role; only one of them gets enforced by the machine.
Why we open-sourced it
The first question people ask, sometimes politely and sometimes not, is: why give this away?
There are three honest answers.
First: the spec is more valuable as a standard than as a moat. If only one platform can apply a brand to LLM outputs, buyers are betting on that vendor specifically. If brand-spec is an open standard with a public validator and a growing ecosystem of tools that can apply it, buyers get to bet on the standard — and gramatr is the easiest, best-integrated way to operationalize it. That’s a better deal for the buyer and a more durable position for us.
This is the same logic Cloudflare ran on Workers, HashiCorp ran on Terraform, and Anthropic ran on MCP. Define the open layer below your commercial layer. Compete on the operationalization, not the spec.
Second: brand-spec only works if the ecosystem ships it. A spec that only gramatr understands is a spec exactly one company ships. A spec that other LLM-tool vendors can consume — that LangChain integrations can adopt, that custom internal assistants can apply, that marketing-automation platforms can read — is a spec that becomes part of how the industry handles brand voice. The latter is what we want. The former is private notation.
Third: it’s the right move for the customer. An enterprise adopting brand-spec doesn’t want to discover, two years in, that the spec is owned by a single vendor and locked behind a paywall when the vendor decides to enforce one. Open source neutralizes that risk. The customer’s brand-spec lives in version control they control. It can be consumed by gramatr today and by whatever wins in 2028.
We get more value from being the reference implementation of an open standard than from being the only implementation of a proprietary one. The math isn’t close.
How an organization adopts it without us
This is the part most “we open-sourced X” posts hand-wave. Here’s the concrete path.
- Draft a brand-spec document. Use the gramatr/brand-spec repository’s schema to describe your brand. Voice attributes, tabu list, terminology rules, behavioral directives. Start with whatever your existing brand book covers; structure it into the spec format. Marketing and engineering should sit at the table for this — it’s a translation, not a rewrite.
- Validate it. Run your draft through gramatr/brand-spec-validator. Fix the errors. Normalize the output. Commit the validated document to your own repo, with the same review process you use for any other production artifact.
- Inject it into your LLM workflows. The spec is structured input. Any LLM workflow that can read structured input can consume it. Retrieval-augmented assistants can pull the spec as a directive. Custom internal tools can include the spec in system prompts. The shape is yours to decide; the structure is consistent enough that the tools can stay coordinated.
- Iterate. When the brand evolves — new product line, new audience, new market — the spec evolves with it. The version-control history of the spec becomes the version-control history of the brand. Audit-friendly. Reproducible.
None of those steps require gramatr. You can adopt the spec, validate it, and apply it across your LLM features using the public repositories and your existing infrastructure. The standard works without us.
How gramatr uses the same spec
Inside gramatr, brand-spec documents plug into the standards layer of the Loop. The Shape stage — where every output gets evaluated against the standard the team committed to in advance — consumes the spec as part of its evaluation criteria. The brand becomes part of the structured standard the cycle uses to determine whether an output meets the bar.
The advantage of using gramatr to operationalize brand-spec, instead of building the integration yourself, is the rest of the Loop. The full cycle keeps running, and brand-spec plugs in at the standards layer. Your brand isn’t a separate system; it’s part of the same cycle everything else flows through.
You can do the spec without gramatr. You can do gramatr without the spec. The combination is sharper than either piece alone, but neither piece requires the other.
That’s the operational meaning of “open standard, commercial operationalization.” Each piece works on its own; together they’re better.
Why this matters for the category
Brand voice is the visible layer of a deeper problem: how do you keep LLM-powered surfaces aligned with anything an organization actually stands for? Compliance language. Risk framing. Tone for sensitive topics. Domain terminology that has to be precise. The brand-spec format solves the brand-voice slice of this, but the pattern — structured behavioral directives that any LLM workflow can consume — generalizes.
In five years there will be similar specs for compliance posture, for accessibility standards, for legal disclosure requirements, for safety-critical-domain terminology. Some will come from vendors. Some will come from standards bodies. Some will come from regulators. The shape will be the same: structured, machine-readable, version-controlled, validated, applied as structured input to LLM workflows.
The companies that figure this out early will be the ones whose LLM features stay consistent as they scale. The companies that don’t will be the ones managing brand-and-compliance drift as a permanent operational tax.
Gramatr published the brand-voice spec because brand-voice was the slice we had to solve for ourselves first. The rest of the pattern is coming — from us and from others — and the more of it that gets standardized in the open, the better the LLM era turns out for everyone.
What’s next
The brand-spec repository takes issues and pull requests. If your team is using LLMs in production and brand drift is a problem you’re solving by hand, the path forward is:
- Read the spec.
- Run the validator against a draft of your own brand-spec document.
- Apply it in your LLM workflows.
- File issues or PRs when the format doesn’t capture something you need.
If you want to see the cycle that uses brand-spec at every Shape stage, /how-it-works walks through it. If you want to see how gramatr fits the broader open-standards-plus-commercial-operationalization pattern, /for-enterprise addresses it directly. If you want to apply brand-spec in your own LLM workflows today, the two public repositories are everything you need.
Brand voice across LLM outputs doesn’t have to be unmanageable. The answer is structured, version-controlled, validatable, and open. We shipped our piece of it. Pick it up if it helps.