#U.RoleStateGraph: The Named State Space of a Role

Pattern A.2.5 · Stable Part A - Kernel Architecture Cluster

A role is not only a name; it is a trajectory of admissible states that governs when, and under which conditions, a holder of that role may enact steps of a U.MethodDescription. FPF therefore introduces a first‑class intensional object:

#Aliases

• U.RoleStateGraph

#Keywords

• state machine
• RSG
• role state
• enactability
• lifecycle.

#Relations

#Content

#Purpose & scope (why this exists)

A role is not only a name; it is a trajectory of admissible states that governs when, and under which conditions, a holder of that role may enact steps of a U.MethodDescription. FPF therefore introduces a first‑class intensional object:

U.RoleStateGraph (RSG) — the finite, named state space of a U.Role in a given U.BoundedContext, with transitions guarded by conditions over the Role Characterisation Space (RCS) and contextual events.

The RSG is the gate between assignment (U.RoleAssignment) and action (U.Work). A step may be performed only when the performer’s assignment is in an enactable RSG state at the relevant Window (time slice) and this is proven by a contemporaneous StateAssertion (verdict of U.Evaluation against the state’s Checklist).

#Problem frame (what goes wrong without an RSG)

1. Readiness blur. Teams conflate “has the badge” with “is fit to act now”. Without explicit states (Ready, Calibrated, Authorized, Suspended…), enactment checks dissolve into ad‑hoc judgement.
2. Checklist drift. Criteria for “ready/approved” live in scattered documents; there is no single conceptual anchor tying them to the role.
3. Workflow/role confusion. “State” of a workflow (according to workplan) is mistaken for the state of a role (eligibility to enact).
4. Status ≠ enactment. Epistemic/Normative roles (e.g., NormativeStandard, ApprovedSpecification) need statuses that are not enactable, yet are used to gate decisions.
5. Cross‑context substitution by name. Labels like Approved or Ready silently cross contexts with different criteria; the loss is hidden and unaudited.

Consequences. Violations of Strict Distinction (A.7) and Didactic Primacy (E.12): ambiguous authority to act, unsafe SoD, and non‑reproducible evaluations.

#Core idea (didactic)

Think of a Role as a mask, and the RSG as the traffic lights for that mask inside one context of meaning.

• The nodes are named states (Ready, Degraded, Suspended, Approved, Obsolete…).
• The edges are transitions with guards (checkable conditions over RCS characteristics and contextual events, e.g., CalibrationAge ≤ 30d; AuthorizationSpeechAct recorded).
• Each state is paired with a Checklist (criteria you test to issue a StateAssertion for a given Window).
• Some states are enactable = true (green lights); others are not enactable (status lights) and therefore can gate decisions but cannot directly authorize U.Work.

One sentence. RSG says when a badge is green. The Checklist proves it, the StateAssertion records it, and the Method step may proceed.

#Minimal vocabulary (this pattern only)

• U.RoleStateGraph (RSG). Intensional object owned by (Role, Context). Finite set of named States and typed Transitions with guards.

• RSG.State. Intensional named place. Properties:

  • enactable ∈ {true,false} — whether being in this state authorizes enactment of steps that require this role.
  • initial?, terminal? — optional markers for lifecycle reasoning.

• RSG.Transition. Edge state_i → state_j with Guard (predicate over RCS characteristics and/or contextual events such as U.SpeechAct, U.Observation, U.Evaluation results).

• RCS (Role Characterisation Space). The characteristic bundle that characterises this role in this Context (e.g., CalibrationAge, AuthorizationScope, FatigueIndex, IndependenceFlag, EvidenceFreshness). (Defined in A.2 Role Taxonomy / RoleDescription.)

• State Checklist (description). A RoleDescription component that enumerates criteria to test whether a holder can legitimately be treated as in a given state for a Window. (Description, not the state itself.)

• U.Evaluation → StateAssertion (verdict). The result of applying the state’s Checklist to a concrete holder at a time window, yielding a verdict “IN‑STATE(S) @Window” with provenance to observations/evidence.

• Window. Temporal interval to which the StateAssertion applies (e.g., [2025‑05‑01, 2025‑06‑01]).

Strict distinction note.

• RSG and its States are intensionals (what the role is allowed to be).
• Checklists and StateAssertions are descriptions/evaluations (how we know a specific holder is in that state now).

#What an RSG is not (guardrails)

