Survivorship and golden records
For the team that owns a company master and has to defend it.
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. Read the argument here, take the takeaways at the foot into your next vendor conversation, and send us a file when you want the same measurement on your own rows.
After the match · 2,032 words · every figure carries the population it was measured over
10 min read, last revised . 6 questions answered at the foot.
all 19guides →how every figure here was measured →On this page
What a golden record is, and what it is not
A golden record is the current best view of an entity: one value per field, assembled from the facts contributed by every record joined to it. It is a projection, computed from the underlying facts, and that is the important architectural claim.
It is not a row somebody edits. The moment a golden record becomes editable state, it stops being derivable from its inputs, its provenance becomes a comment rather than a computation, and nobody can answer why a field says what it says. Every serious implementation keeps the facts and recomputes the view, so that re-running survivorship after a new source arrives, a correction lands or a merge is undone produces a correct answer rather than a conflict.
It is also not the only useful output. The loser of a survivorship contest is frequently the most informative thing in the record — two registers classifying a company differently is exactly what a reviewer needs to see — so the alternatives should be exposed rather than deleted.
Where the projection gets computed decides who owns it. In a stewardship tool it is assembled for you. In a warehouse nothing assembles it, so the golden record is a view somebody writes over the facts and joins to their own source keys through a crosswalk, and an analyst building the view in a warehouse is doing this job with different tools and the same rules.
Merging and survivorship are different steps
Conflating them is the commonest architectural mistake in this area, and it produces bugs that are very hard to diagnose because they present as matching errors.
Merging decides which records belong together. Survivorship decides what the resulting entity looks like. A wrong merge shows up as a golden record containing two companies' addresses; a survivorship bug shows up as a correctly merged entity displaying a stale address. Those need different fixes, and a system that assembles the record inside the merge step cannot tell you which one happened.
Keeping them separate also makes the merge reversible. If facts retain their source record and their provenance, unmerging is a matter of removing edges and recomputing — recoverable, if not free. If survivorship has already flattened the facts into an entity row, the information needed to split it correctly is gone. A merge you cannot undo is a merge you should have thought harder about making.
Field-level survivorship, and the precedence rule
Survivorship runs per field. The company that gives you the most reliable registered address may give you nothing about the website, and the enrichment source with the best domain data may carry a legal name that is two renames out of date. Choosing one record to survive wholesale is choosing to be wrong about several fields in order to be right about one.
A workable rule has three levels applied in order, per field.
The order matters, because inverting the first two is the classic way a scraper overwrites a register.
- Source precedence first. A statutory register is authoritative about the facts it is the register for — a company number, an incorporation date, a registered address — and no amount of freshness in a scraped source should outrank it on those fields. Precedence is per field and not global: the register of incorporation is not authoritative about a company's website.
- Recency second, within a precedence level. Between two claims from equally trusted sources, the more recently confirmed one wins.
- Confidence third, as the tie-break, and it must be the confidence of the fact's own provenance rather than of the match that brought it in.
Why last-confirmed beats first-seen
The recency step needs a timestamp, and there are several available. Choosing the wrong one is a quiet, persistent source of stale golden records.
First-seen is when your system first observed a value. It is useful for provenance and it is the wrong tie-break for currency, because it rewards whichever source happened to load first. A file imported at go-live will hold its addresses against every later, better observation, and the entity will drift further from reality with every load.
Last-confirmed is when a source most recently asserted the value was true. That is the question recency is trying to answer. A value confirmed this morning by a register that re-publishes daily is more likely current than a value first seen two years ago and never re-checked, even if the second source is nominally better — which is precisely why precedence is applied first and recency second rather than the other way around.
There is one important exception. A caller's own submitted facts carry timestamps that record ingest order rather than currency: a record uploaded today may describe a company as it was in a spreadsheet exported eighteen months ago. So recency should be skipped for caller-submitted facts rather than letting the upload date beat a register's confirmation date. Getting this wrong makes every batch upload silently the freshest thing in the system.
Two clocks, and conflating them makes fields misleading
Every fact has two independent time dimensions, and a data model with only one of them cannot express things that are routinely true.
The first clock is yours. When did we first see this value, when did a source last re-confirm it, how many times, when was it retrieved? Every one of those answers a question about your own crawl.
The second clock is the source's. What period does this number cover, and when does the source say the value became true? A revenue figure is for a financial year; an address change has an effective date; a directorship has a start and possibly an end.
Conflating them produces sentences that sound reassuring and mean nothing. "Confirmed today" applied to an FY2023 revenue figure is entirely true and entirely misleading: it is a fresh observation of an old period, and that sentence must remain expressible. The rule that follows is that neither clock may be defaulted from the other. If a source publishes no effective date, the correct value is absent, which says something different from "the source says this became true today".
Temporal facts and superseded values
Once facts carry validity intervals, survivorship has a second job: pick the value that is current, and keep the ones that are not. Half-open intervals — valid from inclusive, valid to exclusive — are the standard construction, and they let assembly exclude both a superseded value and a future-dated one from the current view without deleting either.
Retaining the superseded value is not archival tidiness. A reviewer who tiered a counterparty on last year's revenue needs to be able to see that the number was later restated, and a compliance file that shows only the current address cannot answer what the address was when a transaction was approved. A restated figure should move into a history series with a pointer to what superseded it, not vanish.
One limit sits underneath all of this, and it is the one vendors blur. Retaining source-effective intervals is not the same as a point-in-time store. A system that keeps validity intervals can tell you what a source says was true on a past date. It cannot tell you what your system believed on a past date, which is what bias-free backtesting requires, and filtering on your own crawl timestamps to approximate it answers a question about your crawl rather than about what was knowable at the time. If the second thing is the requirement, it needs a point-in-time vendor.
Provenance, and the licence question hiding inside it
Every field in a golden record should carry where it came from, when it was confirmed, and under what terms it may be used. The first two are conventional. The third is the one that catches people, and it is not a legal formality — it decides what the code is allowed to do.
Sources come with different rights. Some may be stored and redistributed; some may be returned to the caller who asked but not retained; some are open only for particular uses. If licence tier is modelled as a contract clause rather than as a field on the fact, the constraint is enforced by whoever remembers it, which is to say not at all. Modelled as a field, survivorship can drop pass-through facts before assembling a record that will be stored, and an export can be filtered to what is genuinely redistributable.
Per-field provenance also makes disagreement legible instead of embarrassing. When two registers classify the same company differently, the useful output holds both classifications with their sources and designates one primary by a stated rule. What it must never do is average them, invent a mapping between schemes that nobody published, or emit a single flattened value that no source actually asserted.
Things a survivorship implementation should refuse to do
Most survivorship bugs are not errors in ranking. They are manufactured claims — a value in the output that no source ever asserted.
- Never merge two sources' lists into one super-list. A combined list of classifications or trading names has no coherent citation, because no source published it. Keep each source's list whole and rank the lists.
- Never crosswalk between schemes where no official crosswalk exists, and never chain two lossy mappings to manufacture one. If a derived value ships at all, it must be labelled derived and be ineligible to be primary.
- Never default the source's effective date from your retrieval date. Absent is the true value and it is a different statement.
- Never let an inferred value overwrite an authoritative one because it arrived later. Precedence is applied before recency for exactly this reason.
- Never write a field from a source that only identifies something adjacent. An address on a trademark filing is the address the filer had when they filed, not the company's registered address, and folding it in silently competes against a register whose job is to be current.
- Never discard the loser. Expose it as an alternative with its provenance, because the disagreement is frequently the most informative thing in the record.
Freshness is a field, not a promise
The last thing a golden record needs is an account of its own age. Per-field confirmation dates, and an entity-level indicator of the stalest field, let whoever is reading it decide whether the record is fit for the decision in front of them — and only they can decide that, because the tolerance differs between a marketing segmentation and a credit approval.
What that does not license is a claim that anything revalidates on a cadence. A field carries the date it was last confirmed. It does not carry a promise about when it will next be checked, and a supplier who describes freshness as a service level rather than as a recorded observation is describing a scheduler they may or may not run.
What to take away
- A golden record is a projection computed from facts, not editable state. Keep the facts and recompute the view, or provenance becomes a comment.
- Merging and survivorship are separate steps with separate failure modes, and keeping them separate is what makes an unmerge possible.
- Survivorship runs per field, in the order source precedence, then recency, then confidence. Inverting the first two is how a scraper overwrites a register.
- Last-confirmed is the right recency signal, not first-seen — with the exception of caller-submitted facts, whose timestamps record ingest order rather than currency.
- Two clocks: yours (first seen, last checked, retrieved) and the source's (valid from, valid to, effective date). Neither may be defaulted from the other.
- Retaining validity intervals is not a point-in-time store, and saying so is better than implying otherwise.
Those takeaways hold for anybody's data. The number for yours comes out of your own rows — a few hundred of them, with the matches you already have beside them.
Start freePrefer to put it to a person? Talk to us instead →
Where this article is applied
7 pages name this method as the working behind what they claim.
Is this your file?
The article is for anyone. The measurement behind it is worth commissioning for one kind of team.
Teams with a company master they have to defend — an MDM or stewardship queue, a CRM after a migration or a merger, a supplier file before a payment run, or counterparty onboarding that has to survive an audit.
Buying breadth as the product: we hold a fraction of an incumbent’s records and are not building a global company graph. 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.
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. The per-tier rates come from the live-adjudicated 317-company recording of 2026-08-29; the gate figures come from the stub-adjudicated continuous-integration run and are a floor rather than a ceiling. The two are never averaged. Entity Bind holds no SOC 2, no ISO 27001 and no other certification, and claims none. Every figure, with the population it was measured over and the method behind both recordings, is set out on the accuracy page. The retention, erasure, tenancy and sub-processor detail a security review asks for is under Trust and security, with where assurance stands: no external validation of the accuracy figures and no customer holdout.
The same measurement, on your own rows.
Create your workspace, verify your email and run your first company file. The Free plan needs no card. Create API keys in your workspace when you need an integration.
300 credits. No card.
For a guided review of your file, explore the Merge Safety Sprint →
The questions this article answers
What is a golden record?
The current best view of an entity: one value per field, assembled from the facts contributed by every record joined to that entity, with per-field provenance. The important property is that it is computed rather than stored as editable state — if it can be edited directly it stops being derivable from its inputs and nobody can answer why a field says what it says.
What is survivorship in master data management?
Survivorship is the rule that decides which value wins when the records joined to one entity disagree about a field. A workable rule is applied per field in three steps: source precedence first (a statutory register outranks a scrape on the facts it is the register for), recency second within a precedence level, and provenance confidence as the tie-break. Applying recency before precedence is the classic way a scraped value overwrites a register.
Should survivorship pick a winning record or a winning value per field?
Per field, always. The source with the most reliable registered address is rarely the source with the best domain data or the most current trading name. Choosing one record to survive wholesale means accepting known-worse values across several fields in order to be right about one, and it discards evidence you have already paid to collect.
Why is last-confirmed better than first-seen?
Because first-seen rewards whichever source happened to load first. A file imported at go-live will hold its addresses against every later and better observation, and the entity drifts further from reality with each load. Last-confirmed answers the question recency is actually asking: when did a source most recently assert this was true. The exception is a caller's own submitted facts, whose timestamps record ingest order rather than currency, so recency should be skipped for them.
Can I ask what a company record looked like on a past date?
Partly, and the distinction matters. A system retaining source-effective validity intervals can tell you what a source says was true on a past date. It cannot tell you what the system believed on a past date — filtering on crawl timestamps answers a question about the crawl, not about what was knowable — and that second thing is what bias-free backtesting requires. Anyone who needs it needs a point-in-time vendor.
Can a merge be undone?
It should be, and that requirement constrains the architecture. If facts retain their source record and their provenance, an unmerge is a matter of removing edges and recomputing the golden records on both sides. If survivorship has already flattened facts into an entity row, the information needed to split it correctly has been destroyed. Keeping merge and survivorship as separate steps is what preserves the option.