Candidate records need identity merge rules

Duplicate candidate records are not a cleanup nuisance. They are competing claims about a person.

A referral may use a personal email while an application uses a work address. A previous application may contain an old surname. A sourcing tool may import a public profile. Two people can share a name, and one person can share a household address or phone. A careless merge can move interview notes, rejection reasons, accommodations, consent, or suppression state onto the wrong person.

The ICO's current accuracy guidance says organizations should record the source and status of personal data, distinguish opinion, consider challenges, and rectify inaccurate information without delay. Those are useful product requirements even when a team's legal obligations differ by jurisdiction.

I would preserve each source assertion, make matching evidence visible, separate a link from a destructive merge, and keep every application as its own historical process. Canonical identity should improve navigation and communication without flattening the record.

The strongest merge is one the team can explain, undo, and correct.

Define the identity boundary

A person, contact method, account, application, candidacy, talent-community membership, assessment, and employment history are related entities, not interchangeable rows.

I would pressure-test that decision with four questions:

• What does one record represent?
• Which history must remain distinct?
• Can one person hold several applications?
• Which context limits reuse?

The failure mode here is using one candidate table as person, application, communication, and consent at once. In applicant tracking systems, sourcing tools, referrals, assessment platforms, scheduling services, talent communities, and imported recruiting data where the same person can appear under several emails, names, profiles, applications, and historical records, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a recruiting identity entity map. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is duplicate resolution that preserves every process-specific fact. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a recruiting identity entity map beside the question “What does one record represent?” before the first implementation review. The next pass would use “Which history must remain distinct?” to test the boundary, then “Can one person hold several applications?” to expose the state most likely to be missed. I would keep “Which context limits reuse?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports duplicate resolution that preserves every process-specific fact.

Preserve assertions and provenance

Every name, contact method, employer, location, skill, score, and note should carry source, observed time, status, and whether it is reported fact, derived value, or opinion.

The practical review starts here:

• Who asserted this value?
• When was it current?
• Is it fact or opinion?
• Can the person challenge it?

Those questions keep copying the latest-looking value over prior context without evidence from becoming the default. I would capture the decision in a source-aware candidate field model, then use it while the work is still cheap to change. For candidate profiles that become more accurate without erasing provenance, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like operators seeing why each value exists and which source controls correction. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a source-aware candidate field model part of the working surface. I would use it to answer “Who asserted this value?” while scope is still flexible, and “When was it current?” before code or content becomes expensive to unwind. During QA, “Is it fact or opinion?” and “Can the person challenge it?” become concrete checks rather than discussion prompts. That sequence turns candidate profiles that become more accurate without erasing provenance into something the team can operate and gives me a specific outcome to report: operators seeing why each value exists and which source controls correction.

Use evidence tiers

Verified identifiers, candidate confirmation, trusted integration keys, contextual matches, and fuzzy similarities need explicit weights, exclusions, and allowed actions.

Before implementation, I would answer:

• Which signal is deterministic?
• Can it be recycled or shared?
• What corroborates it?
• What action can confidence authorize?

The artifact is an identity evidence and action matrix. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is turning a model score into an automatic consequential merge; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is known collisions remaining separate while strong cases move efficiently. That connects a reversible identity-resolution workflow that preserves source records, separates facts from opinions, scores candidate matches, requires authority for consequential merges, protects application history, supports correction, and propagates canonical identity safely to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which signal is deterministic?” easy to answer. The boundary should force a decision about “Can it be recycled or shared?” and “What corroborates it?.” I would record both in an identity evidence and action matrix, including the part that stayed unresolved after the first pass. The final check, “What action can confidence authorize?,” is where the artifact earns its place: it either supports known collisions remaining separate while strong cases move efficiently, or it shows exactly why another iteration is needed.

Create a review cluster first

Potential matches should become a non-destructive workspace that shows side-by-side sources, conflicts, timelines, applications, and excluded neighbors before canonicalization.

I would use these prompts during the working review:

• Which records are compared?
• What conflicts remain?
• Could another person fit?
• What changes before approval?

If the team slips into hiding merge consequence behind a duplicate badge, the product can still look complete while its operating rule stays ambiguous. I would make a candidate match-review surface the shared reference and keep it small enough to update as evidence changes.

