Built by Noorflows (noorflows.com) for Foundation Legal Advisors, a corporate and institutional counsel practice. Working system, running on demo data. Every company and person in the demo is invented.
A new enquiry arrives as prose. The system does three things and then stops at a person.
A litigation conflicts check compares a person to a person. A corporate one compares a company to a group. An enquiry from a small trading company looks clean right up until you notice it is sixty per cent owned by a holding company the firm is already acting against on an open file. The demo's first enquiry is exactly that case: no name on it appears in the firm's records, and a name-to-name check returns nothing. The route is found in one step.
Conflicts also travel through people. One director sitting on two boards connects two groups that share no name at all.
Company-name matching, model org-v1, measured on our own fixture:
Measured on 1,128 name pairs across 27 entities. Of those pairs, 1,099 are different companies — so a system that matched nothing at all would be "accurate" 97.4% of the time. That is why no single accuracy figure appears anywhere on this page or in the product. The Office for National Statistics removed its accuracy formula from its linkage guidance because it "did not give a good representation of the quality of the linkage and was difficult to interpret", and Splink's documentation states that "high accuracy can be achieved by simply assuming the majority class". Precision and recall, at pair level and at entity level, or nothing.
There is no usable public benchmark for matching company names in a conflicts context. The one large public dataset of real names is real people's data and was ruled out on that ground. Every alternative is synthetic, and the standing criticism of synthetic record-linkage data is that it is almost impossible to guarantee the resulting value patterns are realistic.
So the fixture is built to be inspected rather than believed: 27 entities written under 48 names. Every within-entity pair counts as a match and every across-entity pair counts as a non-match, so nobody chooses which negatives to include. The negatives deliberately include the pairs designed to catch a name matcher out — the same distinctive word on a different business, a parent and its subsidiary, two people whose names differ only by a middle initial, two surnames one letter apart, the same company name in two countries — and also easy ones, because an all-hard negative set flatters a model that finds nothing and fails more dangerously than an all-easy one.
Recall by how the two names differed, so that a class we fail cannot hide inside an average:
Those last two are stated rather than averaged away. An abbreviation is shown to a person and never asserted, because three letters can belong to several companies. A former name that shares no words with the current one cannot be found by comparing strings at all — it is findable only because the firm wrote it down, which this pass does use.
What the fixture cannot tell you: it is our data, written by us. It shows how the model behaves on the variation we knew to put into it, and nothing whatever about how often that variation occurs in any real firm's records.
The public demo and any live system are separate stores that never touch. No real record is ever copied into the demo, for any reason, including testing. One set of credentials per build; no key that can read across two of them; no personal data in shared logging.
Every rule described on this page — each hold, each refusal, each published figure — is covered
by an automated test, and the numbers above are checked against the model's own measurement rather
than typed in. Model org-v1. Model versions last checked 2026-08-08.
Page written 2026-08-08.
How this handles your data — where it lives, what we keep, and the independent security reviews we have not had.