Turning a draft into a claim ledger you can actually finish

Unstructured review is why accuracy work fails

Everyone knows to check the numbers. Almost nobody checks them methodically, because the work has no edges: you read page two, notice a percentage, decide to come back to it, and by page four you cannot remember which figures you already confirmed.

The failure is not diligence, it is bookkeeping. A review with no artefact produces a memory of a review, and a memory is unreliable in exactly the direction that matters: you remember the checks you enjoyed and forget the ones you deferred.

A matrix replaces the memory with a table. Every figure, named organisation and link becomes a row with an identity, a status and a place to put the evidence, so the next decision is always about one row rather than about a document. Progress becomes countable, and countable work gets finished.

It also changes the shape of the conversation with a client. Whether a specific figure was checked stops being a question about your diligence and becomes a lookup in a list you can send.

What gets extracted, and why that set

Four families are pulled out: statistics and percentages, named organisations and products, monetary amounts with their units, and links and citation targets. Those are the places where a document makes a debt to evidence, and they are also the places where a reader is most likely to be misled without noticing.

Extraction is mechanical by design. It will occasionally pull a number that is not a claim, such as a list numbering or a section reference, and it will occasionally miss something a person would have flagged. Both are acceptable costs, because the alternative is a partial review that feels complete.

There is a cap on how many rows are pulled from one draft, which is a feature rather than a limitation: a table with four hundred rows is not a review, it is a spreadsheet that will be abandoned. Split a long report by section and work each one to completion.

Named entities are worth their own attention. A company that does not exist, a product with the wrong name, an expert with a plausible title and no footprint: these are the failures that a fluent summary is most likely to smuggle past a reader, and each one takes about ninety seconds to disprove.

• Statistics and percentages, with the unit as written.
• Named organisations, products and people.
• Monetary amounts and the period they refer to.
• Links and citation targets.

The three states and what each one commits you to

Verified means you found evidence and it supports the sentence as written. The row should carry the URL where you found it, because a verified status without a source is an opinion, and the certificate will not accept it.

Unverified is the honest default. It stays that way until somebody acts, and a matrix full of unverified rows is not a failure of the tool; it is an accurate picture of the work remaining. The temptation to bulk-set rows to verified at four in the afternoon is the single greatest risk in the workflow.

Flagged is for claims that fail: a number nobody can source, a company that does not exist, a link that resolves to something unrelated. Flagged rows should be rare and they should be resolved rather than merely marked, because a flag without an action is a note that the next reader has to re-research.

The source field deserves a moment. Paste the page you checked even when one document supplies several rows, and prefer a specific page to a homepage. Future you, a compliance team and a client's lawyer all need to re-open the evidence without repeating the search.

Working the table in an order that finishes

Sort by type first and handle one family at a time. Statistics in one pass while the calculator or the dataset is open, names in another while the browser has the right tabs, links in a third. Context switching is the expensive part of claim work, not the reading.

Then sort by status and clear the unresolved rows. This is where the table earns its keep: you are never wondering what to do next, because the next thing is the top row.

Then sort by claim text when a client asks about one specific figure. One lookup replaces a re-read, and the answer includes the source rather than a recollection.

Save as you go. The table is kept in the browser between sessions, which means a review can span two days without being restarted, and also that clearing site data clears the work. For anything that matters, export or transcribe the resolved rows into the certificate while the session is fresh.

A worked example: twenty claims in one page

A thousand-word page about a product typically yields between twelve and twenty rows. Four or five statistics, three or four named organisations, two links, a handful of dates. That is an hour of work if the sources are to hand, and a day if they are not, which is itself the finding.

Sort by type and start with names, because they are the cheapest to confirm and the most damaging to get wrong. A company that has been renamed, a product that does not exist, an award that was never given: each takes ninety seconds of search and each would be embarrassing in public.

Then statistics. Open the source, read the number, check the unit and the period. A forty percent improvement in one quarter is not the same claim as forty percent year over year, and the row is where that distinction gets recorded rather than remembered.

Then links, which is mechanical: click each one and confirm it resolves to what the sentence says it does. Two minutes for the whole page, and it catches the most visible failures of all, because a dead link is the one defect every reader can find without expertise.

Keeping the ledger alive across a project

A ledger that lives only inside one review dies with it. The value compounds when the same table is reopened three weeks later for a revision, because the verified rows still hold and only the changed claims need re-checking.

Keep the draft identifier in the table's notes rather than only in your head, since a catalogue of verified claims against the wrong version of a document is worse than no record. A date and a version label are enough.

When a page is rewritten substantially, do not clear the table: mark the rows that no longer appear. A claim that was removed is a decision worth keeping, and it is often the answer to a later question about why a figure was dropped.

And export before you close. Local storage survives a reload but not a cleared browser, a new laptop or a support ticket that begins with the words I cannot find my work.

Turning the ledger into a client-facing summary

A client does not want the table. They want three lines: how many claims were checked, how many needed a correction, and what changed. The table is the appendix that makes those three lines believable.

Write it in that order, and name the corrections rather than counting them. Two figures corrected after checking the annual report tells a client what their money bought; two claims corrected tells them a number.

Attach the source list. It is the part a diligent client will skim, and it is the part that turns a review into something they can rely on later without re-hiring you.

What a verified row should contain

A row that says verified is an assertion. A row that says verified, page four of the annual report, checked on the eleventh, is a record, and only the second one survives contact with a second reader.

Include the exact figure or wording from the source, not just a link. Sources move, pages get redesigned, and a quoted fragment in the row is often the only evidence left when the link stops resolving a year later.

Where a ledger stops

It records that you checked something, not that the claim is true in the world. A verified row means a source exists and you judged it supporting, which is a statement about your process and about the evidence you found.

It cannot check sources for you. There are no network requests: the tool never opens a link, and a link that 404s is only discovered when a person clicks it.

It cannot see the claims that are not extractable: the framing of a paragraph, the omission that makes a comparison misleading, the adjective that implies a finding the study did not support. Those live in the reading, and the reading still has to happen.

So the matrix is what makes the reading finishable rather than what replaces it. A complete ledger plus one careful read of the argument is a review. A ledger on its own is evidence that a review was attempted, which is worth less than it sounds.