#RoleMask — Contextual Adaptation of Kinds (without cloning)

C.3.4 · Cluster C.I - Core CALs / LOGs / CHRs · Stable · Part C - Kernel Extension Specifications

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

One-line summary. Defines RoleMask as a C.2.1 declaration episteme for one named local use of an exact base kind. Its content pins the base KindSignature edition, additional candidate-feature constraints, vocabulary bindings, intended guard use, and definedness. Applying it yields an exact true/false/unknown masked judgment; it creates neither a new kind nor a direct membership relation. Cross-context use requires an obtaining KindBridge relation, a target declaration, and a separate MaskAdapter declaration when constraints or bindings change. Formality remains on declaration epistemes; guard refusal remains separate from unknown.

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 — Kind intent, judgment, and extension: KindSignature is a declaration episteme; the exact four-input judgment is three-valued; any extension is a pinned-edition representation of true candidates.
• 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 declaration episteme
• masked judgment
• candidate-feature constraint
• vocabulary binding
• stable-refinement review.

#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 base kind identity, apply declared constraints and bindings, and publish one named, versioned declaration episteme that a guard can designate. The episteme is not a new U-kind, record ontology, or classification occurrence. When the constraint becomes a stable conceptual distinction, identify a separate local kind and establish its U.SubkindOf relation independently.

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 entityOfConcern (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 declaration and masked judgment

A RoleMask is a named, versioned C.2.1 declaration episteme. Its exact EntityOfConcern is the base local kind used by the named procedure or role, while its claim content designates:

1. the exact base kind and pinned base KindSignature edition;
2. the named receiving use and mask type: constraint, vocabulary, or composite;
3. additional direct candidate-feature predicates, when any;
4. vocabulary or notation bindings;
5. the exact U.ContextSlice conditions and dependencies under which evaluation is defined;
6. any context expectations routed separately to USM Scope; and
7. the intended guard use and the declaration episteme's own U.Formality, when current.

For classification, evaluate:

J_mask(candidate, kind, kindSignatureEdition, roleMaskEdition, slice) ∈ {true, false, unknown}

The masked judgment is the three-valued conjunction of the base C.3.2 judgment and every additional direct candidate-feature predicate: it is false when the base judgment or any added predicate is known false; it is true only when the base and every added predicate are known true; otherwise it is unknown because a required component cannot settle or the candidate is outside its evaluation domain. A vocabulary-only mask adds no predicate and therefore preserves the base judgment exactly. A guard may decline use on unknown; that refusal is not a false classification.

An optional RoleMaskExtension(roleMaskEdition, kindSignatureEdition, slice) may represent the candidates whose exact masked judgment is true, with both declaration editions pinned. It is not U.EntitySet, an A.14 membership occurrence, a new kind, or a direct classification relation. Context conditions such as jurisdiction, API version, and time remain USM Scope predicates and do not become candidate features.

A stable conceptual refinement may justify a separately identified local kind plus an obtaining C.3.1 U.SubkindOf relation. The RoleMask declaration itself never creates that kind or relation.

#Norms & Invariants (normative)

The following state RM-01 through RM-10 over the declaration episteme, masked judgment, Scope split, and cross-context adapter boundary.

#Definition and shape

RM-01 (Definition). A RoleMask SHALL be a named, versioned C.2.1 declaration episteme with exact base kind, pinned KindSignature edition, named receiving use, mask type, direct candidate-feature constraints, vocabulary bindings, definedness conditions, intended guard use, and any separately owned Scope expectations. Its formality characterizes this episteme, not the kind or one judgment result.

RM-02 (Not a new kind). A RoleMask MUST NOT introduce a new U.Kind. If the domain needs a stable conceptual refinement, identify another local kind and establish an obtaining U.SubkindOf relation under C.3.1; a catalog row or mask declaration does neither.

RM-03 (Determinism and three values). The exact masked judgment MUST be reproducible for fixed candidate, kind, kind-signature edition, RoleMask edition, and slice. It returns true, false, or unknown; implicit latest is forbidden and guard refusal does not rewrite unknown.

RM-04 (Mask type). A declaration SHALL state constraint, vocabulary, or composite. A vocabulary mask preserves the base judgment. Constraint and composite masks use only direct candidate-feature predicates and apply the three-valued conjunction rule: any known false conjunct gives false, all known true conjuncts give true, and every other combination gives unknown.

#Separation of channels

RM-05 (Context versus candidate). Direct governed features of the exact candidate may contribute to J_mask. Predicates about ContextSlice, including jurisdiction, standards, environment, and Gamma_time, SHALL be enforced through USM Scope. The declaration may cite both, but the guard routes them to different owners and never hides Scope inside classification.

RM-06 (Guard use). A guard MAY designate a RoleMask declaration only when its exact edition, base KindSignature edition, dependencies, and definedness are recoverable and the required candidate features can be evaluated. A mask name is not a kind synonym. The guard consumes the three-valued masked judgment and makes a separate use decision.

#Stable refinement and catalog representation

RM-07 (Stable refinement). When the additional criterion becomes a broadly reused conceptual distinction, review whether another local kind is warranted. If so, identify that kind under C.3/C.3.2 and establish an obtaining U.SubkindOf relation under C.3.1. Retire or retain the RoleMask only for its remaining local use; no mask, catalog action, or label performs kind admission.

RM-08 (Addressability and catalog representation). Every RoleMask declaration edition used by a guard SHALL have a durable designator or reference that resolves to the exact declaration edition, base KindSignature edition, dependencies, definedness, and intended use. A context MAY present those references, constraints, bindings, examples, and bridge/adapter dependencies in a catalog. The catalog row is a representation, not the declaration episteme or a new kind. Consolidation changes the catalog and may motivate a declaration revision; it does not merge kind identities by itself.

#Cross-context use

RM-09 (Bridge and adapter boundary). For cross-context masked classification, first establish the obtaining KindBridge relation between the independently identified source and target kinds. Use the target KindSignature edition and a target RoleMask declaration. When constraint predicates or vocabulary bindings change, a separate C.2.1 MaskAdapter declaration episteme states the deterministic correspondence and loss; it is neither a relation occurrence nor the target judgment. Evaluate the exact target J_mask; do not copy the source result. CL^k and any scope-bridge consequence affect R only.

RM-10 (Definedness and fail-closed use). The RoleMask and any MaskAdapter declarations SHALL each state their definedness. Outside RoleMask definedness, or when its own required evaluation dependency is unavailable, the target masked judgment is unknown. Outside MaskAdapter definedness, the adapter correspondence is unavailable and a guard declines the cross-context use without rewriting an independently evaluated target J_mask. In both cases fail-closed is a use disposition, not an assertion of false.

#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 entityOfConcern.
• Weakest-link unaffected. RoleMask declarations do not alter weakest-link rules on F/R; guards route candidate-feature predicates to the exact masked judgment and context predicates to USM Scope.

#Interactions (informative)

#With Kinds & Subkinds (C.3.1)

Use a RoleMask declaration for procedural tailoring. If the criterion becomes conceptual and stable, identify another local kind and establish the exact obtaining U.SubkindOf relation; do not treat mask reuse, promotion language, or a catalog link as that relation.

#With judgment and declarations (C.3.2)

• The base KindSignature episteme supplies the kind criterion and its own F.
• The separate RoleMask declaration supplies additional candidate-feature constraints or vocabulary bindings and may have its own F.
• The exact masked judgment pins both editions and preserves unknown; neither formality value belongs to the kind, candidate, or truth value.
• Any RoleMaskExtension is only a pinned-edition representation of true masked judgments.

#With KindBridge (C.3.3)

Cross-context use needs an obtaining KindBridge relation, its separate bridge assertion, the target RoleMask declaration, and—when constraints or aliases change—a separate MaskAdapter declaration episteme. R receives the justified penalties while F, G, and the target judgment remain unchanged. If the target constraint is a stable conceptual refinement, consider a target-side local kind and an independently obtaining U.SubkindOf relation.

#With guards (Annex C.3.A)

Guard_MaskedUse designates the exact RoleMask and base KindSignature editions, evaluates J_mask for the exact candidate and slice, checks USM Scope separately, and preserves unknown when the classification cannot settle. For cross-context use, it composes with Guard_XContext_Typed only after the KindBridge relation, bridge assertion, target declarations, and any MaskAdapter declaration are recoverable. The guard applies justified Phi(CL) and Psi(CL^k) effects to R and then makes its separate use decision; it changes neither F, G, nor classification truth.

#Anti‑patterns & Remedies (informative)

#Worked Examples (informative)

#Vehicle@ABSOnly constraint use

The RoleMask declaration episteme designates Vehicle, pins its KindSignature edition, and adds the direct candidate-feature predicate hasABS(candidate)=true. For an exact vehicle and TargetSlice, evaluate J_mask(vehicle, Vehicle, vehicleEdition, absMaskEdition, TargetSlice). Surface, speed, rig, and time remain Scope predicates. Missing ABS evidence gives unknown; a guard may decline use. If ABS becomes a stable conceptual distinction, identify local kind VehicleWithABS and establish an obtaining U.SubkindOf relation separately.

#AuthenticatedRequest@Frontend vocabulary use

The RoleMask declaration binds authHeader to local spelling X-Auth and adds no candidate criterion. The masked judgment therefore equals the base J(request, AuthenticatedRequest, authEdition, slice). Another spelling, row, or field does not classify the request. Cross-context kind use still requires the exact KindBridge relation; local aliases alone require no MaskAdapter unless their correspondence is relied on across contexts.

#AdultPatient@Clinic composite use

The declaration pins the base adult-patient signature edition and adds the direct candidate-feature criterion ageAt(patient, slice) >= 21; EHR system = X remains Scope. A date-of-birth record may support the age claim, but record availability is not the patient feature or the mask criterion. In Jurisdiction Y, establish the KindBridge relation to the target kind, use a target RoleMask edition, and use a MaskAdapter declaration only for a changed age threshold or interpretation. Evaluate the exact target J_mask. An unavailable date-of-birth dependency yields unknown; the guard declines use separately and R receives only the justified bridge penalties.

#Authoring & Review Guidance (informative)

#Authoring a RoleMask card

Publication fields (suggested). A card or catalog row may represent the RoleMask declaration's designator, base kind, pinned kind-signature edition, declaration edition, type, intended use, candidate-feature constraints, separately routed Scope expectations, bindings, definedness, examples, known bridge/adapter declarations, and any stable-distinction review note. The card is not the declaration episteme or a new ontic object. Rules of thumb.

• Keep entity predicates small and testable.
• Put context predicates in Scope, not in the masked classification criterion.
• If several teams reuse the same stable conceptual constraint, review whether a separately identified local kind and an obtaining U.SubkindOf relation are warranted; mask reuse itself establishes neither.

#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. Does the guard route context to USM, evaluate the exact three-valued masked judgment for the candidate, and keep refusal separate?
6. Does every cross-context use recover the KindBridge relation and assertion, target declarations, any MaskAdapter episteme, target J_mask, and only the justified R penalties?
7. Is declaration consolidation sufficient, or does a stable conceptual distinction warrant a separately identified local kind and independently obtaining subkind relation?

#Conformance Checklist (normative)

#C.3.4:End

---

Last Updated: 2026-08-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)