#U.RoleAssignment - System Role Assignment

A.2.1 · Stable · Definitional (D) · Normative unless marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

Plain name. System role assignment.

#Keywords

• assignment occurrence
• holder System
• role value
• role-taxonomy episteme
• effective ReferenceScheme
• AssignmentInterval
• performedUnderAssignment.

#Relations

#Content

#Use This When

Plain name. System role assignment.

Use this pattern when another claim must rely on which admitted U.System holds which enactment-facing U.Role, under which role vocabulary and interpretation scheme, during which assignment window.

Typical moments:

• a method description names InspectorRole, but the current holder and assignment window are still unstated;
• a performed-work attribution is needed: one exact dated Work occurrence W and one exact assignment RA participate in performedUnderAssignment(W, RA), the direct relation governed by F.6; the actual performer is the admitted holder System S = RA.HolderSystemSlot, and a separate assertion may designate W and RA;
• the same system receives the same role during two separate assignment episodes;
• a DDD-style model-use organization changes the interpretation of an otherwise identical role assignment;
• a constituting decision or installation relation may establish a specialized assignment occurrence;
• a roster entry, configuration line, observation, or evidence relation may support an assignment claim without becoming an assignment slot.

Primary EntityOfConcern. The EntityOfConcern is one obtaining U.RoleAssignment relation occurrence. Its four required actual participants are an admitted U.System holder, one U.Role value, the role-taxonomy episteme, and the effective U.ReferenceScheme under which that value is interpreted. The occurrence has a maximal continuous temporal extent determined by uninterrupted obtaining; an assignment assertion or occurrence description may state the currently known extent as an AssignmentInterval.

Primary working reader. The first reader is an engineer-manager, analyst, method author, or FPF author who must make role admission or work attribution inspectable without turning role, capability, method, performed work, evidence, or publication into one assignment relation occurrence.

First useful move. Write a readable assignment assertion naming the four required participants and the assignment episode being claimed. State the currently known temporal extent separately. Explicitly individuate the relation occurrence only when a receiving claim must distinguish this assignment episode from another rather than merely recognize that the direct relation obtains.

What goes wrong if missed. A role label is mistaken for an assignment, repeated episodes collapse into one timeless relation, or a database row is treated as what makes the assignment obtain. Work may then be attributed to the wrong holder or assignment episode, while evidence, capability, and method claims become hidden fields of the assignment.

What this buys. Assignment identity becomes stable enough for method admission, role-state checking, and work attribution while ordinary prose remains lightweight. The assignment relation has one exact identity rule; all support, decision, capability, method, work, evidence, and publication claims keep their direct governing patterns.

Not this pattern when.

• Use A.2 for role-value interpretation and the role taxonomy itself.
• Use A.2.2 for holder capability, A.2.5 for role state, and A.2.7 for selected relations among role values.
• Use A.3.1, A.3.2, and A.15 for method and role-admission conditions.
• Use A.15.1 and F.6 for performed work and its attribution through an assignment.
• Use the direct decision, responsibility, commitment, evidence, reliance, provenance, publication, external-rule, or currentness pattern when that relation is current.
• Use A.6.5 when an external relation notation labels a participant role and the current task is to recover its exact SlotKind and ValueKind.

#Problem Frame

A role value does not assign itself. InspectorRole may be understood under a role taxonomy, yet no robot, person, or service holds it until an assignment relation obtains. Conversely, the same system can hold several roles without changing system identity, and the same holder-role pair can enter several assignment episodes.

An admitted holder may be a person or another kind of U.System. Holding the role does not by itself establish consciousness, intention, legal or ethical accountability, permission, or gate passage; each stronger claim needs its direct governing pattern.

Role meaning is local to a role-taxonomy episteme and effective reference scheme. Assignment locality therefore needs those four actual relation participants directly, not a mandatory U.BoundedContext. When an actual DDD-style model-use organization changes one receiving interpretation, the receiving assertion or work use may designate the selected BoundedModelUseStructure; the structure is not an optional participant of generic U.RoleAssignment.

Assignment is also not performed work. A current assignment may exist before any work occurs. When work does occur, the admitted holder System S = RA.HolderSystemSlot performs exact Work W under exact assignment RA; F.6 owns the direct performedUnderAssignment(W, RA) relation. Capability, role state, method admission, responsibility, assignment decisions, and evidence remain separate relations with their own obtaining and currentness conditions.

#Problem

Without this pattern:

