#Anti‑Explosion Control (Roles & Statuses)

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

“Name less, express more.”

Status. Architectural pattern. Depends on. F.1 context of meaning; F.2 Harvesting; F.3 Local Sense Clustering; F.4 Role Description; F.5 Naming Discipline; F.7 Concept‑Set Table; F.8 Mint‑or‑Reuse. Coordinates with. F.10 Status Windows & Mapping; F.11 Method Quartet Harmonisation; F.12 Service Acceptance Binding; F.13 Lexical Continuity. Aliases (informative). Role/Status economy; Explosion guard.

Intent. Prevent the uncontrolled growth of Roles and Statuses by privileging reuse, bundling, explicit separation‑of‑duties (SoD), and applicability windows over minting new names. Keep the vocabulary small, crisp, and composable while remaining faithful to local meanings fixed by Contexts (F.1) and SenseCells (F.3).

#Keywords

• vocabulary growth
• guard-rails
• separation-of-duties
• bundles
• reuse.

#Relations

#Content

#Intent & applicability

Intent. Prevent the uncontrolled growth of Roles and Statuses by privileging reuse, bundling, explicit separation‑of‑duties (SoD), and applicability windows over minting new names. Keep the vocabulary small, crisp, and composable while remaining faithful to local meanings fixed by Contexts (F.1) and SenseCells (F.3).

Applicability. Whenever a new Role/Status is proposed, a team merges two lines of work, or a domain shifts its jargon. Use this pattern before adding rows to the Concept‑Set Table (F.7) or new Role Descriptions (F.4).

Non‑goals. No org charts, no RBAC policies, no process roles. This pattern describes mental moves for architectural naming, not governance machinery.

#Problem frame

Left unchecked, Role/Status vocabularies tend to diverge:

1. Synonym stacks. Reviewer, Approver, Validator, Verifier minted separately despite overlapping responsibilities.
2. Modifier creep. Night‑Operator, Shift‑Operator, Remote‑Operator proliferate where one Role plus a window would suffice.
3. SoD leakage. New names invented to evade an intended separation (Requestor‑Approver as one Role).
4. Status paintjobs. Compliant, At‑Risk, Grace, Waived, Temporarily‑Breached—labels multiply where a single Status × window model would be clearer.
5. Context blending. A control‑Context Actuator gets treated as an Enactment Execution Role; a deontic Duty becomes a runtime Status.

Explosion harms didactics and increases alignment cost (F.9).

#Forces

#Minimal vocabulary (this pattern only)

• Role Description (F.4): a Role (behavioural mask) or Status (epistemic/deontic standing) tied to a SenseCell.
• Concept‑Set row (F.7): a Cross‑context intent (“what we count as one thing”) aligned by SenseCells.
• Bundle (this pattern): a named composition of Role Descriptions that are meant to be used together by design (e.g., {Requester, Approver} for change control). A Bundle is a concept, not a package.
• SoD Constraint (this pattern): a conceptual rule stating that two Roles must not be played by the same Holder in the same window.
• Window (F.10): an claim scope (time stance, holon level, run segment) that delimits when a Role/Status holds.

#Core idea (didactic)

Use four levers before minting a name:

1. Reuse the row. If the intent matches an existing Concept‑Set row and the local SenseCell is already present, use it.
2. Bundle, don’t blur. When two Roles must travel together, name the Bundle, not a new hybrid Role.
3. Declare SoD, don’t fuse. When Roles must stay apart, state the SoD instead of minting a “super‑role.”
4. Window, don’t multiply. When a Status looks different across time/scale, keep one Status with explicit windows.

#Solution — the control cabinet (conceptual, notation‑free)

#Reuse by row (first lever)

• Move. If a proposal matches the intension of an existing row (F.7), adopt its Role Description or add a local SenseCell inside that row.
• Pay‑off. Names don’t proliferate; Cross‑context tables stay thin.

