#U.RoleAssignment: Contextual Role Assignment

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

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

with Role Performance View, U.RoleStateGraph (RSG), and Role Characterisation Space (RCS) hooks

Builds on: A.1 Holonic Foundation, A.1.1 U.BoundedContext, A.2 Role Taxonomy.
Coordinates with: A.13 Agential Role & Agency Spectrum, A.15 Role–Method–Work Alignment, E.10.D1 D.CTX (Context discipline), E.10.D2 Strict Distinction.
Lexical discipline. Context ≡ U.BoundedContext (E.10.D1). Appointment is colloquial only; the canonical term in this specification is Role Assignment (see CC‑LX‑1).

Mint vs reuse. This pattern defines U.RoleAssignment and U.RoleEnactment and introduces the labels Role Characterisation Space (RCS) and Role State Graph (RSG) as intensional facets recorded in RoleDescription / RoleSpec. It reuses existing kernel terms (U.Holon, U.System, U.Episteme, U.BoundedContext, U.Work, U.Method) without changing their meanings.

Intent. Provide one, universal, context‑local way to say who is being what, where (and when) without altering what the thing is. The same grammar works for people, machines, software, teams, and also for knowledge artefacts (epistemes) when they hold statuses rather than perform actions.

#Aliases

• U.RoleAssignment

#Keywords

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

#Relations

#Content

#Problem frame

Intent. Provide one, universal, context‑local way to say who is being what, where (and when) without altering what the thing is. The same grammar works for people, machines, software, teams, and also for knowledge artefacts (epistemes) when they hold statuses rather than perform actions.

Scope.

• Defines U.RoleAssignment (binding a holder holon to a role inside a bounded context, optionally within a time window).
• Separates that binding from U.RoleEnactment (the run‑time fact that a piece of Work was performed under that assignment).
• Names the Role Characterisation Space (RCS) and the Role State Graph (RSG) as intensional facets of a Role (recorded in its RoleDescription, upgraded to RoleSpec only after tests exist).
• Declares eligibility constraints so Roles apply to the right holon kinds, without badge‑of‑badge chains like “TransformerRole is assigned to be AgentRole”. If your Context wants taxonomic inheritance between role names, express it with in‑Context role algebra (≤), not via chained assignments.
• Declares eligibility constraints so Roles apply to the right holon kinds, without badge‑of‑badge chains like “TransformerRole is assigned to be AgentRole”. If a Context intends taxonomic inheritance between role names, that relation is expressed in‑Context via role algebra (≤), not via chained assignments.

Non‑goals. No storage models, no workflows, no org charts. This is a thinking Standard; all semantics are notation‑free.

#Problem

1. Type explosion. Baking transient function into rigid types (“CoolingPump”, “AuditDeveloper”) violates parsimony and makes change brittle.
2. Context drift. Labels like Operator, Process Owner, Standard slide in meaning across teams/years when not tied to a Context.
3. Actor vagueness. Work logs state that things happened but not who, in what capacity, under which local rules.
4. Category leaks. Documents “do” tasks; deontic statuses are treated like run‑time states; capabilities are confused with permissions.
5. Role chains. Attempting “System ↦ TransformerRole ↦ AgentRole” hides intent and smuggles taxonomy into the data plane.

#Forces

#Solution

#Canonical definition (notation‑free)

U.RoleAssignment is a **context-local assignment:

RoleAssignment ::=
  〈holder: U.Holon,
   role: U.Role,
   context: U.BoundedContext,
   window?: U.Window,
   justification?: U.Episteme,
   provenance?: U.Method〉

Admissibility constraints (concept‑level; non‑deontic).

• Invariant RA‑1 (Locality). role ∈ Roles(context). The role’s meaning is exactly the one recorded in that Context’s RoleDescription/RoleSpec.
• Invariant RA‑2 (No role‑of‑role). holder : U.Holon and holder ∉ {U.Role, U.RoleAssignment}. (Roles/assignments are never holders.)
• Invariant RA‑3 (Eligibility by role kind).
  • Behavioural roles (agential/transformer/observer/speech and their refinements): holder is a U.System. Only systems can enact Methods and produce Work.
  • Status roles (epistemic‑status / normative‑status / service‑governance): holder is a U.Episteme. Epistemes never enact Work; they gate and justify.
  • Context refinements may tighten eligibility (e.g., “Approver must be human”) but are restrictions of the System/Episteme split (they do not weaken it).