1. a role name is used as if it identified a holder and assignment episode;
2. role value, taxonomy episteme, interpretation scheme, holder, and time are compressed into one label;
3. two assignments with the same holder and role but disjoint windows become one occurrence;
4. assignment is treated as proof of capability, method admission, role state, performed work, or authorization;
5. a constituting assignment decision or installation relation and epistemic evidence or provenance collapse into one untyped justification field;
6. an optional DDD model-use structure is made mandatory or identity-bearing without showing that it changes interpretation.

#Forces

#Solution

State the direct assignment in readable prose first. When another claim needs reusable participant typing or occurrence identity, use the RelationSignature for U.RoleAssignment governed here and declared through A.6.0 and A.6.5. The signature is an episteme about the relation kind; it is not the world-side assignment occurrence. Its SlotSpecs are:

The four SlotSpecs declare all participant meanings of generic U.RoleAssignment. No SlotSpec is declared for the occurrence's temporal extent or for a selected model-use structure used only to qualify a receiving interpretation.

AssignmentInterval is a local content ValueKind for an assignment assertion or relation-occurrence description, not a U-kind and not the ValueKind of a relation-participant SlotSpec. An assignmentInterval field states the currently known temporal extent through a temporal reference, a start boundary, an end boundary or explicit open end, and the continuity claim used to recognize one uninterrupted assignment episode. The world-side occurrence has that temporal extent under its direct identity rule. The field describes the extent and does not make the relation obtain. A shift label is sufficient only when those temporal facts can be resolved. C.27.TA governs fuller temporal-aspect description when the temporal reference or interval itself becomes a relied-on object.

U.RoleAssignment obtains when the admitted system holds the role value, interpreted by the named role-taxonomy episteme under the effective reference scheme, throughout one continuous assignment episode. An assignment assertion is a U.Episteme claiming that this relation obtains. A roster entry or configuration line may express that assertion, and a publication may expose it; evidence may support relying on it. None of those epistemic or representation-side objects makes the world-side relation obtain merely by existing.

#Relation-Occurrence Identity

Do not replace the identity rule with a tuple key. One generic U.RoleAssignment occurrence begins when the assignment predicate starts obtaining for one fixed holder system, role value, role-taxonomy episteme, and effective reference scheme. It continues while that predicate obtains without interruption for those same four actual participants. It ends when the predicate ceases to obtain or one of those participants changes. A later resumption starts another occurrence.

An assignment assertion or occurrence description may carry an AssignmentInterval stating the currently known temporal extent of that occurrence. [start, open] can designate the current episode before its end is known. Recording the end boundary later refines the description of the same occurrence when obtaining was continuous. A gap in available evidence remains unknown and does not by itself split the occurrence. A demonstrated period of non-assignment ends the occurrence; a later resumption begins another. Two descriptions refer to the same occurrence only when they resolve to the same four participants and to temporal information belonging to that one uninterrupted period.

A selected model-use structure does not enter generic assignment identity. A genuinely structure-dependent relation species requires its own direct pattern, a required identity-bearing structure participant, a stronger predicate, and an explicit occurrence-identity rule.

#Filling the Declared Slots

Resolve HolderSystemSlot through U.EntityRef and check that its referent is an admitted U.System. Embed RoleValueSlot and EffectiveReferenceSchemeSlot by value. Resolve RoleTaxonomyEpistemeSlot through U.EpistemeRef to the exact episteme edition used for interpretation. If a receiving assertion or work use depends on a selected BoundedModelUseStructure, designate that structure in the receiving episteme or use relation under its direct governor.

Those four required designations correspond to the actual participants under the declared participant meanings. State the currently known temporal extent separately as assignmentInterval in the assertion or occurrence description. Assignment decision, responsibility, evidence, provenance, installation work, role state, capability, performed work, selected model-use structure, and publication remain separate objects or relation occurrences under their own governing patterns.

#Well-Formedness Predicates

RA-1 HolderAdmission:
  the U.EntityRef filling HolderSystemSlot resolves to an admitted U.System.

RA-2 RoleInterpretation:
  the U.Role filling RoleValueSlot is interpreted through the exact
  taxonomy episteme and effective reference-scheme fillings.

RA-3 AssignmentEpisode:
  the assignment predicate obtains without interruption for the four required
  actual participants; any assignmentInterval states the currently known
  temporal extent in an assertion or occurrence description.
RA-4 NoAssignmentOverread:
  the assignment occurrence alone does not establish capability,
  role state, method admission, performed work, responsibility,
  authorization, evidence sufficiency, or publication currentness.

