Three records walk into a meeting
In this invented example, Alex joins Alder Works, buys a training course from its public shop, and volunteers to organize its annual workshop. Three systems create three records. A dashboard counts three people. Another system notices a shared name, merges everything, and decides Alex's personal course purchase belongs to the employer.
Both systems have been decisive. Neither has established what its records identify. A human being, an employee relationship, a purchasing account, and a workshop responsibility can all mention Alex without being interchangeable.
A person survives a role change
Person means an individual human being. The definition is deliberately steadier than a job title or account status. Alex can stop being an employee without ceasing to be Alex, and can become a customer without turning employment history into purchase history.
The registry defines Employee as a person employed by an organization. That connection gives a useful direction to interpretation: an employee is a person in an employment context. It does not mean every person is an employee or that one employee row describes every relationship the person has ever held.
The customer story follows this distinction through personal and business purchases.
Matching needs more than a name
Two people can share a name. One person can use different spellings, change a surname, or appear under an abbreviated given name. Neither exact equality nor superficial difference settles identity.
An illustrative matching process might retain the source identifiers, candidate links, and reasons for accepting a match. The important distinction is between “these records might describe the same human” and “these records are confirmed to describe the same human.” A merge should not turn uncertainty into an invisible fact.
Email is useful evidence in some contexts, but a shared team inbox is a particularly sociable person if treated as a human identifier. The contact story separates reachability from identity and explains why contact changes need their own history.
The manager belongs to a relationship
Suppose Alex moves from the design team to operations. The manager changes from Priya to Ben. Manager identifies the employee another employee reports to; it is not simply the name of an important person.
For this illustrative scenario, dated reporting relationships would let us answer both “Who manages Alex now?” and “Who managed Alex during the workshop?” Overwriting one field may answer the first while destroying the second.
Likewise, organization identity matters when people transfer between subsidiaries or teams. A familiar brand name does not establish which organization employed someone at a particular time.
A person is not every fact about them
A birth date is a calendar day; a workshop arrival is an occurrence with timing. Treating both as generic timestamps can quietly change their meaning when software converts time zones. Events and timestamps takes that distinction further.
The practical goal is not one enormous row holding everything known about Alex. It is a stable account of who the person is, with clear relationships to the roles, records, and occasions that matter for a question.
Then the dashboard can count one person, the shop can preserve one personal purchase, and the workshop can keep its organizer. Three records can finally attend the same meeting without impersonating three humans.
