accuracy

What this will do to your file, and what it did to ours.

Seven ways a file arrives, and the measured result for each.

You own a company master someone will audit — a stewardship queue, a CRM after a merger, a supplier file that pays real money. Before a resolver goes near it you need two things: what it does to rows shaped like yours, and evidence you can hand to whoever asks for it. Start at the table below. Find the columns your export actually has and read the rate under them. Every figure on this page arrives with its fraction, its fixture and its date, so it survives being quoted.

What those figures do not show is on this page too, at the same size: ten limits, and the three things we are asked for and do not have.

Strongest input
100%317/317 · company number or LEI
Weakest input
58.10%61/105 · truncated names
False binds, every tier
0across all 7 tiers
CI precision bound
98.94%357/357 clean merges · 63.10% automation
Acceptance floor · read the confidence basis0.90
Your data, not ours
A first file runs these same instruments over your rows, and the abstentions and the contradictions come back with them.
Start free →
On this page
who this page is for

Read this if you own a company master

built for

A company master you have to defend to somebody else: a stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, counterparty onboarding that has to survive an audit. Take the fraction and the date with the rate and you have something to put in front of a reviewer.

wrong for

A procurement checklist that needs a certificate. There is no SOC 2 and no external validation, and every fixture on this page was built by the people whose product it measures. Entity Bind resolves companies and organisations only. It does not resolve people, vessels, bank-account ownership, sanctions exposure, emissions or geolocation, and its results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.

what you send, and what resolved

Find the row that matches your columns

Seven ways a file arrives, recorded on 2026-08-29 over 317 live GB companies. Read the input column first: the row that looks like your export is the row that predicts your run.

Resolution rate, fraction, interval and measurement note for each way a file arrives
What you sendResolvedWhat the number rests on
IdentifierA company number or an LEI100%317/317—
Name and websiteA company name and its domain100%197/197Measured separately, at zero model spend, on 197 individually verified company-to-domain pairs. Those companies are large and well known, so this is the tier's behaviour on famous names rather than a register-wide sample.
Name, country and town proseA company name, GB, and a sentence naming the registered town99.37%315/31795% CI [97.7, 99.8]Historical 2026-08-29 recording with earlier identifier arrivals seeding the catalogue. This does not measure a business description, email footer or generic verification purpose alone. Two same-stem groups remained unresolved.
Name and postcodeA company name and a registered postcode98.74%313/317—
Name and countryA company name and nothing else but the country98.42%312/317Forecast at low-to-mid nineties and measured higher, because a representative register is about 99% unique on company names. The collision-dense fixture this was first tested on had hidden that.
Name and townA company name, country and a typed registered town98.42%312/317—
Truncated nameweakestA name whose ending has been cut off by a field-length limit58.10%61/10544 of 105 come back as an abstention with a shortlist, which is the correct answer for a name whose missing tokens were the discriminating ones.

Denominators differ by row, so each row prints its own fraction. Intervals appear where the source publishes one, 1 of 7 rows; a dash means the same fixture as the rows above and no separate note. These are resolution rates — the share of records that got a decision at all. What happened to the decided ones is the safety section.

the fixture behind every row above

Historical live adjudication recorded on 2026-08-29: 1,827 paid verdicts costing $53.53. The September 5 replay uses legacy recordings and has missing calls; it is not a new live measurement.

How the fixture was builtSampled from a dated snapshot, every same-named sibling pulled in

317 live GB companies sampled from the 2026-08-01 Companies House snapshot, with same-name siblings included. Identifier-rich arrivals seed the catalogue before the weaker input shapes are evaluated.

What this fixture is not

Historical results on an internal UK fixture with a preloaded catalogue. The September 5 replay has no full-prompt-verified calls and cannot establish current calibration. No independent customer holdout or global coverage claim.

The row that decides your integration is the one matching the columns in your export, and this fixture is not your export. Create your Free workspace and upload your own CSV to inspect its results. Contact us for an assisted measurement against your labelled rows.

Start free
the blend

One number for the whole fixture, and what it hides

One rate for the whole fixture, printed under the table it summarises. Its value follows the mix of files in that fixture, not the engine: put enough identifier rows in and anything looks excellent.

95.75%

Blended across six ways a file arrives

317 companies · 2026-08-29

What the blend depends on

