How to build a proof library
Guide · Frameworks · 4 min read · last verified 2026-07-27
A proof library is a single maintained place where every claim a company makes in public sits next to the evidence that backs it: the artifact itself, the date it was captured, the person responsible for keeping it true, and an honest grade of its strength. It is the difference between a company that can defend its claims and a company that once could.
The library operationalizes two exercises this site covers separately. What is a proof point establishes the unit — a claim bound to checkable evidence — and How to audit your own claims describes the sweep that inventories every published claim and grades its backing. The library is what makes that audit a system instead of an annual act of heroism. Without it, every audit starts from zero, every finding decays, and the same unproven sentences drift back onto the homepage between sweeps.
The entry: five fields, no more
Each entry is one claim-to-proof pairing with five fields. The claim, in its exact published wording, with a note of everywhere it appears. The artifact — the evidence itself or a durable link to it: the named customer quote, the public benchmark reading, the documentation page, the third-party write-up. The capture date, because evidence is only ever true as of a moment. The owner, a named person and never a team. And the grade, an honest rating of how much weight the claim can bear.
Resist the urge to add fields. A schema anyone can complete in a minute will be completed; a schema that demands ten minutes tends to be admired and abandoned. Sophistication may be the most common way proof libraries die, and it usually arrives disguised as improvement.
Seed it from an audit, not from scratch
Do not build the library by imagining what should be in it; build it from what the audit found. The audit's inventory becomes the initial catalog: claims graded provable enter with their artifacts attached, claims graded provable-with-work enter with an empty artifact field and a deadline, and claims marked for retirement enter a separate retired section — kept, not deleted, because a record of what the company stopped saying and why is protection against saying it again.
Seeding this way has a second benefit: the library opens with its gaps visible. An empty artifact field with an owner and a date is a work queue, and a work queue is harder to ignore than a vague intention to back things up better.
Refresh rules: evidence ages
Every artifact was true as of its capture date, and some drift afterward. The customer quote from a champion who has since left, the reading taken before a product change, the screenshot of an interface two redesigns old — each was honest when filed. The refresh rule attaches to the artifact type: fast-moving evidence gets short review windows, durable evidence gets longer ones, and the capture date makes staleness visible instead of debatable.
Refreshing means re-verifying, and re-verification has two honest outcomes: the artifact holds, or the grade drops. A downgrade is not a failure of the library — it is the library working. The failure is the claim that keeps its grade because nobody looked.
Retirement rules: how a claim leaves
A claim retires when its proof cannot be refreshed, when the product changed underneath it, or when the customer behind its evidence withdrew, churned, or disappeared from public view. What makes retirement operational is propagation: because each entry records where the claim appears, retiring it generates the edit list — the pages, the deck slides, the templates that now need changing. Claims are cheap to publish and usually expensive to retract; the library is what makes retraction routine instead of crisis.
How writers and reps pull from it
The library earns its maintenance cost at the moment of use. Writers draft against it: any claim already in the library arrives with its source attached, and any new claim triggers the one governance rule worth enforcing — no new public claim without a new entry. That single rule keeps the library current as a side effect of publishing rather than as a separate chore.
Sales pulls from it under time pressure. The sourced answer and the matching customer story that belong in a first follow-up — the artifact list in What to send a prospect after the first call — are retrievals from a good library, not research projects. Account teams assemble the bought-versus-got evidence for a renewal brief the same way. When the library is missing, each of these documents gets rebuilt from memory, per deal, by whoever has the least time to do it carefully.
A library decays without a librarian
Every long-lived proof library has one named owner — not a committee, not a rotating duty. The owner runs the review windows, chases empty artifact fields, and holds the no-entry-no-claim line when a launch deadline argues for an exception. Keeping public claims tied to dated, checkable proof is the posture Magrios assumes across a company's entire market presence; the proof library is the in-house expression of the same discipline, and it stands or falls on whether someone actually keeps it.
The test of the whole system is quiet: when a buyer, a new hire, or an auditor asks about any public sentence, the answer is a lookup, not a scramble.