Magrios / Knowledge / Frameworks / How to build a proof library

How to build a proof library

Guide · Frameworks · 4 min read · last verified 2026-07-27

Reviewed before publication Editorial board Independent commercial review
In shortOne place where every public claim's proof lives — artifact, capture date, owner, strength grade — with refresh and retirement rules that make the claims audit repeatable instead of heroic.

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.

Frequently asked questions

What tool should a proof library live in?

Whatever the team already opens every day. A five-column spreadsheet that gets maintained outperforms a dedicated system nobody visits, because the library's value is retrieval speed at the moment of writing or selling, not the elegance of its container.

How is a proof library different from a claims audit?

The audit is a sweep — a one-time inventory and grading of every published claim. The library is the standing system the audit seeds: it holds the results, keeps them current through refresh rules, and absorbs new claims as they are published, so the next audit is a review rather than a rebuild.

Who should own the proof library?

One named person, typically in marketing operations or product marketing. Ownership by committee tends to mean ownership by no one, and the library's failure mode is not a dramatic collapse but a slow drift into staleness that nobody was responsible for noticing.

How often should entries be refreshed?

By artifact age and type rather than a uniform calendar. Evidence tied to people and product surfaces tends to drift quickly and deserves short review windows; methodology pages and published third-party material tend to hold longer. The capture date on each entry is what makes the judgment checkable.

Further reading — chosen for this article
Entities in this research
Magriosproof libraryevidenceclaimsoperations
Related knowledge

How to hand off marketing to a new leader · linked

How to run a positioning sprint · shared entities

How to build an annual marketing plan from evidence · shared entities

How to tier your research sources · shared entities

Recently updated

When does a fractional CMO make sense · 2026-07-27

When to change a locked question set · 2026-07-27

What is CAC payback period · 2026-07-27

The honest guide to intent data · 2026-07-27

Where does your brand stand?
Check your AI visibility free — real evidence, not a score.
Check my visibility or run the full analysis →