A historical 2026-08-29 blend across six input shapes in a preloaded UK catalogue. Its value depends on that mix: truncated names measured 58.10% while the blend measured 95.75%. Neither establishes the current minimum-input target.

Your file has its own mix, and we do not know it yet.

Current target · not achieved
99%

An unmet product target, set September 4: 99% accepted candidate-backed matches at confidence >= 0.90 for each minimum input of name plus context, domain, address, country or postcode. It supersedes the earlier 75% resolved-outcome goal and is not an achieved accuracy or global coverage claim.

Where that target stands today

The minimum-input target diagnostic fails: name plus country accepts 0/205 on the internal regression fixture, and the other minimum-input populations are absent. A passing regression gate does not satisfy this product target.

the two instruments

Where every number above and below came from

Two measurements produced all of it, both ours: a live adjudication recorded on 2026-08-29, and regression gates that run on local fixtures with offline stub models. Neither is a customer holdout. Neither establishes production accuracy or global coverage on its own, and the 99% minimum-input target is unmet.

Instrument one

Historical live adjudication, 2026-08-29

Supplies the per-tier table, the safety results and the calibration population. Identifier-rich records seeded this UK catalogue before the weaker clues were tested, and replaying its saved answers says nothing about current calibration.

Instrument two

Continuous-integration gate, 2026-09-05

Supplies the precision, automation, resolution and cluster figures. It runs on every commit against offline stubs, so a regression fails the build before it can reach this page.

September 5 minimum-input diagnosticsWhere the work stands on strong clues and on weak ones

On a separate 197-company UK source corpus, name plus domain matched 197/197 and name plus postcode matched 188/188 eligible companies, all correctly, in both cold and preloaded catalogues. Nine companies lacked a postcode. The respective 95% Wilson lower bounds are 98.09% and 98.00%; these reused company families must not be pooled as additional independent observations.

Separate 20-query samples of name plus town prose, verification purpose, typed city or country each accepted 0/20 with stub models in both catalogue states. This shows the remaining dependence on adjudication for weaker clues. It does not measure live model conversion, and no business-description-only customer holdout is available.

The five rules this page is written underThe product's own reporting policy
  1. 01Never quote precision without the automation rate beside it. 100% precision at 0% automation is trivial — it is what you get by deciding nothing.
  2. 02Never quote a pairwise number without the resolution-level number. Pairs are not records, and a caller submits records.
  3. 03Never quote pairwise metrics without cluster metrics. Individual comparisons can look excellent while the clusters they build are wrong.
  4. 04Never quote a blended number without the per-tier table under it. A blend is a statement about a fixture's mix, not about an engine.
  5. 05Never quote a rate without its interval and its sample size. A rate over eleven rows and a rate over eleven thousand are not the same claim.
safety

What happens on the records it gets wrong

A resolution rate answers coverage. This answers damage, which is what decides the purchase for anyone merging records into a CRM or a supplier master: a wrong merge there is expensive to find and worse to reverse.

0
False binds, every tier

Zero wrong bindings were observed across the historical six-shape recording and the separate domain fixture. Observed correctness was 1.0000 on accepted outcomes; this does not guarantee an error-free new workload.

1,666 / 1,666
Accepted matches at or above 0.90

Every accepted match on the representative fixture cleared the confidence floor. Nothing below it is returned as a match at all.

72%
Resolved when the context is wrong

In the historical 50-record wrong-town fixture, 72% resolved and zero wrong bindings were observed. This is a measured adversarial sample, not a guarantee for every misleading description.

1.0000
Every record of one company grouped with the others, and with nothing else — B-cubed cluster precision

Cluster F1 0.9646 on the same 317-company representative recording of 2026-08-29. Pairwise numbers are never published without these.

The wrong-town tile is the one to test us on. False context is the normal condition of real data — an address typed four years ago, an office the company has left, a note copied from another account — and a resolver that reads context as corroboration binds the wrong company on those rows. Here it cost coverage instead, and what did not resolve came back as an abstention.

the confidence floor

0.90 is a refusal, not a promise

The most quoted thing about this product and the most often misread. It says what the system will not return, and on its own it says nothing about how often what it does return is right.

0.90

MIN_ACCEPTED_MATCH_CONFIDENCE

One constant, defined once, on all three paths.

A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead.

The refusal is a rule the resolver cannot construct its way around. Enforced as a domain invariant on the resolution outcome and again by a predicate called on the online, batch and replay paths, so a sub-floor accepted match cannot be constructed on any of them. A cached replay whose inherited confidence has fallen below the floor is withheld rather than re-served.