Example (services). Service‑availability‑compliance already exists as a row. New labels SLO‑Met / Uptime‑OK reuse that row; SOSA/SSN Observations later feed it (F.12).

#Bundle instead of hybrid (second lever)

• Move. When practice always pairs two Roles, define a Bundle {RoleA, RoleB}.
• Not a hybrid. Do not coin RoleAB; you’ll erase SoD options and obscure responsibilities.

Example (enactment). {Requester, Approver} is a Bundle. Request‑Approver (one Role) is not allowed; it contradicts intended checks.

#Separate by SoD, don’t evade (third lever)

• Move. Record SoD constraints where separation matters (“Requester ⟂ Approver in run window”).
• Why here. SoD belongs to semantics, not org policy; it protects structure across Contexts and times.

Example (methods). {Author ⟂ Reviewer} in the review window. A proposal Senior‑Reviewer to “do both” is rejected; the Bundle remains {Author, Reviewer} with SoD.

#Window the Status (fourth lever)

• Move. Keep a single Status and attach windows for grace, evaluation, active, archival.
• Avoid. Compliant, At‑Risk, Grace as separate Status types.

Example (acceptance). Compliance Status has readings per window:

• evaluation window: “pending check”,
• active window: “met / breached”,
• grace window: “temporarily tolerated breach”. One Status; clear windows.

#Factor modifiers as facets, not names

• Move. Treat qualifiers (shift, locality, domain) as facets of the same Role/Status or as windows, not new types.

Example (operations). Operator with window facet timeOfDay = night—not a new Role Night‑Operator.

#Invariants (normative)

1. context‑locality. Each Role Description remains tied to a SenseCell in a single Context (F.3, F.4).
2. Row preference. New Role Descriptions SHOULD map to an existing row; new rows (F.7) require F.8 justification.
3. No hybrid Roles. If two Roles are conceptually distinct, they must not be fused into one to bypass SoD. Use Bundle + SoD.
4. Windowed statuses. Status proliferation across time/scale MUST be expressed as windows of a single Status family (F.10).
5. Bundle clarity. A Bundle names only composition; it does not inherit or redefine member semantics.
6. Minimal modifier naming. Adding a modifier to a label MUST pass F.5 tests; prefer facets/windows over new Role/Status names.
7. Concept‑first. No invariant relies on organization charts or access policies; semantics precede governance.

#Reasoning primitives (judgement schemas)

Pure mental moves; no tools, no workflows.

Let rowOf(τ) be the Concept‑Set row of template τ, senseOf(τ) its SenseCell, win(τ) its window set.

1. Row reuse admissibility intent(τₙ) ≡ intent(row r) ∧ ∃σ: senseOf(σ) in r ⊢ reuseRow(τₙ → r) Reading: If the proposed template’s intent matches an existing row with a local SenseCell, reuse the row.

2. Bundle recommendation alwaysTogether{α,β} ∧ distinct(α,β) ⊢ bundle({α,β}) Reading: If two distinct Roles occur together by design, name the Bundle.

3. SoD necessity conflictRisk{α,β} ∧ sameHolder ∧ sameWindow ⊢ SoD(α ⟂ β) Reading: If the same Holder in the same window would create a conflict, require SoD.

4. Hybrid rejection SoD(α ⟂ β) ⊢ forbid(hybrid(α,β)) Reading: A SoD pair cannot be fused into one Role.

5. Windowing over multiplication status σ showsVariantsAcross(w₁,…,wₖ) ⊢ keepOneStatus(σ) ∧ win(σ)={w₁,…,wₖ} Reading: Variants across time/scale become windows, not new Status names.

6. Facet over rename modifier m changes circumstance ¬ essence ⊢ preferFacet(τ,m) Reading: If a modifier alters circumstances only, represent it as a facet/window.

#Micro‑examples (engineer / manager / researcher lenses)

#Enactment (change control)

