The Living Proof Standard

In short

Most data journalism asks readers to trust a methods note they cannot test. A Living Proof story hands over the working. Every claim says what it stands on. Every computed number is calculated by code from one fingerprinted, archived file, and the reader’s own device can calculate it again. Every sourced number links to the document it came from. The conclusion is tested in public, including where it fails. And the story keeps reporting after it is published.

This page is the full standard. The words must, must not, should, should not and may are used in their plain sense: must and must not are requirements, should and should not are strongly expected unless there is a stated reason, and may is optional.

Scope. The standard applies to stories whose main finding is calculated from data that can be published. It sets rules for showing the working; it does not decide what is newsworthy, and it does not replace editorial judgement or legal review.

Terms. The edition is the one frozen data file a story is calculated from. A row or country record is one trial in one country, so a trial with sites in three countries is three rows. The as-of date is the date the engine treats as “today” when it calculates. A fingerprint (SHA-256) is a 64-character code calculated from every byte of a file; it changes completely if a single byte changes. A DOI is a permanent identifier for an archived copy. A story may carry the Living Proof name only while it meets every must, or states in its edition record which requirement it does not yet meet and why (see Conformance). A story that breaks a must without saying so loses the name until it is fixed.

The standard adds to the codes journalists already follow. It does not replace them. We apply the ordinary principles of accuracy, fairness and the separation of fact and comment.

A methods box says “trust our process”. Living Proof says “here is the process, run it”.

The five promises

1. Every claim says what it stands on. Each claim is marked Computed, Sourced, Said or Our reading. Analysis is never dressed as fact.
2. Every computed number can be re-run by the reader. The data, the code and an archived, fingerprinted copy of the data are public, and the reader’s own device does the arithmetic.
3. The conclusion is attacked in public. We publish the other ways we tried to count, including any where the finding does not hold, and what would change our mind.
4. The story stays alive. It shows its age and reports what has changed since publication.
5. Every change is visible. Corrections show the old and the new value, the date and the reason.

1. Claims: four kinds of evidence

Every factual statement in the story must be one of four kinds, and the reader must be able to see which.

Rules

• No computed number may be typed by hand. Every number in the text that comes from the edition, including one inside an Our reading passage, a caption or a limitation, must be written in by code and marked Computed, so the check covers it. Approximate words such as “about a fifth” must be produced by a stated rule from a computed value.
• A number taken from a document is marked Sourced and links to that document; it cannot be re-run. Dates, edition numbers and counts of our own process (for example “six other ways of counting”) are exempt.
• A sourced fact should come from a primary source: the regulator, registry, official report or the organisation itself. News reports are leads, not proof.
• A quotation must be verbatim and come from a published, linked source or from our own on-the-record interview, with its date.
• The story must count its own evidence at the top: how many Computed, Sourced, Said and Our reading claims it stands on.
• Readers should be able to switch on highlighting that colours every claim in the text by its kind.

Technical: how claims are marked

Each claim is an inline element carrying its kind and an identifier that points into the story’s proof record. The proof record is JSON embedded in the story page (<script type="application/json" id="tp-proofs">), so it travels with the text. These are the real forms used in Living Proof No. 1, shortened only where marked with “…”.

<span role="button" tabindex="0" class="pf pf-c" data-proof="p3" aria-expanded="false">11.8</span>   computed
<span role="button" tabindex="0" class="pf pf-s" data-proof="p6" aria-expanded="false">213 days</span>   sourced
<span role="button" tabindex="0" class="pf pf-q" data-proof="p28" aria-expanded="false">…</span>   said
<span class="ev-r"><span class="ev-rl">Our reading</span> …</span>   reading

"p3": { "n": 3, "kind": "c", "value": "11.8",
        "label": "Trials of medicines (phase 1 to 4) started per million people a year, Ireland 2021 to 2025",
        "path": "story.drugPm.Ireland",
        "formula": "Trials started 2021 to 2025 that carry a phase 1, 2, 3 or 4 label ÷ 5 years ÷ 5.44 million people",
        "source": "ClinicalTrials.gov registry, pulled 27 October 2026; Eurostat population, 1 January 2025" }

The path tells the engine which value to recalculate. A sourced record carries doc, publisher, date, checked, link, says and any caveat instead. A formal schema for the record is planned (see What comes next).

2. The edition: one file, fingerprinted and archived

Every computed number in a story must come from one frozen data file, the edition. This is what makes the story re-runnable: the reader checks the same bytes we used.