RA-5 InterpretationQualification:
  any selected model-use structure is designated by the receiving assertion
  or work use, not as a participant of generic U.RoleAssignment.

An evidence gap makes the assignment claim unknown or unrecovered; it does not demonstrate that the assignment predicate failed. A demonstrated non-assignment interval, by contrast, ends the current occurrence.

#Demand-Driven Materialization

Ordinary use can stop at a readable direct assertion:

During Shift-17, Robot-7 holds InspectorRole as interpreted by
MaintenanceRoles-2026 under Maintenance-Scheme-A.

Expose the relation occurrence explicitly only when a receiving claim needs to refer to it, distinguish it from another episode, or use it as a participant. If any required participant filling or the continuity of the assignment episode cannot be recovered, keep the assertion reduced or lower the receiving claim. Do not insert a dummy filling or put a value of another kind into a declared slot.

#Direct Neighboring Relations

A constituting decision, installation relation, or another assignment-establishing occurrence can help make a specialized assignment relation obtain only when that direct ontology says so. Evidence, reliance, and provenance relations instead support knowledge or use of the assignment claim. Do not use epistemic support as the world-side constituting condition by default.

#Performed-Work Attribution

When dated work is performed under role holding, name the admitted holder System, exact Work, and exact assignment directly:

Robot-7 performed InspectionWork-17 under RoleAssignment-17.
performedUnderAssignment(InspectionWork-17, RoleAssignment-17)

Robot-7 is the admitted System in RoleAssignment-17.HolderSystemSlot. [A.15.1](/generated/patterns/A.15.1) governs InspectionWork-17; [A.2.1](/generated/patterns/A.2.1) governs RoleAssignment-17; [F.6](/generated/patterns/F.6) owns the attribution relation. The assignment does not prove that work occurred, and the work occurrence does not alter assignment identity.

If source wording says RoleEnactment, recover the dated U.Work occurrence, exact U.RoleAssignment, admitted holder System, and direct performedUnderAssignment(W, RA) relation. Do not introduce a second run-time U-kind or relation occurrence beside work and assignment.

#Legacy Context Shorthand

Holder#Role:Context@Window is source notation, not the assignment ontology. Context is an untyped source label here. Recover the exact referent, its kind, and the direct relation that makes it relevant. If it denotes an independently selected BoundedModelUseStructure that changes a receiving interpretation, designate that structure in the receiving assertion or work use. Otherwise keep the recovered referent in its own direct relation; never invent a generic context or model-use participant for U.RoleAssignment.

#Archetypal Grounding

#Robot Assigned for One Inspection Shift

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: Robot-7
    RoleValueSlot: InspectorRole
    RoleTaxonomyEpistemeSlot: MaintenanceRoles-2026
    EffectiveReferenceSchemeSlot: Maintenance-Scheme-A
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

The four SlotKind-labelled fields designate the actual relation participants. The assignmentInterval field states the assertion's temporal description of the occurrence; it is not a fifth relation-participant designation. During the shift, the direct assignment predicate obtains for the four actual participants—Robot-7, InspectorRole, MaintenanceRoles-2026, and Maintenance-Scheme-A; the displayed RoleAssignmentAssertion states those participant designations and describes the occurrence's temporal extent. Sensor capability, current role state, the inspection method, and any performed inspection work remain separate claims.

#Repeated Assignment Episodes

Robot-7 is assigned the same role again on the next day under the same taxonomy and scheme. The four stable participant fillings match, but the assignment predicate does not obtain continuously across the two shifts. The second shift is therefore another U.RoleAssignment occurrence. A staffing table that reuses one row identifier must not collapse the two world-side episodes.

#Motor Holding a Drive Role

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: Motor-M1
    RoleValueSlot: DriveMotorRole
    RoleTaxonomyEpistemeSlot: PumpAssemblyRoles-v4
    EffectiveReferenceSchemeSlot: Pump-A-Operating-Scheme
  assignmentInterval: [2026-07-01T08:30, open]

The open end says that this episteme does not yet state the occurrence's end. Extending or later closing that temporal description does not create another assignment while the direct predicate obtains continuously for the same four participants. The holder is the motor as a U.System. Pump Assembly A is the actual system in which installation and work occur; it is not an assignment context slot. Torque capability, electrical interface relations, installation work, and a later pumping run remain direct neighboring claims.

#DDD Model-Use Structure Changes a Receiving Interpretation

