Original practice scenario: A hypothetical operational data platform combines supplier records from several systems. Names and addresses disagree, and incorrectly merging two suppliers would affect downstream work. Design entity resolution.
Read model answer +
Keep source records immutable and make entity links versioned decisions with evidence. A unified identifier should not erase the distinctions needed to audit or reverse a mistaken merge.
Work through it
Normalize selected comparison fields while preserving originals, using strong identifiers where available and marking weaker similarity-based candidate links as uncertain.
Build an entity view from approved links, recording the matching method, confidence evidence and reviewer decisions without presenting a similarity score as certainty.
Support splits and corrected links, tracking downstream dependencies so reports and operational actions can be re-evaluated under the new resolution version.
Tradeoffs to discuss
Aggressive linking improves connected coverage but increases false merges; conservative linking leaves duplicates while protecting distinctions.
Common pitfalls
Do not train and evaluate matching rules on the same reviewed candidate pairs.
A shared address or parent organization may be a relationship rather than evidence of identical entity identity.
Original practice scenario: A hypothetical operations team wants to reproduce which supplier facts an analyst could see before approving an order. Source records have event dates and later ingestion dates. Define the query.
Read model answer +
Use both business-effective time and knowledge-availability time. A fact valid on the decision date may still have been unavailable to the analyst because it arrived afterward.
Work through it
Store source identity, effective intervals, ingestion or publication timestamps and correction versions, defining the decision cutoff in a consistent time zone.
Select records effective for the requested business time and known by the decision cutoff, then resolve correction precedence only within that visible evidence.
Join at the intended supplier and order grain, returning unknown fields and provenance references rather than filling gaps with today's corrected state.
Tradeoffs to discuss
Bitemporal history is more complex than a current snapshot but supports faithful replay and analysis of late-arriving corrections.
Common pitfalls
Filtering only on event date still leaks future backfills.
Check for overlapping effective records and use independent row-count controls so an as-of join does not multiply decisions.