The standard is reviewers able to reject a match without any candidate data moving. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a candidate match-review surface, review it against “Which records are compared?,” implement the narrowest useful path, and then return with evidence for “What conflicts remain?.” I would use “Could another person fit?” to inspect product consequence and “What changes before approval?” to decide whether the result is stable enough to ship. This keeps hiding merge consequence behind a duplicate badge visible as a known risk and makes reviewers able to reject a match without any candidate data moving the release receipt rather than a hopeful conclusion.

Protect sensitive context

Accommodation details, demographic data, background checks, health information, compensation, and restricted notes must not gain a wider audience because two ordinary records were linked.

I would pressure-test that decision with four questions:

• Which fields are specially restricted?
• Does purpose permit propagation?
• Who may approve access?
• Can canonical views omit them?

The failure mode here is unioning all fields and permissions into the most convenient profile. In applicant tracking systems, sourcing tools, referrals, assessment platforms, scheduling services, talent communities, and imported recruiting data where the same person can appear under several emails, names, profiles, applications, and historical records, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a field-level merge boundary table. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is least-privilege visibility surviving link, merge, export, and undo. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a field-level merge boundary table beside the question “Which fields are specially restricted?” before the first implementation review. The next pass would use “Does purpose permit propagation?” to test the boundary, then “Who may approve access?” to expose the state most likely to be missed. I would keep “Can canonical views omit them?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports least-privilege visibility surviving link, merge, export, and undo.

Resolve conflicts field by field

Current contact, legal or preferred name, location, work history, source, consent, suppression, and recruiter opinion require different precedence and historical behavior.

The practical review starts here:

• Which source is authoritative?
• Should both values remain?
• Is recency meaningful?
• What happens to a disputed value?

Those questions keep choosing one whole record as winner and one as loser from becoming the default. I would capture the decision in a candidate field-resolution policy, then use it while the work is still cheap to change. For candidate profiles that become more accurate without erasing provenance, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like canonical fields accurate without deleting conflicting history or opinion provenance. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make a candidate field-resolution policy part of the working surface. I would use it to answer “Which source is authoritative?” while scope is still flexible, and “Should both values remain?” before code or content becomes expensive to unwind. During QA, “Is recency meaningful?” and “What happens to a disputed value?” become concrete checks rather than discussion prompts. That sequence turns candidate profiles that become more accurate without erasing provenance into something the team can operate and gives me a specific outcome to report: canonical fields accurate without deleting conflicting history or opinion provenance.

Preserve application history

A merge should not collapse jobs, stages, scorecards, interview panels, rejection reasons, offer states, or reconsideration windows into one synthetic candidacy.

Before implementation, I would answer:

• Which job owns this event?
• Can stage history move?
• Do decisions conflict legitimately?
• Which metrics use application identity?

The artifact is an application-history invariant list. Its job is to expose the tradeoff early enough that design, engineering, support, or product can disagree with something concrete. The common trap is deduplicating people by deleting a prior application; it moves uncertainty downstream and makes the final interface carry a problem the system never resolved.

For me, the useful receipt is person-level navigation with unchanged application-level decisions and funnel metrics. That connects a reversible identity-resolution workflow that preserves source records, separates facts from opinions, scores candidate matches, requires authority for consequential merges, protects application history, supports correction, and propagates canonical identity safely to an observable result instead of a process claim.

I would test this with one typical case and one boundary case. The typical case should make “Which job owns this event?” easy to answer. The boundary should force a decision about “Can stage history move?” and “Do decisions conflict legitimately?.” I would record both in an application-history invariant list, including the part that stayed unresolved after the first pass. The final check, “Which metrics use application identity?,” is where the artifact earns its place: it either supports person-level navigation with unchanged application-level decisions and funnel metrics, or it shows exactly why another iteration is needed.

Propagate with explicit semantics

Schedulers, assessment tools, email platforms, warehouses, referrals, exports, suppression lists, and search indexes need versioned merge events and idempotent field rules.

I would use these prompts during the working review:

• Which systems receive canonical ID?
• Can they represent aliases?
• What if propagation fails?
• How are stale exports corrected?

If the team slips into updating the ATS while duplicate outreach continues elsewhere, the product can still look complete while its operating rule stays ambiguous. I would make a downstream merge propagation contract the shared reference and keep it small enough to update as evidence changes.

The standard is all consequential consumers converging or surfacing a repairable exception. That tells me whether the decision helped the product, not merely whether the document was completed.

