#RoleMask — Contextual Adaptation of Kinds (without cloning)

Pattern C.3.4 · Stable Part C - Kernel Extension Specifications

One‑line summary. Defines U.RoleMask(kind, Context) as a context‑local adaptation of a U.Kind that (a) adds constraints and/or vocabulary bindings, and (b) may narrow membership deterministically within a U.ContextSlice, without creating a new kind. RoleMasks are catalogued, versioned, and guard‑addressable; frequent, stable constraint masks SHOULD be promoted to explicit subkinds. Cross‑context use of a RoleMask requires a KindBridge (for kinds) and, when needed, a MaskAdapter (for mask constraints). All penalties route to R; F/G remain unchanged.

Status. Normative in Part C. Identifier C.3.4. Audience. Engineering managers, architects, reviewers, editors.

Depends on.

• C.3.1 — U.Kind & SubkindOf (Core): kinds are intensional; ⊑ is a partial order; kinds carry no Scope.
• C.3.2 — KindSignature (+F) & Extension/MemberOf: signature F; deterministic MemberOf(e,k,slice); EntitySet(slice).
• C.3.3 — KindBridge & CL^k: Cross‑context kind mapping; CL^k penalties → R only.
• A.2.6 — USM (Context slices & Scopes): Claim/Work scope (G) over U.ContextSlice; bridges and CL for scope.
• C.2.2 — F–G–R; C.2.3 — U.Formality (F).

Non‑goals. — No repository/notation mandates; conceptual only. — RoleMask is not a governance tier, data policy, or “mini‑type system.” — RoleMask does not redefine Scope; context conditions belong to USM.

Teams often need a local projection of a widely used kind:

#Keywords

• RoleMask
• context-local adaptation
• constraints
• subkind promotion.

#Relations

#Content

#Purpose (manager’s view)

Teams often need a local projection of a widely used kind:

• Constraint: “For our procedure, take Vehicle with ABS only.”
• Vocabulary: “Here, AuthHeader is called X‑Auth.”

If each team clones a fresh kind, catalogs fragment and bridges multiply. RoleMask is the disciplined alternative: keep the kind identity, apply declared constraints and bindings, and make the mask first‑class (registered, versioned, guard‑addressable). When a mask becomes stable “de‑facto subkind,” promote it to ⊑.

Benefits: fewer near‑duplicates, cleaner Cross‑context reuse, deterministic guards, and auditable narrowing instead of hand‑wavy “this is the version we mean.”

#Context

Kinds (C.3.1/3.2) name what claims quantify over; USM (A.2.6) governs where claims hold. In practice, procedures need local tailoring of kinds for a role/process (compliance profile, product line, cohort). RoleMask gives that tailoring without mutating describedEntity (Kind) or applicability (Scope).

#Problem

1. Kind sprawl. Teams mint near‑duplicate kinds (“Account_PCI”, “Account_Ledger”), and alignment decays.
2. Hidden constraints. Informal “we only accept …” statements leak into prose; guards can’t check them deterministically.
3. Scope conflation. Contextual requirements (jurisdiction, API version) get smuggled into “type” talk, blurring Scope vs Kind.
4. Cross‑context fragility. Masks don’t travel unless their constraints are mapped; teams reuse names and hope.

#Forces

#Solution — RoleMask (overview)

A RoleMask is a named, versioned binding U.RoleMask(kind, Context) that:

1. Adds constraints (entity‑level predicates only),
2. Binds vocabulary/notation (aliases, field maps) for the Context/process,
3. May declare context expectations (selectors over U.ContextSlice, e.g., jurisdiction, API version). These are enforced via USM Scope guards (A.2.6) and do not change mask membership.
4. May narrow membership: Extension_mask(k, s) ⊆ Extension(k, s) (entity‑level narrowing only),
5. Never creates a new kind; identity stays with k.
6. Is guard‑addressable and deterministic (no “latest”).

Mask types (declared):

• Constraint mask — adds constraints; may narrow membership;
• Vocabulary mask — aliases only; no membership change;
• Composite mask — both.

Separation discipline.

• Entity‑level predicates (e.g., “hasABS(x)”) → mask membership (narrowing).
• Context conditions (e.g., “jurisdiction=EU”, “API=v2.3”) → USM Scope guards (intersection), not mask membership. Masks may carry both kinds of information, but guards must route them into the right channel.

#Norms & Invariants (normative)

The following formalize and expand RM‑01…RM‑08 referenced in C.3.

#Definition & Shape

RM‑01 (Definition). U.RoleMask(kind, Context) SHALL be a named, versioned record with: (a) intent (what role/procedure the mask serves), (b) constraints (entity‑level predicates; optional context requirements), (c) vocabulary/notation bindings, (d) membership narrowing definition (if any), (e) intended guard use.

RM‑02 (Not a new kind). A RoleMask MUST NOT introduce a new U.Kind. If the domain needs a stable refinement, Contexts SHALL publish an explicit SubkindOf node (C.3.1).

RM‑03 (Determinism). Membership under a mask (if defined) MUST be deterministic given slice and published constraints; implicit “latest” is forbidden.

RM‑04 (Mask taxonomy). A mask SHALL declare its type: constraint / vocabulary / composite. — Vocabulary masks MUST NOT change membership; — Constraint/composite masks MAY narrow membership only via entity‑level predicates.

#Separation of channels

RM‑05 (Context vs entity).

• Predicates about entities (features, attributes) MAY narrow membership: Extension_mask(k, s) ⊆ Extension(k, s).
• Predicates about ContextSlice (jurisdiction, Standards, Γ_time) SHALL be enforced via USM Scope guards (A.2.6). Masks MUST NOT hide Scope requirements inside membership checks.

