#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. Enactment-facing role value.

#Keywords

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

#Relations

#Content

#Use This When

Plain name. Enactment-facing role value.

Use this pattern when the same admitted U.System can participate in different work, transformation, functioning, or method enactments without becoming a different system kind, and a project must state what that system is being in the current participation.

Typical moments:

• the same pump is a cooling circulator in plant operation and a test article in qualification work;
• a relied-on claim names a role but omits the role vocabulary, interpretation scheme, holder, or assignment window;
• ordinary wording says that an episteme, capability, method, or value filling a relation participant slot "plays a role", while the direct FPF relation is still hidden;
• a proposed "part of a role" may instead be a separate role value, role relation, role-state predicate, capability-fit condition, responsibility, commitment, or method or work structure.

Primary EntityOfConcern. The EntityOfConcern is U.Role: an enactment-facing role value interpreted through one named role-taxonomy episteme and its effective U.ReferenceScheme. It says what an admitted U.System holder is being for a current participation claim. U.Role is a root U-kind but not an admitted holon kind; proposed decompositions are dispatched to the direct patterns governing the recovered objects and relations.

Primary working reader. The first reader is an engineer-manager, analyst, or FPF author who must keep system identity stable while making role meaning and role assignment inspectable. A later reader must be able to recover the role vocabulary and scheme, the holder, the assignment window, and the separate work or method claim that relied on the assignment.

First useful move. Name the role value, the role-taxonomy episteme, and its effective reference scheme. Add U.RoleAssignment when holder or assignment-window identity matters. Then state capability, role state, method admission, performed work, responsibility, evidence, or episteme use through its direct governing pattern.

Concern-word boundary. Concern is Plain reader- or viewpoint-facing wording; it does not admit U.Concern or replace the exact EntityOfConcern, viewpoint episteme, role-taxonomy interpretation, assignment, or receiving relation needed by the claim.

What goes wrong if missed. One system's different participations become artificial system kinds, or one role label silently absorbs the holder, local meaning, assignment window, capability, method, and work claim. At the opposite extreme, every contribution is called a role even when no system holds one. Both failures make it impossible to tell who participated, under which interpretation, and what actually happened.

What this buys. A small role vocabulary can be reused without type explosion or a universal context object. The same system may hold several roles through distinct assignments; identical labels under different role taxonomies or reference schemes do not establish identical role meanings; epistemes remain participants in their own use and evidence relations rather than becoming role holders.

Not this pattern when.

• Use A.2.1 when the current object is the assignment relation and its occurrence identity.
• Use A.2.2 for a holder's capability and A.2.5 for a current role state.
• Use A.2.7 for selected substitution, incompatibility, qualification, or bundle relations among role values.
• Use A.15 and its method and work neighbors for method admission, planned work, and performed work.
• When the current participant is an episteme rather than a system holder, recover the direct use, evidence, publication, external-rule, currentness, or reliance relation. C.2.1, A.10, E.17, F.10, and A.15.4 are common exits.
• If only the word role is unclear, use A.6.RSIR until the governed object or relation is recovered.

#Problem Frame

One system can participate differently while retaining its system identity. PumpUnit-3 remains the same pump while it holds CoolingCirculatorRole in plant operation and TestArticleRole in qualification work. A person remains the same person while holding author and verifier roles in different assignments. Role values let a project name these differences without inventing a new system kind for each participation.

Role meaning is not global. A role-taxonomy episteme contains the vocabulary and relation claims through which a role value is interpreted, and an effective U.ReferenceScheme fixes the current interpretation. U.RoleAssignment then states which admitted system holds the role and during which uninterrupted occurrence. When a selected BoundedModelUseStructure changes one receiving interpretation, the receiving assertion or work use may designate that structure; it is not an optional participant of the generic role relations.

Ordinary language also uses role to mean contribution. A design method may use a standard publication as the source for a constraint claim, a report may participate in an evidence relation, and a value may fill a participant slot of another relation. Those are useful claims, but none makes the episteme or slot filler a role holder. The direct relation must be recovered before the wording becomes relied-on FPF content.

#Problem

Without this pattern:

1. one system's different participations are modeled as different system kinds;
2. identical role labels are treated as identical meanings even when their role taxonomies or reference schemes differ;
3. the role value, holder, assignment window, and relied-on work claim are compressed into one label;
4. capability, method admission, role state, responsibility, evidence, or performed work is treated as a property or part of the role value;
5. a proposed role decomposition creates false role mereology instead of recovering the direct role relations or neighboring objects;
6. an episteme or a value filling a relation participant slot is made a role holder merely because ordinary wording says it "plays a role".

#Forces

#Solution

Use U.Role for an enactment-facing role value interpreted through one role-taxonomy episteme and effective reference scheme. Ask: which role value, under which role vocabulary and interpretation scheme, is assigned to this admitted system during the current window?