• Invariant RA‑4 (Window discipline). If window is present, enactments occur within it. If window is absent, interpret the assignment as open‑ended from an assignment time that is still traceable (e.g., via an issuing U.RoleAssigning SpeechAct Work or other evidence).
• Invariant RA‑5 (Separation). A RoleAssignment confers the capacity/authorization to act (or the status to be recognised), but it is not behaviour (no Work implied), not capability (intrinsic ability lives elsewhere), and not structure (it does not participate in BoM / part‑of structure).

Governance metadata (optional but first‑class when present).

• justification carries why the assignment is valid in this Context (policy, standard, evidence Episteme).
• provenance carries how the assignment was issued or verified (method reference; may link to a U.RoleAssigning work step in the evidence graph).

Didactic read. Think badge (who wears which mask, where, when). The rules for the mask live in the room (Context).

Two assignment modes. A RoleAssignment can be: (a) Authoritative — issued by an authority or policy in the Context (often via a U.RoleAssigning SpeechAct Work); it can open a Green‑Gate for steps that require explicit authorization. (b) Observational — an evidence‑backed classification that the holder occupies a Role in this Context (e.g., “Moon as SatelliteRole:IAU_2006”). Observational assignments never by themselves open operational Green‑Gates; they can gate decisions and analysis.

#Role Enactment (distinct from the assignment)

U.RoleEnactment captures the run‑time fact that a specific piece of Work was performed under a specific Role Assignment:

RoleEnactment ::= 〈work: U.Work, by: U.RoleAssignment〉

Admissibility constraints (concept‑level; non‑deontic).

• Invariant RE‑1 (Actor reality). by.holder : U.System. (Epistemes never enact Work.)
• Invariant RE‑2 (Temporal fit). work.window overlaps by.window (or by.window is open and contains work.window).
• Invariant RE‑3 (Method gate). For the MethodStep realised by work, by.role satisfies the step’s requiredRoles in that same Context (directly or via ≤ specialization inside the Context).
• Invariant RE‑4 (Traceability shape). U.Work records cite the performer as performedBy = some U.RoleAssignment. U.RoleEnactment is the conceptual (or derived) association 〈work, work.performedBy〉; if a system persists it explicitly, it is 1:1 with Work.

Reading: Assignments authorize; enactments happen. That single sentence prevents months of muddled logs.

Role Enactment is the occurrence of U.Work performed by a holder while a valid U.RoleAssignment for the required Role is in an enactable state of its RoleStateGraph (A.2.5) within the same Context. Enactment is generic: it includes operational work (e.g., actuation) and communicative work (speech acts such as approvals).

#Role Characterisation Space (RCS) & Role State Graph (RSG)

These are intensional facets of a Role, not containers “inside” the Role. They are recorded in the RoleDescription (or RoleSpec once harnessed), per E.10.D2.

• RCS (Role Characterisation Space). A set of named characteristics that parameterise how the Role is understood in a Context (e.g., AgencyLevel ∈ {None, Assisted, Delegated, Autonomous}; SafetyCriticality ∈ {SC0…SC3}).

• RSG (Role State Graph). A directed graph of named states (nodes) and admissible transitions (edges) for the Role within the Context (e.g., {Eligible → Authorized → Active → Suspended → Revoked}).

  • Each state has a Conformance Checklist (set of observable cues) supporting Evaluations (“X ∈ Authorized@context in W”).
  • RSG governs role state transitions, independent of any Work instance.

Discipline. Prefer the phrasing “Role is characterised by RCS/RSG recorded in RoleDescription”; avoid “Role contains its states.”

#Shorthand & reading

The canonical compact form used in prose and diagrams is:

Holder#Role:Context@Window

Examples:

• PLC_17#Transformer:PipelineOps@2025‑04‑01..2025‑06‑30
• ISO_26262v2018#NormativeStandard:AutoSafetyCase (status role on an Episteme; no enactment)

