#Naming Discipline for U.Types & Roles

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

Status. Definitional pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); E.10.D2 Intension–Description–Specification (I/D/S); F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting & Normalisation; F.3 Intra‑Context Sense Clustering; F.4 Role Description Definition; A.7 Strict Distinction; A.11 Ontological Parsimony; F.0.1 context‑local Lexicon Principle (RLP). Coordinates with. F.7 Concept‑Set Table; F.8 Mint or Reuse?; F.9 Alignment & Bridge; F.13 Term Registry & Deprecation. Aliases (informative). Context‑true naming; Two‑register labels.

Intent. Provide a small, normative code of naming so that U.Types (Cross‑context categories) and Role Descriptions (context‑local Roles/Statuses) are labelled clearly, locally faithful, and globally stable, without importing tooling, workflows, or editorial process. Names are consequences of meaning fixed earlier (F.1–F.4), not badges invented to “stabilise” drifting words.

#Keywords

• naming conventions
• lexical rules
• morphology
• twin registers
• U.Type naming.

#Relations

#Content

#Intent & applicability

Intent. Provide a small, normative code of naming so that U.Types (Cross‑context categories) and Role Descriptions (context‑local Roles/Statuses) are labelled clearly, locally faithful, and globally stable, without importing tooling, workflows, or editorial process. Names are consequences of meaning fixed earlier (F.1–F.4), not badges invented to “stabilise” drifting words.

Applicability. Use whenever you (a) mint or revise a U.Type name from a Concept‑Set row (F.7), or (b) assign labels to a Role Description (F.4). This pattern governs what a good name must be, not how a team produces it.

Non‑goals. No registries, reviews, or hand‑offs. No style‑police for punctuation beyond conceptual clarity. No bridging or synonym decisions across Contexts (F.9 does that).

#Problem frame

Naming errors cause structural errors:

1. Context denial. A label hides its Context, inviting Cross‑context misuse (“process” used for both BPMN and PROV senses).
2. senseFamily blur. Names conflate Role (behavioural mask) with Status (epistemic/deontic badge).
3. Over‑reach. U.Types inherit jargon from one canon and sound global while being parochial.
4. Under-reach. Role Description labels sound so generic that they pretend to be U.Types.
5. Unstable synonyms. Labels drift to placate readers rather than reflect meaning fixed in SenseCells.

This code resolves these by Context fidelity, senseFamily‑aware morphology, and two‑register pedagogy.

#Minimal vocabulary (this pattern only)

• Tech label — the Context‑idiomatic name engineers expect inside that Context.
• Plain label — a teaching gloss in simple English that does not broaden the sense.
• Symbolic alias (optional) — conventional symbol if the canon uses one (e.g., “≤”).
• SenseCell — the (Context × Local-Sense) address cited by a Role Description card (F.3–F.4).
• Concept‑Set row — the Cross‑context table row that supports minting a U.Type name (F.7).

#Core idea (didactic)

Name what the invariants already make true.

For Role Descriptions, speak like the Context (Tech), then teach it (Plain). For U.Types, speak like nobody’s Context: pick the neutral, minimal‑generality label that best fits the intersection shown by your Concept‑Set row.

#Normative rules — Role Descriptions (context‑local labels)

Let T be a Role Description in Context C with SenseCell sense(T)=⟨C,σ⟩.

R‑RD‑1 (Two registers). Provide both: Tech(T) = the Context‑idiomatic phrase (exact canon wording if possible). Plain(T) = a brief, neutral explanation that does not broaden meaning. Symbolic alias is optional and purely informative.

R‑RD‑2 (No Context tags in labels). Do not embed the Context name in the label (avoid “(BPMN)” in the label itself). Context is already carried by the SenseCell; keep labels clean.

R‑RD‑3 (senseFamily‑aware morphology). — Role names are countable nouns for masks (e.g., Participant, Operator, Reviewer). Avoid verbs and gerunds. Add the suffix “Role” only if the Context idiom risks confusion with a substance or a status (e.g., “Reviewer Role” in a Context that also has a “Reviewer Status”). — Status names are state nouns or adjectival‑noun collocations (e.g., Approved, Compliant, In‑Service, Access Role (RBAC)). If a family of levels exists, encode the level (Assurance L1, Readiness L2) rather than inventing decorative adjectives.

R‑RD‑4 (Local idiom first). Prefer the canon’s term of art even if it sounds narrower than a cross‑discipline cliché. The Plain label handles pedagogy; the Tech label honours the Context.

R‑RD‑5 (Minimal generality). Choose the narrowest label whose invariants you actually assert. Do not “upgrade” Task to Activity or Process just to sound universal.

