#U.RoleAlgebra: In-Context Role Relations (≤, ⊥, ⊗)

A.2.7 · Stable · 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.

Status: Stable

RoleRelationStructure@BoundedContext is the FPF object for context-local relations among role descriptions, declared role values, local role expressions, role-bundle expressions, and role-assignment-admission uses. It is not a new U.* kind beside U.Role; it is a selected relation structure over role-side values inside one bounded context. When project prose calls this "role architecture", the FPF object is still the selected role-relation structure in life; a role-algebra, graph, matrix, embedding, distributed, or neural description is a lens over that structure, not the structure itself and not an operation on holder systems. Coupled method relations are governed symmetrically as MethodRelationStructure@BoundedContext under A.3.1, A.3.2, A.15, G.5, or a direct method-composition pattern when current; A.2.7 names the role-relation side and the bridge to role-method naming.

Use this pattern when a method, work-admission rule, staffing rule, safety case, governance rule, or role description needs to say that one role value can satisfy another role requirement, two roles cannot be held together by the same holder during the same window, a role expression has a factor or domain qualification, or a frequent conjunction of roles is worth naming.

Primary EntityOfConcern. The EntityOfConcern is RoleRelationStructure@BoundedContext: a context-local role-relation and role-expression structure in one U.BoundedContext. Algebraic notation, matrices, partial orders, products, graphs, embeddings, neural representations, or other mathematical or representation expressions are descriptions or lenses of that structure. The role architecture in life is the selected relation structure among role values and role expressions; the lens is not the holder, not the performed work, not the living system, not the method, and not the role assignment.

Primary working reader. A manager, architect, method author, safety assessor, or model author who needs role-requirement substitution, separation-of-duties, role-factor or qualification expression, role-bundle expression, or ordinary name guidance without turning the role relation structure into capability, method, holder, work, evidence, status, or kind hierarchy.

First useful move. Name the bounded context, the role descriptions or role values being related, the local role expression or relation being claimed, and the assignment, method, work-admission, naming, or bridge check that will use that relation. Use a role-algebra lens only when mathematical notation helps state or check that relation.

What goes wrong if missed. Role names start acting like type hierarchy, org-chart hierarchy, permission policy, capability model, method family, staffing plan, or cross-context translation. Then FPF grows a second ontology beside U.Role, U.RoleAssignment, U.Capability, and method or work patterns, or treats algebraic notation as if it were the object in life.

What this buys. Context-local role relation structure gives a small, replayable set of role relations for role assignment, method-step checks, naming, and bridge work while keeping ability, work, method, evidence, and status claims in their governing patterns. Role-algebra notation remains a lens for describing those relations, not a substitute ontology.

Not this pattern when.

• If the current claim is who holds a role, use A.2.1.
• If the current claim is whether an assignment is currently in a work-admitting state, use A.2.5.
• If the current claim is ability, use A.2.2.
• If the current claim is a method, method family, or method description, use A.3.1 or A.3.2.
• If the current claim is performed work or planned work, use A.15, A.15.1, or A.15.2.
• If the current claim is cross-context naming or translation, use F-family context and naming patterns such as F.9 and F.18.
• If the current claim is evidence, source, status, assurance, publication, or description use, use C.2.1, A.10, B.3, E.17.*, E.24.PUB, or A.7 as the direct governing pattern for that episteme-use claim.

Work governed by role values and role assignments often needs three small claims:

#Aliases

• U.RoleAlgebra

#Keywords

• role algebra
• specialization (≤)
• incompatibility (⊥)
• bundles (⊗)
• separation of duties (SoD)
• requiredRoles substitution.

#Relations

#Content

#Problem Frame

Work governed by role values and role assignments often needs three small claims:

1. One role value can satisfy another role requirement in the same context when a role-requirement substitution relation is declared.
2. Two roles are incompatible for the same holder during overlapping windows.
3. A recurring conjunction of roles can be named as a role bundle expression.

Without a local role relation structure, teams usually encode those claims in the wrong objects:

• a role assignment says "senior inspector" and silently satisfies "inspector" without declared relation;
• a separation-of-duties rule is written as a deontic slogan rather than an incompatibility relation over assignments;
• a role bundle becomes a new holder, capability, work product, or method;
• a cross-context label match is treated as role equivalence;
• method requirements smuggle capability or work claims into role names.

A.2.7 keeps the role relation structure small and local. It says how role values, role descriptions, and role expressions relate; it does not say who holds them, whether holders are able, whether work happened, or whether an episteme proves something. Algebraic, graph, factor, embedding, distributed, neural, or other mathematical descriptions are optional lenses over that structure.

#Core Role-Relation Structure

RoleRelationStructure@BoundedContext is a relation structure declared inside one U.BoundedContext. A role-algebra description may be attached when notation helps inspection, but the structure remains the governed object.

RoleRelationStructure:
  BoundedContextRef:
  RoleDescriptionRefs?:
  RoleValueSet:
  RoleExpressionSet?:
  RoleRequirementSubstitutionSet:
  IncompatibilityRelationSet:
  FactorOrQualificationExpressionSet?:
  BundleExpressionSet:
  MathematicalOrRepresentationDescriptionRefs?:
  UseRelationRefs:

BoundedContextRef. The role relation structure is local. A relation declared in HospitalOR_2026 does not automatically apply in PlantMaintenance_2026 or another hospital's governance context.

RoleDescriptionRefs. Role descriptions may supply the recognized meaning of role values or role expressions. They are description epistemes, not the holder, not the assignment, and not the algebraic lens.

RoleValueSet. The structure ranges over U.Role values governed by [A.2](/generated/patterns/A.2).

RoleExpressionSet. The structure may include context-local role expressions such as qualified roles, bundle expressions, or labels that ordinary prose uses before a durable role value is declared.

RoleRequirementSubstitutionSet. The context may declare AcceptedRoleForRequirement <= RequiredRole as a role-requirement substitution relation. This is a local admissibility relation for method, work-admission, staffing, safety, or governance checks. It is not kind subsumption, org-chart rank, capability evidence, source-label equivalence, or public naming.

IncompatibilityRelationSet. The context may declare RoleA incompatibleWith RoleB. This means the same holder cannot use overlapping role assignments for both roles in the same bounded context and window when that incompatibility is current for the work claim.

FactorOrQualificationExpressionSet. The context may declare that one ordinary label is a qualified role expression, such as engineer qualified by robotics domain, method family, practice, or work field. This does not automatically create a separate RoboticistRole or a combined role value.

BundleExpressionSet. The context may declare RoleBundle := Role1 and Role2 and Role3 as a role-bundle expression. The expression is satisfied only by valid assignments to each component role under the same bounded context and required window. It does not create a composite holder, composite capability, or method.

MathematicalOrRepresentationDescriptionRefs. A mathematical or representation description may use order, product, factorization, graph, matrix, embedding, neural representation, distributed model, or another lens to express the selected role relation structure. This description is governed like any lens use: it names what it represents, what it preserves, what it loses, and what it must not be overread to prove.

UseRelationRefs. A method step, work-admission check, staffing rule, safety case, naming decision, or governance rule may cite the role relation it uses.

#Role-Relation Expressions

#Role-Requirement Substitution

Use role-requirement substitution when one role value can satisfy another required role in the same bounded context.

SeniorWeldingInspector <= WeldingInspector

Read this as: an assignment to SeniorWeldingInspector may satisfy a method or work-admission requirement for WeldingInspector when the bounded context declares that substitution and the assignment window is current.

The relation is not kind subsumption. SeniorWeldingInspector is not a subtype of a system kind; it is a role value related to another role value for local requirement satisfaction. It is also not capability evidence, public naming, or method identity. A senior inspector role may still require a separate capability claim under [A.2.2](/generated/patterns/A.2.2), a method relation under [A.3.1](/generated/patterns/A.3.1)/[A.3.2](/generated/patterns/A.3.2), or a naming settlement under [F.5](/generated/patterns/F.5)/[F.18](/generated/patterns/F.18).

#Role Incompatibility

