Turn a Publisher Style Guide Into Enforceable AI Rules

Datadog's documentation team doubled from 7 to 14 writers, and the developer-to-writer ratio still stayed at 200 to 1 (Docsio). The team merges over 20,000 documentation pull requests a year (Docsio). No editor reads that much text closely. Style enforcement that depends on someone reading every line breaks well before that volume.

AI writers create the same problem faster. If you paste your style guide into a prompt, the model may not follow every instruction in it. If you split it into typed rules, place each one in the pipeline stage that can enforce it, and score every post afterward, the guide becomes a spec.

This is how we think about it at Ryterr, and how you can apply it to your own guide.

Why "write in our voice" fails as a prompt

"Friendly." "Authoritative." "Conversational but expert." These words describe a feeling. A model can't execute them, and you can't check them.

Deepsmith makes this point directly: adjectives aren't executable, so voice rules have to be written as observable behavior, using Mailchimp's public style guide as the model (Deepsmith). "Sentences under 25 words" is a rule you can measure. "No exclamation marks in body text" is one you can enforce. "Be friendly" is neither.

There's a second problem. Long prompts can reduce adherence to some instructions, especially when guidance is buried (AtomWriter). Treat this as guidance about prompt design, not proof that models universally drop rules near the bottom. A longer prompt doesn't guarantee more compliance.

Then there's volume. Datadog's numbers show what happens when people carry the whole enforcement load. Writers burn hours on comma fixes instead of structure and accuracy.

Publishers are now writing explicit AI rules of their own. The Associated Press updated its newsroom standards in July 2026: AI can help with headlines, summaries, transcription and grammar, while sourcing, verification and editorial judgment stay human. The update states that "all AI-generated outputs must be reviewed and edited by an AP journalist before publication" and that "Disclosure will also be required whenever generative AI plays a material role in published content" (dig.watch).

That's a long way from AP's 2023 stance. Back then, Amanda Barrett, AP vice president of news standards and inclusion, said: "Our goal is to give people a good way to understand how we can do a little experimentation but also be safe," (Fortune). The rules got more specific, and specific rules can be built into a pipeline.

The five rule types every publisher guide contains

Open any publisher style guide and you'll find the same five kinds of rules. Sorting yours into these buckets is the first step, because each type gets enforced differently.

• Voice. Rewrite tone adjectives as numeric scales, like "formal: 2 of 5" (AtomWriter). Then add contrastive examples: one line that sounds right and one that sounds wrong (SUCCESS). Models learn from the gap between them.
• Mechanics. Banned words, dash rules, capitalization, numerals, contractions. These are the easiest to make machine-checkable. PostHog writes its own YAML rules for the Vale linter, including a ban on em dashes (PostHog).
• Sourcing. Every statistic needs an attributable source. Primary sources beat aggregators. Claims without support get cut. If you publish without rewriting, add AP's disclosure requirement here, since it applies "whenever generative AI plays a material role in published content" (dig.watch).
• Citation format. Inline links or footnotes, and whether every post ends with a Sources section.
• Visual style. Palette hex codes, aspect ratios, illustration style, where images sit in the post.

Write every rule as a verifiable instruction. The IFEval benchmark shows how: its authors "create a list of 25 verifiable instructions" and "a set of 541 prompts," each instruction checkable by code (Zhou et al., IFEval). If your rule can't be checked, it's still an adjective.

Where each rule lives in the pipeline

Once your rules are typed, put each one where it can actually be enforced. You have five places to choose from.

System prompt. Keep it short. Voice anchors, audience, and a few hard bans. AtomWriter recommends a condensed AI snapshot of your guidelines in the system prompt, not the full document (AtomWriter). Everything you add here dilutes everything else.

Exemplars. Show the model the exact behavior. One practical guide says to "add 3-10 few-shot examples that demonstrate the exact behavior you want" (DEV Community). The tradeoff is cost: "400 extra tokens per call at 1 million calls per day is $2,000 per day in example tokens alone" on GPT-4o (Pristren). At blog volume that's small. At API volume it's a line item.

