#Role Assignment & Enactment Cycle (Six-Step)

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

“Assign only what you can later justify by local meaning and observable facts.” Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting & Normalisation; F.3 Intra‑Context Sense Clustering; F.4 Role Description; F.5 Naming Discipline. Coordinates with. F.7 Concept‑Set Table; F.8 Mint or Reuse?; F.9 Alignment & Bridge; F.10 Epistemic Status Mapping; A.2.1 U.RoleAssignment; A.15.* Role–Method–Work alignment; KD‑CAL (observations, results). Aliases (informative). Assign-and-verify mental loop; six-step role cycle.

Intent. Provide a minimal set of reasoning moves that turn a Role Description (F.4), anchored in a SenseCell, into a sound claim about a concrete holder—either a Role assignment or a Status assertion—with local meaning (within one context) and a clear path to evidence (KD‑CAL). These are mental moves, not workflows or tools.

#Keywords

• role assignment
• enactment
• conceptual moves
• asserting status.

#Relations

#Content

#Intent & applicability

Intent. Provide a minimal set of reasoning moves that turn a Role Description (F.4), anchored in a SenseCell, into a sound claim about a concrete holder—either a Role assignment or a Status assertion—with local meaning (within one context) and a clear path to evidence (KD‑CAL). These are mental moves, not workflows or tools.

Applicability. Any time you (a) bind a system to a Role mask, or (b) assert a Status about a system/artefact, inside one U.BoundedContext. Use when drafting models, reconciling vocabularies, or reading external canons.

Non‑goals. No process charts, no registries, no governance roles. No Cross‑context equivalences (that is F.9). No operational runbooks—only conceptual judgements.

#Problem frame

Without disciplined Role Assignment & Enactment reasoning:

1. Sense‑family slippage. Behavioural Roles and deontic/epistemic Statuses get mixed (keep them on distinct senseFamilies, per F.0.1).
2. Context drift. A label is lifted from one canon and used as if universal.
3. Evidence vacuum. Assignments are asserted with no thought to what could show they hold.
4. Time blur. Design‑time masks are judged by run‑time traces (or vice versa).
5. Name inflation. New labels are minted to patch noisy assignments.

#Forces

#Minimal vocabulary (this pattern only)

• Context — shorthand for U.BoundedContext (per E.10.D1).
• SenseCell σ — address ⟨Context C × Local‑Sense ℓ⟩ per F.3. (Informative: we write simply σ; it already contains C.)
• Role Description — a Role or Status card anchored in a SenseCell (F.4).
• Holder — the concrete system/artefact considered for a Role binding.
• Subject — the referent of a Status assertion; determined by the Template (may or may not be the Holder).
• subject_of(τ, H) — function yielding the Subject for Status assertions given Template τ (and, if needed, candidate H).
• Eligibility — conditions on the Holder that must hold to apply the Template (F.4 invariants).
• Window — the DesignRunTag or interval relevant to the claim (design/run; instant/period).
• Evidence shape — the Observation/Result/Procedure/Feature pattern (KD‑CAL) that could confirm/refute the claim in its Context.

#Pre‑conditions (lightweight)

1. The Context is in your F.1 cut; Context ≡ U.BoundedContext.
2. The Template references a SenseCell in that Context (F.4).
3. The Holder is identified (by type or instance) without relying on Cross‑context mappings.

#The six moves (judgement schemas, notation‑free)

Each move is a thought you can justify, expressed as premises ⊢ conclusion. All moves are context‑local and side‑effect free (they assert knowledge; they do not modify artefacts).

#M1 - Locate — Fix the Context and the Template

Form. Template τ anchored at SenseCell σ≡⟨C, ℓ⟩ ⊢ address(τ) = σ

Reading. Name the Context and the exact SenseCell that gives local meaning to the Template. Note. This forbids “floating” Roles/Statuses and prevents Context drift.

#M2 - Stance — Respect DesignRunTag

Form. stance(C)=s ∧ stance(τ)∈{s, both} ⊢ compatible_stance(τ,C)

