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, the tool will produce the first version with a review date already on it. Naming its owner is up to you and this page starts there.
Who owns the file when marketing and legal disagree?
One named person, 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 file.
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. The diff is small and every sentence changes. Review this change most carefully, because it looks the 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 an example shows what a description can only describe.
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 changes. Plan for that. 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 uses, re-run the verification check rather than re-reading the file. It takes about ninety seconds, and nothing else 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 has a review date and the file needs a named 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 docs (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 a review date on it from the first version: generate one you can put in a pull request.
Advertisement.
Also from Best Served Cold.