It is an acceptance contract, not calibration evidence: it says what we refuse to return, not how often an accepted match is right. Read it with the coverage it costs.

Two carve-outs, because the floor does not cover everything

  1. 01A merge a human reviewer approves is recorded against the reviewer, excluded from the automated population every accuracy figure is measured over, and withheld on replay.
  2. 02A new entity minted because nothing matched is not a match and is not subject to the floor. Its reject-side confidence can fall as low as 0.6752, on 27 observations.

If you are writing a threshold in your own code, read the decision type before you read the number.

calibration

What the confidence field actually is

Confidence is read off the evidence population behind each decision. There is no universal scale, and an unmeasured population cannot borrow another one’s score. Recomputing a bound checks its arithmetic; calibration on new inputs needs a holdout we do not have.

Before you filter on a confidence value

Confidence bounds depend on the recorded evidence population; there is no universal score for every match. Read match_confidence_basis and the evidence. A 0.99 filter can return some v8 adjudicated matches while excluding valid identifier matches, so validate its coverage cost on your own inputs.

The floor and the two historical bounds, drawn to scaleThree values on one axis, each with its own population
One acceptance rule · two historical populations
ACCEPTANCE FLOOR
0.90

It is an acceptance contract, not calibration evidence: it says what we refuse to return, not how often an accepted match is right. Read it with the coverage it costs.

HISTORICAL V8 MATCH POPULATION
0.9968

The nominal 95% Wilson lower bound of 1,190 historical prompt-v8 uncorroborated MATCH verdicts with zero recorded errors. The 2026-08-29 population pools six input shapes with repeated company families and calibration/evaluation overlap. Its independence and transfer to new customer inputs are unproven. Legacy replay cannot certify current calibration. Confidence bounds depend on the recorded evidence population; there is no universal score for every match. Read match_confidence_basis and the evidence. A 0.99 filter can return some v8 adjudicated matches while excluding valid identifier matches, so validate its coverage cost on your own inputs.

HISTORICAL V8 REJECTION POPULATION
0.8245

The historical prompt-v8 rejection population has 54 verdicts and four errors. Its bound authorises no accepted match; other non-match populations carry their own values.

The floor and the two historical population bounds answer different questions. A score above the floor still needs an accepted decision, an appropriate confidence basis and supporting evidence. Candidate ambiguity can withhold a match even when a pair scores highly. The scoring thresholds are a separate control and are not plotted here.
What the 5 September replay actually servedLegacy adjudications, missing calls, and the rejection population

The replay served 1,221 legacy adjudications, had six missing calls across three inputs and had zero full-prompt-verified calls. Its 1,666 accepted matches out of 1,740 are useful diagnostic evidence and cannot certify current calibration. The rejection bound covers a separate historical population: it must not be substituted for a match probability, or treated as the value of every non-match.

the continuous-integration gate

The numbers that run on every commit

The conservative half of the evidence: a different fixture, a different instrument, lower numbers. Its adjudication and research stages are offline stubs, so the name tiers the live recording bought an adjudicator for are undecided here by construction.

98.94%
Precision on automated merges, as the worst case the sample rules out — 1.0000 observed on 357/357 merges

The 95% Wilson lower bound of 357 error-free automated merges. Proving a 99% lower bound needs at least 381 consecutive clean merges, so this is 24 short of it — and we publish the bound rather than the point estimate.

63.10%
Pairs decided without a person

742 of 1,176 pairs were decided automatically in the September 5 saved gate report. This measures automation, separately from accepted-merge precision.

70.78%
End-to-end resolution — 499/705 records

End-to-end resolution on the internal gated acquisition fixture with offline stub models. All 499 accepted matches were correct in this fixture. The current 99% product-target diagnostic fails; this run does not measure live model conversion or independently establish calibration.

0.7584
Whole companies rebuilt from their records, scored as B-cubed cluster F1

B-cubed cluster F1 on the gate's own 705-record fixture, held as a regression ratchet against a 0.75 floor rather than offered as a headline. It reads far below the live recording's 0.9646 because an unresolved record is a predicted singleton and all 205 name-only arrivals on this fixture abstain by construction, splitting the families they belong to. The two cluster figures come from different instruments over different fixtures and are never averaged.

The gold set, in full