R‑RD‑6 (No permissions by stealth). Role labels must not imply entitlement (“Privileged Operator” is a Status+Role mashup). Keep deontics in Status names in the deontics Context.

R‑RD‑7 (Edition‑neutral labels). Do not bake edition/profile into labels. Edition lives in the Context; the card binds to a SenseCell that already encodes edition where needed.

R‑RD‑8 (Short and stable). Favour 1–3 words. Avoid rhetorical adjectives (“robust, optimal, best‑practice”).

#Normative rules — U.Types (Cross‑context labels)

Let U be a U.Type minted from a Concept‑Set row (F.7) satisfying A.8 (≥3 domain families) AND MinInterFamilyDistance ≥ δ_family (from F1‑Card).

R‑UT‑1 (Witnessed neutrality). The Tech label must not be a term owned by one context when alternatives exist. Prefer discipline‑neutral head nouns (Result, Reading, Execution, Evidence, Requirement, State, Type Node). Use Characteristic/Scale/Value/Level/Coordinate/Score/ScoringMethod only when the U.Type denotes a measurement‑sense kind anchored in a declared CharacteristicSpace; otherwise avoid these measurement‑canon terms to prevent semantics bleed.

R‑UT‑2 (Minimal generality). Name the least upper sense that all row witnesses share. If Observation and Measurement disagree, perhaps the U.Type is Result or Reading, not Observation.

R‑UT‑3 (No senseFamily mixing in names). Do not name a U.Type with deontic or behavioural language (“PermittedService”, “ResponsibleAgent”). Role/Status/Method/Execution belong to Role Descriptions (F.4) or local senses; U.Types are what‑it‑is kinds, not what‑it‑does or what‑is‑allowed.

R‑UT‑4 (Head–modifier discipline). Prefer head nouns with light modifiers over stacked compounds. Good: Evidence Status, Requirement Status, Type Node. Risky: Multi‑stage‑workflow‑execution‑record (compresses a scenario into a name).

R‑UT‑5 (No Context tags in names). U.Types are Context‑agnostic; never append “(BPMN)”/“(PROV)”. Provenance for the row lives in F.7, not in the name.

R‑UT‑6 (Alias only for pedagogy). Allow Plain aliases for teaching; Tech label is unique and stable. Synonym management belongs to F.13; do not invent alternates ad hoc.

R‑UT‑7 (Family coherence). When minting a family, use parallel shapes (… Status, … Level, … Characteristic only for measurement families with a declared CharacteristicSpace) so related U.Types signal relation by form.

R‑UT‑8 (Symbolic names sparingly). Symbols may be listed as aliases for readers of formal sections; they are never the U.Type’s Tech label.

R‑UT‑9 (No edition/version in name). Versions live in the Concept‑Set evidence; the name denotes a time‑robust kind.

#Twin rules

Mandatory Tech name. Every U.Type/Role MUST declare a Tech name; plain twin is optional. Role suffix invariant. Role Tech names MUST end with Role; plain twin MUST keep “(role)” on first use. No head elision. Head terms MUST NOT be dropped in a way that changes expected Kind (e.g., “Approval” ≠ “Approver (role)”). One twin, one context. At most one plain twin per Context; register in E.10.P.

#Invariants (normative, lightweight)

INV-F5-1 (Pair). Every Role Description card and every U.Type MUST carry Tech and Plain labels; symbol is optional and informative.

INV-F5-2 (Context fidelity for Role Descriptions). Tech(T) MUST be idiomatic for its Context; Plain(T) MUST NOT broaden sense(T).

INV‑F5‑3 (Neutrality for U.Types). Tech(U) MUST be discipline‑neutral with respect to the witness Contexts in its Concept‑Set row.

INV‑F5‑4 (senseFamily honesty). Role Description Role labels are behavioural masks; Role Description Status labels are states/badges; neither sneaks in the other senseFamily.

INV‑F5‑5 (Minimality). Labels MUST reflect the minimal generality supported by invariants (F.4 for Role Description, F.7 for U.Types).

INV-F5-6 (No Context tags). Names MUST NOT embed Context/edition tags; that information resides in SenseCells (Role Description) and Concept-Set rows (U.Types).

#Reasoning primitives (judgement schemas, notation‑free)

Pure mental checks; no tools implied.

1. Context-idiom check (Role Description). T in Context C ⊢ idiomatic(Tech(T), C) Reading: The Tech label reads like the Context’s own term of art.

2. Plain‑safety check. sense(T)=⟨C,σ⟩ ⊢ ¬broadens(Plain(T), σ) Reading: The Plain label explains without enlarging the sense.