Reading. The Template’s DesignRunTag is compatible with its Context’s stance (design vs run). Note. Guards against judging a design‑mask by run‑traces or judging a run‑status by design artefacts.

#M3 - Qualify — Check Holder eligibility

Form. Holder H ∧ eligibility(τ) holds in C ⊢ eligible(H, τ @ C)

Reading. Given the Template’s eligibility predicates (F.4), the Holder qualifies to be bound/assessed in this Context. Note. Typical predicates: type membership, capability present, scope fit; all context‑local.

#M4 - Bind/Assert — Make the Role Assignment / Status claim

Role assignment (behavioural mask). eligible(H, τ @ C) ∧ window W ⊢ plays_role(H, τ : C) @ W

Status assertion (epistemic/deontic state). eligible(H, τ @ C) ∧ window W ∧ S = subject_of(τ, H) ⊢ has_status(S, τ : C) @ W

Reading. Assert either a Role binding or a Status about the appropriate subject (system, artefact, service), within a Window. Note. The subject of a Status may differ from the Role holder (e.g., a service has SLO status; a team plays a Role).

#M5 - Evidence — Shape what would make it true/false

Form. plays_role/has_status κ in C ⊢ evidence_shape(κ) = Σ(C)

Reading. From the Context’s semantics, state the Observation/Result pattern (KD‑CAL) that would confirm or refute the claim (what, where, when). Note. This is not an execution plan: it is a conceptual test tied to the Context’s vocabulary.

#M6 - Conclude — Issue a defensible verdict with confidence

Form. evidence E fits Σ(C) ∧ invariants(τ) hold ⊢ holds(κ) with confidence γ ∈ [0,1]

Reading. If observed facts match the expected evidence shape and Template invariants stand, the assignment/status claim holds with some confidence (cf. B.3). Note. Confidence combines measurement adequacy (KD‑CAL) with any Context‑specific uncertainty; no Cross‑context boost is implied.

#Autonomy admission (Green‑Gate) and ledger

• Before enactment: If the Method step lists requiresAutonomyBudget, the enacting U.RoleAssignment MUST pass the Autonomy Green‑Gate: (i) active/enactable RSG state, (ii) budget tokens/envelope remain in the declared Γ_time window, (iii) all guards pass.
• On enactment: Write an AutonomyLedgerEntry attached to the U.Work, with deltas and guard verdicts.
• On depletion: Block further autonomy‑gated steps; emit a DepletionNotice (SpeechAct) and follow the OverrideProtocolRef.
• SoD: Enforce ⊥ between autonomy consumer Role and override caller Role.

#Core invariants (normative)

1. Locality. Every judgement is about one context. No Cross‑context equivalence is presumed or implied (that is F.9’s remit).
2. Strict splits. (a) senseFamily split: Role ≠ Status (per F.0.1); (b) stance split: design ≠ run (A.7). Each judgement names its senseFamily and stance.
3. Eligibility before claim. No binding or status without eligible(H, τ @ C).
4. Window honesty. Every claim states or inherits a Window consistent with stance(τ) and stance(C).
5. Evidence‑ability. Every claim must admit at least one evidence shape Σ in its Context (KD‑CAL compatible).
6. Name discipline. Labels used in judgements follow F.5 (Tech/Plain registers; no Context tags inside names).

#Reasoning aides (didactic)

• Context‑prefix speech. Think and speak with the Context prefix when ambiguity lurks: participant (BPMN), role (RBAC), activity (PROV).
• Window templates. Prefer short phrases: “during release‑R3 cutover”, “for the Q3 service period”, “at 2025‑08‑12T14:30Z”.
• Evidence as shape words. Result of Observation of ⟨Characteristic⟩ on ⟨Feature⟩ by ⟨Procedure⟩ within W—not a measurement script.

“Assign only what you can later justify by local meaning and observable facts.”

#Anti‑patterns & remedies

#Worked examples

Each example is a context-local assignment/status reasoning trace using M1…M6. cross-context relations, if any, are noted as optional bridges (F.9) but not relied upon.

#Service availability status (ITIL + KD‑CAL)