Use role incompatibility when the same holder cannot validly use overlapping assignments to two roles in the same context and window.

SurgeryPerformer incompatibleWith SurgeryVerifier

This relation is often used for separation-of-duties or independence constraints. It does not create a commitment object, permission policy, or evidence record by itself. A work-admission check may use it to reject the proposed assignment combination.

#Role Bundle Expression

Use a role bundle expression when a frequent conjunction of roles is useful to name inside one context.

IncidentLeadOnCall := IncidentCommander and Communicator and DecisionMaker

The bundle expression is satisfied by current assignments to all component roles under the same bounded context and required window. It is not a product of role values, not a new holder, not a method, and not a capability.

A bundle expression becomes a durable role value only when the bounded context declares it as a role with its own role description, role-state expectations, capability requirements, and method or work relations where current.

#How Role Relation Structure Is Used

Role relation structure is normally used by neighboring patterns as one selected structure, sometimes informally called the local role architecture:

MethodStepRequirement:
  requiredRole: WeldingInspector
  acceptedAssignmentRole: SeniorWeldingInspector
  substitutionRef: SeniorWeldingInspector <= WeldingInspector

WorkAdmissionCheck:
  holderRef: SurgeonA
  proposedAssignments: SurgeryPerformer, SurgeryVerifier
  incompatibilityRef: SurgeryPerformer incompatibleWith SurgeryVerifier
  window: AssignmentWindow

The role relation structure supplies one relation used by the check. The method, method family, method relation structure, work plan, performed work, capability envelope, and evidence use remain governed by their direct patterns. When a method relation or method composition structure also needs to be named, the current object is MethodRelationStructure@BoundedContext under [A.3.1](/generated/patterns/A.3.1), [A.3.2](/generated/patterns/A.3.2), [A.15](/generated/patterns/A.15), [G.5](/generated/patterns/G.5), or a direct method-composition pattern when current; method-algebra notation is a lens over that structure, not a hidden product of roles.

#Naming role-relation and role-method expressions

Role relation work may leave behind something people need to name in ordinary project prose. The named object is not always an atomic U.Role value. It may be a holder-in-role statement, a context-local role expression, a role-requirement substitution relation, an incompatibility relation, a role-bundle expression, a durable combined role value, a coupled role-method expression, a method name, or a work name.

Recover the named object before choosing the label:

Role and Method suffixes are optional Tech-register disambiguators. They are not ordinary-name requirements and they do not create the FPF kind. A user-facing sentence may say "Vasya is an engineer-roboticist and musician" without saying "role" when the FPF record or surrounding context lets a reader recover the role expression, role values, holder assignments, methods, and work separately.

Hyphenation is not algebra by itself. Use a hyphenated ordinary label when it helps a reader see a recovered factor, domain, practice, method-family qualification, or combined role expression. Use "and" when the current point is multiple independent role assignments. Do not mechanically concatenate operands into a Tech label.

The math-lens boundary is narrow. A role-algebra, graph, matrix, embedding, distributed, or neural representation is a lens over role values, role-requirement substitution relations, incompatibility relations, role-factor or qualification expressions, and role-bundle expressions. The lens is not itself the role, holder, assignment, method, work, or capability. The name attaches to the recovered object or expression, not to the notation that helped recover it.

#Worked Cases

#Role-Requirement Substitution Without Capability Smuggling

PlantMaintenance_2026 declares:

SeniorHydraulicsTechnician <= HydraulicsTechnician

A method step requiring HydraulicsTechnician may accept an assignment to SeniorHydraulicsTechnician. This does not prove that the technician has the pressure-test capability. The method step may separately require PressureTestCapability under [A.2.2](/generated/patterns/A.2.2).

#Incompatibility for Independence

SafetyCase_2026 declares:

HazardAnalysisAuthor incompatibleWith HazardAnalysisApprover

The same holder cannot use overlapping assignments for both roles when approving the same hazard analysis. If a source sentence says "the approver role is independent", A.2.7 recovers the role incompatibility relation; evidence of independence, approval work, and approval records stay in their direct patterns.