The shorthand is didactic; the semantics are those of §§4.1–4.3.

#No role chains (use algebra, not badge‑of‑badge)

Chained assignments are ill‑formed for encoding taxonomy (see Invariant RA‑2 and CC‑ELIG‑3). Chaining hides intent and defeats validation.

Taxonomic inheritance between role names is declared explicitly in the Context’s role algebra. For example, if (per A.13) your Context treats every transformer as a kind of agent, state:

• TransformerRole ≤ AgentialRole (in that Context’s role algebra)

When a MethodStep requires two independent roles, express the conjunction where it belongs:

• the MethodStep requires both roles; the holder wears two badges, not a badge‑of‑a‑badge.

#Eligibility across holon kinds (normative matrix)

A Role’s family constrains who can wear its badge. Eligibility is part of didactic hygiene and prevents chains like “Transformer → Agent”.

#Holder kinds (recap)

• U.System — any acting holon (person, device, software service, team, organization, socio‑technical unit).
• U.Episteme — any knowledge unit (document, dataset, model, standard, Standard).
• U.Holon — supertype; only Systems enact Work; Epistemes can only hold status roles.

#Role‑kind × holder matrix

Invariant — RA‑3 (eligibility) (restated): RoleAssignments are ill‑formed if they violate this matrix. A Context may tighten (e.g., “Approver must be human”), never loosen.

Conformance checks (easy to remember).

• CC‑ELIG‑1. If role.family ∈ {Agential, Transformer, Observer, Speech}, then holder : U.System.
• CC‑ELIG‑2. If role.family ∈ {Epistemic‑Status, Normative‑Status, Service‑Governance}, then holder : U.Episteme.
• CC‑ELIG‑3. No “role of a role”: role is bound to a holder, not to another role or assignment.

#Role algebra within a single Context (meaning relations)

Role algebra

The in‑Context role algebra relates role types inside one U.BoundedContext. It is not mereology. Its operators (≤, ⊥, ⊗) is specified normatively in A.2.7 U.RoleAlgebra.

A.2.1 relies on it for (i) requiredRoles substitution checks (≤), (ii) separation‑of‑duties validation (⊥), and (iii) conjunctive bundles (⊗), but does not restate the operator semantics here.

#Time & state transition calculus (windows, RSG, enactability)

Assignments authorize, enactments happen — in time. RSG governs the role’s state transitions; window governs the binding’s validity.

#Windows and overlap

• Window form: @t_start..t_end (ends may be open).
• RE‑2 (temporal fit) (restated): work.window lies within (or overlaps appropriately with) assignment.window.
• Handover pattern: Close A#Role@..t and open B#Role@t.. — history is preserved by closing windows rather than deletion.
• (Conformance hook.) See CC‑WIN‑1: preserve history by closing windows rather than erasing RoleAssignments.

#RSG gating of enactment

Each Role’s RoleDescription/RoleSpec defines an RSG with named states; some states are enactable.

• Delegation. Normative author‑facing requirements for U.RoleStateGraph structure (including enactability marking and per‑state checklists) and the shape of StateAssertion evidence are defined in A.2.5; A.2.1 only relies on the resulting enactment gate.
• Invariant RE‑5 (RSG gate). A U.RoleEnactment is valid iff at enactment time the U.RoleAssignment can be supported by a valid StateAssertion that the holder is in an enactable state of the Role’s RSG in this Context.
• (A.2.5 hook.) The Role’s U.RoleStateGraph (A.2.5) identifies enactable states and attaches a Conformance Checklist to each state; checklist verdicts can be recorded as StateAssertions (see SCR‑A2.5‑S02/S03).
• Example. SurgeonRole states: Eligible → Authorized → Active → Suspended → Revoked. Only Active is enactable. A pre‑op checklist produces StateAssertion(SurgeonRole, Active).

Practical reading. Badge valid (window) ∧ state is right (RSG) ⇒ you may act.

#Suspensions, revocations, probation