• Not a workflow. RSG transitions do not encode task order; they encode eligibility changes of the role.
• Not a capability list. RSG is authorization/readiness over time, distinct from U.Capability (ability).
• Not a global status set. RSG lives inside one Context; the label Ready in another Context is a different state unless bridged (F.9).
• Not a log. RSG is not a history. Histories are StateAssertions over Windows; U.Work is the record of enactments.
• Not a document lifecycle. Epistemic role RSGs can look like document lifecycles, but they remain role‑status graphs; the carrier lifecycle stays separate (A.7, U.Carrier).

#Invariants (preview)

1. Locality. RSG(Role, Context) is defined only within that U.BoundedContext.
2. Finiteness. The State set is finite and named.
3. Checklist pairing. Every State has a Checklist in the Role’s RoleDescription; every enactable State has at least one observable criterion.
4. Green‑gate discipline. A Method step requiring Role may proceed only if a contemporaneous StateAssertion exists for an enactable State.
5. No silent Cross‑context reuse. Cross‑Context reuse requires a Bridge with CL and loss notes; local ⊥/≤/⊗ always prevail.

#Formal structure of an RSG (intensional, context‑local)

Definition. For a given U.Role in a given U.BoundedContext, its U.RoleStateGraph is the tuple RSG(Role, Context) = ⟨S, S_en, T, Guard, init?⟩, where:

• S — a finite set of named States (StateName ∈ Tech register, with a Plain label). Names are local to (Role, Context).

• S_en ⊆ S — the subset of enactable states (“green lights”). States in S \ S_en are status‑only (not enactable).

• T ⊆ S × S — a set of typed transitions sᵢ → sⱼ. Transitions are optional; the RSG may be acyclic or cyclic.

• Guard — for each transition (and optionally for state maintenance), a predicate over:

  • the role’s RCS snapshot at a Window (values on named characteristics; see A.2.3), and
  • Context events (e.g., presence of a U.SpeechAct, freshness of U.Observation, validity of a prior U.Evaluation).

• init? : S → {true,false} — optionally marks initial state(s). (Useful for lifecycles; not required for gating.)

Naming discipline (RSG‑N1…N3).

1. RSG‑N1 (Minimal set). |S| ≥ 1. At least one state must exist; if no state is enactable, the role is status‑only in this Context.
2. RSG‑N2 (Disjoint labels). State names are unique within (Role, Context); reusing global labels (e.g., “Ready”) across contexts is allowed only via Bridges (F.9).
3. RSG‑N3 (Human scale). For didactics, ≤ 7 states is the default target; exceeding it requires a one‑sentence rationale (“distinct gate we will actually use”).

#Enactability & Checklist semantics (how a state is known, now)

An RSG does not determine history; it determines what counts as being in a state, and which states authorize enactment.

#State Checklists (description, not the state)

For each s ∈ S, the RoleDescription (A.2.3) includes a State Checklist Checklist(s) — a named set of criteria that can be evaluated at a Window to test “holder is in state s”.

• Criterion kinds (illustrative):

  • Threshold over RCS characteristic: CalibrationAge ≤ 30 days.
  • Presence of act: AuthorizationSpeechAct exists within 90 days.
  • Evidence freshness: Evidence(type=SafetyTest).age ≤ 12 months.
  • SoD flag: IndependenceFlag = true.
  • External status: StandardStatus = Approved.

Strict distinction. Checklist(s) is a description; the state s is an intensional place in the role’s RSG.

#From Checklist to StateAssertion (verdict of U.Evaluation)

Evaluating Checklist(s) at a Window produces an U.Evaluation verdict:

StateAssertion(holder, Role, Context, s, Window) — “For this Window, this holder is in state s”, with provenance to the actual observations/evidence.

Rules (RSG‑C1…C5).

• RSG‑C1 (All‑must‑hold). A StateAssertion MUST justify that all required criteria in Checklist(s) hold at the Window.
• RSG‑C2 (Window freshness). Each criterion MUST define its freshness window; if omitted, default is instantaneous at the Window’s end time.
• RSG‑C3 (No guess). Pure opinion is disallowed; every criterion is grounded in observable facts (U.Observation, U.Work record, U.SpeechAct, or a derived U.Evaluation).
• RSG‑C4 (Non‑monotonic over time). A StateAssertion is not permanent; once the Window ends, a new evaluation is needed unless a maintenance guard keeps it valid (see 8.3).
• RSG‑C5 (Uniqueness not required). Multiple states may be asserted for the same Window if their criteria do not conflict (e.g., Ready and Authorized). Enactability is governed by §8.4.

