FPF Reference

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

Pattern A.2.7 · Stable · Definitional (D) · Normative Part A - Kernel Architecture Cluster

Type: Definitional (D) Status: Stable Normativity: Normative

with requiredRoles substitution, SoD (⊥), and bundle (⊗) hooks

Builds on: A.1.1 U.BoundedContext, A.2 Role Taxonomy.
Coordinates with: A.2.1 U.RoleAssignment, A.15 Role–Method–Work Alignment.

Intent. Provide a tiny, explicit algebra over role types inside one Context so engines can (a) substitute specialisations, (b) enforce separation of duties, and (c) treat frequent conjunctions as named bundles—without encoding taxonomy in RoleAssignments.

Aliases

  • U.RoleAlgebra

Keywords

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

Relations

A.2.7builds onRole Taxonomy
A.2.7prerequisite forRole–Method–Work Alignment (Contextual Enactment)
A.2.7prerequisite forU.RoleStateGraph: The Named State Space of a Role
A.2.7outline parentRole Taxonomy
A.2.7outline prev siblingUnified Scope Mechanism (USM): Context Slices & Scopes
A.2.7outline next siblingU.Commitment: Deontic Commitment Object
A.2.7explicit referenceU.BoundedContext: The Semantic Frame
A.2.7explicit referenceRole Taxonomy
A.2.7explicit referenceU.RoleAssignment: Contextual Role Assignment
A.2.7explicit referenceRole–Method–Work Alignment (Contextual Enactment)

Content

Problem frame

Intent. Provide a tiny, explicit algebra over role types inside one Context so engines can (a) substitute specialisations, (b) enforce separation of duties, and (c) treat frequent conjunctions as named bundles—without encoding taxonomy in RoleAssignments.

Scope.

  • Defines three in‑Context relations/operators: specialization ≤, incompatibility ⊥, and bundle ⊗.
  • States substitution semantics used when checking MethodStep.requiredRoles.
  • States overlap‑prohibition semantics used to validate RoleAssignments.

Non‑goals.

  • No cross‑Context equivalence by label; cross‑Context reuse is Bridge‑only (F.9).
  • No mereology; role algebra does not describe part‑of or structure membership.
  • No capability model; intrinsic ability evidence lives in U.Capability and related patterns.

Disambiguation. Do not confuse role specialization ≤ with kind subsumption ⊑ (Kind‑CAL).
≤ is requirement substitution between role types in one Context; ⊑ is typing between kinds.

Solution (the three operators)

Role algebra relates role types inside one U.BoundedContext. It is not mereology.

Specialization (narrower assignment)

  • Notation: RoleS ≤ RoleG
  • Semantics (normative): For any U.RoleAssignment with role = RoleS in this Context, the holder also satisfies requirements for RoleG in this Context.
  • Use: Stable expertise ladders; privilege inheritance; “junior→senior” substitution.
  • CC‑ALG‑1. Engines that check requiredRoles MUST treat ≤ as admissible substitution.

Incompatibility (conceptual role incompatibility)

  • Notation: RoleA ⊥ RoleB
  • Semantics (normative): Overlapping windows on the same holder for assignments to both roles in this Context are ill‑formed.
  • Use: Separation‑of‑duties (SoD); independence constraints (e.g., performer vs reviewer).
  • CC‑ALG‑2. Validation MUST reject overlapping assignments that violate ⊥.

Bundles (conjunctive requirement)

  • Notation: RoleC := Role1 ⊗ Role2 ⊗ …
  • Semantics: RoleC is satisfied iff the holder has simultaneous valid assignments for each conjunct role (in this Context).
  • Use: Frequent conjunctions (e.g., “On‑call Incident Commander” = Engineer ⊗ Communicator ⊗ Decision‑Maker).
  • CC‑ALG‑3. Engines that check requires: [RoleC] MUST expand to conjunctive checks.

Didactic guardrails. Use ≤ for lasting ladders, ⊥ for critical safety/governance, ⊗ for frequent conjunctions. Prefer listing multiple requiredRoles on Method steps to avoid ornate lattices.

Relations

Builds on / depends on

  • A.1.1 U.BoundedContext — the locality boundary within which the algebra holds.
  • A.2 Role Taxonomy — role families and context‑local naming.

Used by

  • A.2.1 U.RoleAssignment — avoids chained assignments; uses ≤/⊥/⊗ for checking and validation.
  • A.15 Role–Method–Work Alignment — expands requiredRoles and enforces SoD requirements.
  • D.2 ethics/governance patterns — encode SoD and independence via ⊥.

A.2.7:End