Entity resolution basics, answered in full.

Entity Bind is an AI-native entity resolution API and MCP server for company identity. One record in, one resolved company record out — with citations, a calibrated confidence score, a receipt for every decision, and an honest abstention instead of a guess when the evidence will not carry a match. It runs beside the systems you already have rather than replacing one: your CRM, supplier master, master data platform or licensed data feed proposes a company match, and Entity Bind accepts it, withholds it or contradicts it independently, with a citation you can open. Scope is company and organisation identity only. It is built in London, and it is early-stage and priced as one — the resolution method and its measurements are published in full, and the global data breadth is not yet at incumbent scale.

Entity resolution is deciding which records refer to the same real-world thing. In company data, that is the work of establishing that "Acme Widgets Ltd", "ACME WIDGETS LIMITED" and a row carrying only company number 09876543 are one company, and that the similarly named firm three counties away is a different one. It is not deduplication by string similarity, and it is not enrichment: enrichment adds fields to a record you have already identified, and resolution is the step that decides whose record it is. Get that step wrong and every field you add afterwards lands on the wrong company, which is why a wrong merge costs more than a missing one.

Two differences, and only one of them is about the score. The first is calibration: a similarity score of 0.87 is a statement about two strings, while a calibrated confidence is a statement about how often decisions like this one have turned out right, computed from recorded trial and error counts with no tunable term in the module. The second is what happens at the bottom of the range. A fuzzy matcher always returns its best candidate and leaves the threshold to you; Entity Bind refuses to bind below 0.90 confidence and returns an abstention carrying a ranked shortlist and the one column that would have decided it. Keep your fuzzy matcher for the obvious duplicates. This is for the rows that cost you money when they are wrong.

You get an abstention, which is a first-class answer rather than a null or an error. The response carries `decision: "unresolved"`, a ranked shortlist of up to five candidates each with its own probability, a typed reason for stopping, a `clarification` naming the one field that would settle it, a `review_id` so the row lands in a queue a person can work, and a `decision_id` that reopens the whole evidence trail at a URL. It costs zero credits at every stage, including the ones that spent the most getting there. What you do not get is a low-confidence guess with a number attached, because the number is what makes a guess look like a decision.

No. Companies and organisations only, and it is a boundary rather than a gap being closed. The research agent is instructed never to collect information about private individuals, findings are checked against an attribute allow-list at the boundary, and anything outside that list is dropped rather than stored. Two named exceptions exist and both are registry data at company level: UK officer and persons-with-significant-control names under the Open Government Licence, and French officer names and roles under Licence Ouverte 2.0. Dates of birth, birth years, nationalities, countries of residence and personal addresses are discarded at ingestion and never reach storage. If you need a named contact at a company, that is a contacts vendor's job rather than ours.

Every decision the system takes — including the ones where it refused to act — persists a record you can reopen at `GET /v1/decisions/{id}`. It carries the feature vector, the top weighted contributions, the thresholds the call was judged under, the cited evidence with source URLs, the adjudicating model id and prompt version where one ran, the pipeline version, and a re-run of the score from the stored features, so you can recompute the probability rather than take it on trust. Receipts are queryable as a population too, filtered by pipeline version, threshold and date, so "show me every merge taken under the threshold we have since raised" is a question with an answer rather than a project.

An API, an MCP server and CSV uploads in your Entity Bind workspace, all over one pipeline. There is a catalogue behind it — the entities your tenant has resolved, with per-field provenance and freshness — but it is your catalogue, scoped to your tenant, rather than a global company graph we sell access to. That boundary is deliberate: building a proprietary worldwide company database is explicitly not the plan, because breadth is not a battle a new entrant wins against incumbents holding hundreds of millions of records. What is on offer instead is the decision quality, the evidence trail and the refusal to guess, over registers that are public and citable.

Seven stages, cheapest first, each one seeing only what the stage before it could not decide: normalise the record, retrieve candidates, apply deterministic identifier rules, score probabilistically, put the borderline band to an LLM adjudicator, send the ambiguous tail to agentic registry and web research, then abstain. It matters commercially because the price follows the stage. A file carrying company numbers or LEIs binds deterministically, with no model call and no egress; a file of bare names escalates. So the shape of your file rather than its size sets what a run costs — which is why the first thing we ask for is a sample rather than a purchase order.