Guard routing. Enforce ContextSlice predicates via USM Scope (A.2.6) and entity predicates via membership; see Annex C.3.A §4.3 (Guard_MaskedUse) and §5 (E‑01) for the normative order of checks.

RM‑06 (Guard use). Guards MAY reference a RoleMask by name only if the mask is registered, versioned, and its constraints are observable at guard time. Mask names MUST NOT be treated as kind synonyms.

#Promotion & Catalog

RM‑07 (Promotion rule). A constraint mask reused broadly and stably SHOULD be promoted to an explicit subkind with a ⊑ link; retire the mask or keep it as a vocabulary wrapper. Editors SHALL track promotions in the catalog.

RM‑08 (Catalog). Contexts SHALL catalog masks (name, version, type, intent, constraints, bindings, examples, related subkinds, known bridges/adapters). Redundant masks SHOULD be consolidated.

#Cross‑context use

RM‑09 (Bridges & adapters). If a claim uses MemberOf(–, RoleMask(k), TargetSlice) across Contexts, the receiving Context SHALL require: (a) a KindBridge for k (CLᵏ, loss notes), and (b) a MaskAdapter — a documented, deterministic mapping of the mask’s entity‑level constraints and vocabulary bindings into the target Context — whenever those constraints/bindings differ. Penalties MUST route to R: Ψ(CLᵏ) for kind, plus any Φ(CL) for scope bridge.

RM‑10 (Definedness & fail‑closed). Mask evaluation SHALL state its definedness area; outside it, guards fail closed.

#Invariants & Non‑goals (normative)

• No Scope leakage. RoleMasks cannot widen/narrow Claim scope (G); any context conditions are enforced by USM guards.
• Identity preservation. The carrier kind remains k; RoleMask does not change describedEntity.
• Weakest‑link unaffected. RoleMasks do not alter weakest‑link rules on F/R; guards route entity predicates to membership and context predicates to USM Scope.

#Interactions (informative)

#With Kinds & Subkinds (C.3.1)

Use RoleMask for procedural tailoring. If the tailoring becomes conceptual and stable, introduce a subkind with ⊑ and update references.

#With Membership & Signature (C.3.2)

• Entity‑level constraints live in mask membership (deterministic).
• Signature F belongs to the kind; raising F in the signature does not auto‑change masks.

#With KindBridge (C.3.3)

A RoleMask crossing Contexts needs two artifacts: the KindBridge (CL^k, loss notes) and a MaskAdapter (how constraints/aliases translate). R gets both penalties; F/G stay intact. If the adapter systematically narrows membership in the target Context, consider target‑side subkind.

#With Guards (Annex C.3.A)

Use Guard_MaskedUse (Annex C.3.A §4.3). It requires: — mask registration & determinism; — Scope coverage (A.2.6), Γ_time explicit; — where Cross‑context: KindBridge (CL^k) + MaskAdapter + penalties → R. — Cross‑context combo. When masks cross Contexts, use Guard_MaskedUse together with Guard_XContext_Typed (Annex C.3.A §4.5) so both bridges are checked and both penalties (Φ(CL) and Ψ(CLᵏ)) land in R. — Order of checks. Follow Annex C.3.A §5 (E‑01): typed compatibility first, then Scope coverage, then penalties to R and freshness.

#Anti‑patterns & Remedies (informative)

#Worked Examples (informative)

#Vehicle@ABSOnly (constraint mask)

Kind. Vehicle (K2, signature F4). Mask. Vehicle@ABSOnly — entity‑level predicate hasABS(x)=true; type constraint. Guards. MemberOf(–, Vehicle@ABSOnly, TargetSlice) defined & deterministic; Scope (surface/speed/rig/Γ_time) checked separately. Promotion? If ABS‑only becomes a conceptual category, publish VehicleWithABS ⊑ Vehicle and retire the mask.

#AuthenticatedRequest@Frontend (vocabulary mask)

Kind. AuthenticatedRequest defined by AuthStandard v2.3. Mask. @Frontend binds authHeader → X‑Auth (aliases only); no narrowing; type vocabulary. Cross‑context. If reused in another Context, require KindBridge for the kind; no MaskAdapter needed (aliases are local). R. Only scope bridge penalties apply (if any).

#AdultPatient@Clinic (composite mask) across jurisdictions

Kind. AdultPatient (≥ 18 at Γ_time). Mask. @Clinic: entity constraint “DOB present”; context hint “EHR system = X” (this part routes to Scope). Type composite. Cross‑context. Jurisdiction Y uses ≥ 21 → KindBridge with CL^k=1; MaskAdapter maps DOB fields. Guards. Scope bridge (coding system) + KindBridge + MaskAdapter; penalties Ψ(1) (kind) + Φ(CL) (scope) to R. Outcome. Allowed with reduced R; consider target‑side subkind AdultPerson_Y.

#Authoring & Review Guidance (informative)

#Authoring a RoleMask card

Fields (suggested). name, kind, type (constraint/vocabulary/composite), intent, constraints (entity vs context split), bindings, membership definition (if any), definedness, examples, known bridges/adapters, promotion note. Rules of thumb.

• Keep entity predicates small and testable.
• Put context in Scope, not in membership.
• If ≥ 3 teams reuse the same constraint mask → promotion review.

#Reviewer 7‑point checklist

1. Mask registered and versioned?
2. Type declared correctly (constraint/vocabulary/composite)?
3. Entity vs context split respected?
4. Determinism (no “latest”) satisfied?
5. Guard routes context to USM and entity to membership?
6. Any Cross‑context use has KindBridge + MaskAdapter with penalties to R?
7. Promotion warranted (stable, reused) or consolidation needed?

#Conformance Checklist (normative)

#C.3.4:End