#U.RoleAssignment: Contextual 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. Work-role assignment.

#Aliases

• U.RoleAssignment

#Keywords

• Standard
• holder
• role
• context
• RoleEnactment
• RCS/RSG.

#Relations

#Content

#Use This When

Plain name. Work-role assignment.

Use this pattern when a project must say which system, organization, person, team, service, agent, device, or other acting holon holds which U.Role in which bounded context, and when that assignment is current enough to admit, check, plan, or attribute work.

Typical moments:

• a work record says that "Alice reviewed", "Robot-7 inspected", "CI bot deployed", or "the operations team approved" and the role, holder, bounded context, or assignment window is missing;
• a method or method description names required roles, but the project has not linked those roles to concrete performers;
• a role state, capability requirement, separation-of-duties rule, or work gate depends on who holds the role now;
• an old source phrase gives an episteme an "evidence role", "standard role", "status role", or "requirement role" and the text must be repaired without making epistemes into work performers;
• a local notation such as Holder#Role:Context@Window is useful, but the notation must not replace the typed relation it abbreviates.

Primary EntityOfConcern. The EntityOfConcern is U.RoleAssignment: a typed work-facing assignment relation value. It links an admitted acting holder, a U.Role, a U.BoundedContext, and any assignment-currentness window or assignment source that is current for the claim.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who needs work attribution, role admission, role-state checks, method requirements, or responsibility language to remain inspectable across contexts and editions.

First useful move. Recover the four core slots of the assignment relation: holder, role value, bounded context, and assignment window when current. Then recover any direct work-role qualifier, role-state admission, capability requirement, method requirement, work-plan relation, or work occurrence through its governing pattern.

What goes wrong if missed. Role labels float without holders or contexts. A method appears to have been enacted by a document. A work record names a person but not the role under which the work was admitted. A report or standard is treated as if it held a role because it is used as evidence or requirement source. The corpus then grows one role ontology for work and a second role ontology for epistemes.

What this buys. U.RoleAssignment gives one narrow relation for work-facing role holding. It keeps role values reusable, work attribution replayable, method requirements checkable, and episteme evidence or status uses outside the role-assignment relation.

Not this pattern when.

• If the current claim is the role value itself, role taxonomy, or role relation-neighborhood, use A.2.
• If the current claim is ability or operating envelope, use A.2.2.
• If the current claim is role state, role-state predicate, or enactable-state admission, use A.2.5.
• If the current claim is role-requirement substitution, incompatibility, qualification, or role bundle, use A.2.7.
• If the current claim is method, method description, work plan, performed work, or role-method-work alignment, use A.15 and the direct A.15 subpattern.
• If the current claim is evidence, source, standard, requirement, definition, explanation, publication, status, assurance, gate, or decision use of an episteme, use the direct pattern for that relation. Do not make the episteme a U.RoleAssignment holder.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.

#Problem Frame

Work-facing roles are useful only after they are connected to concrete holders in a bounded context. "Reviewer", "operator", "deployer", "inspector", "authorizer", and "coordinator" are not enough by themselves. The project needs to know which holder bears the role, in which context, for which window or current claim, and under which neighboring role-state, capability, method, plan, and work relations.

The assignment relation must be narrow. It should not absorb capability, method, work, evidence, status, or publication use. A standard used as a requirement source can constrain work, but it does not hold a work-facing role. A report can be used as evidence, but it does not perform the review that produced it. A method description can require ReviewerRole, but the method description is not the reviewer.

A.2.1 therefore defines U.RoleAssignment as a typed relation value using A.6.5 SlotSpec discipline. The relation is work-facing: its holder is a U.System or acting holon admitted as system-like performer by the governing work or method pattern. Epistemes stay in evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, assurance-use, gate-use, or decision-use relations.

#Problem

Without this pattern:

1. Role labels do not identify performers. Work records name a role-like word, but not the holder and context needed for attribution.
2. Assignment and role collapse. The role value, the holder, the bounded context, and the assignment window become one label.
3. Assignment and capability collapse. A role assignment is treated as evidence of ability, even though capability has its own envelope and evidence.
4. Assignment and method collapse. Holding a role is treated as if the holder automatically has a method or has already performed work.
5. Episteme-role drift returns. Standards, reports, datasets, definitions, requirements, and model cards are described as role holders instead of being related through evidence, status, source, publication, requirement, or assurance relations.
6. RoleEnactment becomes a second run-time object. A derived performed-by fact is mistaken for a durable U-kind beside U.Work.
7. Slot discipline is lost. Holder, role value, context, window, justification, provenance, and qualifier positions are not recoverable as distinct SlotKinds.

#Forces

#Solution

Use U.RoleAssignment for the typed relation that assigns a work-facing U.Role to an admitted acting holder in one bounded context.