• Suspend: transition to a non‑enactable state (e.g., Suspended). Keep the assignment’s window open; enactment is blocked by RE‑5.
• Revoke: either (a) close the window, or (b) transition to Revoked (non‑enactable).
• Probation: a dedicated RSG state with limited enactability (e.g., only under supervision, modelled as an extra required role on Method steps).
• Discipline (A.2.5). RSG transitions are explicit; no implicit “back to Active”.

#Typical temporal patterns (didactic)

• Shift rotation. A#Role@08:00..16:00, B#Role@16:00..24:00 — clean handover, no ⊥ issues.
• Shadowing. Trainee#Role@.. + Mentor#SupervisorRole@..; Method steps require both roles.
• Emergency bundle. SoloOperator := Incision ⊗ Hemostasis ⊗ Suturing; activate only under declared emergency (Context‑level policy).

#Integration with A.15 (Role–Method–Work alignment)

One line. A U.MethodDescription names the roles it needs; a U.Work cites the concrete U.RoleAssignment that enacted the step; the RSG state + window gates that enactment.

#Design‑time Standard (inside U.MethodDescription)

For every MethodStep:

• requiredRoles — a list of U.Role from the same Context as the step. Example. In Hospital.OR_2025, step “Make incision” has requires: [IncisionOperatorRole].
• Role algebra in‑Context applies: if the Context defines IncisionOperatorRole ≤ SurgeonRole, then requires: [SurgeonRole] also admits holders of IncisionOperatorRole.
• Separation of concerns. Capability checks (does the holder can?) belong to U.Capability and resource limits; authorization belongs to U.RoleAssignment + RSG.

#Run‑time check (inside U.Work)

A U.Work record provides (or allows derivation of) the fields needed to satisfy CC‑ENACT‑1..3:

• performedBy = a concrete U.RoleAssignment (not just a person/system name).
• Window gate. The Work timestamp falls inside the assignment’s @Window.
• State gate. At that timestamp, an enactable state for the assignment is proven by a StateAssertion (the checklist verdict for a named RSG state).
• Role algebra gate. The assignment’s role is either one of requiredRoles or a specialization (≤) thereof; bundles (⊗) expand to conjunctions; incompatibilities (⊥) forbid overlaps on the same holder.

#Evaluation & acceptance (link to services & deontics)

• Observation. The Work produces U.Observation(s).
• Evaluation. A U.Evaluation compares Observations with AcceptanceClause(s) referenced by a promise content clause (U.PromiseContent) or a RequirementRole.
• SoD hook. If the step or evaluation demands independence (e.g., “not performed by its reviewer”), enforce via ⊥ between PerformerRole and ReviewerRole in the same Context.

#Planning & scheduling (design‑time “who will enact”)

• U.WorkPlan (aka “WorkDescription” in prose) binds forthcoming steps to candidate RoleAssignments and time windows.
• Checks before the fact. Validate windows (no gaps/overlaps where disallowed), enforce ⊥, ensure expected RSG state will be enactable at scheduled time (or flag a pre‑flight checklist).

Didactic cue. Think “Step asks for badges; Run cites a badge; Badge must be valid & green.” (Badge = RoleAssignment; valid = window; green = RSG state with a fresh StateAssertion.)

#Cross‑Context bridges in practice (with CL penalties)

Cross‑Context role substitution is Bridge‑only and is specified in F.9 (with CL/waiver regimes) and B.3 (CL‑penalty routing).

A.2.1’s only rule is no substitution by label: any “Role_B@B satisfies Role_A@A” claim used for checking or enactment MUST cite an explicit Bridge (direction, CL, loss notes) and MUST NOT override in‑Context ≤, ⊥, or ⊗.

#Everyday pattern snippets (didactic moves)

Use these micro‑moves to think and speak cleanly; no tooling required.

1. “Who can do this step?” On a MethodStep, write requires: [RoleX]. In your head, expand: “Any performedBy whose role ≤ RoleX, with a valid window and enactable RSG state.” Example: requires: [SurgeonRole] and IncisionOperatorRole ≤ SurgeonRole ⇒ Dr.Kim#IncisionOperatorRole:Hospital.OR_2025 is admissible iff Active.