• The edition, or its manifest or edition record, must record when the data was pulled (the as-of date) and the source of each part, with a link.
• Its SHA-256 fingerprint must be published in a manifest beside it.
• It must be archived in a public repository with a persistent identifier (we use Zenodo DOIs), so it outlives our website, and the archive record must print the same SHA-256 fingerprint.
• It should be small enough to download in a browser. Ours is 5.2 MB (about 0.9 MB compressed) for 47,265 country records: one row per trial per country. If the full data is larger, the edition holds the extract the story uses, and the extract code is published.
• Personal data must not be included. Registry records about organisations are fine; names of private individuals are not.
• A licence and attribution file must be published beside the edition and in the archive. The fingerprinted file itself is never edited after it is published.

verify_manifest.json
{ "edition": "2026-q4", "file": "trials_rows.json",
  "sha256": "ea25dd908cfa79d84ca9fb0afc4f8675c20842cc37d53b837789224704783137",
  "bytes": 5168348, "asOf": "2026-10-28",
  "rows": { "Ireland": 1439, "Denmark": 6410, … }, "total": 47265 }

3. The engine: the reader’s device does the arithmetic

The engine is the code that recalculates every published number. We keep two implementations and test them against each other: the production script that makes the edition, and a browser engine, a line-for-line port of it, that runs on the reader’s device.

1. Download The reader presses “Run the check”. The browser downloads the edition file from our site.
2. Fingerprint The browser computes the file’s SHA-256 using its built-in Web Crypto function and compares it with the fingerprint published in the story and its manifest. The archive record prints the same fingerprint, so anyone can confirm the archived copy is the same file.
3. Recalculate The engine recomputes every indicator from the raw rows, with the as-of date fixed to the edition date, so “today” never shifts the answer.
4. Compare Each recalculated value is compared with the value the story was written from (the edition results and the story’s proof record), and the page reports the result, for example “every number matches, file matches the published fingerprint”. Before publication, a build step also confirms that the number printed in each mark equals the engine’s result.

Rules

• The engine must be deterministic: the same file gives the same numbers every time, on any device.
• It must be plain, readable code, published under an open licence. No AI model may sit between the reader and the number.
• The browser version and the production version must give identical results. Ours are two files kept line-for-line in step; before publishing we run the browser engine in Node.js on the edition file and the build stops if any number differs.
• The check itself must not send any data about the reader or their result to us or anyone else. It only downloads the edition file, which our server logs like any other request.
• Rounding rules must be stated and applied the same way in the story and in the check.
• A mismatch must be shown plainly, never hidden. A mismatch is treated as a possible error and investigated.

What we use

• One JavaScript file for the browser engine (about 11 KB), which runs unchanged in the browser and in Node.js, under the EUPL-1.2 open licence.
• A render script that reads the edition, writes every computed number into the story HTML and the proof record, then loads the browser engine and stops with an error if any marked number differs from it.
• An extract script with its own self-test, which runs the browser engine on the edition file and stops if any edition number differs from the production results.
• No framework and no paid service. The story page adds two scripts of its own: the engine (about 11 KB) and the page script (about 25 KB). The site around the story runs analytics only as described in our privacy notice.

What a check proves, and what it does not

When the check reports that every number matches, it shows three things: the file you downloaded is the edition we used, the code turns that file into the numbers we printed, and the stress tests give the results we reported.

It does not show that we asked the right question, chose the right comparison, or that the source data is complete and correct. Those are judgements, and the story exposes them in other ways: the stress test, the stated limits, what would change our mind, the right of reply and the corrections log. A matching check is evidence that the arithmetic is honest, not proof that the story is true.

4. The stress test and “what would change our mind”

A finding that holds only one way of counting is not a finding. Before the numbers are run, the reporter writes down:

• the claim they expect to make;
• the main way of counting, and why;
• at least six other reasonable ways of counting: other years, other comparison groups, per person versus total, including or excluding edge cases, other data definitions;
• what result would change their mind.

The story must publish all the tests that were run, in a table, with a plain “holds” or “does not hold” for each. If a test fails, the story must show it and explain what it means.

• The plan should be fixed before the analysis, for example by archiving it or committing it to a public repository, and published with the story with its date.
• If the plan was not written first, the story must say so plainly. If anyone saw any result before the plan was dated, the plan must say what was seen and when, and the story must repeat it.
• Tests added after the plan, or after the results were known, must be marked as added later in the stress-test table, with the date.

5. The live layer: the story keeps reporting

A Living Proof story runs on two lanes. The frozen lane is the edition: every published number comes from it, and it never changes. The live lane reports what has happened since.

