When to Route a Public Draft Through a Second Model

The instinct is to re-run the same assistant that helped write the draft. That helps less than you would expect. A controlled experiment with 900 review sessions across 10 conditions, using three reviewer models, found that a top-tier reviewer from a different developer was not significantly different in F1 from the same model reviewing in a fresh session, and that the two found partly different errors, overlapping on a Jaccard score of 41.2% (the cross-model review study). The practical read: at two review calls, one cross-model review plus one fresh same-model review found more planted errors than two fresh same-model reviews, 56.7% versus 42.7%.

The same paper warns against overreading that. The advantage was not clearly separable from the fact that the cross-model reviewer was simply the stronger model, and a lightweight cross-model reviewer scored no higher than same-model review (the cross-model review study).

So the decision rule is not "always use a different vendor." It is:

A separate review of AI-assisted writing makes the same point in a different domain: AI-generated text is usually free of typos but not of factual errors, and the hardest failures are statements written with total confidence that are simply wrong (Document360). That is the class of problem a reviewer prompt has to target.

Five categories cover most public-draft incidents. Keep the list short enough that the reviewer can apply every item to every paragraph.

Inadvertent secrets. API keys, tokens, connection strings, internal hostnames, private email addresses, phone numbers, customer identifiers, screenshots with a session cookie visible. This category is about pattern matching on the surface of the text. Note that the risk cuts both ways: if you paste the draft into a third-party tool for review, you have moved the material somewhere else. Surveys of workplace AI use report that a meaningful share of prompts contain sensitive information, with customer data and employee data the largest slices (SoSafe), and privacy regulators advise assessing what personal information leaves the organization before it is entered into a generative tool at all (NSW IPC).

Internal codenames and unreleased names. Project names, internal tool names, unannounced product names, internal team names, ticket prefixes. Give the reviewer the actual list of banned strings if you have one, because a model cannot know that "Falcon" is an unreleased product unless you say so.

Unverified claims. Superlatives, comparative claims about competitors, performance numbers without a source, dates without evidence, "we are the first," quantified benefits. The reviewer should return the claim, the sentence it appears in, and what evidence would be required to support it. Whether the evidence exists is a human job.

Tone slips. Sarcasm that reads as contempt, jokes at a customer's expense, overly casual phrasing in a regulated context, blame directed at a named person or team, promises of support that the team cannot keep.

Missing context. Acronyms defined nowhere, a metric with no time period, a reference to "last quarter" with no anchor, a link whose destination is unclear, a screenshot described but not explained.

Two categories deserve a note. Trade secret law cares about whether information is generally known and whether it has value from staying unknown, and documentation plus marking is how companies demonstrate they treated something as secret (Finnegan, WIPO). Your reviewer prompt should mirror that: ask it to flag anything that looks like a formula, a cost model, a pricing method or a customer list, because those are the categories most likely to matter later. Second, if your draft is meant to be transparent in the way open startups practice it, sharing revenue, salaries or equity terms (Failory), your reviewer's job is not to remove those numbers but to confirm that the number, the period and the definition are all present.

The most common failure is a reviewer that hands back a rewritten draft. You lose the ability to see what changed, you lose the location of each problem, and you introduce new unreviewed text. Prevent it with an explicit output contract.

You are a disclosure reviewer. You do not edit, rewrite, summarize
or praise. You return findings only.

Draft: <<<DRAFT>>>

Checklist, apply every item to every paragraph:
1. Secrets: keys, tokens, connection strings, internal hostnames,
   private emails, phone numbers, customer identifiers.
2. Internal names: any of these strings, case-insensitive:
   [BANNED_TERMS]. Also flag capitalized names that look like
   unreleased products or internal projects.
3. Claims: superlatives, competitor comparisons, performance
   numbers, dates, "first" claims. For each, state what evidence
   would be needed.
4. Tone: sarcasm, blame aimed at a person or team, promises of
   support, jokes at a third party's expense.
5. Missing context: undefined acronyms, metrics with no period,
   relative time references with no anchor.

Return a table with exactly these columns:
category | quoted text (max 20 words) | paragraph number |
why it is a risk | suggested fix as an instruction, not rewritten prose

If a category has no findings, write the category name and "none".
Do not output anything outside the table.

Three design choices in that prompt matter more than the wording.

First, quote and locate. A finding without a location costs the human reviewer a search. A finding with a 20-word quote and a paragraph number takes seconds to verify.

