How the checks are proven

The number is not typed

There are 225 distinct checks. That figure is not written into this page: it is read from the source at build time, from the same registry the test suite holds itself to. A hand-typed count is a claim nobody re-checks, and every internal audit of this project found one that had gone stale. So the number on the full checks list is generated by a script that reads the code, and if the code and the number ever disagreed, the number would move, not the code.

A check counts only when it fires on a real file

Each check is registered with the route that proves it. Most are proven by running a real file all the way through the pipeline and seeing the finding come out of the far end; a few need a constructed input that a single cell cannot carry, a malformed archive, a network response, or a model call. The distinction is enforced, not decorative. Proving a function works by calling it directly says the function works; it says nothing about whether the product ever reaches it. The suite refuses to accept that kind of evidence for a check that claims to come out of a real scan.

The same registry catches the two failures that let dead checks accumulate: a code the source can emit that nobody registered, and a registered code the source no longer emits. Either one fails the suite. Two checks are marked as deliberately unreachable, kept as guards against a bad upload crashing the scan, and each carries a written reason for being there. Nothing is allowed to sit in the "cannot fire" state as a shrug.

What the recall number means, and what it does not

On the synthetic feeds we build to test against, recall is 100 percent across three formats, xlsx, csv and xml, with zero false positives on a clean control group. Our demonstration catalogue carries 55 distinct defect types and every one is detected.

Here is the honest boundary on that. The defects in those feeds are ones we injected ourselves, so the number measures that the scanner catches what we thought to plant. It does not measure that the scanner catches everything a real catalogue contains, and recall against real merchant feeds is genuinely unknown until real merchant feeds are scanned. We would rather tell you that than round it up. The free scan is the honest way to find out what a real file produces, which is partly why it is free.

The false positives we had to fix

The hardest part of being useful is being right when a value is technically present but meaningless. A generation step on one of our test feeds once proposed the colour "Blue" for a television, because the colour column read Blue on most of the catalogue. The value genuinely was in the merchant's data, and it was still wrong. What stopped it was a relevance filter and a check of each proposed value word by word against the source row, both written after we watched the failure happen.

The same work turned up others worth recording, because they are the kind of mistake that erodes trust quietly: a hint for an EU energy label that matched inside an unrelated Dutch compound word, and a rewrite that was rejected for a two-character inflection difference that is right for English and wrong for a language that builds words by joining them. Each of those now has its own regression test, so the same mistake cannot return unnoticed.

None of this is a claim to be finished. It is a claim that the checks which exist can be shown to fire, that the count is honest, and that we are clear about the difference between tested and proven in the wild. See what a file cannot tell us for the other half of that honesty.