• Live figures must be labelled provisional and kept visibly separate from the checked edition numbers.
• Live data from other sites should be fetched only when the reader asks for it, and the page must say which sites it contacts.
• The story must show its own age: when the edition was pulled and when it was published.
• Live data should come from official sources directly, or from our open data engine, Airmid Éireann, which re-collects public registries every week.
• When live data changes the picture enough, we publish a new checked edition with a new fingerprint and archive record. Earlier editions stay available.

6. Fairness and the right of reply

• Any organisation whose performance the story judges must be offered a right of reply before publication, in writing, with the specific findings, a link to the data and a deadline at least five working days later. The story must say when the findings were sent and what the deadline was. A late reply is added with its date.
• Replies must be published in full or fairly summarised with a link. If no reply arrives, the story says so.
• The publishing system should refuse to build the final story while any reply is still marked as pending. Ours does.
• Living Proof stories are about systems and public data. They should not single out private individuals.

7. Corrections and the edition record

Every story must carry an edition record at the end: the fingerprint, the archive identifier, the as-of date, the date of each change, and how AI was used. Each correction must show the old value, the new value, the date and the reason, both in the story and on our corrections page. Readers can report errors to info@priyalifescience.com.

• If a correction changes the headline finding, the headline must change too, and the change must be stated at the top of the story.
• If a story can no longer meet a must and the fault cannot be fixed, it must drop the Living Proof name and say why in its edition record.

8. AI

The rule is simple: there is no AI between the reader and the number.

• AI tools may help find documents, draft summaries of them, write and test code, draft text that an editor rewrites, and act as one extra reviewer, never the only one.
• An AI model must not produce any number. Every computed number is calculated by code.
• A quotation must not be generated or altered by AI. Charts and data graphics must be drawn by code from the edition.
• An AI-generated image may illustrate a page, but it must be labelled as AI-generated where it appears, must not show real people or invented data, and must never be presented as a photograph of a real scene. Photographs carry their credit and licence.
• A human editor must review, verify and approve every edition before publication, and the edition record must state how AI was used for that story, naming the tools and the steps they were used for.

9. Privacy

• The edition must not include personal data about private individuals.
• The check must not send anything about the reader or their result anywhere. It only downloads.
• Any call the page makes to another site (a live registry, an open data catalogue) must be listed in the publisher’s privacy notice and, where possible, made only when the reader asks.
• Site analytics must follow the publisher’s published privacy notice and consent choices.

Accessibility

• Living Proof pages should meet WCAG 2.2 Level AA and must be tested with an automated checker and by keyboard before publication.
• Every interactive part (proof notes, the check, the live layer) must work with a keyboard and a screen reader, and every chart must have a text alternative.

10. Independence, funding and interests

• Funders, advertisers and clients must not see a story before publication or influence its question, method or conclusion.
• If an organisation judged in the story is a funder, advertiser or client of the publisher, the story must say so.
• The publisher’s ownership must be stated on its About page, and its main sources of income should be.
• Where a source has an interest in the finding (for example an industry body quoting its own figures), the proof note must say so.

11. Conformance

Each story’s edition record carries a conformance statement. It names the version of this standard the story follows and lists any must or should it does not yet meet, with the reason. The approving editor signs it off. Anyone may challenge a statement by writing to info@priyalifescience.com; we answer on the corrections page.

Stories built before this standard. Living Proof No. 1 was built before version 1.0 was written. Its edition record lists what it does not yet meet: it had no plan dated before the analysis, and its trial-level file is being added to the archive.

How it compares with existing codes

Living Proof sits on top of established journalism codes. This table shows what it adds.

Quoted from the Press Council of Ireland Code of Practice and the IFCN Code of Principles, read on 8 November 2026. Mentioning these codes does not mean Priya Life Science is a member or signatory of either body.

What we build on

Others have pushed data journalism towards openness, and we credit them: Proof News’s “ingredients label”, newsrooms that publish their code and data, Tomas Petricek’s The Gamma project (from 2015), which let readers see and change the code behind a chart, the data journalist S Anand’s proposed “Verify” button (May 2026), and the Data2Story research on AI agents that link claims to data (June 2026). Living Proof combines four things we have not seen together in one published story: recalculation on the reader’s device, typed evidence for every claim, a public stress test, and a live layer after publication.

Build it in your newsroom: a step-by-step guide

Living Proof was built by a small independent publisher, without a data team or a paid platform. A newsroom of any size can do the same, and later stories reuse the engine.

What you need

