Using a Model to Audit a Draft Against Your Voice Guide

A voice guide written for humans is full of sentences that a model cannot check: "warm but professional," "human," "confident." Those are goals, not constraints. The style file you paste into the prompt needs rules a reader could verify with a search. The rough test: if two editors could disagree about whether a sentence breaks the rule, it is not ready.

Here is the conversion:

Aim for 12 to 30 rules. Below ten, the audit misses too much; above 40, models start blending them and you cannot tell which rule fired. Number every rule (R-01, R-02) so a finding can cite one identifier rather than paraphrasing. This mirrors standard prompt guidance: label each part of a prompt clearly so the model does not confuse instructions with context, and tell it exactly how to format the output the Prompting Guide's tips.

Two more habits from prompt engineering practice apply directly. Use delimiters or tags to separate the rules from the draft; LangChain-style guidance on prompt structure recommends clear section markers and numbered steps for anything with several parts LaunchDarkly's prompt engineering practices. And describe what to do rather than what to avoid where possible, because positive instructions produce more consistent classification the Prompting Guide's tips.

Line references are the part people skip, and they are why the audit is usable. If a finding says "somewhere in the intro you use a banned word," the editor has to hunt. If it says "line 14," they can fix it in five seconds.

Number the lines in a form the model cannot lose track of, and keep the number outside the text so it is never mistaken for content:

1|Our new platform leverages best-in-class AI.
2|It was built to help teams move faster.
3|We are pleased to inform you that pricing is simple.

Ask for findings indexed to those numbers. The line numbers only survive if the model is not asked to rewrite the whole draft in the same pass, because a rewrite reflows the lines. If you must have both, run two calls: audit first, rewrite second, and re-number afterward.

Long drafts hit context limits and models start losing position accuracy on very long inputs. The reliable pattern is to audit in chunks of a few hundred lines at a time, keeping each chunk's numbering continuous by starting the next chunk at the previous chunk's last line plus one. A 300-line draft splits cleanly into three calls of 100 lines, and 100 lines gives the model plenty of room to cross-reference rules.

The prompt has four blocks: role and task, rules, draft, output contract. Here it is in a form you can run as is.

<role>
You are a style auditor. You do not rewrite the draft. You report violations of the numbered rules below.
</role>

<task>
Read the numbered draft under <draft>. For each place the draft breaks one of the rules, output one finding. If a line breaks two rules, output two findings for that line. Do not report anything else. Do not comment on quality, clarity or ideas.
</task>

<rules>
R-01: US spelling only.
R-02: No exclamation marks.
R-04: Flag: leverage, synergy, best-in-class, circle back, solutioning.
R-07: Flag sentences over 30 words.
R-09: Product is written "Quanta Inference" on first mention, then "Inference".
R-13: Flag: revolutionary, game-changing, unleash.
R-15: Flag passive constructions of the form "was [verb]ed by".
R-18: Instructions sections use present tense.
</rules>

<draft>
1|Our platform leverages best-in-class AI.
2|It was built by our team to help you move faster!
3|We are pleased to inform you that the pricing is simple.
</draft>

<output>
Return only a JSON array. No prose before or after. Each element has exactly these keys:
line (integer), rule (string, e.g. "R-04"), quote (string, the exact offending text, copied character for character), why (string, under 15 words), replacement (string or null if a safe replacement is not obvious).
If there are no violations, return [].
</output>

A sample result for that draft:

[
  {"line": 1, "rule": "R-04", "quote": "leverages", "why": "banned word", "replacement": "uses"},
  {"line": 1, "rule": "R-04", "quote": "best-in-class", "why": "banned phrase", "replacement": null},
  {"line": 2, "rule": "R-15", "quote": "was built by our team", "why": "passive construction", "replacement": "our team built it"},
  {"line": 2, "rule": "R-02", "quote": "faster!", "why": "exclamation mark", "replacement": "faster"},
  {"line": 3, "rule": "R-04", "quote": "We are pleased to inform you", "why": "stiff opening", "replacement": null}
]

Why insist on JSON rather than prose? Because you can parse it, count findings per rule, store them, and feed them into whatever review tool the team already uses. The Agenta guide to structured outputs explains why free-form replies break pipelines and why schema enforcement (either through an API that supports it or through strict prompt instructions plus validation) is the production-grade choice the Agenta structured outputs guide. PromptQuorum's overview makes the same point and adds the crucial caveat: always parse and validate the JSON before acting on it, because even schema-shaped output can contain wrong content the PromptQuorum structured output guide.

If your provider or gateway supports a strict response schema, use it, and put the same field definitions in the prompt as well. Native enforcement varies by API and by model, so a prompt that states the contract is the portable version the Agenta guide.