RoleAssignmentCoreSlotSpec:
  HolderSlot:
  RoleValueSlot:
  BoundedContextSlot:
  AssignmentWindowSlot:
  AssignmentJustificationSlot:
  AssignmentProvenanceSlot:

This is a relation value. A record, registry row, publication, diagram, or file may describe, cite, or store the relation value. It is not the assignment itself by default.

#Core SlotSpecs

Direct work-role patterns may declare additional work-role qualifier SlotSpecs. Evidence-use and status-use relation slots are not assignment qualifiers unless a direct work-role pattern explicitly makes that work-role claim.

#Well-Formedness Constraints

Use these constraints as predicates over a filled assignment relation.

Invariant RA-S1 (Local role):
  RoleValueSlot content is a U.Role admitted in the BoundedContextSlot content.

Invariant RA-S2 (Holder admission):
  HolderSlot content is a U.System or an acting holon admitted as system-like performer by the governing work or method pattern.

Invariant RA-S3 (No role-as-holder):
  HolderSlot content is not U.Role and not U.RoleAssignment.

Invariant RA-S4 (No episteme holder by use):
  U.Episteme is not admitted as HolderSlot content merely because the episteme is used as evidence, source, standard, requirement, definition, explanation, publication, status bearer, or assurance input.

Invariant RA-S5 (Context locality):
  Cross-context assignment reuse requires a named bridge or direct context relation; shared labels do not create sameness.

Invariant RA-S6 (Window honesty):
  A claim that depends on current assignment validity names AssignmentWindowSlot content, inherits a declared bounded-context default, or states that the window is unknown, not recovered, not asserted, or blocking for the stronger claim.

Do not express these predicates with RFC-style deontics unless the sentence is imposing a duty on an author, validator, or published record.

#Open-World Slot Disposition

The SlotSpecs are a thinking discipline, not a demand to fill a form for every casual use.

Use these dispositions:

• filled: the relation instance names the slot filler or reference;
• inherited: the role definition or bounded-context rule fixes the value for the current claim;
• unknown or not recovered: the slot is relevant, but the project has not recovered it;
• not asserted: the text deliberately makes no claim about this slot;
• not current for this claim: the slot exists in the model, but the present claim does not depend on it;
• claim lowering or blocker: a stronger claim depends on the slot, so missing content lowers or blocks that claim.

For example, a quick staffing note may only need holder, role, and context. A safety-critical work attribution claim needs the assignment window, role-state admission, and method or work relation that the note omitted.

#Role State and Role-Description Characterization Hooks

U.RoleAssignment does not contain a role-state relation or a role-state description. The U.Role and its role description may be linked to:

• RoleCharacteristicSpace, the characteristic space used to describe role variants or role requirements in one bounded context;
• Role State Relation, the state-family relation used to decide whether a role assignment is in an enactable state;
• state assertions or evaluations governed by A.2.5 and the relevant evidence or evaluation pattern.

A work attribution claim may depend on those neighboring values. The assignment relation names the holder, role, context, and window; A.2.5 governs whether the assignment is in an enactable state for the current work.

#Role Assignment and Work

Work is not performed by the role value. Work is performed by the holder under a role assignment.

Use the direct relation:

Work.performedBy = RoleAssignment

Then check neighboring claims:

• the work occurrence is governed by [A.15.1](/generated/patterns/A.15.1);
• the selected method is governed by [A.3.1](/generated/patterns/A.3.1);
• the method description or required-role declaration is governed by [A.3.2](/generated/patterns/A.3.2) and [A.15](/generated/patterns/A.15);
• the work plan is governed by [A.15.2](/generated/patterns/A.15.2);
• role-state admission is governed by [A.2.5](/generated/patterns/A.2.5);
• capability is governed by [A.2.2](/generated/patterns/A.2.2).

A U.Work record may cite performedBy = some U.RoleAssignment. That citation does not make the work record the assignment and does not make the assignment a work occurrence.

#RoleEnactmentFact

Older FPF text used U.RoleEnactment. Current FPF treats role enactment as a derived relation or fact over U.Work and U.RoleAssignment, not as a durable U-kind.

Use this named fact only when a named relation is clearer than direct performedBy wording:

RoleEnactmentFact:
  workOccurrence: U.Work
  performedBy: U.RoleAssignment
  methodTrace?: U.Method or U.MethodDescription reference when current
  window?: inherited from work occurrence or role assignment when current

If a database, log, table, or publication stores a role-enactment entry, it stores a record of the fact unless a direct governing pattern admits record-as-value for that use.

#Episteme Evidence, Status, Source, and Publication Uses

Do not use U.RoleAssignment for an episteme merely because the episteme is useful in a project relation.

The repair is not to find a nicer role word. The repair is to recover the current relation and its slot fillers.

#Shorthand Notation

The compact notation is:

Holder#Role:Context@Window

Use it only as a readable notation for the typed assignment relation.

Examples:

• Robot_7#InspectorRole:MaintenanceLine_A@2026-06-15T09:00..2026-06-15T11:00
• OpsTeam#IncidentCommanderRole:PlantIncident_2026@open
• CI_Service#DeployerRole:ReleaseTrain_2026@2026-Q2

If the notation is missing the window, the current text must still say whether the window is inherited, unknown, not asserted, or not current for this claim when the claim depends on assignment currentness.

#Archetypal Grounding

#Industrial Inspection Work

A maintenance line assigns an inspection role to a robot for one shift.

Robot_7#InspectorRole:MaintenanceLine_A@2026-06-15T09:00..2026-06-15T11:00

The holder is a system. The role value is InspectorRole. The bounded context is MaintenanceLine_A. The assignment window covers the planned inspection shift.

This does not assert that the robot has the required sensor capability. Capability stays under [A.2.2](/generated/patterns/A.2.2). It does not assert that inspection work already occurred. Performed work stays under [A.15.1](/generated/patterns/A.15.1). It only gives later method, plan, role-state, and work-attribution claims a typed assignment relation to cite.

#Software Deployment

A release train has a deployment method description with a step requiring DeployerRole.

CI_Service#DeployerRole:ReleaseTrain_2026@2026-Q2
Work DeploymentRun_418 performedBy CI_Service#DeployerRole:ReleaseTrain_2026

The assignment relation admits a candidate performer. The work occurrence still needs the method or method-description relation, the assignment window, and any enactable role-state assertion required by [A.2.5](/generated/patterns/A.2.5). A green test suite, ticket approval, or policy rule may justify the assignment or the work gate, but those are neighboring evidence, gate, or policy relations, not hidden role values.

#Review Report and Reviewer

A human reviewer or review service can hold ReviewerRole in a review context. The review report produced by that work is an episteme.

Later, another team may use the report as evidence for a claim. That later relation is evidence-use around the report. The report does not hold ReviewerRole; the reviewer holder did.

#Standard Used in Safety Work

The source sentence "ISO 26262 has the normative standard role in this safety case" is repaired as a standard-use or requirement-use relation around an episteme. If a safety engineer performs work using that standard, the engineer or engineering team may hold a work-facing role assignment. The standard constrains, defines, or supplies source material; it does not perform work and does not become a holder in U.RoleAssignment.

#Bias Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

A.2.1 makes work attribution and role admission replayable. A reader can ask: who is the holder, what role value is assigned, which bounded context gives that role meaning, and which window or source is current for the claim?

The benefit is compactness. FPF can keep one role-assignment relation for work-facing roles instead of multiplying role kinds for documents, standards, reports, dashboards, interfaces, method descriptions, and relation arguments.

The cost is discipline. Authors must recover neighboring claims instead of putting them into assignment prose. Capability, role state, method, work plan, performed work, evidence, status, publication, assurance, gate, and decision claims each keep their governing pattern.

Reopen A.2.1 only when the core assignment relation changes: admitted holder kinds, SlotSpecs, assignment-currentness discipline, direct work-role qualifiers, or the treatment of RoleEnactmentFact. Reopen neighboring patterns when the dispute is about capability, role state, method, work, evidence, status, source, publication, assurance, gate, or decision use.

#Rationale

The role ontologicalNeighborhood needs both role values and assignment relations. A.2 keeps U.Role as a compact context-bound value. A.2.1 gives that value a typed relation to a holder and context. A.15 then lets work cite the assignment.

The selected ontology prevents two common explosions. First, it prevents every context-local role from becoming a system subtype. Second, it prevents every evidence or status use of an episteme from becoming another role assignment.

The open-world slot model is deliberate. FPF should not require dummy windows or provenance entries for low-risk recognition text. It should also not permit stronger claims to rely on missing windows, missing role-state admission, or missing assignment source. The slot is considered when the claim needs it.

#SoTA-Echoing

#Relations

Builds on.

• A.1 and A.1.1 for holons, systems, and bounded contexts.
• A.2 for U.Role identity, taxonomy, and role relation-neighborhood.
• A.6.5 for SlotSpec discipline.

Coordinates with.

• A.2.2 for capability.
• A.2.5 for role state, role-state relation, role characterization, and enactable-state admission.
• A.2.7 for context-local role relation structure.
• A.15, A.15.1, and A.15.2 for method, work plan, work occurrence, and performed-by relation.
• A.3.1 and A.3.2 for method and method-description required-role relations.
• A.10, B.3, C.2.1, C.28, F.10, G.6, E.17, and E.10.D2 for evidence-use, status-use, source-use, publication-use, assurance, causal-use, and description-boundary cases that older text tried to express as episteme roles.

Does not replace.

• U.Work, U.Method, U.MethodDescription, U.WorkPlan, U.Capability, evidence relations, status assertions, gate decisions, commitments, permissions, or publication forms.
• A.6.5 relation-slot discipline. A.2.1 uses it for this assignment relation; it does not become a second slot discipline.

#A.2.1:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)