1,176 labelled company pairs — 216 handwritten adversarial, 960 generated from a fixed seed — plus a 705-record fixture over 250 UK-registered companies.

The second gate, which fails on purpose--strict-evidence, and what it fails on

Normal continuous integration passes the precision gate through an explicit, disclosed fallback for an under-powered zero-error population. A second mode, run with --strict-evidence, drops the fallback and demands the bound outright. It fails overall and on both gated tiers, purely on sample size, and it stays in the pipeline.

regional parity

The same engine, five registers

Parity was measured with no model spend at all — identifier and digital tiers, plus retrieval and fragmentation — using the same seeded, sibling-complete builder in every register.

The finding that changes an integration

France is 67.96% unique on names, against 99.53% in the United Kingdom. A third of French companies share their exact name — 1,003 live companies sit on one name. A French file needs a town or postcode column, and with one it measured 2,998 of 3,000 on the postcode tier.

A French file without a location column is not hard, it is unanswerable.

Combined parity
0.999955

Against a bar of 0.9565. Scope: United Kingdom, United States (Colorado) and EMEA (France and Norway).

What parity does not carry

Measured with no model spend at all, on identifier and digital tiers plus retrieval and fragmentation, using the same seeded, sibling-complete builder in every register. It does not carry the live-adjudicated name tiers across, which rest on jurisdiction-free calibration keys and have been recorded in the UK only.

The five-register census behind the France figure is published as a study you can cite, with the method, each register’s snapshot and licence, and the figures as a CSV: company name uniqueness by register.

All five registers, with populations and notesCompanies House, Colorado, EDGAR, SIRENE, Brønnøysund
Register, population and share of unique company names for each measured region
RegionRegisterPopulationUnique on nameNote
United KingdomCompanies House5,464,811 live companies99.53%The baseline every other region is measured against.
United StatesColorado Secretary of State2,191,009 extant legal persons97.76%State-level. A first review of the universe rule wrongly read 'live' as 'compliant' and excluded 1.13 million extant delinquent entities; the rule was corrected.
United States (filers)SEC EDGAR6,471 tickered filers with complete rows99.91%Reported beside the combined figure and never blended into it: closed-end fund families at one address measure lower on the digital tier, which is a register-shape finding rather than an engine one.
FranceSIRENE5,841,117 legal persons67.96%A third of French companies share their exact name — 1,003 live companies sit on one name. A French file needs a town or postcode column, and with one it measured 2,998 of 3,000 on the postcode tier.
NorwayBrønnøysund450,754 corporate forms97.78%—

Coverage by register, licence and region →

what this does not demonstrate

Ten limits on everything above

Several of these are why this product is sold as early-stage. Open the one that matters to your evaluation.

The scorer is fitted and scored on the same gold set

The evaluation harness scores the gold set with weights fitted on that same gold set, so the headline precision figures are in-sample. The leakage-free out-of-fold analogue, computed on folds grouped by entity family, is lower — and it is the one that would transfer to your data. Nothing here should be read as an out-of-sample result unless it says so.

There is no external holdout of any kind

No customer data, no time split, no jurisdiction split, no blinded head-to-head against a named competitor, no independent laboratory. Every fixture on this page was built by the people whose product it measures. That is the single largest gap in the evidence and it is not one we can close by writing more of it.

The gold set is mostly generated

The continuous-integration gold set is 1,176 labelled company pairs — 216 handwritten adversarial, 960 generated from a fixed seed — plus a 705-record fixture over 250 UK-registered companies. The generated majority is separable by construction and therefore easier than real data, and the resolution fixture's records are correlated within company families rather than independent samples. Grouped folds and family-collapsed intervals reduce the effect; they do not remove it.

Continuous integration runs against offline stubs

The adjudication and research stages in the gate are deterministic offline stubs with no network. These are software regression measurements, not estimates of live provider conversion or guarantees that a live run will improve every result. Weaker name-based inputs that required a model in the historical recording remain unresolved here.

Per-tier bounds are under-powered

No individual tier has the run of consecutive clean merges its own claim would need. Both gated tiers pass the normal gate only through the disclosed zero-error fallback, and the strict-evidence run fails on each of them. Tier-level precision claims are therefore not made anywhere on this site, and a tier-level precision claim made by anyone else about this system is not supportable.

The reject side is weaker than the accept side

The historical prompt-v8 rejection population bounds at 0.8245. It is separate from accepted-match calibration, and other non-match populations carry different values. Symmetric accuracy is not established.