Suppose a draft runs 300 lines. You split it into three calls of 100 lines. The first call returns 22 findings, the second 9, the third 31, for 62 total. Count them by rule: 24 are banned words (R-04), 14 are spelling (R-01), 5 are exclamation marks (R-02), 4 are long sentences (R-07), 3 are passive constructions (R-15), 2 are first-mention naming (R-09), 1 is tense (R-18), and 9 are findings you read and reject.

That last number is the one to watch. A false-positive rate near 15 percent is normal on a first run; the goal is to drive it down by fixing the rules, not by scolding the model. Most false positives come from three causes:

1. Overlapping rules. R-01 and R-09 both catch a miswritten product name. Merge or cross-reference them.
2. Vague boundaries. "Sentences over 30 words" catches a legitimate list sentence. Add an exception: lists and quoted material excluded.
3. Context the model lacked. The model flags "Inference" as an unapproved term because the case law is in a different rule set. Move the exception into the rule text.

Log every rejected finding with its rule number. After two or three drafts, you will see which rules generate noise, and the fix is a sentence in the style file. This is the same iterate-and-simplify loop that general prompt guidance recommends: start simple, add elements as you see what fails the Prompting Guide's tips.

One more arithmetic fact that changes how editors use the output: the 24 banned-word findings are not equal. Twelve might be the same word appearing twelve times, which is one edit with search-and-replace. Group findings by rule and by quote before you start, and the 62 findings collapse into maybe 15 decisions.

Line numbers are only trustworthy against the exact text you sent. The moment an editor accepts a fix, everything below it shifts. Three practices keep the audit honest:

• Audit the frozen draft. Run the pass on the version that goes to review, and record its hash or timestamp next to the findings.
• Fix from the bottom up. Apply accepted fixes starting at the highest line number and working down, so earlier line references stay valid while you work.
• Keep quote and line together. The quote is the fallback index. If line 37 now holds different text, find the quoted string and fix there.

False positives also cluster around judgment calls that should never have been rules. "Flag cliches" is a judgment rule; "flag these eight phrases" is a mechanical one. When a finding survives a re-read and you still disagree, that is usually a sign the rule is too broad. Split it into specific phrases. The CMI research on effectiveness is blunt about this: progress comes from knowing what success looks like and aligning the team to it, not from adding more inputs the CMI research on effective content marketing. A style file with 15 sharp rules that produce near-zero noise beats 40 poetic ones.

Two structural risks worth naming. First, prompt injection: if the draft contains text that looks like instructions ("ignore the rules above"), a naive audit can be derailed. Keep the draft in a delimited block, instruct the model to treat it as data only, and never run the audit on untrusted third-party text without that guard LaunchDarkly's prompt engineering practices. Second, voice drift: if you also let the same model rewrite, it tends to flatten distinctive phrasing toward the average. That is exactly why the audit pass should not rewrite.

The point of the audit is a decision list, not a corrected document. Sort findings into three piles.

The line between the first two piles and the third is meaning, not preference. "uses" for "leverages" changes nothing. "our team built it" for "it was built by our team" changes emphasis, which may be fine or may be wrong depending on the previous sentence. When the model returns null for a replacement, treat that as a gift: it has flagged a problem without pretending to solve it.

A worked decision: finding 14 says R-04 quote: "solutioning" replacement: "problem solving". That swap is not neutral, because "solutioning" in a services business means presales work. Reject it. Change R-04 to remove "solutioning" from the banned list, or to specify a domain term. One rejected finding, one line edited in the style file, fewer false positives forever after.

Finally, feed the decisions back. The best style files are grown from rejected findings. Keep the audit log, tag every rejection with the rule, and revise rules on a schedule. This is the same documentation discipline that separates effective content programs from busy ones, applied to sentence-level quality the CMI research on effective content marketing. If you would rather have the review itself handled for you, a specialist working inside your context can take the style file and the draft and hand back the findings list, which is how Quanta Experts is set up to work.

The audit is one gate, not the whole review. A practical sequence for a team publishing several pieces a week:

1. Draft stage: the writer runs the audit themselves, fixes mechanical findings, and resolves the rest before the draft reaches anyone else.
2. Editor stage: the editor receives the draft plus the remaining findings. Review starts from a known list rather than a blank read.
3. Pre-publish stage: a final automated pass catches text added during edits, which is where new violations usually appear.
4. Distribution stage: outputs for other channels (newsletter, social, sales emails) get the same style file applied. Teams that repurpose content widely already know consistency across formats is the hard part; the COPE approach of adapting one asset for many channels depends on the message staying the same while the format changes the Hannon Hill repurposing guide. A single style file is what makes the rule survive the format change.

If you are building this pipeline as tooling rather than doing it by hand, Quanta Inference gives you one API key across text, embedding and other model types through an OpenAI-compatible interface, which matters when you want to run the same audit prompt against two models and compare findings side by side Quanta Inference.

And keep the audit's scope honest. It checks rules you wrote. It does not check whether a claim is true, whether the example is real, or whether the piece respects a source. Those stay with humans, which is why every finding needs a person to accept it.