2. Handover without history loss. Close one window, open another. Never delete. Alex#IncidentCommander:SRE_Prod@08:00..12:00 Riya#IncidentCommander:SRE_Prod@12:00..20:00

3. Independence by construction (SoD). Declare Developer ⊥ IndependentAuditor. Then it’s impossible (by validation) to have overlapping windows on one holder for both roles.

4. Supervision as bundle. Model apprenticeship by requiring Trainee ⊗ Supervisor on sensitive steps, or by RSG state Probation that flips enactable only if SupervisorRole is also present.

5. Same badge name in two Contexts. LeadEngineer:ProjectPhoenix ≠ LeadEngineer:DivisionR&D. If you must relate, create a Bridge with CL & loss notes; never rely on the name.

6. Documents don’t act; they frame. Replace “the SOP executed X” with: SOP_v4#RequirementRole:SafetyCase and a SpeechAct “approve run” by QA_Officer#AuthorizerRole:Plant_2025.

7. Window + state ⇒ permission. Quick mental check: badge valid? (window) ∧ state OK? (RSG) ⇒ go; else no‑go.

8. Communicative enactment (approval) CAB_Chair#ApproverRole:ChangeControl@2026-05-01T10:05 performs a SpeechAct Work “Approve Change-4711”. Effect: moves ApproverRole’s RSG state from Authorized?→Approved and opens the Green‑Gate for the operational step “Deploy Change-4711” (performed by a different RoleAssignment).

#Archetypal Grounding (three disparate arenas)

Goal. Show that the same assignment Holder#Role:Context@Window, plus RCS (Role-Characterisation Space) and RSG (Role-State Graph), works uniformly for operational systems, software/service operations, and knowledge governance.

Natural systems note. Spontaneous physical phenomena (e.g., Moon orbiting Earth) are modeled as U.Dynamics, not as U.Work. An observational RoleAssignment like Moon#SatelliteRole:IAU_2006 is valid classification but does not imply enactment of a method.

#Industrial operations (welding cell)

Role (family). WelderRole (Transformer) *RCS (illustrative characteristics).

• ProcessClass ∈ {MIG, TIG, Spot}
• QualifiedMaterial ∈ {Al, SS, Ti, …}
• MaxCurrentAmp ∈ ℝ⁺
• SafetyProfile ∈ {Standard, HotWork, ConfinedSpace}

RSG (named states). Unqualified → Qualified → Authorized → Active → Suspended → Revoked (enactable: Active only)

Assignments.

• Robot_SN789#WelderRole:AssemblyLine_2025@2025‑02‑01..open
• Robot_SN790#WelderRole:AssemblyLine_2025@2025‑02‑01..open

StateAssertions (via checklists).

• StateAssertion(WelderRole, Qualified, AssemblyLine_2025, @2025‑02‑01..2026‑02‑01) — training & test weld coupons.
• StateAssertion(WelderRole, Active, AssemblyLine_2025, @2025‑03‑01..open) — daily pre‑shift checks + gas/torch inspection.

Enactment (gated by RSG). A U.Work entry W#Seam134 is valid only if performedBy = Robot_SN789#WelderRole:AssemblyLine_2025 and an Active StateAssertion covers the timestamp. If the torch‑health checklist fails, RSG transitions Active → Suspended; further seams are blocked by RE‑5.

#Software & cloud operations (continuous delivery / SRE)

Roles (families).

• DeployerRole (Transformer) — authorises execution of deployment Methods.
• IncidentCommanderRole (Agential/Speech) — directs response and issues SpeechActs (declares incident states).

RCS (illustrative).

• DeployerRole: Env ∈ {staging, prod}, ChangeWindow, RollbackAuthority ∈ {self, peer, CAB}.
• IncidentCommanderRole: OnCallTier ∈ {L1,L2,L3}, ServiceScope, PageDuty ∈ {primary, secondary}.

RSGs (named states).

• DeployerRole: Eligible → Authorized → Active → Suspended (enactable: Active).
• IncidentCommanderRole: OnCall → Engaged → Handover → Rest (enactable: Engaged).

Assignments.