Retrieval truncation is disclosed but not priced

A majority of records in the gated fixture ran against a retrieval that hit its candidate cap, as did a substantial share of the mints that followed one. The specific mis-scoring that could create has no labelled instance in the fixture, so it is disclosed as a fact on the receipt — the response carries candidates_truncated — rather than folded into any published number. Retrieval completeness is not claimed.

There is no name-only accuracy sample

The gate's name-only tier includes country and accepts none of its 205 inputs, so it provides no accepted-match accuracy estimate for that population. The historical 99.37% context result used both country and registered-town prose in a previously seeded catalogue; it does not establish the effect of adding arbitrary context to a new query.

Some safety features rest on very few labelled rows

Several conflict features — registration-number conflict, jurisdiction-subdivision conflict, email-domain conflict — carry single-digit labelled row counts, and three more carry none at all. Their behaviour in production is asserted from the code rather than estimated from data, and one of them was silently broken until an adversarial construction exposed it.

The recommended threshold rests on one row

The knee of the operating frontier behind the shipped upper threshold is a single labelled pair. A frontier one row deep is a frontier that will move again, and when it moves the numbers on this page move with it. Every figure here is dated for that reason.

And three things we are asked for and do not have

No SOC 2. It has not been started.

No independent external validation of the accuracy figures. Every fixture is one we built.

No production customer holdout. The evidence is internal.

The other half of a security review — retention, erasure, tenancy and what a design partner is committed to — is on the trust page.

If one of these limits is what decides it for you, name it: we would rather measure that question on your file than argue about a fixture you did not build.

Talk to us
checking it yourself

Three ways to check this, in order of what they prove

The first two are us showing our working. The third is the only one measured on your data.

01  Read the method

The accuracy document behind this page runs to a few thousand lines and carries every table this page summarises. It goes out in full during a technical evaluation, with the fixture definitions and the calibration table.

02  Watch the gates run

The replays are free and deterministic — a recorded run played back, so the model stages cost nothing and answer the same way every time. We run them on a call with the artefacts open, including the one that fails.

The commands that produce every figure aboveBoth gates, resolution, the floor frontier, the confidence audit
The pairwise tables and the gate
uv run python scripts/build_goldset.py --check
uv run python scripts/check_eval_artifacts.py
uv run python scripts/calibrate_weights.py
uv run python scripts/run_eval.py --gate
uv run python scripts/run_eval.py --gate --strict-evidence
#   ^ fails, by design, purely on sample size
End-to-end resolution and the batch gate
uv run python scripts/run_resolution_eval.py \
  --cases data/goldset/realworld/cases.jsonl \
  --register data/goldset/realworld/register.jsonl \
  --acquisition-only --production-config --gate \
  --adjudicator stub --researcher stub --no-report

uv run python scripts/run_batch_eval.py \
  --production-config --gate \
  --adjudicator stub --researcher stub --no-report
The confidence floor frontier, and the calibration table behind the field
uv run python scripts/run_eval.py --derive-floor --no-sweep

uv run python scripts/audit_confidence_field.py \
  --field match_confidence \
  --verdict-log data/eval/verdicts.jsonl \
  --json-path /tmp/confidence-audit.json

# re-derives every shipped confidence value from its counts;
# non-zero exit on any drift, which is why they cannot be tuned
uv run python scripts/fit_confidence_calibration.py \
  --audit /tmp/confidence-audit.json \
  --verdict-log data/eval/verdicts.jsonl --sensitivity

The live measurement is a separate run. It costs money, needs a model credential, cannot pass the gate, and will not overwrite the checked-in report — so a paid number can never be mistaken for the free one that CI produces.

03  Run it on your own file

Everything above is us measuring ourselves on fixtures we built. Send an export and you get which of your rows are the same company, which of your matches we would not have made, and what we could not decide — with a receipt per decision. That is the audit pack.

evidence footnote

Internal fixtures only. The historical 2026-08-29 per-tier recording covers 317 GB companies with identifier-rich arrivals seeding the catalogue first; the context tier includes country and registered-town prose. Its legacy replay has no full-prompt-verified calls and cannot certify current calibration. The September 5 CI reports cover 1,176 labelled pairs and 705 records over 250 companies using offline stubs. These are not independent customer holdouts or live production validation; the 99% minimum-input product target remains unmet. Scope is company and organisation identity only — not people, vessels, bank-account ownership, sanctions or emissions. Results may not be used for eligibility decisions about individuals, including employment, credit and tenancy.