Then keep three moves distinct. Interpret the role value. State U.RoleAssignment when holder or window identity matters. Add only the direct role-state, capability, method-admission, work, transformation, responsibility, evidence, or reliance relations needed by the current claim.

A selected BoundedModelUseStructure can qualify one receiving interpretation. Designate it in the receiving assertion or work use only when an independently established DDD-style organization changes that interpretation; it is not an optional participant of a generic role relation and does not assign, hold, or enact the role.

#Core Definitions

U.Role. A U.Role is an enactment-facing role value. Its meaning is recovered from a named role-taxonomy episteme under an effective U.ReferenceScheme; the value names what an admitted U.System holder is being when assignment, method admission, transformation or functioning participation, work attribution, or role-state checking is current. A role value is not the holder, assignment relation, taxonomy episteme, reference scheme, or selected model-use structure.

Plain gloss: a role says what one system is being in a particular participation without turning that participation into a new system kind. The role vocabulary and scheme make that statement interpretable; the assignment says who holds it and when.

U.RoleAssignment. A U.RoleAssignment is an assignment relation governed by A.2.1. Its four participants are an admitted U.System holder, one U.Role value, the role-taxonomy episteme that states its local vocabulary, and the effective reference scheme. Its actual assignment extent is the maximal continuous period during which the assignment predicate obtains; an assertion or occurrence description may state the currently known extent separately. A.2 explains the distinction; A.2.1 governs the complete SlotSpecs and relation-occurrence identity.

Role holder. A holder of U.RoleAssignment is an admitted U.System. A current method-admission, work, transformation, or functioning relation cites that assignment when system participation matters. Motors, pumps, organisms, teams, services, and people can therefore be holders without implying consciousness, social agency, legal responsibility, or ethical responsibility. An episteme remains a participant in the direct relation through which a system uses it to describe, constrain, evidence, or inform work.

Role description. A role description is a U.Episteme whose EntityOfConcern is a role value, role assignment, or selected role relation. It may contain claims about role admission, use, or interpretation. Systems may teach from it or store it, and a publication relation may expose it; those uses do not make the description the role value.

No role mereology. U.Role is not an admitted holon kind. If a proposed role decomposition matters, identify what the proposed element actually is. A narrower role value, a substitution or incompatibility relation, a role-state predicate, a holder-eligibility or capability-fit condition, a responsibility or commitment relation, and a method or work structure are governed separately. Rich slots in an assignment or a role description do not make those values parts of the role.

Relations around a role value. These direct relations make a role usable without becoming slots or parts of U.Role:

Select only the rows needed by the current claim. A long relation neighborhood is not a larger role.

#Role Assignment Boundary

Begin with a readable sentence: an admitted system holds a named role, interpreted through a named role taxonomy and reference scheme, during a stated assignment interval.

A.2.1 directly governs U.RoleAssignment. It alone owns the relation's RelationSignature, four participant SlotSpec declarations, obtaining condition, and occurrence-identity rule. The relation connects the admitted holder system, enactment-facing role value, role-taxonomy episteme, and effective reference scheme; its actual assignment extent follows uninterrupted obtaining. Any selected model-use structure belongs to the receiving assertion or use, not this signature.

The role-taxonomy episteme and effective reference scheme make local interpretation explicit without introducing a universal context object. The optional model-use structure neither holds nor assigns the role. Assignment authority, role state, capability, method admission, performed work, responsibility, evidence, reliance, and publication remain separate claims under their direct governing patterns.

When another claim relies on assignment identity, cite the exact U.RoleAssignment occurrence declared under A.2.1; do not recreate its signature in this taxonomy pattern.

#Recover the Direct Relation behind Contribution Wording

In ordinary language, the role of X often means that X contributes to some use. First ask whether X is an admitted U.System being something in work, transformation, functioning, or method participation. If yes, recover U.Role and, when relied on, U.RoleAssignment. If no, keep X in its actual kind and name the direct relation that makes its contribution matter.

The alternatives in a row are triage questions, not a union kind. Select the one relation that the relied-on claim actually uses. If that relation is still unclear, apply A.6.RSIR and stop before minting a role value.

#Role Taxonomy Episteme and Role Relation Structure

A role-taxonomy episteme contains the role vocabulary and selected role-relation claims interpreted under one effective U.ReferenceScheme. The episteme does not assign a role. A U.RoleAssignment relates the holder system to one role value and declares participant SlotSpecs for the taxonomy episteme and scheme needed to interpret that value.

A.2.7 governs a selected role relation structure made from exact substitution, incompatibility, qualification, and role-bundle relation occurrences. A receiving check may use an assertion about one of those occurrences alongside separately governed U.RoleAssignment, RoleStateRelation, or capability-fit claims. Those neighboring relations remain direct-owner objects; they are not A.2.7 relation participants, role parts, or system-kind subsumption.