Context. ITIL 4 (services family; design) *Template (Status). SLO:availability≥99.9% anchored at SenseCell ⟨ITIL4, “SLO (availability)”⟩.

M1 Locate. address(τ)=⟨ITIL4, SLO(availability)⟩ M2 Stance. stance(ITIL4)=design, stance(τ)=design ⇒ compatible_stance(τ, ITIL4) M3 Qualify. eligible(Service S, τ@ITIL4) if S is a published service with declared availability target. M4 Assert. has_status(S, τ:ITIL4) @ W where W = Q1‑2025 (the evaluation period). M5 Evidence shape Σ(ITIL4). Observation of availability characteristic (MM‑CHR) for S, produced by a Procedure that samples uptime and computes the Result as ratio over W. (KD‑CAL/MM‑CHR terms only; no tool implied.) M6 Conclude. If Results across W give ≥ 99.9 % with adequate sampling and declared exclusions applied, holds( has_status(S, τ:ITIL4) @ W ) with γ≈0.9. Optional bridge. If uptime sensing vocabulary is expressed in SOSA/SSN, an F.9 Bridge may map ITIL’s “availability metric” to ObservableProperty(availability) with a declared CL penalty; the assignment/status claim itself remains ITIL-local.

#Behavioural operator role (IEC 61131‑3 + Enactment)

Context. IEC 61131‑3 (control languages; run) *Template (Role). Control‑Task‑Executor anchored at SenseCell ⟨IEC61131‑3, “task executes program”⟩.

M1 Locate. address(τ)=⟨IEC61131‑3, task‑execution⟩ M2 Stance. stance(IEC61131‑3)=run, stance(τ)=run ⇒ compatible. M3 Qualify. Holder PLC_7 qualifies if it hosts program P and is scheduled by task T. M4 Bind. plays_role(PLC_7, τ:IEC) @ W where W = [08:00, 18:00] 2025‑06‑05. M5 Evidence shape Σ(IEC). Observation of task schedule and program invocation logs as Results for features T/P during W; presence of expected cyclic/event‑driven triggers. M6 Conclude. If Results show the expected executions with no missed cycles beyond tolerance, holds( plays_role(PLC_7, τ:IEC) @ W ) with γ≈0.8. Trip-wire. Do not restate this as “PROV Activity” without F.9; keep the assignment/status claim IEC-local.

#Dataset accuracy status (ISO/IEC 25024 + KD‑CAL)

Context. ISO/IEC 25024 (data‑quality; design) *Template (Status). accuracy≥0.98 anchored at SenseCell ⟨ISO25024, “data accuracy”⟩.

M1 Locate. address(τ)=⟨ISO25024, data‑accuracy⟩ M2 Stance. stance(Context)=design, stance(τ)=design ⇒ compatible. M3 Qualify. Subject Dataset D has a defined reference set and sampling protocol. M4 Assert. has_status(D, τ:ISO25024) @ W where W = “snapshot v2025‑04”. M5 Evidence shape Σ(ISO25024). Observation of correctness of sampled records vs reference, Procedure per standard, Result as proportion correct with confidence interval. M6 Conclude. If CI lower bound ≥ 0.98, holds( has_status(D, τ) @ W ) with γ≈0.85.

#Access vs behavioural: two claims, two Contexts

Contexts. NIST RBAC (access; design) and BPMN 2.0 (workflow; design). Templates. DB‑Admin (RBAC status) vs Participant (BPMN role).

RBAC claim (Status). M1…M6 yield has_status(User U, RBAC:DB‑Admin) @ W_dir with Σ(RBAC) = Observation of assignment state in the access model at time W_dir.

BPMN claim (Role). M1…M6 yield plays_role(Team T, BPMN:Participant) @ W_proc with Σ(BPMN) = Observation that lanes/pools enact tasks during W_proc.

Lesson. Two separate context-local claims — one Status assertion and one Role assignment; no implication that holding RBAC status entails playing the BPMN Role.

#Relations (with other patterns)

