#Role Description (RCS + RoleStateGraph + Checklists)

Pattern F.4 · Stable Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

“Name the mask or the badge — and say what it commits to — but only inside a Context.” Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); E.10.D2 Intension–Description–Specification Discipline; F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting; F.3 Intra‑Context Sense Clustering; A.2.1 U.RoleAssignment; A.7 Strict Distinction; A.11 Ontological Parsimony. Coordinates with. F.5 Naming Discipline for U.Types & Roles; F.7 Concept‑Set Table; F.9 Alignment & Bridge Across Contexts; B.3 Trust & Assurance Calculus (for later status evaluation). Aliases (informative). Mask/Badge card; role card (plain only).

Intent. Provide a conceptual template for two kinds of assignables:

#Keywords

• role template
• status template
• invariants
• RoleStateGraph (RSG)
• Role Characterisation Space (RCS).

#Relations

#Content

#Intent & applicability

Intent. Provide a conceptual template for two kinds of assignables:

• Role Template — a behavioural mask that a holder can wear in a specific Context (U.BoundedContext), shaping how it acts (via Method/Execution relations).
• Status Template — an epistemic or deontic badge that a holder (or artefact, event, claim) can bear inside a Context, shaping how it is treated (evaluation, permission, standing).

Each template is grounded in a SenseCell ⟨Context, Local‑Sense⟩ from F.3 and declares minimal invariants that later assignments must satisfy. No Cross‑context meaning is imported here.

Applicability. Whenever you need to speak precisely about what it means to be a Participant (BPMN), hold an access‑role (RBAC), be an Incident (ITIL), or carry a Verified status (evidence line), before minting U.Types or drawing Cross‑context bridges.

Non‑goals. No workflows, no storage, no editors. No equations for assurance or control; those live in Part B/C. This pattern describes how to think and speak about assignables — not how to manage files.

#Problem frame

Without explicit Role Descriptions:

1. Role/status conflation. Access role (RBAC) treated as behavioural mask (BPMN participant); deontic duty treated as runtime effect.
2. Context drift. A “role” quietly starts meaning different things across canons; later assignments contradict each other.
3. Hidden commitments. We name a role/status but never state what must hold when it is assigned; downstream reasoning becomes arbitrary.
4. Premature unification. A single template tries to straddle several Contexts; losses remain implicit.

#Forces

#Minimal vocabulary (this pattern only)

• Context — U.BoundedContext (per E.10.D1).
• Local‑Sense — a consolidated sense in a Context (F.3).
• SenseCell — the address ⟨Context, Local‑Sense⟩.
• Role Template — behavioural mask defined in a Context, later bound by U.RoleAssignment.
• Status Template — epistemic/deontic badge defined in a Context, later asserted as a claim about a holder/artefact.
• Holder — the thing that may wear a mask or carry a badge (e.g., a U.System, U.MethodDescription, U.Work, U.Episteme).

#Core idea (didactic)

A Role Description is a small card that says: (i) which Context’s sense it relies on (SenseCell), (ii) what label we use to speak about it (Tech & Plain), and (iii) what must hold when someone wears the mask (Role) or bears the badge (Status).

It is not a definition by prose alone; it is a pledge of invariants — minimal, Context‑true, and later checkable.

#The Role Description Card (one‑screen sketch)

Each bullet is a thought‑item, not a file field.

Header

• Template kind: Role | Status
• Label pair: Tech (idiomatic) - Plain (didactic) (naming discipline in F.5)
• SenseCell: ⟨ContextId, Local‑Sense label⟩

Applicability

• Holder scope: what can wear/bear it (e.g., U.System, U.Work, U.MethodDescription, U.Episteme).
• Time stance: design / run aligned to the Context (F.1).
• Preconditions (Context‑true): crisp conditions that must already be true in the Context’s idiom.

Invariants (minimal)

• Behavioural invariants (Role) or Evaluation invariants (Status) — 2–5 short lines stating what must hold after assignment/assertion, using the Context’s vocabulary and SenseCells where needed.
• Separation guard: a one‑line reminder of what this template does not imply (prevents senseFamily mixing).

Consequences (informative)

• Typical interactions: which Method/Execution/Observation constructs (by SenseCell) this template usually touches — names only.
• Common misreads (trip‑wire): 1–2 bullets to prevent known confusions.

Memory rule: If your card can’t be read in under two minutes, you are writing a manual, not a template.

Autonomy hooks (when Role may act autonomously)