3. Neutral‑witness check (U.Type). witnessContexts(U)=R ⊢ neutral(Tech(U), R) Reading: The Tech label doesn’t privilege one witness Context’s jargon.

4. senseFamily form check (Role Description). senseFamily(T)=Role ⊢ nounMask(Tech(T)) senseFamily(T)=Status ⊢ stateForm(Tech(T)) Reading: The morphology matches the senseFamily.

5. Minimality proof. inv(T) ⇒ nameScope(Tech(T)) ⊆ senseScope(sense(T)) (Role Description) rowWitnesses(U) ⇒ nameScope(Tech(U)) ⊆ intersectionScope(row) (U.Type) Reading: The name’s scope is no wider than what the invariants/witnesses support.

6. Collision ping. similar(Tech(X), Tech(Y)) ∧ senseFamily(X)≠senseFamily(Y) ⊢ requireDisambiguatorOrSplit Reading: If two labels nearly coincide across senseFamilies, either add a minimal disambiguator (Role Description only, within Context idiom) or split concepts.

#Micro‑examples (illustrative)

Role Description (BPMN Context). Tech: Participant - Plain: actor in a workflow - senseFamily: Role (No “BPMN” in label; behaviour mask, not entitlement.)

Role Description (RBAC Context). Tech: Access Role - Plain: named permission set - senseFamily: Status (Deontic badge; not a behavioural mask.)

Role Description (ITIL Context). Tech: Service‑Level Objective - Plain: service target value - senseFamily: Status (Levelable family: SLO [target], SLI [indicator] handled in F.10/F.12 semantics, not in the label.)

U.Type (from Concept‑Set row: SOSA Observation, PROV Activity (result‑bearing), ML Metric Reading). Tech: Result - Plain: the produced value or record of a measurement/assessment (Neutral head noun when “Observation” is too Context‑coloured.)

U.Type (from OWL class, FCA concept, taxonomy nodes). Tech: Type Node - Plain: a node in a type hierarchy or lattice (Neutral across DL and FCA.)

#Anti‑patterns & remedies

#Worked examples

Each example shows the reasoning move that leads to the label; no procedures, no tooling.

#Role Description labels (context-local)

(a) BPMN Context — behavioural mask vs node word

• SenseCell. ⟨BPMN 2.0, local‑sense: lane/pool actor that enacts tasks⟩
• Decision. Tech = Participant (Context idiom); Plain = actor in a workflow
• Why. Participant is the mask; it is not the node (Task, Event). (R-RD-3, R-RD-4)

(b) RBAC Context — deontic badge

• SenseCell. ⟨NIST RBAC, local‑sense: named permission set assigned to sessions⟩
• Decision. Tech = Access Role; Plain = named permission set
• Why. It’s a Status, not a behavioural mask; deontic plane kept explicit. (R-RD-3, R-RD-6)

(c) ITIL Context — service target

• SenseCell. ⟨ITIL 4, local‑sense: target value for a service characteristic⟩
• Decision. Tech = Service‑Level Objective; Plain = service target value
• Why. Family will carry … Level, … Indicator in adjacent cards; avoids jargon drift. (R-RD-3, R-UT-7)

(d) IEC 61131-3 Context — run-time execution notion as Role Description?

• SenseCell. ⟨IEC 61131‑3, local‑sense: cyclic/event‑driven task unit⟩
• Decision. For a Role Description Status of a run, label Completed, Failed, Skipped (Context idiom); avoid naming the Work itself here.
• Why. The record of work is a U.Type elsewhere (A.15.1); Role Description in this Context carries badges of runs. (A.7 stance split; R-RD-3)

#U.Type labels (from Concept‑Set rows)

Row R₁ (measurement‑sense): SOSA: Observation • ML practice: metric reading • Metrology: measurement result

• Witness Contexts. sensing; ML metrics; metrology
• Decision. U.Type Tech = Result; Plain = the produced value or record of a measurement/assessment
• Why. Neutral head noun covering all witnesses; avoids privileging SOSA’s Observation. (R‑UT‑1, R‑UT‑2)

Row R₂ (type‑structure): OWL: class / subclass • FCA: formal concept (node in concept lattice)

• Witness Contexts. DL; FCA
• Decision. U.Type Tech = Type Node; Plain = a node in a type hierarchy or lattice
• Why. Neutral over DL vs FCA; head‑modifier shape is stable. (R‑UT‑1, R‑UT‑4, R‑UT‑7)

Row R₃ (status family): ITIL: incident status • Safety cert.: assurance level • QA: readiness level

