Indexxero · What we have proved
Every claim on this page comes with the file or the command that lets you test it yourself, offline. Where something is not yet proved, it says so.
One synthetic book of 2,000 accounts. Two analyses that differ in exactly one respect: when the field values were read. Three year retention comes out at 91.6 percent one way and 80.8 percent the other. The gap is not a rounding error, it is the difference between reading a field as it is today and as it was on the day the decision was made.
The repository regenerates the book from a fixed seed. Its README says which four fields move between runs and why, rather than promising a byte match it cannot keep.
A manifest is a short file that lets a stranger confirm a report matches the data it came from, with our servers off. Below is a live example. Change any measured number and watch the seal break and name the row. The unmeasurable row has nothing to change, because you cannot edit a number that was never produced.
The hash is SHA-256 over the canonical rows, computed in your browser with Web Crypto. Nothing is sent anywhere.
Download the folder. It holds an invented input file generated from a committed seed, the report our production code produced from it, the manifest, an offline verifier that needs nothing but Python, and a tampered copy of the report with exactly one field changed. The report says what it is in its own first lines: "fixture": true, labelled synthetic, 72 invented accounts. Change that to false and the seal breaks and names the field.
$ python3 verify_report.py retention_report.manifest.json --csv synthetic_input.csv --report retention_report.json PASS input rows 4cb09da88d66… PASS document seal 9082d4c82158… PASS versions method 1.0.0 ANCHOR content_hash c7dca95f30ab… RESULT: PASS. Every check that ran passed. This establishes that the report matches its manifest and that the manifest belongs to the named input. It does not establish who sealed it. Anyone holding this folder can change the report and re-seal it, so compare content_hash above with the value Indexxero published for this report. It does not establish that the computation from input to number is correct.
$ python3 verify_report.py retention_report.manifest.json --csv synthetic_input.csv --report tamper/retention_report.json PASS input rows 4cb09da88d66… FAIL document seal this report seals to d850aaee18e7… manifest payload differs at accounts_analysed PASS versions method 1.0.0 ANCHOR content_hash c7dca95f30ab… RESULT: FAIL. 1 of 5 checks did not pass. This FAIL establishes that the report does NOT match its manifest. The field that moved is accounts_analysed.
Those two runs are what a stranger performs. We cannot make the second one pass by editing the report alone.
The seal is a plain hash, not a signature. Anyone holding the folder can change a number and re-seal both files, and the verifier will pass. We tried it, and it passed. So a PASS means the report matches its manifest. To know the manifest is ours, compare the content_hash in it with the value published here.
For a real engagement the same two values go to you in the delivery note, outside the folder. Whether to sign the manifest with a key is a product decision we have not made, and this page will say so when we do.
It establishes that a report matches its manifest and that the manifest belongs to the named input. It does not establish who sealed it; the anchor above is for that. It does not establish that the computation from input to number is correct. The verifier says that in its own output, on every run. The correctness of the computation is what the first demonstration and the code behind it are for.
On a 1,400 account export we built to behave like a real one, mismatched headers, four date formats, blank revenue and duplicate rows included, our report left four of eight sections unreported and printed the reason instead of a number. Gross revenue retention was not reported because contraction could not be measured and 46 accounts whose ending could not be resolved were still sitting on the retained side of the ratio. Either one is enough to make the percentage wrong in the direction that flatters you.
Three labels, measured, a floor, or not measurable, and no fourth. A tool that estimates can print a retention percentage for anybody who uploads a file. Often we cannot, and we print the reason.
A detector for the same defect in public code. We are running a scanner for outputs that print zero where nothing was measured against widely used open source reporting and analytics libraries. So far: 18 findings across 12 public repositories, every one read by hand from the public source, none yet reproduced in a running process. The target we set ourselves is 25. None reported to maintainers yet, nothing published, and no project is named here until its maintainers have heard from us first.
Last updated 24 September 2026.
If you are a few months from a raise or a sale, or you know someone who is, the short version of what we do is at what-we-do.html.