The working sequence is small: draft a downstream merge propagation contract, review it against “Which systems receive canonical ID?,” implement the narrowest useful path, and then return with evidence for “Can they represent aliases?.” I would use “What if propagation fails?” to inspect product consequence and “How are stale exports corrected?” to decide whether the result is stable enough to ship. This keeps updating the ATS while duplicate outreach continues elsewhere visible as a known risk and makes all consequential consumers converging or surfacing a repairable exception the release receipt rather than a hopeful conclusion.

Support correction and undo

Candidates and operators need routes to challenge a match, split records, restore aliases, explain the change, and reconcile downstream effects without losing the original audit trail.

I would pressure-test that decision with four questions:

• Who may request correction?
• Can a merge be reversed?
• Which effects cannot be undone?
• How is the challenge recorded?

The failure mode here is making identity cleanup permanent because downstream systems are inconvenient. In applicant tracking systems, sourcing tools, referrals, assessment platforms, scheduling services, talent communities, and imported recruiting data where the same person can appear under several emails, names, profiles, applications, and historical records, that can hide the exact boundary a reviewer or teammate needs to understand. My working artifact would be a merge correction and split runbook. I want it close enough to the implementation that it can change the work, not created afterward to decorate the story.

The result I would look for is incorrect merges reversed with bounded communication and metric repair. That is a narrower claim than saying the whole system improved, but it is also one I can verify and defend.

In practice, I would put a merge correction and split runbook beside the question “Who may request correction?” before the first implementation review. The next pass would use “Can a merge be reversed?” to test the boundary, then “Which effects cannot be undone?” to expose the state most likely to be missed. I would keep “How is the challenge recorded?” for the release check because it asks whether the decision still holds outside the ideal path. The work is ready to move when the artifact can explain the choice and the observed result supports incorrect merges reversed with bounded communication and metric repair.

Measure harm, not merge volume

Quality evidence should include false merges, missed duplicates, duplicate outreach, candidate corrections, restricted-field exposure, review latency, downstream drift, and sampled precision.

The practical review starts here:

• Which error hurts candidates most?
• How is ground truth sampled?
• Are some groups harder to match?
• Which model or rule changed?

Those questions keep celebrating a shrinking duplicate queue without measuring incorrect combinations from becoming the default. I would capture the decision in an identity-resolution quality review, then use it while the work is still cheap to change. For candidate profiles that become more accurate without erasing provenance, the artifact should make ownership, constraint, and next action visible without requiring a private explanation.

Success would look like fewer duplicate experiences without increasing false-merge or privacy incidents. If I cannot point to that evidence, I have a direction, not a finished decision.

The implementation move is to make an identity-resolution quality review part of the working surface. I would use it to answer “Which error hurts candidates most?” while scope is still flexible, and “How is ground truth sampled?” before code or content becomes expensive to unwind. During QA, “Are some groups harder to match?” and “Which model or rule changed?” become concrete checks rather than discussion prompts. That sequence turns candidate profiles that become more accurate without erasing provenance into something the team can operate and gives me a specific outcome to report: fewer duplicate experiences without increasing false-merge or privacy incidents.

What I would show in the work

The public version needs evidence from the work itself. For this topic, the first five artifacts I would reach for are:

• a recruiting identity entity map
• a source-aware candidate field model
• an identity evidence and action matrix
• a candidate match-review surface
• a field-level merge boundary table

I would not publish all five at equal weight. One should orient the reader, one should reveal the hardest tradeoff, and one should prove the result. The others can live in a downloadable note or appear as supporting frames. That edit matters because a reversible identity-resolution workflow that preserves source records, separates facts from opinions, scores candidate matches, requires authority for consequential merges, protects application history, supports correction, and propagates canonical identity safely becomes harder to understand when every process detail is treated as equally important.

I would also show one rejected direction. The useful version is specific: which option looked attractive, which constraint made it wrong, and what evidence supported the narrower choice. That gives an engineering manager something real to question and keeps the case study from reading like the final answer was obvious from the beginning.

# cluster
r_81 referral / r_93 application / r_104 source
Two verified emails connected by candidate confirmation; surname change documented; similar-name r_77 explicitly excluded.
# resolution
person p_42 / applications remain 3
Current contact from candidate, referral source retained, recruiter opinions source-labeled, accommodation scoped to one process.
# propagation
ATS + scheduler updated / undo through day 14
Suppression union applied, duplicate outreach cancelled, exports tombstoned, candidate correction route active, reviewer and policy recorded.