• sCG‑Spec_ci_bot#DeployerRole:CD_Pipeline_v7@2025‑04‑01..open
• Alex#IncidentCommanderRole:SRE_Prod@2025‑04‑10T08:00..2025‑04‑10T20:00

StateAssertions (via checklists).

• DeployerRole/Active: completed change ticket, green pre‑deploy tests, peer‑review check mark.
• IncidentCommanderRole/Engaged: accepted page, situational brief read, comms‑channel opened.

Enactment.

• A deployment Work is valid only with performedBy: sCG‑Spec_ci_bot#DeployerRole:CD_Pipeline_v7 and Active state asserted for the moment of start.
• Declaring Incident SEV‑1 is a SpeechAct Work performed by Alex#IncidentCommanderRole:SRE_Prod in Engaged state; it changes deontic conditions (e.g., elevates RollbackAuthority).

#Knowledge governance (standards & requirements)

Roles (families).

• NormativeStandardRole (Normative‑Status Episteme) — a document that is the standard in this Context.
• RequirementRole (Deontic‑Status Episteme) — a statement that binds behaviour in this Context.

RCS (illustrative).

• NormativeStandardRole: Scope, Edition, ApplicabilityWindow.
• RequirementRole: BindingClass ∈ {shall, should, may}, TargetRole, AcceptanceClauseRef.

RSGs (named states).

• NormativeStandardRole: Proposed → Adopted → Effective → Superseded (enactable: N/A — Episteme roles are non‑enactable; they gate others).
• RequirementRole: Draft → Approved → Effective → Retired (non‑enactable).

Assignments.

• ISO_26262_ed2.pdf#NormativeStandardRole:AutoSafetyCase_2025@2025‑01‑01..open
• REQ‑BRAKE‑001.md#RequirementRole:AutoSafetyCase_2025@2025‑03‑05..open

Effects (gating, not acting).

• A system’s Work (e.g., HIL test run) is evaluated against clauses referenced by RequirementRole.
• An Approval SpeechAct (by a CAB chair who is a U.System) may transition RequirementRole: Draft → Approved. The Episteme does not “act”; Systems act, Epistemes hold status.

#Bias-Annotation

Lenses tested: Arch, Onto/Epist, Socio‑tech, Prag, Did. Scope: Kernel (A‑cluster).

• Architecture bias (Arch): treating roles/assignments as structural parts can smuggle function into mereology and break holarchies.
  Mitigation: keep roles out of BoM/structure trees; close windows instead of deleting history.

• Onto/Epist bias (Onto/Epist): anthropomorphising epistemes collapses evidence into agency (“the SOP approved”).
  Mitigation: only Systems enact Work; Epistemes may justify, constrain, and gate; enforce RE‑1 and CC‑SD‑2.

• Socio‑technical bias (Socio‑tech): role eligibility rules can silently encode exclusion, power asymmetries, or discrimination (e.g., “Approver must be X” with no rationale).
  Mitigation: keep eligibility refinements explicit in the Context, recorded as Episteme policy, and review them under D.2/D.* ethics patterns; prefer capability/competence evidence over demographic proxies.

• Pragmatic bias (Prag): over‑localising role labels can fragment reuse and create naming drift.
  Mitigation: require explicit :Context binding and explicit Bridges with CL/loss notes instead of silent equivalence.

• Didactic bias (Did): metaphors (“badge”, “mask”, “green gate”) may be misread as informal or security‑only.
  Mitigation: bind obligations to the Conformance Checklist; keep metaphors as mnemonic only.

#Conformance Checklist (normative)

#SCR (compact, memorable)

Pass these and your RoleAssignments are sound.

Anchoring & locality

1. CC‑CTX‑1. A conformant model/record MUST ensure that every RoleAssignment’s role names a role defined in the same U.BoundedContext as that assignment.
2. CC‑CTX‑2. Authors and validators MUST NOT assume cross‑Context equivalence by label; any cross‑Context relation used for substitution or checking MUST be represented only in Bridges (F.9).