#Bundle Expression Without New Capability

IncidentOps_2026 declares:

IncidentLeadOnCall := IncidentCommander and Communicator and DecisionMaker

This is a reusable role-bundle expression for method requirements. It does not state that one person has incident-management capability; that remains a capability claim. It does not state that incident work happened; that remains a work claim.

#Naming Engineer-Roboticist and Musician

A project says: "Vasya is an engineer, does robot engineering, is therefore an engineer-roboticist. These are musical robots, and Vasya is also a musician, performs music, and teaches robots music."

Good ordinary rewrite:

Vasya is our engineer-roboticist and musician: he works on robot engineering, and in the musical-robots project he also performs music and teaches robots music.

This ordinary sentence is admissible because a reader can recover the separate FPF values behind it:

BoundedContextRef: MusicalRobotLab_2026
HolderRef: Vasya
EngineeringRoleExpression: EngineerRole qualified by robotics domain, robotics-engineering method family, practice, or work field
OrdinaryRoleLabel: engineer-roboticist or robotics engineer
IndependentRoleValue: MusicianRole
HolderAssignmentRefs: Vasya assigned to the robotics-qualified engineering role expression or declared RoboticsEngineerRole; Vasya assigned to MusicianRole
MethodOrWorkRefs: robot-engineering method or work; music-performance work; robot-music-teaching method or work
RepresentationLensRefs?: role-algebra, graph, matrix, embedding, or neural representation only if the project explicitly uses such a description of the role relation structure

Do not write "engineer and roboticist and musician" unless EngineerRole, RoboticistRole, and MusicianRole are three independent role values with separate assignments.

Do not write "engineer-roboticist-musician" unless the bounded context declares one durable combined role value or one named role-bundle expression with its own role description and naming settlement. Without that declaration, the label hides that musician is a separate role assignment.

Robot-engineering, music performance, and teaching robots music are method or work names when those values are current. They are not produced by a role-algebra lens merely because their labels share words with role names. The role relation structure and a MethodRelationStructure@BoundedContext can be coupled in the same working sentence, but the FPF record keeps their typed values distinct.

#Cross-Context Boundary

Role relation structure is context-local. Matching role labels across contexts are not enough.

ArticleAssessorRole:JournalContext and SafetyAssessorRole:SafetyCaseContext may share a source label, but a role-requirement substitution or incompatibility relation in one context does not transfer to the other context by label. Cross-context reuse, bridge, translation, public naming, or semantic alignment uses F-family context and naming patterns.

#Checklist

#Anti-Patterns and Repairs

#Consequences

Benefits.

• Method requirements can accept declared role substitutions without encoding taxonomy in every method step.
• Separation-of-duties and independence claims become inspectable relations over assignments and windows.
• Frequent role conjunctions can be named without creating fake holders or capabilities.
• Role relation structure remains small enough to use in ordinary project work.

Costs.

• Contexts need to declare their role relations instead of relying on job-title intuition.
• Some role-like source labels need F-family cross-context repair before role relation structure can be reused.
• Capability and method requirements need separate claims when role labels used to hide them.

#SoTA-Echoing

Source-currentness note: RBAC and separation-of-duties are stable lineage, not the full current frontier. Current pressure comes from attribute and zero-trust authorization, context and currentness checking, policy-as-code practice, and FPF's newer slot-relation discipline. A.2.7 therefore keeps only the role-relation part and leaves currentness, policy decision, capability, method, work, and evidence to their direct patterns.

#Relations

#Excluded Objects

Do not use RoleRelationStructure@BoundedContext or a role-algebra lens as the current object for:

• holder taxonomy, system kind hierarchy, or org chart hierarchy;
• capability model, skill model, performance threshold, or operating envelope;
• method family, algorithm family, or work procedure;
• work plan, work occurrence, approval act, or audit record;
• evidence graph, source record, standard, report, dashboard, publication, or model card;
• cross-context translation, public naming, or bridge claim.

Those values may cite or justify a role relation. They do not become role relation structure by adjacency.

#A.2.7:End

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