• Proposal. Requester‑Approver as a single Role “to move faster.”
• Moves. SoD(Requester ⟂ Approver) + Bundle {Requester, Approver}.
• Result. Same throughput, preserved checks, no hybrid Role.

#Services (SLO evaluation)

• Proposal. New Status At‑Risk.
• Moves. Keep Compliance Status; add grace window and a forecast facet (informative) if needed.
• Result. One Status with windows; fewer names, clearer timelines.

#KD‑CAL (evidence)

• Proposal. Pre‑validated between Verified and Validated.
• Moves. Use Status chain within one family: Verified → Validated; represent uncertainty as confidence (F.10), not another Status.
• Result. Clean ladder; no extra label.

#Sys‑CAL (plant ops)

• Proposal. Night‑Operator, Remote‑Operator.
• Moves. Role: Operator; facets/windows: timeOfDay, presenceMode.
• Result. One Role, portable qualifiers.

#Method quartet (reviews)

• Proposal. Senior‑Reviewer to bypass {Author ⟂ Reviewer}.
• Moves. Keep SoD; if seniority matters, introduce Assurance Level facet (F.10) on the review decision, not a new Role.
• Result. Separation preserved; trust expressed as a Status property, not a Role type.

#Anti‑patterns & remedies

#Worked examples

#Enactment + Services + KD‑CAL — “SLO compliance without label sprawl”

Contexts. ITIL 4 (services), SOSA/SSN (sensing), PROV‑O (run). Intent. Track SLO compliance with minimal Status vocabulary.

• Naïve proposal. Statuses: Compliant, At‑Risk, Breached, Grace, Waived.
• Moves (F.14). Keep Compliance as one Status family; define windows: evaluation (prediction against forecast), active (actuals vs target), grace (tolerated breach). Waiver becomes a deontic Status in ODRL Context, not part of Compliance.
• Outcome. One Status + windows; observations (SOSA) and provenance (PROV) feed the active window; service policy (ITIL/ODRL) defines grace.

#Method‑CAL + Enactment — “Reviews with SoD and Bundle”

Contexts. SPEM/ISO 24744 (methods), Enactment lexicon. Intent. Prevent authors reviewing their own work while keeping names lean.

• Naïve proposal. Roles: Author, Self‑Reviewer, Peer‑Reviewer, Senior‑Reviewer.
• Moves. Roles Author, Reviewer only; SoD(Author ⟂ Reviewer) in the review window. If practice needs two reviewers, mint Bundle {Reviewer, Reviewer₂}; express seniority as a facet on the decision (Assurance Level), not a new Role.
• Outcome. Two Roles, one Bundle, one SoD; no hybrid Role; assurance is visible as a property of the review result.

#Sys‑CAL + LCA‑CAL + Services — “Operations without role fragments”

Contexts. IEC 61131‑3 (execution), state‑space control texts (actuation), ITIL 4 (services). Intent. Staff coverage across shifts and locations without ten operator types.

• Naïve proposal. Night‑Operator, Remote‑Operator, Local‑Operator, Shift‑Lead, On‑call‑Operator.
• Moves. Role = Operator; add facets/windows: timeOfDay, presenceMode, dutyCycle. If coordination is distinct, mint Coordinator Role; when both occur together, Bundle {Operator, Coordinator}; keep SoD where needed (e.g., Operator ⟂ Approver for production change).
• Outcome. One Role + small facet set + Bundle; clean hooks to execution and actuation semantics.

#KD‑CAL + Kind-CAL — “Evidence ladder without new labels”

Contexts. KD‑CAL (evidence), OWL 2/FCA (types). Intent. Express proof maturity without inflating Status names.

• Naïve proposal. Candidate‑Evidence, Preliminary‑Evidence, Verified‑Evidence, Validated‑Evidence.
• Moves. Keep one Evidence Status ladder (Collected → Verified → Validated); use Assurance Level facet (numeric or ordinal) and windows for in‑review vs active. Align types in a row; do not mint new Status names for granularity.
• Outcome. Short vocabulary, clear ladder, quantitative facet where nuance is needed.

