The obvious way to build that tool is a PDF parser: upload the report, extract the numbers, return a score. I didn't build that. I built a checklist. This post explains why, how the checklist is modelled as data, how its verdicts behave and why it runs entirely in the browser.

The problem: there is no standard COA

If you've worked with invoices or receipts, you know layout-agnostic extraction is hard. Lab reports are worse.

A COA might be a clean PDF from an independent lab, a scan of a printed page, a screenshot pasted into a product image, or a document assembled by the supplier. The same fields (batch number, method, purity, test date, analyst) appear in different places, under different names, sometimes in tables and sometimes in images.

A parser that works on one lab's template fails on the next. Worse, a parser can only read what is written. The questions that matter for trust are mostly about what is missing or inconsistent:

• Is there a batch number at all?
• Does it match the number on the vial?
• Was the same report reused across different products?
• Do the fonts and alignment look edited?

None of those are extraction problems. They're judgement problems that a person can answer in seconds while looking at the document. The software's job is to make sure they ask the right questions.

I took a related approach in my earlier post on normalising supplier listings: when the input is messy and a confident wrong answer is costly, flag the uncertain case for a human instead of guessing.

The decision: validate, don't extract

So the tool flips the problem. Instead of reading the report for the user, it gives them a short list of things to look for and records what they find.

That has three practical benefits:

1. It works on any format. PDF, image or screenshot all work, because the user is the reader.
2. It's harder to fool with a convincing layout. A forged report can contain perfect-looking numbers. It's much harder to fake a matching lot number, a real chromatogram and a named analyst at the same time.
3. It builds a habit. The list is short enough to remember, so the questions can stick even when the tool isn't open.

The data model: 16 flags, two lists

The checklist is plain data: 8 red flags (signs of risk) and 8 green flags (signs of trust). Each list has its own progress counter, from 0/8 to 8/8. Here is a simplified version of the structure:

type FlagKind = "red" | "green";

interface Flag {
  id: string;
  kind: FlagKind;
  label: string;
}

// Labels shortened for the article.
export const FLAGS: Flag[] = [
  // Red flags: each one is a risk
  { id: "no-lot", kind: "red", label: "No lot or batch number" },
  { id: "no-method", kind: "red", label: "No analytical method named" },
  { id: "no-trace", kind: "red", label: "No chromatogram or MS spectrum" },
  { id: "reused", kind: "red", label: "Same COA reused across products or batches" },
  // ...4 more red flags

  // Green flags: each one adds trust
  { id: "third-party", kind: "green", label: "Independent third-party lab" },
  { id: "lot-match", kind: "green", label: "Lot number matches the vial label" },
  { id: "named-method", kind: "green", label: "Named method (HPLC-UV, LC-MS)" },
  { id: "recent", kind: "green", label: "Report dated within roughly 12 months" },
  // ...4 more green flags
];

Modelling the flags as data rather than markup means both lists render from one source, the counters come from a simple filter and changing a label is a one-line edit with no layout work.

The two lists mirror each other. "No analytical method named" sits against "a named method with real parameters". "No lot number" sits against "a lot number that matches the vial". That symmetry makes the user look at each property twice, once for its absence and once for its presence.

If you want to see what real reports look like before using the checklist, PepLookup collects suppliers' published lab reports in one place.

The verdict

The user ticks what the report actually shows, on both lists. Below the lists, a result box shows the running tally (for example "4 green · 1 red") and one of four states. These are the outcomes I saw when testing the live tool:

Three design choices matter more to me than the exact tally:

• One good sign isn't enough. Ticking a single green flag with no red flags still returns "Mixed signals". A clean result needs a strong set of green flags, so one reassuring detail can't carry the whole verdict.
• Every state says what to do next. "Needs review" tells the user to ask the seller for the missing pieces. "Mixed signals" tells them which part to double-check: the specific gaps. The verdict is a prompt for the next step, not just a label.
• The best outcome is deliberately modest. The strongest state says the COA "passes a basic sanity check". It never says a report is authentic or certified. A COA is documentation for research use, not a guarantee, and the wording is built to say so.

Privacy by design

The COA Reader runs entirely in the browser. Nothing the user ticks is sent anywhere, and the page says so right above the lists.

That wasn't only a nice-to-have. People check reports for products they're considering, and which lab reports someone is reading is nobody else's business. A checklist made that easy to guarantee. There's no upload, so there's no file to store, scan or leak and no server endpoint to secure.

Compare that with the parser approach. Uploading a PDF means handling untrusted files, storing them at least briefly and writing a privacy policy that explains it all. The checklist removes that whole category of problem.

What I'd change next

These are ideas, not shipped features:

• Explain each flag inline. A short "what this looks like" note or example image under items like "a chromatogram" would help first-time users.
• Make the result shareable without a server. Encoding the ticked flags in the URL (for example ?r=no-lot,reused&g=third-party) would let people share a result while keeping the no-backend design.
• Add a "not sure" state. Some items are hard to judge from a blurry image. A third option would be more honest than forcing a yes or no.

Closing note

Not every data problem needs extraction. Sometimes the most reliable system is a well-designed set of questions and a person who answers them.

You can read more about the project and background on how I compare prices on Medium.

PepLookup lists products sold by third-party suppliers for laboratory research use only. This post is about data processing and makes no claims about any compound.