• Witness Contexts. services; assurance; QA
• Decision. Two U.Types: Assurance Level, Readiness Level (family‑coherent), plus Requirement Status (for normative clauses)
• Why. Separates families; preserves level vs status distinction. (R‑UT‑7, R‑UT‑3)

#Mixed scenario (service acceptance over execution traces)

Contexts in play. IEC 61131‑3 (run), SOSA/SSN (sensing), ITIL 4 (services).

1. Role Description (ITIL) — Tech: Service-Level Objective; Plain: service target value.
2. U.Type (from R₁) — Tech: Result (to host measured values).
3. Role Description (IEC) — Tech: Completed / Failed (Status on a run).
4. Name discipline payoff. The sentence “Compare IEC run Results against the ITIL Service‑Level Objective” is Context‑true without tags, because each label encodes its senseFamily and neutrality.

#Migration notes (conceptual)

1. When a Context changes edition. Names stay; the SenseCell shifts to the new edition. Only change a label if the sense has changed; then split the card rather than mutate the name. (INV‑F5‑2, R‑RD‑7)

2. When a Concept‑Set row gains a new witness Context. Re‑ask neutrality: if the Tech label now privileges a Context, refactor to a more neutral head (e.g., Observation → Result). (R‑UT‑1, R‑UT‑2)

3. Collision emergence. If a Role card and a Status card converge phonetically (Approver vs Approved), keep both but add the minimal morphological disambiguator only where the Context idiom demands it (Reviewer Role). (R-RD-3)

4. Family hygiene. As families grow, keep parallel shapes (… Level, … Status). If a legacy label breaks shape, add a Plain alias for teaching; don’t rename the Tech label without Concept‑Set pressure. (R‑UT‑7, R‑UT‑6)

5. Language variants. Non-English canons keep their own Tech labels (idiomatic in that Context); the Plain label remains English in FPF unless the Part mandates localisation. (R-RD-4, INV-F5-1)

6. Symbol addition. You may add a symbolic alias later for readers of formal sections; never promote a symbol to the Tech label. (R‑UT‑8)

7. De‑jargonising the Plain label. If readers stumble, adjust Plain wording only; do not widen the sense. (Plain‑safety check)

8. Deprecation path. If a label must change, publish the new Tech + Plain, keep the old as an alias in the registry (F.13), and leave the reasoning trail in the Concept‑Set row that forced the rename. (R‑UT‑6, F.13 linkage)

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

#Static conformance (SCR)

• SCR-F5-S01 (Two registers). Every Role Description card and U.Type has both Tech and Plain labels; any symbol is marked alias.
• SCR-F5-S02 (Context fidelity for Role Descriptions). For any Role Description T in Context C, Tech(T) appears idiomatic in C; Plain(T) does not broaden sense(T).
• SCR‑F5‑S03 (Neutrality for U.Types). For any U.Type U, its Tech label does not coincide with a witness Context’s proprietary term when alternatives exist.
• SCR‑F5‑S04 (senseFamily morphology). Role labels are countable nouns; Status labels are state nouns / adjectival‑noun forms.
• SCR-F5-S05 (Minimal generality). For each label, there exists a reading where the name’s scope ⊆ invariant scope (Role Description) or ⊆ row intersection (U.Type).
• SCR‑F5‑S06 (No Context tags). No label embeds Context or edition strings.
• SCR‑F5‑S07 (Family coherence). Families that claim parity (e.g., Levels) show parallel shapes across members.

#Regression checks (RSCR)

• RSCR‑F5‑E01 (Witness drift). When a Concept‑Set row gains/removes a witness Context, re‑evaluate neutrality; if violated, refactor the Tech label to a more neutral head.
• RSCR-F5-E02 (Edition churn). When a Context updates, Role Description labels remain stable unless the sense changed; if sense changed, split the card and keep aliases in F.13.
• RSCR‑F5‑E03 (Collision guard). If two labels become confusable across senseFamilies, either add the minimal disambiguator (Role Description only, Context‑idiom) or separate the concepts.
• RSCR‑F5‑E04 (Rhetoric creep). Periodic skim for decorative adjectives; remove them unless they encode formal levels or families.

#Didactic distillation (60‑second recap)

Name what is already true. Role Description labels speak like the Context (Tech) and teach without widening (Plain). U.Type labels speak like nobody’s Context: neutral head nouns at minimal generality, shaped in parallel families. Never glue Context tags or editions into names. Never mix senseFamilies in morphology. If witnesses change, reconsider neutrality; if senses split, split names, don’t stretch them. The label is the last step of understanding, not the first.

#F.5:End