# Claim Annotation & Reference Discovery, Explained

> What claims annotation (annotated references, referenced copy) actually involves in pharma promotional work — the page/column/paragraph locator format, why automation kept failing at it, and how evidence-linked writing changes the workflow.

> **Claim annotation** is the practice of marking every claim in a pharmaceutical deliverable with a human-readable pointer to the exact passage that substantiates it — typically *source / page / column / paragraph / lines*, e.g. `Pasieka 2020/pg3/col1/para2/lines2–6`. US teams call the output **annotated references**; UK teams call it **referenced copy**. It exists because reviewers and vault operators must *verify* claims, not trust them — and a citation to a 14-page paper is not verification.

## What the annotation actually looks like

Real annotations from working medical writers follow a compact grammar:

- `Mannstadt 2017/pg 3/col1/Figure1 description` — a figure caption as evidence
- `Astor 2016/pg3049/Table3` — a table, by the paper's own label
- `CLTX-305 Protocol V1.0/pg15/col1/Study Design/para1/lines1–4` — unpublished sources use title + version, and named sections stand in for columns
- Multiple sources stack in a single annotation; some carry **derivation math** showing how a claimed number was computed from source numbers (e.g., "Nonsurgical (152) − idiopathic (67) = 85; 85/522 ≈ 16%")

The defining property: the locator is **human-visual**. Page, column, paragraph, and line numbers refer to the printed page as a person reads it — not to a text extraction's reflowed output.

## Why software kept failing at this

Writers have tried automating annotation for years, and the failure mode is always the same: **the computer's view of a document differs from the human's**. PDF text extraction loses columns, merges paragraphs, and has no concept of printed line breaks — so generated locators point somewhere subtly wrong, and a subtly wrong locator is worse than none: it burns the reviewer's trust *and* their time. Any tool claiming to automate annotation should be interrogated on exactly this: *how does it count what a human counts?*

The honest state of the art is hybrid: layout-aware document parsing gets page/column/paragraph mechanically right most of the time; the writer verifies and corrects; line-level precision comes from a human eye (or a vision model reading the rendered page — which is where this is heading). This is precisely how we built annotation in [Claims](/): locators are generated from the parsed layout at the moment a claim is linked to its evidence, shown as an editable, copyable chip — auto-generated, writer-verified, never hallucinated. Where confidence is low (line numbers), the tool deliberately says less rather than guessing.

## Reference discovery: the other half

Annotation presumes you've *found* the substantiating passage. In practice, reference discovery — locating which paper, which page, which paragraph supports a claim — consumes as much time as the annotation itself, especially across a project's shared reference pack. The emerging workflow inverts it:

1. **Parse references once** into selectable evidence blocks (headings, passages, tables)
2. **Write claims against evidence**, not before it — select the passage, then the claim is born already-linked
3. **Reuse via the claims matrix** — a claim used in a new deliverable carries its annotation with it
4. **Verify continuously** — if claim text drifts from its linked evidence, something flags it before review does

Under this model annotation stops being a separate documentation chore performed after writing and becomes a *byproduct of writing itself* — which is the only version of "automated annotation" that has ever actually held up.

## Practical standards, whatever tool you use

- Adopt one locator grammar team-wide and put it in the style guide (`Source Year/pgN/colN/paraN/linesN–M`)
- Annotate to the finest granularity you can *verify* — a right paragraph beats a guessed line range
- Keep annotations with the claim (matrix/library), not only in the deliverable — they're reusable assets
- Label derived numbers with their arithmetic; reviewers check math you don't show

---
Source: https://medcom.claims/resources/claim-annotation-explained/ · Updated 2026-07-13 · © Mantir, Inc.