• RCS additions (illustrative): AgencyLevel ∈ {None, Assisted, Delegated, Autonomous}, SafetyCriticality ∈ {SC0..SC3}.
• RSG gate: mark which states are enactable under autonomy (cf. A.2.5); link to AutonomyBudgetDeclRef.
• References: If autonomy is claimed for this Role, the Role Description MUST reference: AutonomyBudgetDeclRef (id, version), Aut-Guard policy-id (PolicyIdRef), OverrideProtocolRef.
• Checklist: include a pre‑enactment checklist item “Autonomy Green‑Gate passed” (guard verdicts present).

#Normative invariants (template discipline)

1. context‑local grounding. Every Role Description MUST cite exactly one SenseCell as its semantic locus.
2. I/D/S layer separation.
   • A Role Template MUST NOT encode deontic, access, or measurement rules.
   • A Status Template MUST NOT encode behaviour or control flow.
3. Time honesty. The card’s stance (design/run) MUST match the Context’s stance (F.1).
4. Minimality. Invariants SHOULD be the fewest that decide the assignment; avoid procedural sequences.
5. No Cross‑context smuggling. A single card MUST NOT import foreign semantics; if two Contexts are needed, the relation is handled later in F.9.
6. Label fidelity. Tech label MUST be idiomatic to the Context; Plain label MUST not widen the sense (F.3).
7. Binding Standard (roles). A Role Template is the design‑time mask; at run‑time, a U.RoleAssignment creates System‑in‑Role instances that are subject to the card’s invariants.
8. Assertion Standard (statuses). A Status Template is a badge; asserting it commits to the card’s evaluation invariants and to the Context’s way of checking them (later anchored via SenseCells, not formulas here).

#Reasoning primitives (judgement schemas, notation‑free)

Conceptual moves only; no APIs, no data stores.

1. Template grounding Template T cites SenseCell ⟨C,σ⟩ ⊢ meaning(T) is local to C Reading: The template’s meaning is context‑local.

2. Role assignability holder h, RoleTemplate T, preconds_T(h) ⊢ assignable(h,T) Reading: If the preconditions hold for h, it is eligible to wear the mask T.

3. Role assignment obligation assignable(h,T) ∧ bind(h,T: C) ⊢ invariants_T(h) must hold Reading: Once bound (via U.RoleAssignment), h must satisfy T’s behavioural invariants.

4. Status assertability StatusTemplate S, evidence_in_C supports S for x ⊢ assertable(x,S) Reading: If evidence in the Context C supports S for x, the badge is assertable (details of evidence logic live in Part B).

5. Status consequence assertable(x,S) ∧ assert(x,S) ⊢ evaluation_invariants_S(x) Reading: Once asserted, S’s evaluation invariants constrain how x is treated.

6. Separation guard RoleTemplate T ⊢ not(deontic_implied(T)) - StatusTemplate S ⊢ not(behaviour_implied(S)) Reading: Wearing a mask doesn’t grant permissions; carrying a badge doesn’t define behaviour.

7. Bridge embargo T cites ⟨C,σ⟩ ∧ C≠C′ ⊢ no‑equivalence(T@C, −) inside F.4 Reading: No Cross‑context equivalence is asserted here; use F.9 later.

#Worked examples (Context‑true)

Illustrative cards only; names are tech/plain labels, not final U.Type IDs (F.5 will govern naming).

#Role Template: participant (workflow actor) — Context: BPMN 2.0 (2011)

• Kind: Role

• Label: Tech participant - Plain workflow actor

• SenseCell: ⟨BPMN_2_0, participant (actor in workflow)⟩

• Holder scope: U.System (organisation, team, service)

• Time stance: design

• Preconditions: Holder is addressable as a lane/pool in the workflow model.

• Behavioural invariants:

  1. Activities assigned to the participant appear in its lane/pool.
  2. The participant interacts through message flows at its boundaries.
  3. The participant does not define run‑time occurrence; it structures the model.

• Separation guard: No permissions implied; no execution logs implied.

• Typical interactions (informative): BPMN process (graph); message event (node).

• Common misreads: ≠ RBAC role; ≠ PROV Activity.

#Status Template: access‑role membership — Context: NIST RBAC (2004)

• Kind: Status

• Label: Tech access‑role - Plain permission role

• SenseCell: ⟨NIST_RBAC_2004, role (permission grouping)⟩

• Holder scope: U.System (user/session)

• Time stance: run

• Preconditions: A defined set of permissions exists for the role.

• Evaluation invariants:

  1. If x carries this badge, x’s session inherits exactly the role’s permissions.
  2. The badge does not describe behaviour in a workflow; it determines access.