Resource path

The practical follow-up I would build is a candidate identity merge worksheet with source records, identifiers, provenance, purpose, fact-versus-opinion labels, match evidence, confidence bands, conflict fields, protected boundaries, approval, before-and-after preview, canonical links, redirects, downstream propagation, undo, candidate correction, retention, and audit events. I am treating that as a resource backlog item, not pretending the adjacent downloads below are the same artifact. The related cards cover useful pieces of the workflow today; this specific file should only be published when its examples, fields, and instructions are complete.

The first version should stay concise: context, constraint, decision, evidence, owner, and follow-up. Its value would come from helping someone repeat this exact review, not from adding another generic PDF to the site.

Review checklist

The article-specific review questions are:

• What does one record represent?
• Who asserted this value?
• Which signal is deterministic?
• Which records are compared?
• Which fields are specially restricted?
• Which source is authoritative?
• Which job owns this event?
• Which systems receive canonical ID?
• Who may request correction?
• Which error hurts candidates most?

I would add two editorial checks before publishing: can a recruiter find the point in the first minute, and can an engineer trace at least one claim to an implementation or production receipt? If either answer is no, the article needs another edit.

Implementation notes

For candidate profiles that become more accurate without erasing provenance, I would write the implementation note before polish. It would name the changed surface, source of truth, owner, failure boundary, and verification path. Those details prevent the principle from floating above the actual code or operational workflow.

The proof signals I care about are specific to this article:

• canonical fields accurate without deleting conflicting history or opinion provenance
• person-level navigation with unchanged application-level decisions and funnel metrics
• all consequential consumers converging or surfacing a repairable exception
• incorrect merges reversed with bounded communication and metric repair
• fewer duplicate experiences without increasing false-merge or privacy incidents

I would choose two or three of those signals for the first release rather than instrumenting everything. The strongest pair usually combines one direct behavior check with one operating check: a route and a data query, a keyboard path and a support state, a handler replay and a reconciliation result, or a migration count and a rendered screen.

The follow-up belongs in the note before shipping. It should say what remains temporary, what evidence would trigger another pass, and who owns that decision. That is how the first version stays intentionally narrow without making the boundary invisible.

Case-study packaging

I would structure the case-study version around the four visual lessons already established:

• Identity resolution links evidence before it combines records.
• Matching confidence changes the allowed action.
• Familiar identifiers carry different collision risk.
• A merge receipt records field-level decisions.

The opening frame explains the product pressure. The middle two show the decision moving through the system. The last frame is the receipt: what was checked, what held, and what remained unresolved. That order lets the reader move from product judgment into implementation detail without reconstructing the whole project first.

I would include one caveat tied to applicant tracking systems, sourcing tools, referrals, assessment platforms, scheduling services, talent communities, and imported recruiting data where the same person can appear under several emails, names, profiles, applications, and historical records: a data limit, rollout boundary, unsupported state, external dependency, or result that is still directional. A precise caveat makes the evidence easier to trust because it shows where the claim stops.

The final test is whether the page creates a better conversation. If the artifact helps someone ask a sharper question about product judgment, implementation detail, or release proof in a live interview, it belongs in the story.

Interview angle

In an interview, I would explain this through a reversible identity-resolution workflow that preserves source records, separates facts from opinions, scores candidate matches, requires authority for consequential merges, protects application history, supports correction, and propagates canonical identity safely. The story should start with the product pressure, then move into the system constraint, the artifact, and the proof. That order keeps the answer grounded. It also gives the interviewer several places to go deeper: data, frontend architecture, design systems, support, migration, accessibility, or release process.

The strongest version of the answer includes a tradeoff. I want to be able to say what I chose, what I left alone, and how I knew the work helped. That is more credible than presenting every project as a clean win.

The hiring signal

A candidate identity-resolution model is a hiring signal because it shows I can connect recruiting operations, privacy, entity resolution, data provenance, human review, integrations, and reversible product states.

That is the level I want this site to communicate. The work should show taste, but it should also show operating judgment. It should make me look like someone who can enter a real product system, understand the messy middle, ship the useful version, and leave enough proof for the next person to trust it.