#Role Taxonomy

A.2 · Stable · Architectural (A) · 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: Architectural (A) Status: Stable Normativity: Normative unless marked informative

Plain name. Work-facing role value.

#Keywords

• role
• assignment
• holder
• context
• function vs identity
• responsibility
• U.RoleAssignment.

#Relations

#Content

#Use This When

Plain name. Work-facing role value.

Use this pattern when a project needs to say what a system, organization, person, team, tool, agent, machine, or other acting holon is being in a bounded context before method, plan, work, evidence, responsibility, or naming claims can be made safely.

Typical moments:

• a project sentence says "engineer", "reviewer", "operator", "supplier", "model verifier", "agent", "service provider", or another role-like name, and it is unclear what holder, context, and work claim are current;
• a team treats a role name as if it created capability, commitment, obligation, permission, method, work, or evidence;
• a standard, report, dataset, model card, publication, requirement, or definition is described as having a "role" in evidence, status, assurance, source use, or publication use;
• a method, plan, work occurrence, or result is attributed to a role without naming the holder and role assignment under which the work is performed;
• role names must be kept reusable across contexts without making each context-local role into a new system kind.

Primary EntityOfConcern. The EntityOfConcern is U.Role: a context-bound role value in the role ontologicalNeighborhood. A role value names what an acting system or acting holon is being for a bounded context. It is not the holder, not the assignment relation, not a capability, not a method, not a work occurrence, not a commitment, not an obligation, not a permission, not a description, and not a slot kind.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who must separate role value, holder, role assignment, method, plan, work, evidence, and source-use claims before acting or writing a pattern. The downstream reader is the project participant who needs role language to answer who held what role, in which context, for which claim.

First useful move. Name the role value, the bounded context, and whether the current claim is about role identity, a role assignment, role description, role state, role relation structure, capability requirement, method requirement, planned work, performed work, or an episteme used as evidence, source, standard, requirement, definition, explanation, status bearer, or publication.

What goes wrong if missed. Role words become an ontology shortcut. A document becomes a "verifier role"; a capability becomes a role; a role name is treated as evidence that work happened; a method is treated as a role's hidden behavior; a publication is treated as if it acted. FPF then grows a second role ontology for epistemes, status labels, access labels, relation arguments, and source labels.

What this buys. A small role vocabulary can serve many projects without type explosion. The same system can hold different roles in different contexts; work remains performed by a holder under a role assignment; epistemes remain used through their own evidence, status, source, publication, requirement, definition, explanation, and assurance relations.

Not this pattern when.

• If the current claim is the assignment relation linking holder, role, context, and window, use A.2.1.
• If the current claim is capability, use A.2.2.
• If the current claim is role state, use A.2.5.
• If the current claim is role-requirement substitution, incompatibility, qualification, or bundles, use A.2.7.
• If the current claim is method, method description, work plan, or performed work alignment, use A.15.
• If the current claim is an episteme used as evidence, source, standard, definition, requirement, explanation, status bearer, publication, or assurance input, use the direct evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, or assurance pattern. Do not force it through U.Role.
• If the current issue is only a confusing role-like word, first use A.6.RSIR to recover the governed object or claim kind.

#Problem Frame

FPF needs role language because the same holon can be used, treated, expected, or named differently in different bounded contexts. A pump can be a cooling circulator in one plant context and a test article in another. A person can be verifier in one work package and author in another. A service can be supplier in one agreement-like relation and consumer in another. Without a role value, these contextual uses either become new system subtypes or remain vague source language.

At the same time, role language is dangerous. Everyday phrases such as "the role of this standard", "the role of this dataset", "the role of this theorem", "the role of this dashboard", or "the role of this interface" can hide several different FPF claims. They may be evidence-use, source-use, publication-use, status-use, requirement-use, explanation-use, interface, signature, capability, method, or work claims. They are not automatically U.Role claims.

A.2 therefore keeps U.Role real, but narrow. A role is a work-facing context-bound role value. It becomes operational through neighboring relations, especially U.RoleAssignment in A.2.1 and role-method-work alignment in A.15. It does not absorb every relation in which a value participates.

#Problem

Without this pattern:

1. Type explosion returns. Each contextual use becomes a new system kind such as PumpAsCoolingCirculator or ReviewerReportSystem.
2. Role and assignment collapse. The role value, the holder, the context, and the time window are treated as one vague label.
3. Role and capability collapse. A role name is treated as if it created ability.
4. Role and method collapse. A role name is treated as if it contained the method by which work is done.
5. Role and evidence collapse. A document, dataset, standard, proof, or model card is treated as a role holder because it is used as evidence or source material.
6. Role and work collapse. A role label is treated as evidence that work was performed.
7. Argument-position drift appears. "Role" is used for relation argument positions or slot positions, competing with A.6.5 SlotSpec discipline.