• Separation guard: No commitment about BPMN assignment; no deontic duties.

• Typical interactions (informative): permission, session (RBAC).

• Common misreads: ≠ participant (BPMN); ≠ person as an ontological type.

#Status Template: incident (service disruption) — Context: ITIL 4 (2020)

• Kind: Status

• Label: Tech incident - Plain service disruption

• SenseCell: ⟨ITIL4_2020, incident (service quality drop)⟩

• Holder scope: U.Work (recorded occurrence affecting a service)

• Time stance: run

• Preconditions: A service exists with declared SLOs/quality metrics.

• Evaluation invariants:

  1. The occurrence reduces service quality below acceptable levels.
  2. It triggers restoration activities per service practice (names only).

• Separation guard: Not a plant fault; not a BPMN event node.

• Typical interactions: SLO (ITIL), Observation (SOSA) — names only.

• Common misreads: ≠ problem (root cause category).

#Role Template: task runner (control runtime) — Context: IEC 61131‑3

• Kind: Role

• Label: Tech task - Plain program runner

• SenseCell: ⟨IEC_61131_3, task (runtime execution unit)⟩

• Holder scope: U.System (controller CPU/task scheduler)

• Time stance: run

• Preconditions: A program is registered for cyclic/event execution.

• Behavioural invariants:

  1. Invokes assigned program according to cycle/trigger.
  2. Provides schedule constraints (period/priority) to its program.

• Separation guard: No claim about deontic guarantees or service targets.

• Typical interactions: Execution (A.15 family), Actuation (Sys‑CAL).

• Common misreads: ≠ workflow task; ≠ algorithm (design).

#Anti‑patterns & remedies

#Concept‑level operators (refinement & compatibility)

Judgement schemas — pure reasoning moves over cards. No APIs, no storage, no workflow.

Let sense(T) denote the SenseCell cited by template T. Let inv(T) denote the set of invariants on T. Let senseFamily(T) ∈ {Role, Status}. Let stance(T) ∈ {design, run} (from the Context).

#Same‑Context equivalence

Form. sense(T₁) = sense(T₂) ∧ inv(T₁) ⇔ inv(T₂) ⊢ T₁ ≡ T₂

Reading. Two cards in the same Context with logically equivalent invariants co‑designate the same assignable.

Tech cue. Use this to merge duplicates conceptually without changing labels.

#Refinement (strictness order)

Form. sense(T₁) = sense(T₂) ∧ inv(T₁) ⇒ inv(T₂) ⊢ T₁ ⪯ T₂

Reading. T₁ is a refinement of T₂ if its invariants imply those of T₂ (same Context).

Effects. Assigning T₁ automatically satisfies T₂; the converse need not hold.

#Incompatibility (mutual exclusion)

Form. sense(T₁) = sense(T₂) ∧ (inv(T₁) ∧ inv(T₂) ⇒ ⊥) ⊢ incompatible(T₁,T₂)

Reading. Two cards in the same Context are mutually exclusive if their invariants cannot co‑hold.

Use. A conceptual Separation‑of‑Duty signal without governance.

#Co‑wearability / co‑bearability

Form. senseFamily(T₁)=senseFamily(T₂)=Role ∧ stance(T₁)=stance(T₂) ∧ ¬incompatible(T₁,T₂) ⊢ coWearable(T₁,T₂) senseFamily(T₁)=senseFamily(T₂)=Status ∧ ¬incompatible(T₁,T₂) ⊢ stackable(T₁,T₂)

Reading. Within a Context, two Roles can be worn together (or two Statuses carried) when they do not conflict.

#Time‑stance alignment

Form. stance(T)=design ⊢ inv(T) may not assert run‑facts stance(T)=run ⊢ inv(T) may not assert design‑commitments

Reading. Invariants must respect the Context’s DesignRunTag (F.1).

#Binding/Assertion admissibility

Form. (Roles) holder h ∧ preconds_T(h) ⊢ assignable(h,T) assignable(h,T) ∧ bind(h,T) ⊢ inv(T)(h)

Form. (Statuses) evidence_in_Context(C) supports S for x ∧ sense(S)=⟨C,σ⟩ ⊢ assertable(x,S) assertable(x,S) ∧ assert(x,S) ⊢ inv(S)(x)

Reading. Preconditions and evidence gate the act of wearing a mask or bearing a badge; once done, invariants apply.

#Cross‑context embargo (inside F.4)