Second, fix as instruction. "Replace the account number with a placeholder" is actionable. A rewritten sentence is a new draft that nobody reviewed.

Third, one pass, one job. Combining accuracy, structure and style in one pass risks letting accuracy issues slip through, which is why documentation reviewers are advised to separate those checks (Document360). The same logic applies here: run the disclosure pass on its own, then a separate edit pass if you want one.

There is a useful experiment on prompt style worth knowing about. A case study comparing three prompting strategies on the same artifact found that contrastive prompting, which asks the model what a correct review would catch and what a naive review would miss, surfaced 67% of the unique critical issues, while a heavily negative "do not do this" prompt found 8% (Trilogy AI). The takeaway for a disclosure reviewer is to describe what a good finding looks like, with an example, rather than pile up prohibitions. One line does the job:

A good finding looks like this:
secrets | "sk-live-4f2a...c9" | paragraph 6 | live API key |
replace with a redacted placeholder
A bad finding looks like this: "Consider reviewing the tone."

The same literature on structured prompts treats the prompt itself as a versioned artifact kept alongside the material it governs, which is the right habit for a review checklist that will be reused (Martin Fowler). Store the checklist in the repo next to the draft template and treat changes as reviewed changes.

Two operational notes. Long drafts should be chunked by section with a stable paragraph numbering scheme, because a reviewer given a 6,000-word draft starts summarizing. And empty results are a signal, not proof: a reviewer that finds nothing on a draft you know contains a placeholder is broken, so seed a test draft with deliberate violations and check that each category fires.

Treat the output as a triage queue with three lanes.

Block. A live secret, a customer identifier, an unreleased product name, a personal email or phone number, or an unverified claim about a competitor. Nothing ships until it is resolved.

Fix in place. Undefined acronyms, metrics missing a period, vague relative dates, links with no description. Fast edits, no judgment needed.

Decide. Tone calls, whether a revenue figure is appropriate to share, whether a roadmap hint gives away too much, whether a customer story needs written permission. These need a person with context.

That middle lane is where the time savings live. The mechanical items are the ones a human reviewer skims when reading for meaning, and the ones a model applies uniformly to paragraph 40 as readily as paragraph 1. The marketing and communications literature is blunt that model output should never be the only source: practitioners are advised to supplement AI findings with additional research and to keep human oversight for accuracy and ethics (PRSA).

A worked example, using round numbers for illustration. Suppose a 2,500-word launch post. A human reviewer reading for judgment takes roughly 45 minutes and catches the big issues. A disclosure pass returns 18 findings: 2 blocking, 6 fix-in-place, 10 decide. Removing the 6 mechanical items and resolving the 2 blocks takes about 15 minutes, and the human then spends 30 minutes on the 10 decisions with the mechanical noise already cleared. You have not saved the whole hour, but the human hour is now spent entirely on the part only a human can do. The arithmetic is the argument: the pass is worth it when the mechanical share of findings is large, and the share grows with draft length and with how many drafts you ship.

Aim to sample-check the reviewer periodically against a human's own list on the same draft, and count what the reviewer missed. If misses cluster in one category, rewrite that category's description before adding new categories. Documentation review guidance on alignment samples, where AI results are compared against human reviewers and discrepancies analyzed, transfers directly here (DISCO).

Here is the honest split.

Do not use a second model as the only reviewer for legal, security or reputational risk. It cannot verify a number, it cannot clear a customer quote, and it cannot weigh whether a hint about an unannounced partnership breaks an agreement. The cross-model experiment's own caveat applies with force: gains from a second reviewer were partly confounded with which reviewer was stronger, and a weaker second model added nothing (the cross-model review study). Adding an arbitrary cheap model to the loop is not a control, it is another reader.

One more boundary. Whatever you paste into the reviewer leaves your environment. If the draft contains personal information, the review step is itself a data flow, and regulators expect it to be assessed like any other (NSW IPC). If the draft contains trade secrets, confirm the retention and training terms of the tool you use before the paste, and prefer a provider whose contractual terms you have read. Where the sensitivity is high, route the reviewer through an API with a business agreement rather than a consumer chat window; Quanta Inference puts text, image, audio and embedding models behind one API key with prepaid pricing in US dollars, which keeps the review step inside a single billing and access boundary (Quanta Inference).

When you first stand this up, write the checklist against three past drafts whose problems you already know, tune until each category fires on the right paragraphs, then start running it on live drafts. If you want help designing the review step for a specific publishing cadence, a free 30-minute discovery call is the shortest path (Quanta Consulting).