Retrieval. Pull the relevant slice of your guide, terminology list, or brand facts per topic instead of stuffing everything into every call. Prodinit offers an unsourced estimate that "Roughly 70% of production LLM problems are solved by RAG or better prompting; fine-tuning serves the remaining 30%" (Prodinit).

Fine-tuning, and when to skip it. PEFT brand-voice tuning costs "$1,000-$10,000+ (training + infrastructure)" and needs "500-5,000 labeled examples" (Search Engine Land). Hillock Studio's advice is to test whether your voice is teachable with a micro set of 50 to 200 examples through few-shot prompting first: "Don't fine-tune yet" (Hillock Studio).

A Restack study did find that "Fine-tuning on simulated data outperforms prompting for agent tone of voice" (arXiv). Read the scope carefully, though. It measured conversational agent tone, not long-form publisher style. Most evidence for fine-tuning style comes from customer-service tasks and vendor blogs. For a blog, few-shot plus retrieval is usually enough, and fine-tuning adds data, evaluation and retraining work every time your guide changes.

Post-generation checks. This is the layer that catches what the first four miss. It gets its own section next.

Detect with code, fix with a model

PostHog's handbook states the core pattern: use Vale to detect issues, then use LLMs to help fix them (PostHog). Detection stays deterministic and reproducible. The fix gets the language flexibility a regex can't offer.

Here's what one Vale existence rule looks like. This one bans em dashes:

extends: existence
message: "Don't use em dashes. Use a comma, colon, or period."
level: error
nonword: true
tokens:
  - '\x{2014}'

Datadog runs Vale in its authoring environment and in CI. The team reports that "Vale has helped us cut down on editing time, reduced the mental toll on writers" (Datadog). Contributors fix their own issues before a human reviewer sees the draft.

Start small. Meilisearch says that "At the Meilisearch documentation repository, we configured it to run for every pull request," and it recommends beginning with a few rules, because too many early rules cause false-positive failures (Meilisearch). A linter that blocks good posts gets turned off.

This is mainstream tooling now. Vale's creator, Joseph Kato, called it "a command-line tool that brings code-like linting to prose" (LWN.net). Its GitHub page invites you to "Turn your team's writing guidelines into checks that run in your editor, in CI, and alongside your code," and lists teams at AWS, NVIDIA, Microsoft, GitLab and Red Hat as users (Vale on GitHub).

The limit is real. Lint catches mechanics, banned words, capitalization and citation patterns. Voice, tone and claim hedging still need a rubric or an LLM judge, and a judge adds bias and cost.

Score adherence with a scorecard, not a vibe check

"It reads fine" doesn't tell you whether the post followed your guide. Borrow IFEval's method instead: every rule becomes a pass or fail check, and adherence is the share of rules a post passes.

Build a scorecard with one row per rule and these columns:

• Rule type: voice, mechanics, sourcing, citation format, or visual style
• Check method: code, LLM judge, or human
• Result: pass or fail
• Weight: how much a failure costs

Mechanics and citation format get scored by code. Voice gets scored by a rubric judge comparing the post against your paired right and wrong examples. Sourcing gets scored by a claim-to-source check: does each statistic match the page it cites?

Watch your sample size. IFEval has 541 prompts, and "IFEval has 31 prompts that require the response language to be in a language other than English" (arXiv). Small subsets produce noisy scores. Test against at least a few dozen posts per rule category before you trust a number.

Calibrate the judge, too. Score a small set of posts by hand, compare against the LLM judge, and repeat the check whenever your guide changes.

Style, research, and fact-check in one visible pipeline

Style can't be a separate pass. A style fix that rewrites a sentence can change a claim. "Revenue grew 40%" becomes "revenue roughly doubled" because the editor wanted rhythm. A perfectly styled article can still be wrong. So style checks and fact checks have to run on the same final text, and both have to show their work.

Here's how we do it at Ryterr:

• Ryterr reads your public website to save your product, prices and voice, each fact with the quote it came from.
• Trace checks each statistic, price, name and date against live sources.
• The Review tab lists every claim Trace checked and the page it checked against.
• Corrections are shown before and after, with the old words, the new words and the reason.

You can see the full flow on how Ryterr writes and checks a post. Visual style is part of the same run: each post comes with a hero image and inline images in brand colours, plus a title, slug, description, an FAQ and a Sources section.

A flagged post is a gate. A post with an open fact-check finding waits for review and isn't published by a scheduled run. That lines up with AP's position that verification stays accountable to a person. On our sample post, all 25 claims were verified with zero open review warnings.

When a post clears, it goes straight to your site through WordPress, Ghost, GitHub, a signed webhook or the Content API. Details are on publish to the site you already run.

Your next step: convert 10 rules this week

You don't need to rebuild your whole guide. Start with 10 rules.

1. Pull 10 rules from your current style guide and tag each one: voice, mechanics, sourcing, citation format, or visual.
2. Rewrite every adjective-based rule as an observable one. Add one right and one wrong example for each voice rule.
3. Assign each rule a stage: system prompt, exemplars, retrieval, or post-generation check. Put every code-checkable rule in a linter first.
4. Score your last 5 published posts against the scorecard. That's your baseline before you change anything.

For structuring posts so answer engines can cite them, our AI SEO guides cover the next layer.

FAQ

Can I just paste my whole style guide into the system prompt?

You can, but long prompts can reduce adherence to some instructions, especially when guidance is buried. The cited guidance does not establish that models universally drop rules near the bottom. Keep the system prompt to a condensed snapshot: audience, voice anchors and a few hard bans. Move the rest to exemplars, retrieval and post-generation checks.

Do I need to fine-tune a model to match my publication's voice?

Probably not at first. Test with a micro set of 50 to 200 examples through few-shot prompting before you spend $1,000-$10,000+ on PEFT tuning. The main study favoring fine-tuning measured conversational agent tone, not long-form articles.

Which rules should go into a linter first?

Start with high-confidence mechanics: banned words, dash rules and capitalization. These rarely produce false positives. Add rules slowly, the way Meilisearch recommends, so the linter doesn't block good posts and get switched off.

How do I check voice if code can't measure it?

Use a rubric judge, either a person or an LLM, that compares each post against your paired right and wrong examples. Calibrate an LLM judge against human scores on a small set first. Re-check it whenever the guide changes, because judges add bias.

Does passing every style rule mean the post is accurate?

No. Style compliance and factual accuracy are separate checks. A post can pass every lint rule and still cite the wrong number, so claim-to-source checks need to run on the same final text as the style checks.

Sources

• Deepsmith: Document brand voice and tone for humans and AI
• AtomWriter: AI writing style guide template
• AtomWriter: Brand voice guidelines for AI
• SUCCESS: How to train AI to match your brand voice
• Docsio: Vale linter
• dig.watch: AP AI newsroom rules
• Fortune: Associated Press AI guidelines
• PostHog handbook: Vale
• Zhou et al.: Instruction-Following Evaluation for Large Language Models (IFEval)
• DEV Community: Fine-tuning vs prompting, a practical team's guide for 2026
• Pristren: Few-shot prompting guide
• Prodinit: LLM fine-tuning vs RAG decision framework
• Search Engine Land: How to train in-house LLMs on brand voice
• Hillock Studio: Brand voice
• arXiv: Fine-tuning on simulated data outperforms prompting for agent tone of voice
• Datadog: How we use Vale to improve our documentation editing process
• Meilisearch: Prose linting with Vale
• Vale on GitHub
• LWN.net: Vale article
• arXiv: Finnish LLM post-training paper

See it run on your own site

If you want to watch style, research and fact-checking run together on your own brand, Ryterr gives you 2 free posts with no card required. Each one comes with a fact-check report that lists the source for every claim. See pricing and the free plan, then read the report before anything goes live.