• People: one reporter who can write simple code (or a reporter and a developer), and one editor who did not do the analysis.
• Data: a public, licensed data source with stable identifiers: a registry, official statistics, procurement records.
• Tools: a code editor, Node.js or Python, a public code repository, and a free archive such as Zenodo. Nothing else is required.

The steps

1. Ask a question the data can answer. Write it in one sentence. Check the data’s licence allows reuse and publication.
2. Write the plan first. The expected claim, the main measure, at least six other ways of counting, and what would change your mind. Date it.
3. Build the edition. Pull the data, clean it in code (never by hand), save one file, compute its SHA-256, and write the manifest.
4. Write the engine. Deterministic code that turns the edition into every number, plus a browser version that must give identical results. Test one against the other.
5. Run the stress test. Every way of counting from the plan. Record holds or does not hold.
6. Report the rest. Find the primary documents and on-the-record quotes. Record each with its date and caveat.
7. Write the story. Let the render script put every number into the text. Mark every claim with its kind. Label every reading.
8. Offer the right of reply. Send the findings and the data to those judged, with a deadline. Log the answers.
9. Review. An editor who did not do the analysis reads the story, opens the proofs and runs the check. AI may be one extra reviewer, never the only one.
10. Archive and publish. Deposit the edition with a DOI, publish the page, the proof record and the code, and run the check on the live page: every number must match.
11. Keep it alive. Connect the live layer, watch for changes, and publish a new edition when the picture changes. Log every correction.

Reuse ours

Our browser engine and page script are published under the EUPL-1.2 open licence, and the code that produced the first edition, the browser engine and the story scripts are at github.com/priyalifescience/ireland-trials-index, and the trial-level file is archived at doi.org/10.5281/zenodo.24229455. Start from them and replace the data and the indicators. Please credit “Living Proof Standard, Priya Life Science” and link to this page. Tell us when you publish a story to the standard, and we will list it.

The checklist

A story may carry the Living Proof name when every item is true, or when its conformance statement lists the item it does not yet meet and why.

• Every claim is marked Computed, Sourced, Said or Our reading, and the story counts its evidence at the top.
• No computed number was typed by hand; all come from the edition through code, and every sourced number links to its document.
• The edition is fingerprinted (SHA-256), archived with a persistent identifier that prints the same fingerprint, and has a licence and attribution file beside it.
• The engine is published under an open licence, deterministic, and runs in the reader’s browser; the live page shows N of N numbers matching.
• The dated plan, with at least six alternative counts and “what would change our mind”, is published. Either it was fixed before the analysis, or the story says plainly that it was not, and any test added later is marked.
• The stress-test table is published, including any test that fails.
• The live layer is labelled provisional and separate from edition numbers; the story shows its age.
• Everyone judged was offered a right of reply, and the replies (or their absence) are in the story.
• No personal data about private individuals is published, and every call to another site is listed in the privacy notice.
• Any interest of a funder, client or source in the finding is disclosed.
• The edition record states how AI was used, and a human editor approved the edition.
• Corrections show old and new values, date and reason, in the story and on the corrections page.

What comes next

We think the next step for data journalism is not more trust in journalists, or in AI, but less need for it. When readers can check the working themselves, a story’s authority comes from its evidence. That matters more as AI-generated text becomes cheap and common.

Our plans for the standard:

• More stories. A series of Living Proof stories on Irish health and the pharmaceutical sector, starting with clinical trials and hospital waiting lists.
• An open specification. A published, versioned format for the proof record, so any newsroom’s tools can read it.
• A shared engine library. Reusable parts for fingerprinting, recalculating and comparing, so a newsroom only writes its own indicators.
• A public list of stories published to the standard, by us and by others.
• Revisions in the open. Each version of this standard is dated, and its changes are listed under Version and licence.

Version and licence

Version 1.0, 12 November 2026. Published by Priya Life Science, Ireland. Questions and suggestions: info@priyalifescience.com.

Changes

• 1.0, 12 November 2026: first published version.

The text of this standard may be reused under the Creative Commons Attribution 4.0 licence (CC BY 4.0), with credit to “Living Proof Standard, Priya Life Science” and a link to this page. Our code is published under the European Union Public Licence 1.2 (EUPL-1.2); the data carries its own licence (CC BY 4.0, with the source registries’ terms).

How to cite this standard

Priya Life Science (2026). The Living Proof Standard, version 1.0, 12 November 2026. https://priyalifescience.com/living-proof/standard

See also: Living Proof, the format and its stories · Living Proof No. 1: Ireland’s missing clinical trials · Airmid Éireann open data · How our data registers are built · Corrections