Your voice as a linter

A style guide nobody enforces is a document, not a standard. Developers solved the equivalent problem decades ago by making the rules executable, and the same tooling works on prose: Vale is a linter for writing.

There is a conspicuous gap in it. Vale's official package registry contains sixteen styles, and every one of them is a documentation house style or a generic prose checker. Not one is a brand voice.

This sits under the AI writing tells, and the tool at the end of it emits a configured style along with the rest of your files.

Can a brand voice be a linter rule set?

Partly, and the boundary is the useful thing to know. Vale is unusually clear about what it is: its own documentation states that it is not a general-purpose writing aid, that it does not teach you how to write, and that it is a tool for writers rather than a replacement for one.

More to the point, it offers no opinions of its own. The documentation says so directly: Vale does not offer any of its own advice, it offers a framework for creating and enforcing custom rules. It describes itself as focused on consistency across multiple authors rather than on general correctness.

That is exactly the shape a brand voice needs. You are not asking whether the writing is good. You are asking whether it obeys decisions you already made.

Which of its checks does a voice rule map onto?

Vale has eleven extension points, and a rule declares which one it uses. Most of a voice document maps onto four of them.

Vale's checks, and what a voice rule uses them for
CheckWhat it doesVoice rule it carries
existenceFinds a regex patternBanned words, forbidden punctuation
substitutionReplaces a pattern with a preferred stringSay this, not that
occurrenceCounts matches in a scopeRationing exclamation marks
capitalizationEnforces a case styleSentence case in headings
metricComputes a readability formulaA reading-age target
consistencyFlags mixing two accepted formsOne spelling variant throughout
conditionalRequires B wherever A appearsDefine an acronym on first use
repetitionFinds repeated matchesWord echo
sequenceMatches part-of-speech patternsRarely useful for a voice
spellingRuns a dictionaryLocale spelling
scriptRuns a small program over the textSentence rhythm, when nothing else fits

Every rule shares the same header regardless of check: the extension point it uses, the message shown when it fires, and a severity level that decides whether the rule is a suggestion, a warning or an error. Severity is where a voice guide becomes a gate rather than a leaflet.

Why is no published package a brand voice?

This is checkable rather than asserted. Vale's official registry is a single file listing every package it ships, and it contains sixteen: AsciiDoc, Elastic, Google, Hugo, Joblint, MDX, Microsoft, NoAnimalViolence, OpenShift, proselint, Readability, RedHat, Salesforce, write-good, alex and the rest of that family.

Every one is a documentation house style or a generic prose checker. Microsoft's own package README describes it as an implementation of the Microsoft Writing Style Guide, which is a technical documentation standard. Google's is the Google developer documentation style guide. There is no Mailchimp, no Monzo, no brand of any kind.

That is not an oversight by the Vale project. It is what happens when a tool is adopted by technical writers and never reaches marketing teams, who keep their standards in a slide deck. The tooling has been sitting there the whole time.

What cannot be linted, and what to do about it?

The honest half, and the reason to trust the other one. A linter matches patterns. Anything that requires knowing what the writing means is out of reach.

The answer to all five is the same and it is not more rules: those are review, and a linter exists so that review can spend its attention on them instead of on spelling variants. The wider list of what a voice file cannot fix sets out the rest.

Why does the false-positive rate decide whether anyone keeps using it?

Because a checker that cries wolf gets switched off, and once it is off the standard is gone with it. This is the ordinary fate of a linter introduced with too many rules at once.

The practical route is the reverse of how most people do it. Start with the rules nobody will argue about, set them to error, and add the contentious ones as suggestions where they inform rather than block. A rule that fires on correct writing costs more than the rule is worth.

This site publishes no false-positive figure of its own, because it has not measured one and it does not publish measurements it has not made.

Where should it run?

Wherever the writing happens, and as early as possible. In an editor while drafting, in a pull request for anything kept in version control, and in a scheduled check over published pages if you have a large estate.

The severity levels do the work here: errors block, warnings surface, suggestions inform. A voice standard that fails a build is a real standard, and one that only exists in a document is a preference.

The download includes a configured style built from the same rules as the rest of your files, so the checker and the instructions cannot disagree.

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.

A standard nobody can run is a preference: generate the rules and the checker together.