Figures read off the product repository on 2026-09-05. Entity Bind holds no SOC 2, no ISO 27001 and no other certification, and claims none.

The published methods behind the bounds and the cluster scores

Each dated run on this page, and the API change behind the confidence field, is in the changelog.

the ask

Try to break it on your own data.

Create your Free workspace and inspect your own company CSV. For an assisted measurement against your labelled rows, contact us separately. We write nothing back to your systems.

300 credits. No card.

For a guided review of your file, explore the Merge Safety Sprint →

Questions about the numbers

The 12 questions we are asked most often about the evidence.

How accurate is it? Is it 99%?

On the continuous-integration gold set, 357/357 automated merges were clean, with 63.10% of pairs decided automatically; the rest abstain. We quote the cautious end of that result, the 95% Wilson lower bound: 98.94%, which sits below 99% and is 24 clean labelled merges short of proving a 0.99 bound. The point estimate of precision is 1.0000. End-to-end resolution on that fixture is 70.78% (499/705). A "99% entity resolution" figure quoted without the evidence shortfall, the automation rate and the resolution-level number beside it overstates this system, whoever is quoting it.

So what is the number you would put in front of a sceptic?

Two, side by side. On six input shapes measured over 317 live GB companies, resolution ran from 100% on an identifier down to 58.10% on a name whose ending had been cut off by a field-length limit, blending to 95.75%. Accuracy on decided outcomes was 1.0000 on every one of those tiers, with 0 false binds. The blend is the fragile figure: its value is set by the mix of shapes in your file rather than by the engine, so a file of truncated names lands nearer 58.10% than 95.75%. Read the tier that matches your columns, not the average.

What is the confidence floor, and is it an accuracy promise?

The floor is 0.90, and it is not an accuracy promise. It is an acceptance contract, not calibration evidence: it says what we refuse to return, not how often an accepted match is right. Read it with the coverage it costs. A match below 0.90 confidence is unrepresentable. The record comes back as an abstention with a ranked shortlist instead. The rule sits on the resolution outcome itself, so an accepted match below the floor cannot be constructed anywhere in the system — a domain invariant — and a separate predicate re-checks it on the online, batch and replay paths. Even a cached replay whose inherited confidence has since fallen below the floor is withheld rather than re-served. On the representative fixture 1,666 / 1,666 accepted matches cleared it.

Can the API return 0.99 confidence?

Yes. Some supported evidence populations return values above 0.99, and the recorded v8 uncorroborated population carries 0.9968. The nominal 95% Wilson lower bound of 1,190 historical prompt-v8 uncorroborated MATCH verdicts with zero recorded errors. The 2026-08-29 population pools six input shapes with repeated company families and calibration/evaluation overlap. Its independence and transfer to new customer inputs are unproven. Legacy replay cannot certify current calibration. Confidence bounds depend on the recorded evidence population; there is no universal score for every match. Read match_confidence_basis and the evidence. A 0.99 filter can return some v8 adjudicated matches while excluding valid identifier matches, so validate its coverage cost on your own inputs. Read `decision` alongside `match_confidence_basis`: the confidence only means something once you know which outcome it belongs to.

What happens to a file that is just company names?

It comes back as shortlists rather than matches. A record carrying only a name, or a name plus prose, abstains at the probabilistic stage and returns the top five candidates plus the column that would decide between them — so the tier that cannot be answered stops being the tier that costs the most. Measured on the gated acquisition fixture, the true company ranked first for 151/205 (74%) and appeared in the top three for 205/205 (100%). The stub-adjudicated run behind the pairwise gate, not the 317-company live recording behind the tier table. Recall is a property of the list rather than of the winner, and 74% sits far below the 0.90 acceptance floor, so no row of that shortlist may be offered to you as a match, and none of it is folded into an accepted-match count. Send a domain, a postcode, a registration number or an LEI and the same rows resolve.

What if the context in our records is wrong?

It degrades to an abstention rather than to a wrong answer. In the historical 50-record wrong-town fixture, 72% resolved and zero wrong bindings were observed. This is a measured adversarial sample, not a guarantee for every misleading description. That result is the one worth testing us on, because false context is the normal condition of real CRM data: a trading address typed years ago, an office the company has since left, a note copied from a different account. A resolver that treats context as corroboration will confidently bind the wrong company on exactly those rows. The same property shows up in retrieval — a deliberately wrong town still returns the true company inside the top ten, and produces no false binds.

