How to Catch an Agent Inventing a Number from the Wrong Source

You cannot check a number against a source you have not modeled. The first artifact is a table, not a prompt. For each metric the agent is allowed to report, record where the authoritative figure lives, which period it covers, what unit it is in, and how the source defines it.

Most documents you would feed an agent already have a natural key structure. Investor updates, for instance, are supposed to report cash, burn and runway at the top, with a single headline key performance indicator tracked in every issue (Carta's investor update guide). That structure gives you exactly the fields you need.

A worked example, kept deliberately small:

The definition column is doing more work than it looks. A cash figure can mean the gross bank balance or the true usable liquidity once fixed deposits securing credit lines are removed, and updates that blur the two erode trust faster than a missed target (raisemoney.ventures on monthly updates). If your table does not pin the definition, the agent can be wrong while quoting a real number.

How you store the metric definition over time is a design decision, not an afterthought. If the definition of "net burn" changes in the source document, you need the version that was in force when the figure was published. That is a slowly changing dimension problem, and the standard options are well catalogued: Type 1 overwrites in place and loses history, while Type 2 keeps a new row per change with effective dates (datawarehouseinfo.com on SCD strategies). For metrics that get quoted in board materials, use Type 2 on the definition attribute.

-- Source-of-truth table with Type 2 history on the definition
CREATE TABLE metric_registry (
  metric_key      TEXT NOT NULL,
  period_start    DATE NOT NULL,
  period_end      DATE NOT NULL,
  unit            TEXT NOT NULL,      -- 'USD', 'USD_thousands', 'percent'
  definition      TEXT NOT NULL,
  source_doc_id   TEXT NOT NULL,
  effective_from  DATE NOT NULL,
  effective_to    DATE,               -- NULL means current
  PRIMARY KEY (metric_key, effective_from)
);

A claim like "cash was 1.4 million (see Q3 update)" gives a reviewer nothing to automate. The fix is a schema: every number in an agent response must arrive with the document identifier, the period, the unit and the verbatim sentence it was taken from.

This is the practical version of the finding that attribution needs to be short. Current systems often cite whole documents, which forces the reader to read the entire text to verify a single claim, making fact-checking impractical (Batista, Vatai and Wahib). Sentence-level attribution is the smallest unit that is still checkable by machine.

Return ONLY JSON. Every numeric claim must include all fields.
{
  "metric_key": "cash_balance",
  "value": 1.4,
  "unit": "USD_millions",
  "period_start": "2026-07-01",
  "period_end": "2026-07-31",
  "source_doc_id": "investor-update-2026-08",
  "source_quote": "Cash in bank at month end was $1.4M",
  "source_locator": "section: Cash and runway, paragraph 1"
}
If you cannot supply source_doc_id and source_quote from the provided
documents, set value to null and explain what is missing.

Three details in that prompt do the heavy lifting. source_quote must be verbatim, so a reviewer can search for it. source_locator narrows the check to a section rather than a 40-page file. And the null instruction gives the model a legal way out, which matters because an agent asked for a figure it does not have will produce one rather than admit the gap.

Enforce the schema at the boundary. If a response parses but a required field is missing, reject it and re-ask once before falling back to a human. A validation layer that refuses malformed attributions is cheaper than a review meeting.

Now the actual catch. For each claim, run three checks in order, cheapest first.

Check one, existence. Search the full text of the cited document for the claimed value in the format it appears in the source. Normalize first: strip currency symbols, thousands separators and trailing zeros, and search for the numeric token as well as the formatted string. A value that appears nowhere in the cited document is a hard fail, no judgment required.

Check two, period and unit. Pull the period label and unit from the stored document metadata and compare to the claim. A figure of 610 thousand is not wrong because it is wrong; it is wrong because it belongs to the prior quarter. Unit mismatches are the most common false alarm in manual review, so normalize both sides to a base unit before comparing.

Check three, the quote. Confirm the source_quote string appears in the document at or near the locator. This catches the subtle case where the number is real, the document is real, and the sentence says something else entirely.

Two practical guardrails. Fetch the source through the same pipeline the agent used, not a live URL, so a page that has changed since ingestion does not masquerade as an agent error. And record every check result alongside the claim, so a reviewer sees "not found in cited source" rather than having to rediscover it.

Beware the near-miss that looks like a bug and is not. In payments data, Stripe's payments count and its balance transaction count differ for perfectly healthy reasons, because a balance transaction is created for every movement of money, including payouts, refunds and disputes, not only customer charges (acodei on why counts differ). If your source table does not say which count is authoritative for "number of transactions," the agent can cite a real figure from the wrong report and your check will correctly flag it. The fix is in the table, not the agent.

Not every mismatch deserves the same response. Triage by severity, and write the rules down so two reviewers reach the same verdict.

Two rules make this rubric stick. First, a Fail is never downgraded to a Warning without a written reason, because the most expensive errors are the ones someone decided were fine. Second, track the rate of each verdict per metric. A metric with a rising unsupported rate is usually a retrieval problem, meaning the right document is not being retrieved, not a model problem.

Measure the checker itself, too. Sample 20 passing claims a week and have a person verify them by hand. If your checker passes things a human rejects, the existence and quote checks are too loose.

The same discipline applies beyond finance. Any agent that reports figures from a document set, whether contracts, clinical literature or competitor filings, needs a registry, a schema and a comparator. The citation tools that exist for drafting help spot passages that need support and format references, but they do not confirm that the cited source contains the specific number (Grammarly's Citation Finder). Confirmation is the step you build.

If you are validating accuracy at the document level rather than the number level, natural-language-inference scoring of claim against source is a reasonable extension of the same idea, and the method is documented in full with an implementation (Brenndoerfer).

For teams that would rather run the whole pipeline on one key than wire up separate providers for text, embeddings and reranking, Quanta Inference exposes text, image, video, audio and embedding models through a single OpenAI-compatible API, which keeps the retrieval and checking steps in one place.