Eligibility & families 3. CC‑ELIG‑1. Validators MUST reject any RoleAssignment record where role.family ∈ {Agential, Transformer, Observer, Speech} but holder :̸ U.System. 4. CC‑ELIG‑2. Validators MUST reject any RoleAssignment record where role.family ∈ {Epistemic‑Status, Normative‑Status, Service‑Governance} but holder :̸ U.Episteme. 5. CC‑ELIG‑3. Validators MUST reject any RoleAssignment record whose holder ∈ {U.Role, U.RoleAssignment} (no badge‑of‑badge chains).

Role algebra (in‑Context) See A.2.7 U.RoleAlgebra (CC‑ALG‑1, 2, 3).

Time & gating 9. CC‑WIN‑1. Record‑keeping systems and models MUST NOT delete historic RoleAssignment records; they close windows instead. If window is absent, the record MUST retain a traceable assignment start time (e.g., via a U.RoleAssigning SpeechAct Work or other evidence). 10. CC‑ENACT‑1. Conformant Work records MUST cite performedBy = some U.RoleAssignment; validators MUST be able to check that the Work interval fits the assignment window (or that an open‑ended window contains it). 11. CC‑ENACT‑2. At the Work time, validators MUST be able to (a) locate/derive a StateAssertion supporting an enactable RSG state for the cited assignment, and (b) verify that the assignment’s role satisfies the executed MethodStep’s requiredRoles in that same Context (directly or via ≤; ⊗ expands to conjunctions). 12. CC‑ENACT‑3. Runtime gates and validators MUST block enactment while the assignment lacks a supporting StateAssertion for an enactable state (e.g., during Suspended).

Strict distinction & category hygiene 13. CC‑SD‑1. Models and tools MUST NOT place Roles into BoM/structure trees; roles do not participate in mereology. 14. CC‑SD‑2. Models and tools MUST NOT treat Epistemes as Work actors; validators MUST enforce RE‑1 (by.holder : U.System).

Lexical hygiene 15. CC‑LX‑1. Authors MUST NOT use appointment as a synonym for Role Assignment in normative clauses.

Traceability 16. CC‑TRC‑1. From any U.Work, reviewers MUST be able to trace performedBy → RoleAssignment → Role → (RCS,RSG) → Context and retrieve supporting StateAssertion evidence.

#RSCR (regression harness)

Run these mental “diff checks” whenever you change roles, contexts, or states.

RSG & gating

• RSCR‑RSG‑E01. After editing an RSG, verify that each enactable state still has a live Conformance Checklist and that historic StateAssertions remain interpretable (no silent renames).
• RSCR‑RSG‑E02. If a state flips enactable⇄non‑enactable, re‑evaluate pending or recurring U.Work plans (no hidden authorisations).

SoD & windows

• RSCR‑SOD‑E01. On adding ⊥ constraints, scan for overlapping assignments that newly violate SoD; schedule revocations or rescheduling.
• RSCR‑SOD‑E02. On removing ⊥, confirm that governance rationale is recorded elsewhere (policy change Episteme).

Context churn

• RSCR‑CTX‑E01. When a Context edition updates, freeze prior RoleAssignments; create new assignments in the new Context rather than mutating old ones.
• RSCR‑CTX‑E02. Bridges referencing affected roles are reviewed for CL/loss adjustments.

Eligibility drift

• RSCR‑ELIG‑E01. If a role family changes (e.g., reclassifying Offerer from behavioral to status), audit all assignments for holder‑type violations.

Trace continuity

• RSCR‑TRC‑E01. Spot‑check that U.Work → RoleAssignment → StateAssertion chains still resolve after refactors.
• RSCR‑TRC‑E02. Randomly sample old incidents/runs to ensure reproducible authorisation verdicts.

Name stability

• RSCR‑NAME‑E01. If a role label changes, maintain the role identity; treat renamed labels as aliases inside the same Context rather than minting a new role unless RCS/RSG changed materially.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits

1. No type explosion. Structure stays stable; function lives in RoleAssignments with small, local lattices.
2. Traceable authority. Every U.Work has a clean chain: performedBy → RoleAssignment → Role → (RCS,RSG) → Context.
3. Safe heterogeneity. Different Contexts can use the same badge name differently; conflicts are dissolved by locality and explicit Bridges.
4. Didactic economy. One mental form — Holder#Role:Context@Window — covers factories, clouds, labs, and libraries.
5. Strong SoD. Incompatibilities (⊥) and bundles (⊗) are first‑class; audits become mechanical.
6. Assurance‑ready. RSG + StateAssertions convert checklists into explicit gates; CL penalties quantify Cross‑context risk.
7. Temporal honesty. Windows encode the ebb and flow of assignments without history loss.

Costs / discipline required

1. RoleDescription work. Each Context needs a minimal RoleDescription (name, RCS, RSG, checklists).
2. Bridge authorship. Cross‑context work requires explicit Bridges with CL & loss notes.
3. Vocabulary hygiene. Teams must stop using context‑less role labels.

#Teaching distillation (60‑second recap)

“Give every action a badge with a Context. The badge is a U.RoleAssignment: Holder#Role:Context@Window. The badge is valid in time (window) and green in state (RSG + StateAssertion). A Method step names the badges it needs; a Work cites the exact badge that enacted it. If a badge comes from another Context, cross with a Bridge and respect its CL penalty. Keep SoD with ⊥, reuse expertise with ≤, and require combos with ⊗. Documents don’t act — they hold status roles; only systems enact Work. With this, factories, clouds, and knowledge all speak the same, small grammar.”

#So what? Adoption test (1 minute)

If a team claims to “use A.2.1”, a random audit sample should pass all of these in minutes:

1. Badge locality: every role label is always read as Role:Context (or explicitly bridged), never as a global name.
2. Work attribution: each sampled U.Work cites a concrete performedBy = U.RoleAssignment, not just a person/system string.
3. Window + state gate: at the Work time, the assignment window fits and an enactable RSG StateAssertion exists (or the run is correctly blocked/exceptioned).
4. No badge‑of‑badge: no assignment ever binds a U.Role or U.RoleAssignment as its holder.
5. Status hygiene: no Episteme (Standard/Requirement/Evidence) is ever an actor of Work; it only gates/justifies/evaluates.

#Rationale

• Strict Distinction (A.7). Keeps identity (Holon) separate from assignment (RoleAssignment), behaviour (Method/Work), and knowledge (Episteme).
• Ontological Parsimony (A.11). One universal binding, three tiny in‑Context relations (≤, ⊥, ⊗), no global role types.
• Universal core (A.8). The same mechanism works across systems (machines, software, teams) and epistemes (standards, requirements), demonstrated in §5.
• Lexical discipline (E.10.D1 & E.10.D2). Roles are context‑local; descriptions (RCS, RSG) are descriptions of intensional roles, not the roles themselves.
• Assurance posture. Windows + RSG + StateAssertions make authorisation explicit and reviewable; Bridges + CL make cross‑Context reuse explicit and risk‑graded (B.3).

#SoTA-Echoing (notes)

#Relations

Builds on / depends on

• A.1 Holonic Foundation — U.Holon (holders).
• A.1.1 U.BoundedContext — the Context of meaning.
• A.2 Role Taxonomy — role kinds for Systems vs Epistemes; context‑local naming.
• A.2.7 U.RoleAlgebra — in‑Context ≤/⊥/⊗ relations used for substitution, SoD, and bundles.
• E.10.D1 (D.CTX) & E.10.D2 (Strict Distinction of intensional vs description) — locality & description discipline.

Enables / instantiated by

• A.15 Role–Method–Work Alignment — step gating, performer linking, evaluation hooks.
• B.1 Γ‑algebra — constructors/observers are simply roles enacted by systems.
• B.3 Trust & Assurance Calculus — CL penalties on Bridges; evidence from StateAssertions.
• D.2 Multi‑Scale Ethics — duties attach to roles; SoD encoded via ⊥.
• F‑cluster (Unification Method) — Context definitions (F.1–F.4) and Bridges (F.9) consumed here.

Interacts with

• C.* Patterns (Sys‑CAL, KD‑CAL, Method‑CAL, CHR‑CAL) — enactment hooks, measurement via Observations.
• Service & Deontics (Part D/E) — obligations and acceptance evaluated against role‑gated Work.

#A.2.1:End