Field notes

Shipped: the inline verify button in drafts

Hover any drafted sentence in the proposal builder and a verify button surfaces the source block, the entailment trace, and the timestamp of the last KB update. Shipped this week.

PursuitAgent 3 min read Engineering

We shipped the inline verify button in the proposal builder this week.

Every drafted sentence in a response now has a verify affordance attached to it. Hover the sentence, a small icon appears in the right margin. Click the icon, a side panel opens with three things: the source block the sentence cites, the entailment trace from the verifier (which spans of the source the verifier matched against the noun phrases in the drafted sentence), and the last-updated timestamp of the KB block.

The lifecycle:

  1. Hover. A reviewer reading a draft hovers a sentence. The icon fades in to the right of the line. There is no UI shift; the icon sits in margin space that’s reserved for it.
  2. Click. The right side panel opens. The source block is rendered with the matched spans highlighted. The entailment trace lists each noun phrase the verifier checked, the span it matched against, and a confidence score.
  3. Approve, edit, or escalate. Three buttons at the bottom of the panel. Approve marks the sentence reviewed and clears the icon for that reviewer. Edit opens the sentence for inline edit and re-runs verification on save. Escalate opens a one-line comment thread tied to the sentence; the SME or section owner gets a notification.

Two notes worth calling out.

Verifications are cached per (sentence, block-version). If neither the sentence nor the block has changed since the last verification, the panel renders instantly from cache. If the underlying KB block has been edited since the draft was generated, the panel renders an “out of date” badge and re-runs verification on demand. This is the case the Grounded-AI Pledge cares about — a sentence cited against a block that has since been replaced or edited is exactly the failure mode the pledge is built to prevent.

Refusals show up in the same panel. If a sentence couldn’t be drafted because the retrieval floor wasn’t met or the entailment verifier rejected the candidate, the verify panel shows the refusal reason and the candidate blocks the engine considered. Reviewers see why the engine wouldn’t draft, not just an empty paragraph.

Two reviewer behaviors changed in the rollout we ran with five customers in June. First, the percentage of sentences a reviewer interacted with via verify-then-approve climbed from baseline (zero, because the affordance didn’t exist) to roughly two-thirds of substantive sentences in regulated-industry responses. Second, edit rates on drafted sentences dropped, because reviewers who confirmed the source agreed with the sentence often left it alone instead of rewriting it from feel.

We are not going to claim a number on review-time savings yet. The five-customer sample is too small and the deployment too short. We will publish a real number in the Q3 2025 state-of-product post once we have a fuller deployment behind it.

The component lives in the Proposal Builder. If you have an account, it’s already on. If you don’t, the trust page describes the verification mechanism in more detail at the Grounded-AI Pledge.

For the engineering side of how the verifier produces the entailment trace, the canonical post is How the Grounded-AI Pledge is enforced in code.

Sources

  1. 1. PursuitAgent — Proposal Builder
  2. 2. PursuitAgent Grounded-AI Pledge