Algebraic, graph, matrix, embedding, or neural representations are mathematical lenses over that selected role relation structure when a project declares such a lens use. A BoundedModelUseStructure remains a separate U.Structure; when it changes one receiving interpretation, the receiving assertion or use designates it without extending generic role-relation signatures.

#Reduced Use and Stronger Claims

A role-like word may remain Plain when it only helps people recognize a local conversation and no decision, attribution, admission, or reliance depends on its identity. Do not materialize U.Role or U.RoleAssignment merely to improve wording.

When a stronger claim appears:

• name the role-taxonomy episteme and effective reference scheme when role meaning matters;
• add U.RoleAssignment when holder or assignment-window identity matters;
• add the direct role-state, capability-fit, method-admission, work, transformation, evidence, or reliance relation when that relation carries the claim;
• use A.2.7 for selected role relations inside one interpretation; when a proposed comparison, substitution, translation, or reuse crosses role taxonomies or reference schemes, use F.9 and A.6.9 to establish the exact Bridge, then state a separate C.2.1 assertion about that Bridge naming the bounded use, direction, correspondence rule, tolerated semantic loss, polarity, and effective scheme; recover current reliance through A.10 or B.3 before acting.

The earlier Plain mention is not evidence for any stronger claim. Complete only the smallest direct relation needed by the current use.

#Archetypal Grounding

#Pump in a Cooling Loop

Plant operation relies on a current assignment. The four values under participantDesignations designate the direct relation participants; assignmentInterval is assertion content describing the currently known extent of the uninterrupted occurrence.

RoleAssignmentAssertion@PumpUnit3:
  participantDesignations:
    HolderSystemSlot: PumpUnit-3
    RoleValueSlot: CoolingCirculatorRole
    RoleTaxonomyEpistemeSlot: PlantOperationsRoleTaxonomy-2026
    EffectiveReferenceSchemeSlot: Plant-A-Operations-Scheme
  assignmentInterval: [2026-06-01, open]

PumpUnit-3 is the holder system. PlantOperationsRoleTaxonomy-2026 contains the role-vocabulary claims, and CoolingCirculatorRole is interpreted under Plant-A-Operations-Scheme. Plant A is an actual plant system and work locus, not a context slot. No selected model-use structure is needed because none changes interpretation of this assignment.

The world-side assignment occurrence continues only while its predicate obtains without interruption for the same four participants. Closing the open assertion interval later refines the same description when continuity holds; the declared interval neither makes the relation obtain nor becomes a fifth participant.

The assignment does not prove that the pump can circulate coolant throughout every operating region, that circulation work occurred, or that a maintenance method was followed. Those claims use [A.2.2](/generated/patterns/A.2.2), [A.15.1](/generated/patterns/A.15.1), and the applicable method, transformation, measurement, and evidence relations.

#A Standard Used in Design Work

An engineering team uses the RFC 9110 publication while designing an HTTP service. Keep three claims separate:

1. DesignTeam-2 holds ProtocolDesignerRole under EngineeringRoles-2026, interpreted through HTTP-Design-Scheme, during one current uninterrupted assignment episode.
2. The RFC publication is the source episteme in a source-use relation whose receiving use is the HTTP-semantics constraint set in the team's design method description.
3. The dated design work is performed by DesignTeam-2 and may produce a method description or system description.

The team uses the publication as the named source for those constraints. The publication neither holds the design role nor performs the work.

#The Same Label under Two Role Taxonomies

An editorial team and a safety-assurance team both use ReviewerRole. Their role-taxonomy epistemes contain different admission, independence, evidence, and completion claims, each interpreted under its effective reference scheme. The shared label establishes neither one role meaning nor a Bridge.

Suppose a staffing dashboard proposes u-reviewer-display: show assignments from both taxonomies in one Reviewer column. First recover the exact F.17 sense cells and establish the exact obtaining F.9 Bridge between them. Then state a separate affirmative C.2.1 assertion about that Bridge: direction d-safety-to-editorial-display; rule r-preserve-reviewer-differences, which keeps each taxonomy's admission, independence, evidence, and completion claims in separate fields; and tolerance t-shared-label-only, which permits the shared display label but no assignment, eligibility, capability, substitution, or performed-work inference. Its effective reference scheme interprets those designations.

For this ordinary display use, the exact current A.10 evidence-provenance graph relation and RelianceDisposition=pass support only u-reviewer-display. They do not justify putting a safety-assurance reviewer into an editorial assignment. That substitution would be another bounded-use assertion with its own direction, rule, tolerance, polarity, and reliance. If an assurance claim is being made or B.3's material-reliance threshold is met, first ask whether a current positive B.3 assurance claim exists: only one that carries the same use with a sufficient minimum reliance safety assurance record supports it; otherwise an explicit no-assurance, insufficient-record, narrowed, rejected, withdrawn, abstaining, or blocked disposition stops or narrows the use.

