Owning a voice file
You shipped the file. Now somebody has to keep it true, and this is the chapter every guide skips. The closest thing to a direct competitor for this content states in its own text that it omits version control, team collaboration and what to do when voice rules conflict across departments, which are precisely the three problems that arrive in week two.
This page answers those three. It sits under brand voice guidelines, which covers what goes in the document in the first place.
If you have not made one yet, eleven questions will produce the first version and it will already carry an owner and a review date.
Who owns the file when marketing and legal disagree?
One named person, and the schema has a field for them, because an unowned file is one that drifts until somebody notices it is wrong and then nobody is responsible for that.
The useful split is that marketing owns how it sounds and legal owns what may not be said. Those two are rarely in genuine conflict, and where they are, the mandated-terms and banned-terms fields are the seam: legal populates them, marketing populates everything else, and neither edits the other's list.
That structure works because prohibitions compose. Two people can add to a prohibition list without contradicting each other, which is not true of two people editing a paragraph describing a personality.
What does a voice file look like in a pull request?
Like any other configuration file, which is the argument for the format. The canonical document is structured data, so a change to it shows up as a changed field rather than as a rewritten paragraph, and a reviewer can see that the contraction rule flipped without reading the whole thing.
Commit the canonical file and the rendered outputs together, and treat the rendered files as build artefacts that are never hand-edited. The moment somebody fixes a typo in one rendered copy rather than in the source, you have two voices and no way to tell which is current.
How do you diff two versions of a voice?
Diff the canonical document, never the prose. A rendered guide reflows when one setting changes, so a text diff of the readable version shows fifty changed lines for a one-field edit and hides the edit among them.
There are three kinds of change and they deserve different scrutiny.
- A mechanical setting flipped. Small diff, large effect, every sentence changes. This is the one to review most carefully and the one that looks least alarming.
- A rule added or removed. Check the count first: if adding this one takes you past fifteen, something else should come out rather than the cap being ignored.
- A worked example replaced. Usually the safest change and often the most valuable, because examples carry more than descriptions do.
When to re-run it, and what triggers a re-run
- A repositioning, a new primary audience, or a merger. The answers to the first three questions changed, so the file should be rebuilt rather than patched.
- A new surface. Adding a channel with a different register is a real change to how tone varies by surface.
- A rule that keeps being broken in practice. Either the rule is wrong or the file is too long and the rule is getting lost, and both are worth finding out.
- A model release you actually use. See below.
- Not on a calendar for its own sake. Re-dating a document that has not changed is the habit that makes this whole category untrustworthy, and it is worth refusing even though it is free.
What happens when the model changes underneath you?
Your file stays the same and its effect does not, which is the part nobody plans for. A model release can make a rule that never worked start working, and it can change a default your file was implicitly relying on without mentioning it.
The concrete case people know is punctuation. A constraint that a great many users reported as impossible to make stick became reliable with a later model release, while the highest-ranking community answer still says it cannot be done. The advice was right when written and is now wrong, and nothing about it announced the change.
The maintenance procedure that follows is short: on a release of a model your team actually uses, re-run the verification check rather than re-reading the file. It takes about ninety seconds and it is the only thing that will tell you whether the ground moved.
Keeping the file and the human style guide in step
The human guide stays canonical for the organisation and the machine file is derived from it. Say so inside the machine file, naming the source document and its version, so that nobody has to argue about which one wins.
When the human guide changes, re-derive rather than edit both. When the machine file needs a rule the human guide does not contain, that is a finding about the human guide: it means a real editorial decision was never written down, and the right fix is to add it there first. Turning an existing guide into a file covers the first pass of that work.
A review date, and what to do on it
The schema carries a review date and an owner because a file with neither is a file nobody is accountable for. The date is a prompt to look, not a promise to change.
On the day: run the verification check, read the rule list and ask of each rule whether removing it would change anything, and confirm the owner is still at the organisation. Change the date only if you changed something. If nothing changed, the honest record is that it was reviewed and left alone, which is a different fact from being updated.
The limits page is worth re-reading on the same day, because most of what a review turns up is a thing a voice file was never going to fix.
Where these come from
Every claim above is quoted from one of these, and each was read on the date beside it. If one of them has changed since, the page is wrong and we would like to know.
- Anthropic: memory files, load order and length checked 2026-08-16
- OpenAI: Model Spec checked 2026-08-16
- Mailchimp content style guide, a maintained published example checked 2026-08-16
A file with an owner and a review date on it from the first version: generate one you can put in a pull request.