#Relations (with other patterns)

• Builds on: F.1 (Contexts), F.2 (Harvesting), F.3 (Local Clustering), F.4 (Role Description), F.5 (Naming).

• Constrains:

  • F.7 (Concept‑Set Table): prefer row reuse; new rows require F.8 justification.
  • F.8 (Mint‑or‑Reuse): apply four levers (reuse, bundle, SoD, window) before minting.
  • F.10 (Status Windows & Mapping): encode temporal/scale variation as windows, not new Status types.
  • F.12 (Service Acceptance Binding): bind acceptance to the Compliance Status family; avoid ad‑hoc status labels.
  • F.13 (Lexical Continuity): prior names become aliases; do not carry forward inflated vocabularies as new types.

• Used by. FPF patterns to keep Role/Status vocabularies tight.

#Migration notes (conceptual playbook)

1. Map to rows. For each existing Role/Status, identify its Concept‑Set row; if two names share an intent, collapse to one row (keep other names as aliases, F.13).
2. Extract SoD. Replace “super‑roles” with Bundles plus explicit SoD; where conflict exists, SoD is normative, not cultural.
3. Demote modifiers. Convert adjectival Role types into U.Facet (per Compose‑CAL) or windows on the base Role.
4. Window statuses. Merge Status families split by time/scale into one Status + windows; move waived/exempt notions to the deontic Context if applicable.
5. Re‑use before minting. When encountering a gap, scan rows for a near‑match; only if intent genuinely differs, open a new row (F.8).
6. Preserve continuity. Keep historic labels as aliases under the consolidated template (F.13); do not rewrite past texts.
7. Rehearse the cut. After consolidation, you should be able to recite the entire Role/Status vocabulary from memory; if not, reduce again.

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

#SCR — Static conformance

• SCR‑F14‑S01 (Row reuse). Every newly proposed Role Description either references an existing row or includes a clear F.8 justification for a new row.
• SCR‑F14‑S02 (No hybrids). No Role Description’s label or definition conflates two Roles that stand in a declared SoD relation.
• SCR‑F14‑S03 (Windowed statuses). Each Status family that shows temporal/scale variation is expressed as one Status + windows (not multiple Status types).
• SCR‑F14‑S04 (Facet over modifier). Role names do not encode circumstantial modifiers; such modifiers appear only as facets/windows.
• SCR‑F14‑S05 (Context locality). Every Role Description is anchored to exactly one SenseCell; no Cross‑context semantics inside a single template.
• SCR‑F14‑S06 (Bundles are pure). Every Bundle is a set of templates with no additional semantics beyond membership and referenced SoD.

#RSCR — Regression (evolution)

• RSCR‑F14‑E01 (Vocabulary slope). Over a given interval, the count of distinct Role/Status templates does not increase unless matched by row justifications (F.8).
• RSCR‑F14‑E02 (SoD integrity). Adding templates does not introduce a label that circumvents any existing SoD relation.
• RSCR‑F14‑E03 (Window integrity). When windows are refined, Status type count remains constant; only window definitions change.
• RSCR‑F14‑E04 (Alias discipline). When labels change, prior names are recorded as aliases (F.13); no silent type multiplication.

#Didactic distillation (90‑second script)

Name less, express more. Before minting a new Role or Status, try four levers: (1) Reuse the row — if the intent already exists, adopt it and add your local SenseCell. (2) Bundle, don’t blur — when two Roles travel together, Bundle them; keep SoD if they must stay apart. (3) Declare SoD, don’t fuse — conflicts of interest are solved with SoD, not with “trusted” super‑roles. (4) Window, don’t multiply — one Status can wear different windows (evaluation/active/grace); that’s not four Status types. Keep modifiers as facets, not names; keep every Role Description context‑local via its SenseCell. If your vocabulary no longer fits in a thoughtful mind, you have an explosion—return to the levers and reduce.

#F.14:End