Your data doesn't need more storage. It needs a verdict.
Two records that look different are often the same thing. Deciding which — millions of times, consistently, with the reasoning written down — is the work almost nobody does. It's the reason your AI answers confidently and wrongly, and it's what we do.
What it looks like from your side
You already know something is off. You just can't point at it.
Sales says 41,000 customers. Finance says 34,000.
Both are right about their own list. Nobody can prove which 7,000 are duplicates, so every number built on top of either list is quietly disputed.
The same part has three part numbers.
One in the ERP, one from the supplier feed, one a human typed. Total spend by part is unanswerable — not hard, unanswerable.
You bought the AI. It sounds certain.
And it's wrong in ways nobody can trace, because it inherited every collision, duplicate and stale row underneath it — with no way to tell you it did.
None of this is a storage problem, and none of it is a model problem. Each one is a judgment call: is this the same thing as that? A person could settle any single case in ten seconds. You have four million of them.
How we work
Every answer is recomputed by someone who didn't produce it.
This is a method before it's a product. It runs the same way whether the subject is a parts catalog, a customer list, or a claims history.
01
Brief
The question, the scope, and what would count as a wrong answer are written down before any work runs. So a disappointing result stays a result instead of becoming a rewrite.
02
Run
Every step is a script with a fixed output location. Nothing is done by hand, because anything done by hand happens once and can't be checked.
03
Verify
A second pass recomputes the result from the files on disk. A number that exists only in a run log does not count as a number. Re-runs are checked byte-for-byte against the originals.
04
Catch
When the two passes disagree, the disagreement is investigated and published — not smoothed. Findings that die under recomputation are reported as dead.
05
Rule
Each case a human settles becomes a written rule with the reasoning attached, and that rule decides the next thousand cases automatically. This is the part that compounds: the cost per decision falls as the decisions accumulate.
Exhibits
Measurements from our own operation, not a case study we wrote about ourselves.
We've run this machine daily on our own data for over a year, across auction archives, grading censuses and product catalogs. Every figure below came out of an artifact on disk that can be recomputed on request.
Auction archive · producer names
1,161→1
One distillery was listed under 1,161 different spellings across the archive. Anyone measuring "sales by producer" was measuring 1,161 producers who mostly sold a lot or two each. After folding: one producer, 6,580 lots — and 24 further variants deliberately left unfolded, because each names several distilleries in a single string. Knowing when not to fold is the same skill.
The same public census, pulled two weeks apart. Of 367,169 records present in both, the number that kept their primary id: zero. The vendor rebuilds and reassigns. Any system joined on that id would have mis-joined silently — no error, no warning, just wrong.
two snapshots retained side by side · full-census count, not a sample
Grading census · "last modified"
14,154→823
Records that actually changed, versus the ones whose "last modified" timestamp noticed. Recall: 5.8%. The cheap incremental sync every engineer reaches for first would have missed 94% of the movement — and reported success.
row-grain recall, both snapshots · plus 2,022 false positives
Product catalog · publisher field
3→9,548
A catalog of roughly a million rows carried three distinct publishers — stamped at ingestion, then believed downstream for weeks. Repaired against source evidence: 9,548. A fabricated value is indistinguishable from a measured one unless something records the difference.
repaired into a new dated snapshot · the poisoned one kept, not deleted
Governance · this morning
472 / 0 / 0
Registered data surfaces, errors, warnings — from a machine check that runs before and after every single write. Not an annual audit. A gate.
full-registry lint · 2026-08-18
Verification record
33
Consecutive deliverables independently verified before acceptance, with the most recent six reproduced byte-for-byte from a clean re-run. Two of yesterday's three headline findings died under that check. Both deaths were published.
running count · checksums shipped with every deliverable
Who you'd be working with
We've done this before, where a missed match was a federal penalty.
Before this, we built and sold Franco Signor. Strip out the industry vocabulary and that company was identity resolution with legal teeth: take an insurer's claimant records, match them against federal Medicare beneficiary data, and report the result correctly.
A missed match there wasn't a soft metric or an awkward dashboard. It was a reporting failure with a statutory penalty attached. We did that for more than a decade, on other people's messy data, at scale, under audit — which is where the habits on this page come from. None of them were invented for a pitch.
Co-founder
Jeff Signor
Co-founded Franco Signor and co-authored the field's reference text on Medicare Secondary Payer compliance. Trained as a lawyer — which is why the method above reads the way it does. A decision, the reasoning behind it, and the precedent it sets for every case after is how case law works, and it turns out to be how data adjudication should work too.
Co-founder
Jesse Hamby
On the Franco Signor team through the build and the sale. Today he works inside a public data-analytics company on how AI systems behave in practice rather than in a demo — which is the entire distance this page is about. He is the reason we test the claim before we make it.
The pedigree is what gets us in the room. The method is what we'd actually bring once we're in it.
Where to start
A hygiene audit. The deliverable is a document, not a login.
Fixed scope, fixed fee, no software installed on your side. You find out what's actually in there before anyone asks you to buy a platform.
You send
One slice of data
A customer list, a parts master, an order history — an export through whatever channel your security team already approves. No VPN into anything, no access to your systems, no agent running inside your network.
We run
The same machine
Duplicate detection, collision analysis, identifier-stability checks, staleness, encoding damage, and the structural ambiguities that only show up when you try to join two sources honestly.
You get
A before-and-after
What's duplicated and by how much. What collides. What can be resolved automatically, and the short list where a human has to rule once so the machine can apply it forever — with counts, and the method to re-derive every one. Including where a defect is costing you money: vendor records split three ways so volume never consolidates, parts bought twice because they're catalogued twice.
A real one
This is what comes back. Excerpted from an actual run.
Generated by the same suite, on one of our own tables — 250,000 music releases, unretouched. Note what it leads with: not findings, but an account of what it was given and what it never looked at.
Each skipped detector states its reason. Alias explosion, for instance, needs a target family token the caller has to supply; without one it does not guess, and it does not report zero.
Ordering rule
Findings are ordered by consequence — critical, error, warning, info — then by affected rows. Count is not allowed to outrank consequence.
What this one export answered
DL-0018 · warning · confidence high
170,259 of 250,000 release rows (68.10%) carry a source-assigned low-quality state — “Needs Vote,” “Needs Major Changes,” “Entirely Incorrect.” The source is telling you it doubts two thirds of its own records, in a column most pipelines drop on import.
DL-0019 · warning · confidence medium
19,313 catalogue identifiers appear under more than one label — 45,935 of 300,455 label-catalogue entries (15.29%). An identifier unique inside its own scope, used as if it were unique globally, is the classic silent join failure.
DL-0009 · info · confidence high
0 of 250,000 rows (0.00%) — no season-span values in a year-like field. A measured zero, reported as a finding. The check ran, the answer was clean, and the report says so rather than staying silent.
What a second pull would answer
Five diseases named individually — identifier stability, timestamp recall, merges and deletions, reclassification without a tombstone, registered-but-stale. Each is structurally unanswerable from one export, and the report says that plainly rather than implying it checked.
What needs a person to rule once
Six more, including fabricated-versus-measured values, which no single table can settle without provenance or a second witness. The report's own words: the machine should not invent the ruling — but once a ruling exists, the same machinery applies it to every later row.
Every rate above names what its denominator counts, because they differ: releases, label-catalogue entries, and text cells are three different populations drawn from the same 250,000 rows.
Boundaries
What this isn't.
×Not a dashboard. Nothing to log into, nothing to adopt, no seats. Mid-sized companies don't need another tab open.
×Not a warehouse migration. We don't ask you to move off anything. The audit runs on an export.
×Not a model. We don't fine-tune, and we don't sell you inference. We make the inputs worth running a model on.
×Not a headcount replacement. The judgment calls that need a person still need a person — once each, instead of forever.
Send us one table.
The fastest way to know whether any of this applies to you is to hand over a single messy export and read what comes back. If the answer is "your data is clean," that is a real answer and it's the one we'll send.