Role-Scoped Record Type¶
Record schema — instantiates Aspect-Scoped Identity Projection
Defines a distinct stored record type for an entity under a role, with its own key and its own rules for reconciling clashes with the underlying entity.
A Role-Scoped Record Type is a schema — a design-time class or resource type — that gives an entity-under-a-role its own stored record: its own set of fields, its own primary key, and its own rules for what happens when that record and the underlying entity disagree. Its defining idea is that the aspect is a first-class stored thing with a type, not a computed window and not a permission. Where a view re-presents the base rows on every read and stores nothing, a role-scoped record type materializes the aspect as a separate persisted record, linked back to the bearer but standing on its own — which is why it needs its own key and, crucially, an explicit rule for reconciling clashes the bearer link inevitably produces.
Example¶
A hospital's information system must model that the same human can be both a patient and a clinician. Rather than overload one person-record with fields for both, it defines two record types. Under the HL7 FHIR standard these are literally different resource types — a Patient resource and a Practitioner resource — each with its own schema and its own identifier, both linkable to the same underlying human.[n1] The Patient record carries medical-record number, allergies, and next of kin; the Practitioner record carries license number, specialty, and scheduling.
Because both records can name the person's demographics, the type must say what happens when they disagree — if the patient record lists one date of birth and the practitioner record another. The record type's conflict rule declares a source of truth (say, demographics are owned by the person-record and both aspects inherit them, so neither may fork) while role-local fields (allergies, specialty) are owned outright by their own record. Each record has its own key — the medical-record number is not the license number — so the patient aspect and the practitioner aspect are addressable, storable, and auditable as separate typed objects that happen to share a human.
How it works¶
- Declare the type. Define the aspect as a named record type with a fixed field set — the role-local attributes plus the reference to the underlying bearer.
- Select on role. The type exists because of a role; which entities get a record of this type is decided by the role selector, not by every entity automatically.
- Assign a scoped key. Each record gets its own identifier under a rule that keeps it distinct from the bearer's key and from other role records, so it can be stored and referenced independently.
- Encode conflict resolution. State, per field, who wins when the record and the bearer (or another aspect) disagree — inherit-and-freeze, local-overrides, or flag-for-review — so clashes resolve by rule rather than by whoever wrote last.
Tuning parameters¶
- Field locality — how many fields are owned locally versus inherited from the bearer. More local fields make the aspect self-contained but multiply what can drift from the bearer.
- Key independence — whether the record's key is derived from the bearer's or fully independent. Independent keys decouple lifecycles; derived keys keep the link obvious but couple them.
- Conflict policy — inherit-and-freeze, local-override, or manual reconciliation for clashing fields. Automatic policies are cheap but can entrench a wrong value; manual review is safe but slow.
- Type rigidity — a fixed schema versus an extensible one. Rigid types guarantee shape and validation; extensible ones bend to edge cases at the cost of predictability.
- Duplication guard — how strictly the type prevents two records of the same role for one bearer. Strict guards stop proliferation; loose ones tolerate legitimate multiplicity (two separate patient episodes).
When it helps, and when it misleads¶
Its strength is that it gives an aspect a durable, typed, independently addressable home. Role-local data lives in a record that validates to its own schema, survives on its own key, and reconciles disagreements with the bearer by an explicit rule rather than by accident — which is exactly what the archetype needs when an aspect "must survive changes in some underlying properties but not others." It is the right choice when the aspect genuinely accrues its own data over time, not just a filtered look at the bearer's.
It misleads through over-fragmentation and silent drift. Because each record stores its own copy of anything it doesn't strictly inherit, demographics duplicated across a patient and a practitioner record can diverge — the archetype's "duplicate records proliferate" symptom made concrete — unless the conflict rule truly pins a single source of truth. The classic misuse is minting a fresh record type for every passing context until one human sprawls across a dozen weakly-linked records nobody can reconcile. The guarding discipline is master-data hygiene: keep shared attributes owned by exactly one record and inherited everywhere else, enforce the conflict rule at write time, and reserve a new record type for aspects that genuinely own local data rather than merely re-present the bearer's.
How it implements the components¶
aspect_or_role_selector— the record type exists for a specific role and is created only for entities in that role, which is the selector in schema form.scoped_identifier_rule— each record carries its own key under a rule that keeps it distinct from the bearer and from sibling aspects, making it independently addressable.aspect_conflict_resolution_rule— the per-field policy for who wins when the record and the bearer (or another aspect) disagree is stored on the type itself.
It does not implement projection_scope_boundary, derived_bearer_record, or property_inheritance_and_exclusion_map — this type stores a real record with its own key rather than computing a window over the source; the read-time projection that stores nothing is its nearest twin, Database View or Entity Projection.
Related¶
- Instantiates: Aspect-Scoped Identity Projection — the stored, typed way to give an aspect a record of its own linked back to the bearer.
- Sibling mechanisms: Database View or Entity Projection · Aspect Lifecycle Register · Legal Capacity or Status Record · Role-Based Access Profile · Scoped Namespace Suffix · Typed Identity-Relation Edge · Work / Expression / Manifestation / Item Model
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Role-Scoped Record Type operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it defines a distinct stored record type for an entity under a role, with its own key and its own rules for reconciling clashes with the underlying entity.
Independent corroboration: The frozen evidence defines Role-Scoped Record Type as 'Defines a distinct stored record type for an entity under a role, with its own key and its own rules for reconciling clashes with the underlying entity', so its operative form is Representation, Specification & Plan.
Nearest alternative: Structure, Architecture & Configuration — Role-Scoped Record Type includes features of a configured physical, technical, or logical arrangement whose structure creates the effect, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Specialized
Rationale: Distinct role-qualified record types and reconciliation rules are data-modeling mechanisms.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: defines a distinct stored record type for an entity under a role, with its own key and its own rules for reconciling clashes with the underlying entity.
- Library & Information Science — Authority records and role-specific descriptions materially inform entity-versus-role representation.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement starts from reviewer_a’s mechanism-specific evidence: Distinct role-qualified record types and reconciliation rules are data-modeling mechanisms. Reviewer A proposed alternates=library_information_science, origin_mode=convergent, domain_reach=specialized, and encyclopedia_synthesis=false; reviewer B proposed alternates=engineering_design, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=true. The final record retains every independently supported alternate from either review (library_information_science, engineering_design) without an arbitrary cap, selects origin_mode=convergent to represent the combined lineage evidence, and keeps domain_reach=specialized and encyclopedia_synthesis=false from the more mechanism-specific assessment. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] HL7 FHIR models the same real-world human as separate resource types — Patient, Practitioner, RelatedPerson — each a distinct record with its own identifier, linkable to the others. It is a working example of one entity carrying several role-scoped record types rather than one overloaded record. ↩