#Transitions & guards (admission, maintenance, exit)

RSG transitions express how eligibility changes when guards fire. Guards are predicates; the RSG stays notation‑neutral.

• Admission guard (→ s) declares conditions to enter state s.
• Maintenance guard (s ↺) must hold to remain in s (e.g., FatigueIndex < 0.8, checked every shift).
• Exit guard (s →) declares conditions to leave s (e.g., CalibrationAge > 30d).

Rules (RSG‑G1…G3).

• RSG‑G1 (Checklists vs guards). Checklists decide recognition (“am I in s now?”). Guards describe change (“what moves me in/out of s?”). They may reuse the same predicates; their roles are distinct.
• RSG‑G2 (No control‑flow). Guards may refer to events (e.g., “Calibration completed”), but RSG is not a task graph; it does not prescribe task order.
• RSG‑G3 (Observable basis). Every guard references observable RCS characteristics or recorded events (no hidden timers).

#The Green‑Gate Law (enactment gating)

Law (RSG‑E1). A U.MethodDescription step that requires role R may be enacted at Window W iff there exists a StateAssertion(holder, R, Context, s, W) with s ∈ S_en.

Corollaries:

• RSG‑E2 (Specialization lift). If the step requires a general role R, and the holder has a StateAssertion for a specialist role R' ≤ R in an enactable state whose lift (see §9.1) is enactable for R, the gate passes.
• RSG‑E3 (Bundle gate). If the step requires a bundle R* = R₁ ⊗ … ⊗ Rₙ, enactment requires n distinct StateAssertions meeting RSG‑E1 for each Rᵢ (unless the Context defines a CompositeRole with its own RSG; see §9.3).
• RSG‑E4 (Status‑only roles). Roles with S_en = ∅ can never authorize enactment; they may gate decisions (e.g., ApprovedSpecRole) but not U.Work.

#Interaction with role algebra (≤, ⊥, ⊗) and refinement

#Specialization (≤) — RSG refinement map

When R' ≤ R (Specialist role refines General role) in the same Context, their RSGs must align by a refinement map.

