A Citation Shows Where to Look. A Check Says Whether It Holds.

What a review team needs before anyone signs an AI-drafted answer

A reviewer who sees a footnote on every AI-drafted sentence tends to read less carefully, not more. The footnote looks like the checking has already happened. Usually it hasn't. A footnote records where the writer took its material from. It says nothing about whether the sentence above it says what that source says.

This post is about the gap between those two things, and about what a proposal team should ask for at review time so that an AI draft goes to pink team as an input and doesn't take the place of the review.

1. The terms, once

• The writer is the AI model that drafts an answer from your own documents.
• Evidence is one of those documents: a certificate, a policy, a past-performance record.
• A claim is one checkable statement inside a draft. A five-sentence answer usually holds four or five.
• A citation is the writer's own record of which piece of evidence a claim came from.
• The checker is a separate AI model that reads each claim beside the evidence it cites and returns one of four verdicts: supported, partly supported, not supported or can't tell.
• A flagged claim is any claim the checker did not mark supported.
• The approver is the named person who signs off the text as the company's answer.

Proposal teams review a bid in stages, each named after a colour. The names vary from shop to shop; in this post:

• A colour team is any one of those staged reviews.
• Pink team is an early review of the first draft: is the approach right, and does it answer what was asked?
• Red team is a review of a near-final draft, read the way the buyer's evaluators will score it.
• Gold team is the last review before submission, where a senior person signs off the bid.

Everything below uses these words and only these.

2. Three things that look alike and are not

A citation is a pointer. It is useful, and it is the minimum, but it puts all the checking work back on the reviewer, one footnote at a time. Under deadline, that work doesn't happen for every footnote.

A score for the whole answer is a warning light. It can tell a reviewer which answers to read first. It cannot tell them which of the five claims caused the low score. And a high score on an answer with one overstated sentence reads as "fine".

A verdict per claim is the only one of the three that points at a sentence and says this one. It is also the only one that can be wrong in a way you can inspect, because the evidence is right next to the claim and a person can disagree with it.

3. What overreach looks like in practice

The dangerous sentence is rarely invented from nothing. It usually says a little more than the evidence does.

EXAMPLE 1

Question (a security questionnaire): "Do you train AI models on customer data?"

What the evidence supports: a statement that the company does not train models on customer data, and a description of how requests are routed only to providers that neither keep the data nor train on it.

The draft adds: "Evaluators can audit the complete record of which data was sent to which model provider."

The checker says: not supported. No document describes such a record. The sentence sounds like a natural extension of the policy, which is why a reviewer reading at speed would pass it.

What the system does: highlights the sentence in the draft. Approval waits until a person edits it, removes it, or accepts it with a note saying why.

That example comes from our own test run against a made-up questionnaire, using our real answer library. In a security questionnaire, approved text becomes a representation the company can be held to. One overstated sentence there is a contract problem as well as a writing problem.

The second example goes wrong in the opposite direction. The writer tells the truth about a gap, but in the wrong place.

EXAMPLE 2

Question (the same questionnaire): "Describe your process for deleting customer data, including data held by subprocessors."

What the evidence supports: how deleted data leaves the company's own systems and backups, and within how many days. No document covers the subprocessors' side.

The draft adds, as its last sentence: "The provided evidence does not address deletion procedures for data held by subprocessors beyond the primary backup window."

What goes wrong: the sentence is true, and it is the right thing to tell the reviewer. But it is in the answer, so the buyer reads it too. To a buyer it says the vendor has no deletion process for subprocessors, which is not what anyone meant.

What the system does: moves the sentence out of the answer into a box beside the draft headed "What the evidence does not cover". Approval waits until the approver confirms they have read it. They then decide what to do: find the missing document, or have someone who knows the answer write it.

Why not just reword the gap into the company's voice? Because "subprocessor data outside the backup window is not covered" turns we have no document about this into we don't do this. That is a new claim, and nothing supports it. A note about missing evidence is for the reviewer. It belongs beside the draft, not inside it.

4. Noticing is not deciding

A checker can find the overstated sentence in Example 1 and still change nothing. If the verdicts sit in a separate report that runs only when someone clicks a button, and approval doesn't look at them, then the system noticed and nobody decided. A reviewer who never opens the report, or skims it, approves the sentence.

So the useful question for any AI drafting tool isn't whether it can check claims. It is what happens to approval when a claim is flagged. There are four answers in common use:

1. Nothing. The verdicts are informational.
2. A warning. The approver sees a banner and can click past it.
3. A count. The approver sees "3 claims flagged" with no record of what was done about them.
4. A gate. Approval is refused until each flagged claim has a recorded human decision.

Only the fourth leaves something an auditor, a customer's security reviewer or your own red team can read afterwards.

5. What a claim-review gate should do

These are the rules we built to, written so that a team can hold any tool to them, including ours.

Check every draft, without being asked. If the check runs only on request, the drafts most likely to be wrong are the ones nobody asked about. Every new version of a draft should be checked as it is created, including versions a person edited by hand, since people overstate too.

Show the verdict on the sentence. Highlight the flagged claim in the draft text, not in a list on another tab. A reviewer reads the answer. The verdict has to be where the reading happens.

Give each flagged claim three ways out, and only three:

• Edit the sentence so the evidence supports it.
• Remove the sentence.
• Accept it as written, with a short note saying why. For example: "true; the insurance certificate covers it but isn't in the library yet."

Editing or removing creates a new version of the draft, and the new version is checked again. Accepting leaves the sentence in place and records who accepted it, when, and what they wrote.

Refuse approval while anything is open. Approval waits while the check is still running, while it has failed, or while any flagged claim has no decision. The refusal should name the reason: "checking", "check failed, run it again", or "3 claims need review".

Keep the decision human. An AI agent may read the verdicts and the decisions. It must not record an "accept". If an agent can ask for approval, it must hit the same refusal a person would. A rule that software can route around is a suggestion, not a rule.

Move evidence-gap notes out of the answer. Statements about what the evidence doesn't cover go into a separate box beside the draft, never into the text the buyer receives. The approver confirms they have read them before approving.

Record it with the approval. When the draft is approved, the record should say how many flagged claims were accepted and that the gap notes were read. "Approved with 2 accepted claims," with the two notes, is a sentence a reviewer can defend later. "Approved" on its own is not.

6. Where this sits in your review cycle

None of this replaces a colour team. It changes what the colour team spends its time on.

Without per-claim verdicts, a pink team reading an AI draft is doing two jobs at once: checking whether each statement is true to the evidence, and judging whether the answer is compliant, persuasive and on-theme. The first job is slow, repetitive and easy to skip under deadline. The second is the one a pink team exists for.

With a gate, the first job arrives already sorted. The supported claims carry their evidence. The flagged ones are marked, each with a decision recorded or still open. The pink team can test the decisions, especially the accepted ones, because each has a note to argue with. The red team can read the record and see which statements the company chose to stand behind on someone's word rather than on a document.

An AI draft that has passed the gate is still an input to review, not the output of one.

7. What a gate does not do

It doesn't make the checker right. The checker is a model and it can be wrong in both directions: it can flag a true sentence, and it can pass one that overreaches. The gate makes its errors visible and correctable. It doesn't remove them. Ask how often the checker agrees with a person, on how many cases. To date, our own figure comes from a small, hand-labelled test set, not from customer work. We plan to measure it on real bids with our design partners, with their consent, and to publish what we find. That includes what share of flags reviewers accept, edit or remove.

It doesn't decide whether the evidence is current. The checker asks whether the evidence says what the claim says, not whether the evidence is still valid. In BidAngel that is handled before the writer starts. A document past the expiry date someone recorded on it is never used for drafting. A document older than the workspace's age limit for that kind of document is marked stale and left out, unless a team chooses to allow stale documents for one bid. A document with no expiry date that is still inside its age limit can be cited, so it is worth recording expiry dates on certificates.

It adds work. Someone has to read every flagged claim. "Partly supported" is the verdict most likely to be noise. For now every partly supported claim is flagged, in every workspace. Once design-partner reviews show how often reviewers accept those flags unchanged, we will decide whether that verdict should still hold up approval. A team that finds itself accepting nearly every flag has learned something about either its checker or its evidence library, and both are worth knowing.

8. Questions for your review team

Ask these of any AI drafting tool before its output reaches a colour team, ours included:

1. When a claim is flagged, can the draft still be approved? If yes, the check is advice.
2. Is every draft checked, or only the ones someone asks about?
3. Is the verdict on the sentence, or in a separate report?
4. When someone accepts a flagged claim, is their name and reason recorded with the approval?
5. Can an AI agent approve, or accept a flag, where a person would be stopped?
6. Where do notes about missing evidence go: beside the answer, or inside it?

A tool that answers all six well hasn't proved its drafts are right. It has made it possible for your team to show who decided, sentence by sentence, and why.