A Bridge Card may package the Bridge, bounded-use assertion, evidence, and disposition, but neither the card nor the Bridge alone establishes use suitability, assigns either role, or proves that dashboard or substitution work occurred. Any actual assignment, comparison, or work remains under its direct owner. If an independently selected DDD-style model-use structure changes one receiving interpretation, designate it in that receiving assertion or use. A genuinely structure-dependent relation species requires its own direct pattern, required structure participant, stronger predicate, and occurrence-identity rule; it is not an optional extension of a generic role relation.

#Relation Participant Slot Named Role

An external relation notation may label one participant as role. In FPF the declaration first recovers one participant SlotKind and its SlotSpec. The ValueKind is U.Role only when the filler is genuinely an enactment-facing role value. Otherwise the ValueKind remains the direct kind of the actual participant. The external label alone creates neither a U.Role value nor a U.RoleAssignment; an admitted system holds a role only through the separately obtaining assignment relation.

#Bias Annotation

#Working Guidance

1. Identify the candidate holder. U.Role applies only when an admitted U.System is what the current participation claim classifies.
2. Name the role value, the role-taxonomy episteme, and the effective reference scheme that interprets it.
3. When another claim relies on who holds the role or when, state U.RoleAssignment under A.2.1.
4. State role state, capability fit, method admission, responsibility, commitment, work, transformation, evidence, and reliance through their direct patterns; do not put them inside the role value.
5. When a proposed subrole appears, use A.2.7 only for substitution, incompatibility, qualification, or joint-admission bundle relations among role values. Use A.2 for another role value, and send role state, capability fit, responsibility, commitment, method, or work to its direct owner. Do not assume partOf.
6. When an independently selected BoundedModelUseStructure changes a receiving interpretation, designate it in that receiving assertion or use rather than in a generic role relation.
7. For a cross-scheme role use, establish the exact F.9 Bridge, state the separate C.2.1 bounded-use assertion, and recover current A.10 or B.3 reliance; a matching label, profile, Bridge, or card alone grants no use.
8. If the source phrase only says that a non-system entity contributes, recover the direct relation with A.6.RSIR and stop before creating U.Role.

#Conformance Checklist

#Common Anti-Patterns

#Consequences

#Rationale

Roles solve a participation problem, not a system-identity problem. The pump does not become a new system because it is used as a cooling circulator, and the person does not become a new system kind because a verification assignment starts. U.Role names what the holder is being; U.RoleAssignment states who holds that role and when.

The selected ontology keeps three levels separate:

1. the role value interpreted through a role-taxonomy episteme and effective reference scheme;
2. the obtaining U.RoleAssignment relation occurrence linking holder, role value, taxonomy episteme, and scheme, with its actual extent derived from uninterrupted obtaining and described separately;
3. direct neighboring relations for role state, capability, method admission, responsibility, commitment, work, transformation, evidence, reliance, description, and publication.

This separation explains why U.Role is not a holon. Proposed role "parts" do not pass a constructive assembly and meta-holon transition test for the role value. They repeatedly resolve into relation occurrences, predicates, other role values, method or work structures, or parts of description epistemes. The useful structure is therefore the selected role relation structure governed by A.2.7, not role mereology.

Semantic locality also does not require a universal bounded context. The role-taxonomy episteme and reference scheme ordinarily suffice. A receiving assertion or use may designate a selected BoundedModelUseStructure only in the narrower case where an actual model-use organization changes that interpretation.

#SoTA-Echoing

#Relations

Builds on: A.1 for system and holon grounding; C.2.1 for the role-taxonomy episteme and effective reference scheme; A.6.0, A.6.5, and A.6.REL for assignment RelationSignature, participant SlotSpecs, and occurrences; E.24 for U-kind discipline.

Governs with: A.2.1 for role assignment; A.2.2 for capability; A.2.5 for role state; A.2.7 for selected role relation structure; A.15 for role-method-work alignment; F.4 and F.5 for role description and naming.

Crosses semantic-locality boundaries through: F.9 and A.6.9 for the exact Bridge between scheme-local sense cells; C.2.1 for the separate bounded-use assertion; and A.10 or B.3 for current reliance. A.1.1 plus the receiving assertion or use pattern governs any selected BoundedModelUseStructure that changes interpretation. An actual assignment, comparison, substitution, translation, publication, or work occurrence remains under its direct owner.

Keeps separate from: direct episteme-use, evidence, reliance, publication, external-rule, currentness, and assurance patterns. Apply A.6.RSIR only until the actual object or relation behind contribution wording is recovered, then continue with that governing pattern.

#A.2:End

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