Two software teams use ApproverRole under different model vocabularies. In the fulfilment model it admits acceptance of a fulfilment-state transition; in the payment model it admits payment authorization. The generic assignment still has exactly four participants:

RoleAssignmentAssertion:
  participantDesignations:
    HolderSystemSlot: ApprovalService-2
    RoleValueSlot: ApproverRole
    RoleTaxonomyEpistemeSlot: FulfilmentRoles-v3
    EffectiveReferenceSchemeSlot: Fulfilment-Approval-Scheme
  assignmentInterval: [2026-07-13T10:00, 2026-07-13T18:00]

ReceivingInterpretationUse:
  roleAssignmentRef: ApprovalService-2-ApproverAssignment
  selectedModelUseStructureRef: Orders-Fulfilment-ModelUseStructure

The second block belongs to the receiving assertion or work use. It does not add a fifth participant to U.RoleAssignment and does not change generic occurrence identity. The selected structure was independently recovered under [A.1.1](/generated/patterns/A.1.1); it neither assigns the service nor performs approval work. If a future dependent relation species truly obtains only with one selected structure, its direct pattern must declare that structure as a required identity-bearing participant.

#Reviewer and Review Report

ReviewService-4 holds ReviewerRole through ReviewService-4-ReviewerAssignment and, as that assignment's admitted holder System, performs ReviewWork-82 under it through F.6 performedUnderAssignment(ReviewWork-82, ReviewService-4-ReviewerAssignment). ReviewReport-82 is a separately identified U.Episteme; when the work first constitutes that exact episteme and the inception claim matters, A.15.PROD recovers the local work/change/identity claim. Its content may state a review judgment under the direct evaluation pattern. A later evidence relation may use the report for another claim; the report never fills HolderSystemSlot merely because it is useful.

#Bias Annotation

#Working Guidance

1. State the assignment predicate in ordinary language.
2. Name the four required relation participants, then state the currently known temporal extent separately as an AssignmentInterval in the assertion or occurrence description.
3. Decide whether a receiving use needs explicit occurrence identity. Stop at the readable assertion when it does not.
4. Distinguish repeated episodes by temporal extent; do not use a database row identifier as the discriminator.
5. Keep capability, role state, method admission, performed work, responsibility, decision, evidence, reliance, provenance, and publication under their direct patterns.
6. When a selected model-use structure changes a receiving interpretation, designate it in that receiving assertion or use; do not extend the generic assignment signature.
7. For old Context shorthand, recover its exact referent, kind, and direct governing relation before continuing.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

U.RoleAssignment is admitted because a role value and holder identity answer different questions. U.Role is the admitted kind for role values; one exact role value carries the work-facing participation meaning. One obtaining assignment occurrence RA : U.RoleAssignment relates one admitted System to that role value through one role-taxonomy episteme and one effective reference scheme over its maximal continuous extent. A separately identified assignment assertion or description may designate those four participants and state the occurrence's temporal extent. U.Work is the admitted kind for work individuals; one W : U.Work is the world-side dated occurrence. A separate assertion or record may say that W occurred and state its obtaining relations.

The assignment is a relation occurrence, not a relation value stored in a row. Its participant meanings and temporal episode provide the domain identity required by A.6.REL. This prevents two opposite errors: treating every role label as a complete assignment, and requiring explicit assignment-occurrence individuation for casual recognition text.

The role-taxonomy episteme and effective reference scheme provide semantic locality directly. They remove the need for mandatory U.BoundedContext. A selected model-use structure remains available to a receiving assertion or work use without becoming an agent, role taxonomy, generic assignment participant, or identity component.

#SoTA-Echoing

#Relations

Builds on: A.2 for U.Role; A.6.REL for relation obtaining and occurrence identity; A.6.5 for SlotSpec discipline; C.2.1 for the role-taxonomy episteme and effective reference scheme.

Coordinates with: A.2.2 for capability; A.2.5 for role state; A.2.7 for selected role relation structure; A.3.1, A.3.2, and A.15 for method admission; A.15.1 and F.6 for performed-work attribution.

Uses when current: A.1.1 for an optional selected model-use structure; F.9 and A.6.9 for cross-scheme alignment; direct responsibility, decision, evidence, reliance, provenance, currentness, and publication patterns for claims about the assignment occurrence.

Does not replace: role value, role state, capability, method, work, assignment decision, evidence, publication, or their descriptions.

#A.2.1:End

Last Updated: 2026-08-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)