Claim Annotation & Reference Discovery, Explained

Updated 2026-07-13 · markdown version

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