Form. sense(T₁)=⟨C,−⟩, sense(T₂)=⟨C′,−⟩, C≠C′ ⊢ no‑relation(T₁,T₂) here

Reading. F.4 never asserts Cross‑context relations. If a relation is desired, it becomes a Bridge in F.9.

#Relations (where this card sits)

Builds on: E.10.D1 D.CTX (Context ≡ U.BoundedContext); F.1 (Contexts cut); F.2 (harvested terms); F.3 (Local‑Sense → SenseCell); A.2.1 U.RoleAssignment; A.7 Strict Distinction.

Constrains: F.5 (Naming): pairs Tech/Plain must reflect the Context idiom and avoid Cross‑context overreach. F.7 (Concept-Set Table): rows reference SenseCells; Role Description cards point to those rows but never create cross-context identity. F.8 (Mint or Reuse?): prefer refinement (⪯) over new cards; split cards rather than mixing senseFamilies. F.9 (Alignment & Bridge): any relation across Contexts is declared there; Role Description cards remain context-local.

Is used by. A.15 family (Role–Method–Work alignment) to interpret System‑in‑Role and Work; Part B evidence/status checks to interpret evaluation invariants.

#Migration notes (conceptual playbook)

1. Context update (edition split). If the Context’s Local‑Sense changes, fork the card per new SenseCell; keep the old card as historically valid.
2. Family correction (Role/Status). If a card mixes behaviour and deontics, split into one Role and one Status; move permission language to the Status.
3. Tighten by refinement. When practice reveals a stricter understanding, prefer T′ ⪯ T over replacing T; this preserves existing assignments conceptually.
4. Rename safely (labels only). If F.5 revises labels, change Tech/Plain wording; SenseCell and invariants remain untouched.
5. Scope correction. If Holder scope was too wide, split into parallel cards with disjoint Holder scopes; avoid complex conditional invariants.
6. Bridge discovery. Do not inject Cross‑context text into cards; record the relation as an F.9 Bridge (with CL policy), leaving the cards as they are.

#Acceptance tests (SCR/RSCR — concept‑level)

#Static conformance (SCR)

• SCR‑F4‑S01 (Uni‑Context grounding). Each card cites exactly one SenseCell.
• SCR‑F4‑S02 (Family honesty). senseFamily(T) is either Role or Status; invariants match the family; a separation guard line is present.
• SCR‑F4‑S03 (Time honesty). stance(T) matches the Context’s stance; no opposing‑stance claims appear.
• SCR‑F4‑S04 (Minimality). Card lists 2–5 invariants; none are procedural step lists.
• SCR‑F4‑S05 (Label fidelity). Tech label is idiomatic to the Context; Plain label does not widen meaning.
• SCR‑F4‑S06 (No Cross‑context import). Invariants reference only the Context’s idiom or other SenseCells by name (no identity claims).
• SCR‑F4‑S07 (Holder clarity). Holder scope is a single coherent kind (e.g., U.System or U.Work), not a grab‑bag.
• SCR‑F4‑S08 (No tooling/governance). Card contains no mentions of manifests, pipelines, editors, or workflows.

#Regression (RSCR)

• RSCR‑F4‑E01 (Edition churn). When a Context edition changes, existing cards are not overwritten; new cards are added per SenseCell.
• RSCR‑F4‑E02 (Refinement safety). If T′ ⪯ T is introduced, prior usages of T remain conceptually valid; no backward contradictions arise.
• RSCR‑F4‑E03 (senseFamily integrity). No card changes senseFamily across revisions (Role↔Status) without an explicit split noted.
• RSCR-F4-E04 (Bridge discipline). After adding an F.9 Bridge, Role Description cards remain unchanged; cross-context meanings do not seep back into cards.
• RSCR‑F4‑E05 (Label updates). Label changes per F.5 preserve SenseCell and invariants; tests treat them as renames, not semantic edits.

#Didactic distillation (60‑second close)

A Role Description card is a Context-true way to speak about an assignable: a Role (behavioural mask) or a Status (epistemic/deontic badge). Each card names one SenseCell, gives a Tech/Plain label, states minimal invariants, and declares what it does not imply. Cards never mix Role/Status senseFamilies and never cross I/D/S layers, never flip time stance, and never import other Contexts. Inside one context, you can compare cards by equivalence (≡), refinement (⪯), incompatibility, and co‑wearability. across Contexts, say nothing in the card; use a Bridge later. Keep cards one‑screen simple: enough to decide assignments; nothing procedural; no tools; just clear thought.

#F.4:End