Builds on: F.1 Domain‑Family Landscape Survey (Contexts fixed); F.2 Term Harvesting (local terms); F.3 Intra‑Context Clustering (SenseCells); F.4 Role Description (invariants, stance); F.5 Naming Discipline (labels).

Constrains: 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? Uses outcomes of Role/Status claims to decide: a new Role/Status label only when existing Templates cannot express the claim with eligibility/Window adjustments. F.9 (Alignment & Bridge): any relation across Contexts is declared there; Role Description cards remain context-local. F.10 Epistemic Status Mapping. Consumes M6 confidences γ and Σ‑adequacy to roll up assurance.

Coordinates with. MM‑CHR (characteristics, scales) wherever Characteristic/Scale is used in evidence shapes.

Used by. Patterns (Part C) to anchor their examples: Sys‑CAL (execution/actuation roles), KD‑CAL (measurement statuses), Method‑CAL (execution claims for Methods/MethodDescription), Kind-CAL (typing claims remain outside Role Assignment & Enactment, but may inform eligibility predicates).

#Migration notes (conceptual)

1. Template refactor. If a Template’s invariants change, claims remain as‑is; re‑evaluate M6 on demand. Do not silently rewrite past claims.
2. Edition updates. When a Context’s canon updates, treat it as a new Context if sense shifts; Claims anchored to the old Context stay valid for their Window.
3. Name revisions. Renaming per F.5 does not alter address(τ)=⟨Context, SenseCell⟩; claims reference the address, not surface form.
4. Bridge introduction. Adding an F.9 Bridge never upgrades an existing Role/Status claim; at most it enables separate translations with declared loss.
5. From exception to Status. If recurring exceptions to a Role appear, prefer minting a Status Template that marks the exception rather than proliferating Roles.
6. Window tightening. If evidence shows drift, narrow future Windows; past claims remain tied to their original Windows.

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

#Static conformance (SCR)

• SCR-F6-S01 (Local address). Every assignment/status claim states address(τ)=σ where σ is a SenseCell (per F.3); no bare labels.
• SCR‑F6‑S02 (SenseFamily clarity). Each claim is typed Role or Status, never both; subjects are of the correct kind. Claim records both senseFamily and stance explicitly or by inheritance.
• SCR‑F6‑S03 (Stance compatibility). stance(Context) and stance(τ) are compatible (design/run).
• SCR‑F6‑S04 (Eligibility first). For each claim, eligible(H, τ@context) is derivable prior to assertion.
• SCR‑F6‑S05 (Window explicit). Each claim has a Window (explicit or inherited) consistent with stance.
• SCR‑F6‑S06 (Evidence‑ability). For each claim, an evidence shape Σ(Context) is stated using only that Context’s vocabulary plus KD‑CAL/MM‑CHR primitives.
• SCR‑F6‑S07 (Locality guard). No Cross‑context terms appear inside a claim; any reference to other Contexts is flagged as F.9 Bridge (informative), not used to justify the claim.

#Regression (RSCR)

• RSCR‑F6‑E01 (Edition stability). Adding a new edition/Context does not mutate existing claims’ Contexts or Windows.
• RSCR‑F6‑E02 (Name stability). Changing labels per F.5 leaves addresses and conclusions invariant.
• RSCR‑F6‑E03 (Bridge neutrality). Introducing or revising an F.9 Bridge does not auto‑flip claim truth values; at most it enables explicit translations with loss notes.
• RSCR‑F6‑E04 (Evidence refresh). When KD‑CAL procedures or MM‑CHR characteristic scales change, only γ is re‑evaluated; the claim’s semantics remain.

#Didactic distillation (60‑second recap)

Six moves. (M1) Locate the Context & SenseCell; (M2) check stance; (M3) test eligibility; (M4) bind/assert with a Window; (M5) sketch the evidence shape in that Context; (M6) conclude with confidence γ. Two iron rules. Keep it context‑local; keep Role and Status on their senseFamily. Pay-off. Assignment/status claims become small, auditable thoughts: easy to teach, easy to check, and easy to relate—later—via explicit Bridges when you truly must step between Contexts.

#F.6:End