#Forces

#Solution

Use U.Role as a context-bound role value, not as a generic contextual classifier.

U.Role answers the question: what is this acting system or acting holon being, in this bounded context, for the current work-facing claim?

It does not answer by itself:

• who holds the role;
• whether the holder can do the work;
• which method is selected;
• which work was planned or performed;
• which evidence justifies a claim;
• which publication or description expresses the role;
• which status applies to a document, method, result, or claim;
• which relation argument position or SlotKind is current.

Those claims belong to neighboring patterns.

#Core Definitions

U.Role. A U.Role is a context-bound role value: a reusable value that names what an acting system or acting holon is being in a bounded context. It is work-facing because its primary practical use is to govern or explain role assignment, method requirements, work attribution, role-state checks, role naming, and role-related evidence about work.

Plain gloss: a role is a contextual functional mask. The gloss is helpful only if the normative object stays clear: the role value is not the holder and not the work.

U.RoleAssignment. A U.RoleAssignment is a typed assignment relation value governed by A.2.1. It links a holder, a U.Role, a bounded context, and any current assignment window. A.2 names why this relation is needed; A.2.1 governs its SlotSpecs.

Role holder. A holder of a U.RoleAssignment is a U.System or acting holon admitted by the governing work or method pattern as a system-like performer for the bounded context. An episteme is not admitted as holder merely because it is used as evidence, source, standard, requirement, definition, explanation, status bearer, publication, or assurance input.

Role description. A role description is an episteme that describes, constrains, teaches, publishes, or stores a role value or role assignment. The description is not the role value by default.

Role relation-neighborhood. A role value is surrounded by relations that are not parts of the role:

Do not turn every relation in this neighborhood into a slot of U.Role. Use SlotSpec discipline only when the governing pattern declares a slot-bearing relation.

#Work-Facing Role Assignment Boundary

Use the short readable notation only as a notation for a typed assignment relation:

Holder#Role:Context@Window

The normative assignment relation is governed by [A.2.1](/generated/patterns/A.2.1), not by the notation. Its core slots are:

RoleAssignmentCoreSlotSpec:
  HolderSlot:
  RoleValueSlot:
  BoundedContextSlot:
  AssignmentWindowSlot:

HolderSlot is filled by a U.System or acting holon admitted as system-like performer for the current work or method claim.

RoleValueSlot is filled by U.Role.

BoundedContextSlot is filled by the context that gives the role value its local meaning.

AssignmentWindowSlot is filled when assignment currentness, work attribution, role-state admission, or source freshness depends on a window. An open-world missing slot means unknown, not asserted, not recovered, or not current for this claim; it does not mean no such value exists.

Direct work-role patterns may add work-role qualifier slots. Evidence-use and status-use slots are not work-role qualifier slots and do not belong in assignment provenance.

#What Does Not Become U.Role

The following are not role values merely because source language says "role":

If the direct kind is not yet clear, use A.6.RSIR.

#Role Taxonomy Inside a Bounded Context

Inside one bounded context, roles may be organized by:

• role-requirement substitution;
• role incompatibility;
• role bundles;
• role-state predicates;
• holder eligibility constraints;
• capability requirements;
• method requirements or exclusions;
• naming and description conventions.

A.2.7 governs role relation structure. It is context-local role architecture in life, not mereology, not class subsumption for systems, not generic concern algebra, not MethodRelationStructure@BoundedContext, and not method algebra. Algebraic, graph, matrix, embedding, or neural descriptions are only lenses over selected role relation structure when a project explicitly uses them.

Typical work-facing role families include:

Domains may define roles such as CoolingCirculatorRole, BridgeInspectorRole, ClinicalTrialCoordinatorRole, ModelCardReviewerRole, or ShipyardOperatorRole. Define them in their bounded context and connect them to role assignment, capability, method, work, and evidence only when those claims are current.

#Reduced Use and Reopen Conditions

A role-like word may stay in reduced use when it only helps people recognize a local conversation and no claim depends on holder, assignment, context, time, capability, method, work, evidence, status, source, publication, or gate use.

Use the fuller role pattern when a claim based on the role-like word would change what can be done, claimed, checked, relied on, or attributed:

• use A.2 when the role value itself, bounded context, role taxonomy, or role relation-neighborhood is current;
• use A.2.1 when holder, role value, context, window, assignment source, or work-role qualifier is current;
• use A.2.2 when ability or capability is current;
• use A.2.5 when role-state admission, currentness, or role-state gate is current;
• use A.2.7 when role-requirement substitution, incompatibility, qualification, or role bundles are current;
• use A.15 when method, method description, work plan, or performed work is current;
• use direct episteme-use patterns when evidence, status, source, publication, requirement, definition, explanation, assurance, or gate use of an episteme is current;
• use A.6.5 when the word "role" is only a relation position or SlotKind.

If a reduced-use role label is later used for a stronger claim, do not treat the earlier reduced use as evidence. Recover the needed role value, assignment relation, neighboring value, or direct episteme-use relation before the stronger claim is made.

#Archetypal Grounding

#Pump in a Cooling Loop

PumpUnit-3#CoolingCirculatorRole:Plant-A@2026-06-01..open

The holder is PumpUnit-3, a system. The role value is CoolingCirculatorRole. The context is Plant-A. The assignment window is open from a named date.

This does not say the pump has the capability to circulate under every condition. Capability claims stay under [A.2.2](/generated/patterns/A.2.2). It does not say which method is used or which work occurred. Method, method description, work plan, and work claims stay under [A.15](/generated/patterns/A.15).

#Standard Used in Design Work

"RFC-9110 has the protocol-standard role in this design" is source-side wording that must be repaired.

Current FPF expression:

• the RFC publication is an episteme or publication used as source, standard, requirement, or method-description source;
• the design service, engineer, or team is the system or acting holon holding any work-facing role;
• the design work is performed by that holder under a role assignment;
• the RFC does not perform the work and does not hold U.Role.

#Reviewer and Review Report

A person, team, or agent service can hold ReviewerRole for a review context. The review report produced by that work is an episteme. Later, another project may use the report as evidence or status input. That use is an evidence-use or status-use relation around the report, not a role assignment to the report.

#Relation Argument Named "Role"

In a relation signature, "role" may mean an argument position. If the claim is about a relation position, use A.6.5 SlotSpec discipline. Do not create a U.Role merely because the source says "argument role".

#Bias Annotation

#Working Guidance

1. Start with the source phrase and recover the current project concern.
2. If the phrase names what an acting system or acting holon is being in a bounded context, recover a U.Role value.
3. If the phrase names the holder-role-context-window relation, recover U.RoleAssignment under A.2.1.
4. If the phrase names ability, recover capability under A.2.2.
5. If the phrase names performed work, intended work, or governing method, use A.15 and its neighboring method and work patterns.
6. If the phrase names evidence, source, standard, requirement, definition, explanation, publication, status, assurance, or gate use of an episteme, use the direct episteme-use relation pattern.
7. If the phrase only names a relation position, field, parameter, or argument, use A.6.5.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

Roles are needed because holons participate in different contexts without changing their substantial identity. A role value gives this context-local participation a name. The pump remains the same pump while being a cooling circulator in one context and test article in another. The engineer remains the same person while holding verifier or author roles in different work packages.

The selected ontology keeps three levels separate:

1. U.Role: the context-bound role value.
2. U.RoleAssignment: the typed relation value linking holder, role, context, and window.
3. Neighboring values: capability, method, method description, work plan, work occurrence, evidence-use relation, status-use relation, source-use relation, publication-use relation, and role description.

This is a compact architecture. It avoids type explosion, but it also avoids the opposite error of making role a generic slot word for anything that participates in anything else. A role is a real role value when an acting system or acting holon is being something in a bounded context. Other participation claims use their own relation patterns.

#SoTA-Echoing

#Relations

Builds on: A.1 for holon and system grounding; A.6.5 for SlotSpec discipline; E.24 for ontic and slot-relation discipline; A.6.RSIR for first-level wording-use recovery.

Governs with: A.2.1 for role assignment; A.2.2 for capability; A.2.5 for role state; A.2.7 for role relation structure and role-algebra lens boundary; A.15 for role-method-work alignment; Part F role-description and naming patterns for durable role names.

Keeps separate from: A.10, B.3, C.2.1, C.28, E.17, F.10, and direct evidence-use, status-use, source-use, publication-use, requirement-use, definition-use, explanation-use, assurance-use, and gate patterns for episteme use.

Precision-restoration applications: If source wording uses "role" for interface, signature, argument, field, parameter, capability, method, function, concern, interest, status, evidence, or publication, apply A.6.RSIR only until the governed object or claim kind is recovered, then apply the direct governing pattern.

#A.2:End

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