Has any of this been validated externally?

No. Every fixture is internal and repository-authored. The per-tier table rests on 317 live GB companies sampled from the 2026-08-01 Companies House snapshot, with same-name siblings included. Identifier-rich arrivals seed the catalogue before the weaker input shapes are evaluated. The continuous-integration gate rests on 1,176 labelled company pairs — 216 handwritten adversarial, 960 generated from a fixed seed — plus a 705-record fixture over 250 UK-registered companies. There is no customer holdout, no time or jurisdiction split, no blinded head-to-head against a named competitor, no independent laboratory validation and no third-party penetration test. The internal readiness rubric scores external validation 3 out of 15 and the product 74 out of 100 overall, which is why the site says early-stage rather than proven. What is available in its place is the method, the fixtures and the failure cases in full, and an evaluation that begins by running your file rather than by reading ours.

What happens if the model changes?

Adjudicated confidence is keyed by model id and prompt version, and both are written onto every verdict inside the decision receipt. Change either and the system fails closed: adjudicated bindings stop being publishable at the old bound until labelled calibration exists for the new pair, so a prompt tweak degrades the product to abstention rather than quietly recalibrating it upward. The alternative arrangement — a model swap nobody outside notices, while the accuracy page keeps its old number — is the one this design exists to rule out. It also means a receipt written last quarter tells you exactly which model saw what under which prompt, which is the question an auditor asks about an automated decision.

How is the confidence number actually produced?

It is not the model's self-report. Each stage publishes the cautious end of its own measured accuracy over recorded trials — the 95% Wilson lower bound — so a stage claims at or below what it has been shown to deliver, and an audit of every stage confirms that none overstates. The pooled headline is 0.9968: The nominal 95% Wilson lower bound of 1,190 historical prompt-v8 uncorroborated MATCH verdicts with zero recorded errors. The 2026-08-29 population pools six input shapes with repeated company families and calibration/evaluation overlap. Its independence and transfer to new customer inputs are unproven. Legacy replay cannot certify current calibration. The adjudicating model's own confidence is carried separately and is uncalibrated — a self-report with a large calibration error against outcomes, never thresholdable, and never comparable with the calibrated field. Where the model was never asked about a candidate, that field is null, and null means "not asked" rather than "asked and unconvinced".

Is the non-match side as reliable as the match side?

No. The historical prompt-v8 rejection population has 54 verdicts and four errors. Its bound authorises no accepted match; other non-match populations carry their own values. The bound is 0.8245, it is reported but not gated, and a wrong non-match costs you a duplicate entity rather than a wrong merge — the cheaper failure, but still a failure. There is a second asymmetry worth reading in full, because it is the one that catches people: a new entity minted because nothing matched is not a match and is not subject to the floor. Its reject-side confidence can fall as low as 0.6752, on 27 observations. That row rests on 27 observations and is attached to the riskiest branch of the API, so never read "everything this endpoint returns is above the floor" into the floor.

Do you publish cluster metrics as well as pairwise ones?

Yes, and never one without the other. Pairwise numbers describe individual comparisons and can look excellent while the clusters they build are wrong, so the house rule is that a pairwise figure is never published without the cluster figure beside it. On the representative fixture, how well the groups the system built match the true groups, member by member — B-cubed cluster precision — measured 1.0000. Cluster F1 0.9646 on the same 317-company representative recording of 2026-08-29. Pairwise numbers are never published without these. The same rule runs across the board: precision never appears without the automation rate, because 100% precision at 0% automation is trivial, and no rate appears without its interval and sample size. A figure on this site without its denominator is a bug in the page.

Does the answer depend on how we chunk the file?

Within one batch, no: resolution is order-independent by construction. Every record is proposed against the store as it stood when the batch began, the links made inside the batch are then folded so that everything transitively connected lands in one group, and the same sixty records in four different orders produce an identical partition — against an earlier implementation that produced four. Across batches, yes. The same twenty-four rows produced fifteen entities and seven review items as one batch, and eight entities as twenty-four batches of one. Smaller batches collapse more duplicates; one large batch buys order-independence within it. Both directions are real, so chunking is a decision to take deliberately rather than a detail to leave to a loader.