The Same Board, Two Names: Role-Playing Entities

Opening Scene

Pull a length of oak from the rack, and it’s just a board — no inherent identity as anything in particular. Set it vertically in a frame, and it becomes a stile. Set an identically dimensioned board horizontally, and it becomes a rail. Nothing about the wood itself changed; the same species, the same dimensions, even boards cut from the same original plank can end up serving both roles in the same finished piece. What determines “stile” versus “rail” isn’t a property of the board — it’s the role that board is currently playing in the frame’s structure.

Database schemas run into this constantly: the same underlying entity — usually a Person — showing up as a Customer here and an Employee there, sometimes both roles held by the very same individual.

In Plain English

A role-playing entity pattern separates a person’s or thing’s core identity from the specific role or roles it plays in different relationships. Rather than creating entirely separate Customer and Employee tables that each duplicate a person’s name, date of birth, and contact details, a shared Party or Person table holds that core identity once, while separate role tables — Customer, Employee, Vendor — each reference back to that shared identity and add only the attributes specific to that role. The same person can then legitimately hold multiple roles at once, or the same role over time, without their core identity ever being duplicated or drifting out of sync between copies.

The Old Way

Before role-playing entity modeling became common, especially in customer relationship and enterprise systems, teams handled this awkwardly:

• Separate, duplicated tables for each role — Customer, Employee, Supplier — each storing their own copy of a person’s name and contact details, meaning the same actual individual appearing in two roles existed as two disconnected, potentially inconsistent records with no link between them.
• A single bloated table trying to hold every possible role’s attributes at once, with most columns null for any given row, and no clean way to represent someone holding two roles simultaneously without duplicating the whole row.
• The role-playing pattern (sometimes called a “party model”) resolved this by separating “who this genuinely is” from “what role they’re currently playing,” letting one identity support any number of roles cleanly.

Recognizing when an apparent difference — customer versus employee — is really just a role rather than a fundamentally different kind of entity has always been the key judgment call.

What’s Changing (and Why AI Is the Reason)

1. AI-assisted entity resolution can now detect when records in separate role-specific tables actually refer to the same real-world person or organization, matching names, addresses, and other identifying details across tables far more reliably than manual matching, making it genuinely feasible to retrofit a role-playing pattern onto data that wasn’t originally modeled that way.
2. Generative AI coding assistants building customer-facing systems sometimes default to separate, duplicated tables per role because it’s the simpler code path, missing the party-model pattern entirely unless a modeler explicitly directs the design toward it, which makes this a pattern worth specifying rather than assuming will emerge on its own.
3. AI agents personalizing interactions across multiple contexts — sales, support, billing — depend on recognizing that the same underlying person is behind several role-specific interactions, and a properly separated role-playing model gives an agent a single, reliable identity to reason about across every role that person happens to hold.

The Metaphor, Fully Extended

Joinery Element	ER Modelling Concept
A board with no assigned position yet, just oak of a given dimension	The core Party or Person entity, holding identity attributes shared by every role
The same board set vertically, now serving as a stile	A role-specific table, such as Customer, referencing the shared identity
The same board set horizontally elsewhere in the frame, now serving as a rail	A different role-specific table, such as Employee, referencing that same identity
One length of oak legitimately serving as both a stile in one frame and a rail in another	One person holding multiple roles simultaneously, all pointing back to a single identity
A joiner recognizing two seemingly different pieces came from the very same board	AI-assisted entity resolution matching records across role tables back to one real person

Quick Recap

• A role-playing entity pattern separates a shared core identity from the specific roles it plays, the same way one board becomes a stile in one position and a rail in another without changing what it fundamentally is.
• This avoids both disconnected, duplicated per-role tables and one bloated table trying to hold every role’s attributes at once.
• Recognizing when apparent categories are really just roles of the same underlying entity is the key judgment call.
• AI-assisted entity resolution can retrofit this pattern onto legacy duplicated data, and a clean role-playing model directly benefits AI agents reasoning across a person’s multiple contexts.

Where This Fits in the Series

Article 5 covered variants of a shared core entity; this article covered one entity playing multiple roles at once. Article 7 turns to relationships that change validity over time — the breadboard end and effective-dated data.