Uniquley identify the PSC records

ahmed.sammour · September 16, 2026, 8:14pm

Is there a way to uniquely identify a PSC data. For example:

PCS of Company A:

PSC 1: Individual (John Kennedy) - born 1990
PSC2: Individual (Morgan Freeman) born in 2000

Then after few days, suppose we receive an event from streaming API, that update:

PSC1: Individual (John F. Kennedy) born in 1991

How can I know whether this updated record refers to the same PSC/person as the original PSC 1? Is there a unique identifier for a PSC that remains stable across updates, corrections, name changes, or date-of-birth changes?

companieshousedata · September 18, 2026, 12:38pm

The short answer is that you cannot absolutely know that two different PSC records represent the same real-world person.

For an update to an existing PSC resource, however, you can normally identify it using resource_id:

Original:

company_number = 12345678
resource_id    = AbCdEf123...
name           = John Kennedy
DOB            = 1990

Later stream event:

company_number = 12345678
resource_id    = AbCdEf123...
fields_changed = ["name", "date_of_birth"]
name           = John F. Kennedy
DOB            = 1991

Because the resource_id is unchanged, you can treat the later event as an update to the same Companies House PSC resource, despite the name and DOB having changed.

The complication is that the PSC resource is not necessarily a permanent identifier for the real-world person. For example, if a PSC ceases and is subsequently added again, you could potentially have:

Event 1
resource_id = AAA
John Kennedy
DOB 1990

Event 2
resource_id = AAA
ceased_on = ...

Event 3
resource_id = BBB
John F Kennedy
DOB 1991

AAA and BBB are different Companies House PSC resources. From those identifiers alone, you cannot safely conclude that they represent the same real-world person; you would need your own identity-resolution logic if making that association matters to your application.

So, if your only concern is determining whether a streaming event is an update to an existing PSC resource, use resource_id. If the resource_id changes, determining whether the old and new resources represent the same person is a separate identity-resolution problem.

companieshousedata · September 21, 2026, 8:56am

These are the rules I stuck with whilst developing a solution to trace multi hop company->company relationships via PSC’s:

# PSC de-duplication rules when `resource_id` differs

This is the quick guide to how I decide whether two **individual PSC source

records** probably describe the same natural person when their Companies House

`resource_id` values are different.

The short version is: a different `resource_id` does **not** prove that two

people are different, but it is also never enough evidence to merge them. We

keep both source records and, where the evidence is strong enough, link them to

one resolved `Person`.

## What the percentages mean

The percentages below are **operational certainty bands**, not measured

population probabilities. They describe how safe a rule is considered for an

automatic identity link under the current resolution policy. They must not be

read as a claim that a match is literally correct in exactly that percentage of

cases.

| Certainty | Meaning | Action |

| —: | — | — |

| 99–100% | Very strong, deterministic or explicitly reviewed evidence | A link may be published, subject to all vetoes and uniqueness checks |

| 95–98% | Strong corroborated evidence, with a controlled address equivalence | A link may be published only by the stated rule |

| Below 95% | Useful investigative evidence, but not safe for automatic merging | Keep the PSC source record separate and flag it as unresolved/candidate evidence |

## Rules, in order of preference

| Method | Working certainty | Automatic action |

| — | —: | — |

| Exact existing canonical identity or stable source anchor | 100% | Link to that identity. Preserve the original PSC record. |

| Exact normalised name + exact DOB month/year + exact canonical address + one unique Officer anchor | 99% | Merge the PSC source link to the Officer-backed `Person`. Record `MATCH_EXACT_ADDRESS`. |

| Exact normalised name + exact DOB month/year + safe format-equivalent address + one unique Officer anchor | 98% | Link to the same `Person`. Record `MATCH_SAFE_FORMAT_ADDRESS`. |

| Exact normalised name + exact DOB month/year + safe component-equivalent address + one unique Officer anchor | 95% | Link to the same `Person`. Record `MATCH_SAFE_COMPONENT_ADDRESS`. |

| A reviewed cross-root Officer alias, then the same exact name/DOB/address composite | 99% | Link only after explicit review. Record the review ID/version and rebuild the DatasetVersion-derived outputs. |

| Same name + same DOB, but no accepted address evidence | 50% or less | Candidate only; do not merge automatically. |

| Same name + same address, but DOB is missing | 20% or less | Do not merge automatically. Missing DOB is not agreement. |

| Same name + same postcode only | 10% or less | Do not merge. A postcode can contain many people and addresses. |

| Same or similar name only | 1% or less | Do not merge. Generate no identity link from this alone. |

The first four automatic methods require **all** of the following:

1. The PSC is an eligible natural-person record.

2. The name matches after the versioned normalisation rules (case,

punctuation, whitespace and ordinary honorific differences are handled).

3. The PSC and Officer DOB month and year are both present and agree exactly.

4. The address comparison is one of the accepted classes below.

5. Exactly one eligible Officer anchor is found.

If any requirement is missing, contradictory or non-unique, we do not pick the

most convenient candidate.

## Address evidence

Different address IDs do not automatically mean different people. The address

comparison is evaluated separately from canonical Address identity:

- **Exact canonical** — the two source addresses have the same canonical

Address ID.

- **Safe format equivalent** — presentation differs, such as punctuation,

case, whitespace, or a safe optional county/country representation, while

the substantive address is unchanged.

- **Safe component equivalent** — the structured components agree, including

the full postcode, premise (including suffix), street, compatible locality

and country, and compatible sub-premise.

The following are not safe shortcuts:

- postcode alone;

- a partial address;

- removing flat, unit or premise-suffix information;

- treating different streets or premises as equivalent;

- substring or fuzzy matching;

- assuming two different canonical Address IDs are equivalent without a

recorded resolution rule.

## Hard stops

These rules always prevent an automatic PSC-to-Person merge:

- conflicting DOB month/year evidence;

- missing DOB where the strong composite is required;

- more than one eligible Officer anchor;

- ambiguous or conflicting address structure;

- corporate, legal-entity, statement or other non-natural-person PSC records;

- Officer-root differences by themselves;

- a matching `resource_id` without matching identity evidence (the source ID

identifies a record, not necessarily a human).

The result remains a valid source-scoped PSC identity and can be reviewed later.

Unresolved is preferable to a false merge.

## Reviewed Officer aliases

Some historical Officer records can represent the same person under different

Officer source IDs or deterministic roots. These are not automatically merged

just because their names, dates and addresses look alike.

An alias is allowed only when a reviewer explicitly confirms the generated

candidate. The confirmation is DatasetVersion-local, audited, versioned and

consumed only by a later Person/derived-graph rebuild. It does not alter either

Officer source record.

## Provenance and interpretation

De-duplication creates a resolution link; it never destroys source evidence.

For every link, retain the source identities, DatasetVersion, resolution rule,

address rule/version, confidence class and relevant evidence. Officer and PSC

remain roles/relationships, not alternative kinds of Person.

These percentages are therefore a communication aid for investigators and

reviewers. The authoritative decision is the recorded rule and evidence, not a

free-standing score.