Rule (RSG‑R1 Refinement). There exists a surjective mapping π : S(R') → S(R) such that:

1. Enactability preservation: s' ∈ S_en(R') ⇒ π(s') ∈ S_en(R).
2. Checklist entailment: Checklist_R'(s') ⇒ Checklist_R(π(s')) (each specialist state’s criteria imply the general state’s criteria).
3. Guard monotonicity (informal): Transitions in R' do not weaken the general readiness implied by R (entering/exiting patterns respect π).

Interpretation. Being in s' for R' guarantees being in π(s') for R. Thus StateAssertions lift along π, enabling RSG‑E2.

Design note. RCS for R' may extend that of R; specialist states can be stricter (more criteria) but not looser than their general counterparts.

#Incompatibility (⊥) — state‑aware SoD

R_A ⊥ R_B (within the same Context) states that a single holder must not have overlapping, enactable authority for both roles.

Rule (RSG‑I1). At Window W, a holder violates R_A ⊥ R_B iff there exist StateAssertions … in s_A ∈ S_en(R_A) and … in s_B ∈ S_en(R_B) both valid at W.

Optional refinement (soft ⊥). Contexts may tighten incompatibility by listing state pairs that are forbidden (e.g., Ready_A ⊥ Authorized_B), while allowing benign combinations (e.g., Suspended_A + Ready_B). By default, any enactable pair conflicts.

Didactic payoff. SoD is checked by states in Windows, not by static role labels.

#Bundles (⊗) — conjunction without product explosion

A bundle role R* := R₁ ⊗ … ⊗ Rₙ expresses “must wear all these badges at once”.

Rule (RSG‑B1). If R* exists only as a requirement macro, do not construct a product RSG. The gate for a step requiring R* is satisfied by n separate StateAssertions sᵢ ∈ S_en(Rᵢ) at the same Window.

Rule (RSG‑B2 CompositeRole). If the Context declares R* as a first‑class U.Role, it MUST also specify an RSG(R*) and an embedding ιᵢ : S(R*) → S(Rᵢ) that preserves enactability; being in an enactable state of R* implies being enactable in each Rᵢ.

Rationale. Avoid combinatorial blow‑up by default; allow a composite role only when the organization genuinely maintains its own readiness graph.

#Readiness monotonicity across specialization & bundles

• RSG‑M1 (Specialist suffices). If a step requires R, any R' ≤ R whose lifted state is enactable suffices.
• RSG‑M2 (Bundle conjunctivity). If a step requires R₁ ⊗ R₂, the performer must produce both gates (two StateAssertions), unless a CompositeRole with RSG exists and is used.

#Guard design (types and discipline)

To keep RSGs operational but not procedural, guards draw on observable inputs only.

Guard types (non‑exhaustive).

1. Threshold guards over RCS characteristics FatigueIndex < 0.8, CalibrationAge ≤ 30d, EvidenceFreshness(role=Tester) ≤ 90d.
2. Event guards (occurrence since last Window) exists SpeechAct(type=Authorization), exists Evaluation(verdict=Pass, checklist=SafetyKit).
3. Temporal guards (time within range) now ∈ AuthorizationValidityWindow, MaintenanceWindow not active.
4. Relational guards IndependenceFrom(holder=X) = true (for SoD), NoOpenIncident(severity≥High).

Rules (RSG‑G4…G6).

• RSG‑G4 (Observable only). Each guard MUST be checkable from observable artefacts (observations, work logs, speech acts, evaluations) or present RCS values.
• RSG‑G5 (Context‑local semantics). Guard semantics are scoped to Context; Cross‑context reuse requires a Bridge (§14 in Part 1/4, F.9).
• RSG‑G6 (Didactic sparseness). Prefer few, stable guards over many brittle micro‑conditions. If a guard encodes task order, you are drifting into workflow; refactor back to eligibility.

Allowed guard evidences include:

• Observation facts (measurements/metrics),
• Evaluation verdicts (checklist results),
• SpeechAct occurrences (communicative U.Work), identified by role, act kind, and window (e.g., “Approved(change=4711)”).

A SpeechAct can change the state (e.g., Prepared→Authorized) but does not by itself satisfy operational steps; it only opens their Green‑Gate.

#Putting it together (one‑screen mental model)

At any Window:

1. RoleAssignment exists (A.2.1): Holder#Role:Context.
2. StateAssertion(s) exist: the holder is in one or more states as proven by checklists (U.Evaluation).
3. Green‑Gate Law applies: if at least one asserted state is enactable, role‑gated Method steps may be enacted; if all are status‑only, the role can gate decisions but not perform work.
4. Role algebra checks: specialization lifts readiness; bundles require conjunction; incompatibilities are detected when two enactable states coincide for the same holder at the same Window.

This yields a clean separation:

• assignment (RoleAssignment)
• Readiness (RSG + Checklists + StateAssertions)
• Action (U.Work, gated by RSG)

…and keeps meaning local, evidence observable, and reasoning testable.

#Archetypal RoleStateGraphs (cross‑domain patterns)

Below are didactic, reusable RSG skeletons for the three principal behavioural role families and for epistemic/status roles. Names and criteria are context‑local; treat them as templates to specialise inside your U.BoundedContext (E.10.D1). For each RSG we list:

• S — candidate States (enactable states marked [E]);
• Checklist gist — the recognition criteria (cf. §8.1);
• Guards — illustrative admission/maintenance/exit predicates (cf. §8.3).

Reminder. Only enactable states (S_en) can open the Green‑Gate for U.Work (RSG‑E1). Status‑only states gate decisions but never execution.

#AgentialRole (decision‑capable actor)

Context sketch: Ops_ChangeManagement_2025. RCS (characteristics, examples): CompetenceLevel, FatigueIndex, IndependenceFlag, AuthorizationValidity, IncidentLoad, RiskClass.

States S

• Unprepared — training incomplete; checklists fail.
• Prepared — training + competence thresholds met.
• Authorized — valid approval window present. [E]
• Ready — Prepared ∧ Authorized ∧ FatigueIndex < τ. [E]
• Active — contemporaneous U.Work step is underway under this role (with a valid StateAssertion in the window). [E]
• Suspended — temporary block (incident/conflict).
• Revoked — authorization expired/withdrawn.

Checklist gist

• Prepared: certificates valid; recency of practice ≤ X; simulator score ≥ Y.
• Authorized: exists SpeechAct(type=Approval, scope=Role, age≤30d).
• Ready: Prepared ∧ Authorized ∧ independence from conflicting work; fatigue within limits.

Guards

• Admission → Prepared: ExamPassed ∧ SimulatorScore≥Y.
• Admission → Authorized: presence of approval speech‑act within window.
• Maintenance Ready ↺: FatigueIndex<τ ∧ IncidentLoad≤k.
• Exit Ready → Suspended: high‑severity incident assigned OR SoD violation detected.
• Exit Authorized → Revoked: window elapsed or explicit revoke speech‑act.

#TransformerRole (non‑agential executor of change)

Context sketch: PlantOps_Pipeline_2025. RCS: CalibrationAge, SafetyInterlock, SelfTestPass, EnvRangeOK, DegradationIndex.

States S

• Unavailable — offline, missing prerequisites.
• Calibrated — calibration fresh; self‑test ok.
• Permitted — safety interlocks clear; clearance token valid.
• Ready — Calibrated ∧ Permitted ∧ EnvRangeOK. [E]
• Running — executing a method step (with contemporaneous StateAssertion). [E]
• Degraded — still operable under derated envelope. [E] (if policy allows)
• Quarantined — suspected hazard; no enactment.

Checklist gist

• Calibrated: CalibrationAge≤30d ∧ SelfTestPass=true.
• Permitted: SafetyInterlock = Clear ∧ NoOpenIncident(sev≥High).
• Ready: Calibrated ∧ Permitted ∧ environment in spec.

Guards

• Admission → Calibrated: calibration record timestamp ≤30d.
• Maintenance Ready ↺: env sensors within limits; no new hazard event.
• Exit Ready → Quarantined: detected leak OR hazard alarm.
• Transition Running → Ready: step completed ∧ cool‑down satisfied.
• Transition Ready → Degraded: DegradationIndex∈[d₁,d₂] ∧ derate policy active.

#ObserverRole (measurement actor, incl. SOSA/SSN style)

Context sketch: Lab_Thermo_2025. RCS: CalibrationAge, TraceabilityChainOK, DriftRate, SyncError, CleanlinessScore.

States S

• Unqualified — no metrological chain.
• Calibrated — with traceability to standard.
• Synchronized — time/phase sync within tolerance.
• In‑Range — drift & environment within spec.
• Measuring — performing observation. [E]
• Stale — calibration or sync expired.
• Quarantined — suspect bias/contamination.

Checklist gist

• Calibrated: traceability cert valid; calibration within period.
• Synchronized: SyncError≤ε.
• In‑Range: drift ≤ threshold; contamination tests passed.
• Measuring: Calibrated ∧ Synchronized ∧ In‑Range AND observation procedure active.

Guards

• Admission → Calibrated: calibration event recorded < 180d.
• Exit Calibrated → Stale: calibration age > threshold.
• Exit In‑Range → Quarantined: contamination alert OR failed control sample.
• Transition Measuring → In‑Range: procedure complete.

Note. Many ObserverRole states are pre‑enactment gates; only Measuring is enactable.

#Epistemic/status roles (no enactment)

These roles are status‑only; S_en = ∅. They gate decisions (e.g., can be cited, can constrain), but can never authorize U.Work.

#NormativeStandardRole

States: Draft, Candidate, Approved, Superseded, Deprecated. Checklist gist: governance decision records; publication identifiers; supersession links. Guards: Approved → Superseded on adoption of newer edition; Candidate → Approved after ratification vote.

#EvidenceRole

States: Collected, Verified, Validated, Obsolete, Contested. Checklist gist: verification/validation U.Evaluation present; freshness window; reproducibility tag. Guards: decay to Obsolete by age; transition to Contested upon counter‑evidence.

#RequirementRole

States: Proposed, Accepted, Implemented, Verified, Waived. Checklist gist: acceptance decision; trace links to U.Work; verification report; waiver authorization. Guards: Accepted → Implemented when linked executions close; Implemented → Verified on passed acceptance checklist; Any → Waived by authorized speech‑act.

#One‑screen authoring templates (didactic cards)

Keep each RSG teachable on one screen. Use the following notation‑neutral templates when drafting RoleDescriptions (A.2.3).

#RSG card (per Role, per Context)

RSG for: <RoleName>   Context: <ContextName/Edition>
RCS characteristics (gist): <characteristic1>, <characteristic2>, … 
States (◉ = enactable):
  - [◉] <StateName> — checklist gist; typical admission/maintenance/exit
  - [  ] <StateName> — … 
  - … 
Green‑Gate: step requiring <RoleName> is enactable iff holder asserts any ◉ state at Window.
Role algebra hooks: specialization (≤ … ), incompatibility (⊥ … ), bundles (⊗ … ).

#State checklist snippet (per State)

State <StateName> (enactable? yes/no)
Checklist (all must hold at Window):
  - <Observable criterion 1>  (e.g., CalibrationAge ≤ 30d)
  - <Observable criterion 2>  (e.g., exists SpeechAct(Approval) age ≤ 30d)
Maintenance (optional): <predicate> (e.g., EnvRangeOK)
Evidence Graph Ref: <Observation/Evaluation ids>

#Specialization refinement map (R' ≤ R)

Refinement map π : S(R') → S(R)
R' state        π(state in R)   entailment note (why Checklist_R' ⇒ Checklist_R)
-----------     -------------    -----------------------------------------------
<Ready+>        Ready            adds stricter fatigue & independence thresholds
<Authorized+>   Authorized       requires same approval + extra duty segregation
… 

#SoD focus (⊥) — enactable pairs

Incompatibility ⊥ (applies when both sides enactable at same Window):
  <RoleA.StateX>  ⊥  <RoleB.StateY>
  <RoleA.(any ◉)> ⊥  <RoleB.(any ◉)>   // default if not refined
Rationale: <one‑line reason>

Didactic cue. If your “template” spills beyond a screen, you’re drifting into workflow. Pull back to eligibility (RSG) and recognition (checklists).

#Cross‑context adjustments (via Bridges, not imports)

RSGs are context‑local. When similar roles appear in different Contexts, relate them with an Alignment Bridge (F.9), never by silently importing state names.

#State name correspondence (lossy mapping)

Bridge example: Observer readiness across two contexts:

Bridge: Observer-RSG alignment
From: Lab_Thermo_2025.ObserverRole
To:   Metrology_Line_2025.ObserverRole
Map (with CL):
  Calibrated(Lab)     ≈  Calibrated(Metro)            CL=3 (minor criterion diffs)
  In‑Range(Lab)       ↘  Fit‑for‑Use(Metro)           CL=2 (Metro adds robustness test)
  Measuring(Lab)      ↔  Measuring(Metro)             CL=3
Notes: 'Synchronized' in Lab maps to 'Time‑Aligned' in Metro (terminology shift).
Losses: Metro’s 'Robustness' has no direct Lab counterpart (explicit loss recorded).

Rule (RSG‑X1). A Bridge MUST record losses and extra criteria; it MUST NOT assert identity without a stated CL (congruence level).

#Authorization vocabulary drift (deontic vs operational)

Bridge note: In some IT change contexts, “Authorized” (deontic) overlaps with “Permitted” (operational). A Bridge can explain the design choice:

• Authorized(AgentialRole@ITIL) ↔ Permitted(TransformerRole@IEC) with CL=1 and a note: operational interlock ≠ managerial approval; both required to lift to Ready under our policy.

Payoff. Bridges keep local honesty while enabling Cross‑context reasoning with explicit penalties (B.3).

#Author conformance (write good RSGs)

When you define or revise an RSG, check these concept‑level rules. They are easy to hold in mind; no tooling implied.

CC‑RSG‑01 (Locality). State names and meanings are scoped to (Role, Context). Reuse across contexts only via a Bridge (F.9).

CC‑RSG‑02 (Enactability). Mark which states are enactable (S_en). If none are, the role is status‑only (valid); then it cannot open the Green‑Gate.

CC‑RSG‑03 (Observable criteria). Every checklist item must be observable (Observation, Work record, SpeechAct, or derived Evaluation). No opinions.

CC‑RSG‑04 (Guard discipline). Guards gate change, checklists recognise state. Don’t smuggle task order into guards; workflow lives elsewhere (A.15).

CC‑RSG‑05 (Refinement map). If you declare R' ≤ R, provide a π‑map and ensure entailment (RSG‑R1). Specialist states may be stricter, never weaker.

CC‑RSG‑06 (SoD by state). Define ⊥ in terms of enactable pairs. Avoid blanket ⊥ if finer, state‑aware rules reduce false conflicts.

CC‑RSG‑07 (Human scale). Default to ≤ 7 states. If you exceed, add a one‑sentence didactic rationale (“distinct gate we will actually use”).

CC‑RSG‑08 (Green‑Gate wiring). Ensure every MethodDescription step that requires this Role names the ◉ states it expects, or relies on the default “any ◉”.

CC‑RSG‑09 (Window clarity). Checklists specify freshness windows; state assertions are Window‑bound and non‑permanent.

CC‑RSG‑10 (Status/behaviour split). Epistemic/status roles: S_en = ∅. They gate decisions, not Work. Behavioural roles require U.System holders (A.2.1).

#Extended grounding across four disciplines

Each vignette shows (i) the Context, Role, RCS characteristics, States (◉ = enactable), Green‑Gate condition, and how a U.Work is gated by a U.RoleAssignment+RSG. Names are context‑local.

#Clinical surgery (medicine)

Context. Hospital.OR_2026 Role. SurgeonRole (AgentialRole) RCS characteristics. CompetenceLevel, FatigueIndex, AuthorizationValidity, CaseComplexityBand, TeamSoD.

States.

• Unprepared — training/recency incomplete.
• Prepared — credentials valid; recency ≤ 90 days.
• Authorized — procedure‑specific approval active.
• Ready — Prepared ∧ Authorized ∧ FatigueIndex<τ ∧ TeamSoD_OK. ◉
• Operating — currently performing steps. ◉
• Suspended — incident or conflict raised.
• Revoked — approval expired/withdrawn.

Green‑Gate. A MethodDescription step tagged requires: SurgeonRole is enactable iff the performer’s RoleAssignment asserts Ready at the Window.

Work gating. performedBy = Dr.Kim#SurgeonRole:Hospital.OR_2026 is valid for step “Incision” only when Ready(Dr.Kim, SurgeonRole, OR_2026, W) holds (checklist items: approval id, fatigue score, SoD against AuditorRole).

#Software operations (SRE)

Context. SRE_Prod_Cluster_EU_2026 Role. IncidentCommanderRole (AgentialRole) RCS characteristics. OnCallStatus, PageFreshness, AuthorityToken, CognitiveLoad, ConflictSoD.

States.

• Off‑Duty — not on call.
• On‑Call — rota active; page reachable.
• Authorized — escalation token valid.
• Ready — On‑Call ∧ Authorized ∧ CognitiveLoad≤k ∧ SoD_OK. ◉
• RunningIncident — commanding an active incident. ◉
• CoolingDown — post‑incident refractory period.
• Blocked — conflict with ChangeAuthorRole detected.

Green‑Gate. Steps in “Major Incident Process” that require: IncidentCommanderRole open only with Ready.

Work gating. performedBy = Dana#IncidentCommanderRole:SRE_Prod_Cluster_EU_2026 is invalid for “Declare SEV‑1” if ConflictSoD(ChangeAuthorRole) holds or PageFreshness>5 min.

#Laboratory metrology

Context. Metrology_Thermo_2026 Role. ThermometerObserverRole (ObserverRole) RCS characteristics. CalibrationAge, DriftRate, TraceabilityChainOK, CleanlinessScore, SyncError.

States.

• Unqualified — missing traceability.
• Calibrated — cert valid (≤ 180 d); drift within baseline.
• Synchronized — SyncError≤ε.
• In‑Range — contamination absent; env OK.
• Measuring — procedure active. ◉
• Stale — calibration/sync expired.
• Quarantined — suspected bias.

Green‑Gate. MethodDescription step “Record temperature” is enactable only in state Measuring (which requires Calibrated ∧ Synchronized ∧ In‑Range).

Work gating. performedBy = SensorT‑17#ThermometerObserverRole:Metrology_Thermo_2026 is rejected if CalibrationAge>180 d or ControlSampleBias>δ.

#Governance / compliance

Context. Finance_Audit_2026 Role. IndependentAuditorRole (AgentialRole) and EvidenceRole (status‑only) RCS (auditor). CertificationLevel, IndependenceFlag, AssignmentToken, CaseLoad. States (auditor). Ready/Auditing as in §12.1; ⊥ with DeveloperRole. RCS (evidence). VerificationStatus, ValidationStatus, Age, ProvenanceChainOK. States (evidence). Collected, Verified, Validated, Contested, Obsolete (status‑only).

Green‑Gate. Audit step requires: IndependentAuditorRole — enactable only with Ready and ⊥ DeveloperRole at the Window. Evidence states gate decisions (e.g., “accept finding”), never open Work.

Work gating. performedBy = Alice#IndependentAuditorRole:Finance_Audit_2026 fails if Alice holds any overlapping DeveloperRole binding in the same context.

#Acceptance harness (static conformance)

Author‑facing checks; notation‑free, concept‑level. Use them when drafting or reviewing an RSG.

SCR‑A.2.5‑S01 - Local scope. Every state name is qualified by (Role, Context). No global states. SCR‑A.2.5‑S02 - Enactability mark. The set S_en is explicit; each ◉ state is listed. SCR‑A.2.5‑S03 - Observable checklists. Each state has a Checklist of observable predicates (Observation / Evaluation / SpeechAct / Work evidence). SCR‑A.2.5‑S04 - Green‑Gate wiring. Every MethodDescription step that names the Role either (a) names its ◉ state(s) or (b) relies on the default “any ◉” policy; the RSG declares which. SCR‑A.2.5‑S05 - Guard discipline. Guards only gate transitions; they do not encode task order. SCR‑A.2.5‑S06 - SoD by state. Incompatibilities (⊥) are declared over states (or “any ◉”), not over bare role names. SCR‑A.2.5‑S07 - Specialisation entailment. For every R' ≤ R, a refinement map π: S(R')→S(R) is provided; each mapped pair has an entailment note (why Checklist_R' ⇒ Checklist_R). SCR‑A.2.5‑S08 - Human scale. |S| ≤ 7 unless a one‑line didactic rationale is recorded. SCR‑A.2.5‑S09 - Status‑only roles. If S_en=∅, the Role is explicitly tagged status‑only; it cannot open the Green‑Gate. SCR‑A.2.5‑S10 - Bridge discipline. Any cross‑context reuse is via an Alignment Bridge (F.9) with recorded CL and losses; no silent imports.

#Regression harness (evolution checks)

Use when adding/removing states, changing criteria, or bridging across contexts.

RSCR‑A.2.5‑R01 - State churn impact. For every added/removed/renamed state, list affected MethodDescription steps and Work validators; confirm the Green‑Gate policy remains decidable. RSCR‑A.2.5‑R02 - Entailment stability. When R' ≤ R changes, update the π map and re‑justify entailments; fail the check if any previously valid entailment breaks. RSCR‑A.2.5‑R03 - SoD coverage. After edits, recompute the set of enactable pairs; verify declared ⊥ still blocks all intended conflicts and no longer blocks permitted cases. RSCR‑A.2.5‑R04 - Evidence freshness. If any checklist predicate uses age/freshness, ensure default Windows are documented and existing state assertions re‑evaluate accordingly. RSCR‑A.2.5‑R05 - Bridge congruence drift. If a Bridge maps states with CL=k, and either side’s checklist changes, revisit the mapping; do not keep CL unchanged by default—raise or lower with a short rationale. RSCR‑A.2.5‑R06 - Status/behaviour split. Verify behavioural roles still require U.System holders (A.2.1); status‑only roles still have S_en=∅. RSCR‑A.2.5‑R07 - One‑screen rule. If cumulative edits push the RSG beyond one screen, split states or tighten criteria; record a one‑line teaching rationale if you must exceed.

#Common failure modes (and quick remedies)

#Didactic script (90 seconds): how A.2.5 ties to A.2.1 & A.2.3

*“A role assignment says who wears which mask where (A.2.1). The RoleStateGraph says when that mask is actually wearable. Each role’s RSG is a small named state space with checklists for each state. Some states are enactable (◉): they open the Green‑Gate for Work. Others are status‑only: they gate decisions, never execution.

A RoleDescription (A.2.3) is where you publish the role’s RCS (characteristics), its RSG (states + checklists + guards), and any role algebra (≤, ⊥, ⊗) specific to your context.

In practice: a MethodDescription step lists required roles; at runtime, a Work record is valid only if its performer is a RoleAssignment whose RSG asserts an enactable state at the Window. That’s the Green‑Gate.

Different Contexts may use the same role labels. We never assume global meaning; we relate Contexts with Bridges that map states and record losses.

Keep each RSG on one screen, with observable checklists. If you’re writing task order, you’ve slipped into workflow—move it to the Method. If you’re writing opinions, convert them into observables or drop them. That’s the whole trick.”*

#Relations (quick pointers)

• Builds on: A.2.1 U.RoleAssignment (the binding that can assert states); A.2.3 U.RoleDescription (the carrier of RSG); E.10.D1 (Context discipline).
• Enables. A.15 (Role‑Method‑Work Alignment via Green‑Gate); B.3 (Trust penalties when crossing Bridges with lower CL).
• Interacts with. D‑cluster deontics (speech‑acts gate Authorized‑like states for agential roles); F.9 (state‑level alignment across contexts).

#A.2.5:End