A real named individual, not an abstract persona.
A person is a specific human being: a named individual with a real calendar, real availability, and a real set of skills. The graph treats the person as distinct from the role they hold. People rotate between roles, hold several at once, go on leave, and leave the company, while the responsibilities they carry persist.
Modelling the individual apart from their function is a long-standing convention in organisational data. HR systems separate the employee record from the position; the position from the jobJobUserJob To Be Done: what the user is trying to accomplishView reference →; the job from the grade. Each layer changes on a different clock, and conflating them produces well-known failures: lose the position-versus-person distinction and a resignation deletes the work, a promotion rewrites history, a maternity cover looks like a duplicate employee.
Product practice imported the same discipline through the responsibility assignment matrix. RACI charts (responsibility charting, traceable to the 1950s and named through the 1970s, Perfony) deliberately assign roles, not named people, to tasksTaskProduct SpecificationA unit of work within a story or epicView reference →, so that a chart survives a reorganisation. The person is the late binding: you fill the role with a name only when you needNeedUserA user need, pain, desire, or constraintView reference → to know whose calendar to check.
The refinement worth keeping is that a person is real where a personaPersonaUserAn archetype representing a user segmentView reference → is invented. The two words sit one letter apart and get muddled constantly, but they answer opposite questions. A persona is a research-derived composite that stands for a segment of users. A person is one actual employee on the building team. The graph never confuses them, because they live in different regions and connect to different things.
Cooper introduced the persona into software product practice as a direct counter to this muddling: his argument was that teams designing for everyone — the abstract, shapeless "elastic user" — produce products that satisfy no one, and that committing to a named, fictional but research-grounded composite forces concrete design decisionsDecisionStrategyA recorded decision with context, rationale, and consequencesView reference →. On that account, the persona is deliberately not a person: its value lies precisely in being a stable archetype rather than a fluctuating individual.
A platform team has five people. One of them, call her Priya, holds the engineering manager role and also, for one quarter, an interim tech-lead role on a spun-up payments initiativeInitiativeStrategyA large coordinated effort to achieve a strategic goalView reference →. The graph records Priya once, as a person, and connects her to two roles. When she takes four weeks of leave, the tech-lead role reassigns to a colleague; Priya's node is untouched, her EM responsibilities are flagged as covered, and the payments work keeps its owner. A naive model that pinned the work directly to "Priya" would have stranded it the day she logged off. A query for "who is overloaded" can now count roles per person and surfaceSurfaceExperience DesignA place inside a screen, the features that occupy it, and the rule that decides who wins itView reference → that Priya is carrying two before the burnout does.
In the Unified Product Graph, personteam_org domain. Two edges point at a person and they say different things. node_owned_by_personnode_assigned_to_personnode_owned_by_role
Until 0.33.0 every one of those edges pointed at a person and none pointed out of one. A person was a pure sink: you could name them as an owner or an assignee, but the person node itself said nothing about where they sat. Two new edges close that. person_member_of_teamperson_reports_to_person
0.34.0 adds the third member of that triangle. person_holds_rolefilled, described as the role being staffed. team_staffed_with_roleperson_member_of_team
The shape follows the two edges before it. Direction runs person to role, matching the other person edges, so the containment reading stays unavailable rather than merely unchosen: sourcing it on the slot would read as the slot owning the human. Classification is semantic and not cross-domain, because person, role and team all sit in one domain and a cross-domain label on a same-domain edge would contradict itself. The edge is unqualified for the reason membership is: role is already an entity type, so a role string on the edge would be a second role model sitting beside a node type that already exists. What the graph gains is the ability to state three separate facts and keep them separate. A team has a slot. A person is on the team. That person fills that slot.
Type-specific fields on BaseNode
role_titlestringFree-text job title. Distinct from the structured `role` entity.
time_zonestringIANA time zone (e.g. "Europe/Berlin"). Useful for capacity / on-call planning.
idstringrequiredUnique identifier (UUID)
typeNodeTyperequiredDiscriminator for the entity type
titlestringrequiredDisplay name
descriptionstringOptional detailed description
statusstringLifecycle status
tagsstring[]Freeform tags for filtering
4 edge types connected to this entity.