The grounded drafting loop, step by step

We have written about the Grounded-AI Pledge and the gates that enforce it. This post zooms one level out. The Pledge enforcement lives inside a four-step loop that runs on every drafted answer the product produces. The loop is small. Each step exists to catch a specific failure mode the previous step does not catch.

If you are evaluating proposal-AI software, this is the shape we think the loop has to take. We are publishing it because most of the field does not run this loop, and the difference shows up in the output.

The four steps

question  ->  retrieve  ->  draft (rewrite-only)  ->  verify  ->  emit
                  |               |                      |
                  v               v                      v
             UNGROUNDED        REFUSE              ENTAILMENT-FAILURE

Every drafted sentence the product emits has passed all three gates. Every refusal exits at the gate that caught the problem, with a structured reason a reviewer can act on.

Step 1 — Retrieve

What it does. Takes the question (an RFP item, a DDQ row, a security questionnaire row), rewrites it for retrieval if it has implicit context (more on that in Thursday’s post), runs hybrid retrieval against the customer’s KB, and returns ranked candidate blocks.

The failure mode this step prevents. Drafting from an empty corpus. The most common cause of fabricated answers in RAG systems is the model getting the question and a retrieval result that was technically returned but not actually relevant. The model then generates from training data and labels the generation with the retrieved citation. The citation looks supporting. The text is invented.

We gate on a relevance floor. If no retrieved block clears the floor, the loop exits with UNGROUNDED and the question goes to the human reviewer with the candidates that almost made it. The reviewer either adds a KB block, escalates to an SME, or accepts that this is a question the corpus cannot answer today.

The failure mode this step does not prevent. A block that retrieves with high score but contains adjacent rather than answering content. “We support SOC 2” retrieves on a question about ISO 27001 because both are framed as security certifications. Retrieval does not know the difference. The next two steps do.

Step 2 — Draft, rewrite-only

What it does. Takes the qualifying retrieved blocks and the question, calls a Claude-family model with a system prompt that instructs it to rewrite the source into an answer. Not generate. Rewrite. If the source does not contain enough information, the prompt tells the model to emit the literal string REFUSE.

The failure mode this step prevents. Generation drift. A typical “answer this question helpfully” prompt invites the model to fill gaps. Filling gaps with training data is exactly the failure we are trying to prevent. A rewrite prompt frames the task as transformation rather than authorship — the model has less license to invent because the task is to restate, not to compose.

Rewrite prompts are not magic. The model will still occasionally embellish. But the failure mode shifts from “invented a number” to “paraphrased too aggressively,” and the next step catches the embellishment.

The shape of the prompt. Stripped of safety boilerplate:

You are given a QUESTION and a SOURCE block. Rewrite the SOURCE into a
sentence or paragraph that answers the QUESTION. Do not introduce facts
that are not in the SOURCE. Preserve numbers, dates, and named entities
exactly. If the SOURCE does not contain enough information to answer
the QUESTION, respond with the literal string REFUSE.

The prompt is short on purpose. We have measured longer prompts and found that the additional instructions reduce compliance with the core constraint. Most of the work is being done by the framing of the task, not by the volume of guardrails.

Step 3 — Verify, model-independent

What it does. Takes the drafted sentence (or paragraph) and the source block. Extracts the substantive noun phrases and numeric claims from the draft. For each, asks an entailment model whether the source supports it. If any claim fails entailment, the draft is rejected.

The failure mode this step prevents. The source-attribution / claim-support gap that the Stanford HAI legal-RAG study quantified at 17 to 33 percent across commercial tools. Citing the right block does not mean the block supports the sentence. Verification is the only mechanism that closes that gap, because it is the only mechanism that asks the question directly: does this specific claim follow from this specific source.

The verifier is a smaller, cheaper model tuned for entailment. It is not the same model as the drafter. That independence matters — if the drafter and verifier are the same model with the same blind spots, they will agree on hallucinations. Two different models with two different training distributions are more likely to disagree, and disagreement is what we want at this gate.

Where the verifier struggles. Numeric tolerances (“99.9%” vs “99.94%”), tense and aspect (“we maintain” vs “we have maintained”), and compound claims that span two source blocks. We err strict on numerics — mismatch fails. We accept common paraphrase. We do not yet compose entailment across multiple blocks in production, though it is in a research branch.

Step 4 — Emit

What it does. If the draft passed retrieval, drafting, and verification, it is attached to its source pointer (block ID, version, document ID, page) and surfaced to the reviewer. The reviewer sees the drafted text and a link to the source. They can accept, edit, or reject.

The failure mode this step prevents. Drafted text that gets shipped without provenance. The pointer is mandatory. We do not emit a sentence without one. If the pipeline cannot produce a pointer, the loop exits at one of the earlier gates with a refusal — it does not produce a pointer-less sentence.

What the reviewer sees on a refusal. Three things: the question, the candidate blocks the system considered, and the reason the loop exited. “Retrieval floor not met” with the top three candidates and their scores. “Drafting refused — source did not contain answer.” “Entailment failure on the phrase ‘annual third-party audit’ — source supports periodic audit but not the annual cadence.” Refusals are structured because refusals are the most useful output the system produces — they tell the reviewer where to put their attention.

What this loop is not

It is not novel. The shape is close to standard RAG plus a verifier. The novelty, such as it is, is in the discipline: the relevance floor as a hard refusal, the rewrite-only drafting prompt, the model-independent verifier, and the absence of a path that emits text without a pointer. Each of those choices is a failure-mode-driven decision. None of them are clever.

It is also not free. The verifier adds latency and cost on every emit. We measured the marginal cost in the cost-per-response post we will publish later this week — short answer, it is small, and we would not turn it off to save the money.

What we are still working on

Multi-block entailment. The current production verifier checks each claim against a single block. A claim that is jointly supported by two blocks (one cites the certification, another cites the audit cadence) currently fails and forces the reviewer to either accept a partial answer or wait for an SME. The research branch composes evidence across blocks; we are not confident enough in the false-positive rate to ship it.

Numeric tolerance. Strict numeric matching is loud. “We support 1,000 concurrent users” against a source that says “up to 1,200” fails entailment, even though the broader claim is true. We have a calibration tool internally that lets the customer set the tolerance per question type. It is not in the public product yet.

Compound questions. A question like “describe your approach to security and your compliance certifications” is two questions. The current loop runs once. The output is one drafted paragraph that may answer one half well and the other half poorly. We are experimenting with question decomposition — split, retrieve per part, draft per part, recompose — but the recomposition step has its own verification problems.

The short version

Four steps. Each catches a failure the previous one cannot. The system refuses when any gate is not met, and the refusal carries enough structure for a human to do something useful with it. That is the entire story of grounded drafting in our product. The rest is tuning.

Next time the loop produces a refusal in your account, look at which gate caught it. The answer tells you whether you have a KB problem, a question-framing problem, or a verifier-tolerance problem — and each one has a different fix.