Fpf Local First Unification Naming Protocol

F.18:2 - Problem

Without a shared naming protocol inside Part F, the same recurrent failures appear:

1. Global‑name illusion. A short label travels from one context to another and is assumed to mean the same thing; later, contradictions surface during acceptance or assurance.
2. Context drift. A label gradually changes inside its Context (edition, scope, envelope) without leaving a clean trace; readers argue over “what we meant.”
3. Kind confusion. Names hide what sort of thing is being named (System vs Episteme vs Role vs Service, etc.), leading to category errors and brittle integration.
4. Threshold‑in‑the‑name. Numeric limits, duty segregation, or state qualifiers get baked into names (“Critical‑Reviewer‑0.2 mm”), which cannot age or compose.
5. Stealth renames. Quiet label swaps, steered by fashion or politics, sever continuity with earlier evidence, plans, and bridges.
6. Explosion by synonyms. Teams mint many near‑synonyms instead of reusing a Concept‑Set row or creating an explicit Bridge with loss notes.

These failures erode trust, block reuse, and make Part F machinery (Concept-Sets, U.RoleDescription, Bridges) harder to apply.

F.18:3 - Forces

F.18:4 - Solution — The Local‑First Naming Protocol

F.18 defines eight rules (R‑rules) and six practices (P‑practices). Together they produce Name Cards that any reader can interpret ontologically without guessing, and that slot cleanly into the rest of Part F.

Path Card (subset of Name Card). A Name Card whose object‑of‑talk/entity-of-interest is an EvidenceGraph Path: it cites a PathId (or PathSliceId), Context, ReferencePlane, Γ_time, and any Bridge id(s) + CL/CL^plane (with loss notes). Used by G.6 and G.10 to make justifications portable on UTS.

F.18:4.1 - The Eight R‑rules (normative)

R1 — Speak every name with its Context. A name is never context‑free. When you introduce or use a name, pair it with the Bounded Context where it lives (the “Context of meaning”), and with the edition of that Context if relevant. In everyday speech: “X, in Y.” Cross‑context use requires a Bridge; labels alone do not travel.

R2 — State the ontological Kind on the Card. Every Name Card must state the Kind (System, Episteme, Role, Service, Method, Work, Objective, Requirement, Decision, Characteristic, etc.). This prevents category errors and keeps Role–Method–Work alignment clean. Clarification: this is a Card requirement, not a demand that the label string begin with the Kind.

R3 — Declare the Purpose / use‑domain on the Card. In addition to Kind, the Name Card must state the intended Purpose / use‑domain that situates the concept in practice and signals which families of contexts are expected to use it (e.g., mathematical formalism, engineering practice, computer science, systems management). This enables reconstruction of usage from the lexicon and reduces unintended scope drift. Clarification: this is a Card field; it does not require the label string to carry the purpose qualifier.

R4 — Resolve the name to a Local‑Sense. A minted name must resolve to a Local-Sense inside its Context (the result of F.2–F.3). If a name points to a Role Description, state that template and its sense basis. Avoid heavily overloaded surface terms: when needed, prefer concise two-word Tech labels that hint at the intended sense.

R5 — Use Twin Registers (Unified Tech + Plain). Provide two human‑oriented labels on the Name Card, per E.10 register discipline:

• a Unified Tech label (short, morphology‑stable, neutral in wording);
• a Plain label (reader‑friendly phrasing for managers and subject‑matter experts).

The Unified Tech label is the only one used in Core normative prose; Plain is for teaching and examples. Both remain context‑local; neither establishes Cross‑context identity (that is the job of the UTS row and Bridges).

R6 — Keep thresholds and states out of the name. Do not encode numeric limits, separation‑of‑duties, or readiness states in the label. Put thresholds on Method steps (capability/acceptance), states in Role State Graphs, and SoD via incompatibility relations. Names carry what this is and which Context claims it—not when and how it may act.

R7 — Cross‑context only by Bridge with loss notes. When another Context needs to reference a name, use an Alignment Bridge that states the relation (equivalent, narrower, broader, analogous) and its Congruence Level with explicit loss/fit annotations. Never equate two names by label alone.

R8 — Make renames and merges first‑class events. When a label changes, or two labels consolidate or split, record it on the Name Card as a lifecycle action (rename, merge, split, retire) with rationale and dates. Past uses remain valid as historical facts; continuity comes from lineage, not silent edits.

F.18:4.2 - The Six P‑practices (normative process)

P1 — Candidate set (NQD-front of seed-words). Do not pick a label “in one shot”. Build a small, non-dominated candidate set (an NQD-front, typically 5–10 items) by seeding and varying along: Traditions — mathematics, physics, engineering, computer science, systems thinking, management, etc. with their typical contexts and situations; use maximum diversity here; Novelty/Familiarity — from careful reuse of established terms to sharper neologisms from recent SoTA traditions;
Lexical form — distinct head terms and morpheme families, readability/pronounceability, inflection/declension, transparency. Use the Novelty–Quality–Diversity discipline from Part G to maintain only non-dominated candidates; when appropriate, you may implement this via Γ_nqd.generate (G.18). Record the seeds and the short rationale in the Card’s notes. Choose final Unified Tech/Plain labels from this frontier; if a strong candidate is discarded, briefly note why.

For the purposes of Diversity_P, group candidates into head-term families (same base noun/verb + minor prepositions or case endings). Variants such as “Reference plane”, “Plane of reference” and “Referred plane” count as one family, not three distinct candidates. An NQD-front with multiple near-clones from one family does not satisfy the diversity requirement. Aim for ≥ 3 distinct head-term families in the CandidateSet; if the front ends up with fewer families (e.g. due to a very narrow domain or strong AliasRisk on other heads), the Name Card MUST record a brief rationale in the NQD-front notes.

Lexical Q‑axes for the NQD‑front When P1 uses NQD‑CAL (C.18), treat the Quality vector over candidates as part of the same archive as C.18’s NQD‑frontier. Recommended axes (all ordinal; no arithmetic means):

• SemanticFidelity (P — Ontological precision). Question. Does the label verify against the Minimal Definitional Statement (MDS) and Concept‑Set row without adding or losing core invariants? Scale (ordinal; ↑ better). {Misleading, Vague, Precise, Exact} with Exact ≻ Precise ≻ Vague ≻ Misleading.
  Link to P2. When P2 is run, derive the SemanticFidelity rating from the per‑sense‑seed judgements: candidates with any core sense‑seeds classified as wrong‑prototype MUST be rated Misleading; candidates rated SemanticFidelity ≥ Precise SHOULD have at least a configurable fraction θ_P (default θ_P = 0.7) of sense‑seeds in on‑target and NONE in wrong‑prototype. Discard candidates that remain Misleading after revision.

• CognitiveErgonomics (S — Sociolinguistic admissibility).
  Question. Can the target RoleEnactors (engineers, managers) read, pronounce, and recall the label without specialist training?
  Scale (ordinal; ↑ better). {Alienating, Jargon, Acceptable, Natural} with Natural ≻ Acceptable ≻ Jargon ≻ Alienating. Prefer labels ≥ Acceptable in the home Context.

• OperationalAffordance (O — Morphological/action alignment). Question. Does the morphology of the label hint at its role in methods/morphisms (object vs process vs result) and support the required derivational family (noun/verb/participial forms)? Scale (ordinal; ↑ better). {Opaque, Role‑hinting, Action‑aligned}. Action‑aligned labels make it obvious whether we are naming an actor, an activity, or an artifact (e.g., Author vs Authoring vs AuthoredArtifact).
  Kind‑sensitive cues. When the Kind on the Card is a Role, prefer agentive/holder morphology (…Role, …er, …or or local equivalents); when the Kind is Method/MethodDescription, prefer verbal or gerundive forms; when the Kind is Holon, prefer result nouns, when Work, prefer verb. Misaligned morphology (e.g., a Role named with a pure process noun) should be treated as a penalty on OperationalAffordance and, if retained for legacy or regulatory reasons, called out explicitly in Card notes. See F.5/F.11/F.12 and LEX‑BUNDLE §8.

• AliasRisk (A — Lexical overload).
  Question. How likely is a careful reader to import a wrong sense from neighbouring FPF artefacts or external canons when they see this string?
  Scale (ordinal; ↓ better). {Safe, Context‑dependent, High‑Risk, Overloaded} with Safe ≻ Context‑dependent ≻ High‑Risk ≻ Overloaded. Avoid adopting Overloaded labels unless required by legacy and called out explicitly in notes. When C.18’s DomainDiversitySignature is available, AliasRisk MAY be refined into a CHR‑typed characteristic with the same polarity.

Use these axes for Pareto comparison only (per C.16 ordinal discipline). Do not collapse them into a single scalar score; the NQD‑front is computed over the vector of lexical Q‑components together with Novelty and Diversity_P.

P2 — Semantic read‑through against archetypal situations.
Alongside the NQD‑front of label candidates, maintain a small set of 5–10 archetypal situations (“sense‑seeds”) that instantiate the intended use (purpose) across different traditions. For each candidate label and each sense‑seed, perform a read‑through test:
– write 1–2 short example sentences per sense‑seed (e.g., “In case X, we perform <Label>”);
– classify the outcome, for a careful reader in the home Context, as one of {too‑narrow, on‑target, too‑wide, wrong‑prototype}.
Maintain, on the Name Card, a small tally per candidate of how many sense‑seeds fall into each class. Use these tallies both to prune candidates and to instantiate SemanticFidelity (P‑axis): labels with a sustained pattern of wrong‑prototype hits on core sense‑seeds SHALL be removed from the NQD‑front (or kept only as deprecated aliases with an explicit warning). Candidates rated SemanticFidelity ≥ Precise SHOULD satisfy the θ_P constraint from the SemanticFidelity definition (fraction of on‑target seeds) and have no wrong‑prototype counts.
Record rejected candidates and their mismatch patterns in the Name Card’s NQD‑front notes.

P3 — Mint‑or‑Reuse gate (F.8). Before minting, search your Context’s Concept‑Set table. If a row already covers your sense, reuse it and only add a local label. If not, propose a new row and capture the decision in a brief rationale.

P4 — Concept‑Set linkage (F.7). Every Name Card must indicate its Concept‑Set row (or record “not applicable” for intentionally Context‑unique names). This is the handle for alignment and anti‑explosion control.

P5 — UTS registration (F.17). Publish each Name Card to the Unified Term Sheet with Context, kind, twin labels, sense anchor, edition, and lifecycle status. Keep the UTS the single, human‑readable table of record.

P6 — Lifecycle hygiene (F.13). Apply the same discipline to renames, splits/merges, and retirements; leave a forward/backward pointer so readers can trace continuity at a glance.

F.18:5 - The Name Card (authoring template, representation-agnostic)

F.18:5.1 - Card purpose & mode guard (normative)

To prevent “post-hoc justification” of intuitively chosen labels, every Name Card SHALL declare its CardMode ∈ {MintNew, DocumentLegacy}:

• MintNew. The Card is the output of an NQD-style lexical search over a candidate label set generated inside the home Context(s), using the lexical Q-tuple {SemanticFidelity, CognitiveErgonomics, OperationalAffordance, AliasRisk} together with Novelty (N) and Diversity_P (per A.0 / C.17–C.18 / B.5.2.1).
  – The Card SHALL record:
  – a minimal CandidateSet (the labels actually evaluated), with head-term family tags for each candidate;
  – the resulting NQD-front of non-dominated candidates over ⟨Q-tuple, N, Diversity_P⟩;
  – a short selection note explaining why the chosen Tech/Plain pair was picked from that front (e.g., “better CognitiveErgonomics at equal SemanticFidelity”).

  – A single-element NQD-front is permitted only if the Card records a brief rationale why no alternative candidate survived the lexical and NQD filters (e.g., legacy constraints, strong AliasRisk on all other options).

• DocumentLegacy. The Card documents an externally imposed legacy label (e.g., a regulatory or de facto Standard) and its mapping to FPF structures. In this mode the Card MAY omit a full NQD-front, but SHALL:
  – state the legacy source / provenance;
  – either (i) provide at least a sketched NQD-comparison of viable internal variants against the legacy label, or
  (ii) record a short out-of-scope rationale (e.g., “name frozen by law; see cited Standard”) explaining why NQD search is not being used for selection.

For all Core-surface naming of U.Types and other canonical FPF concepts, MintNew is the default CardMode; using DocumentLegacy for such names requires an explicit justification on the Card.

A Name Card is the authoritative, human‑readable record of a name inside its Context. It has these fields; teams may add local notes.

1. Row ID — the stable, opaque UTS row identifier (the identity anchor).
2. Twin labels — Unified Tech and Plain (per E.10).
3. Context of meaning — the Bounded Context and, if relevant, its edition.
4. Kind — what sort of thing this is (System, Episteme, Role, Service, Method, Work, Objective, Requirement, Decision, Characteristic, etc.). This is an ontological category, not a surface‑string prefix.
5. Purpose / use‑domain — the intended area(s) of use (which families of contexts are expected to use it).
6. Minimal Definitional Statement (MDS) — one‑paragraph intended sense in the home context (no tool/process slang).
7. Didactic subtitle — ≤ 12 words that signal pragmatic use.
8. Sense reference — a Local‑Sense reference (how F.2–F.3 clustered it).
9. Concept‑Set linkage — Concept‑Set reference or “not applicable” (with rationale).
10. Alignment note — if a Bridge exists to other Contexts, cite it and record loss/fit in plain words (no formulas required on the Card).
11. Relation kind — if the name is for a relation, declare structural vs epistemic and validationMode ∈ {axiomatic, inferential, postulate}. For structural relations, provide Constructive grounding (tv:groundedBy → Γₘ.sum|set|slice). If the name is not for a relation with arity ≥ 2, set this field to “n/a”.
12. Manager’s clip — one‑line “use/avoid” guidance for everyday communication.
13. Archetypal situations (sense‑seeds) — 5-10 short “X‑case” lines used by P2 for the semantic read‑through; keep them edition‑aware and context‑local.
14. NQD‑front seeds — brief rationale for discarded candidates (include mismatch patterns from P2 and any lexical Q‑scores used in P1).
15. SemanticFidelity/CognitiveErgonomics/OperationalAffordance/AliasRisk scores for the NQD-front labels.
16. Version — current status and history of editions.
17. Card notes — optional free text with comments about the name (e.g., recommended translations, etymology, pronunciation).

Manager’s reading habit. When two names collide in a meeting, ask for their Context, Kind, Purpose/use‑domain, and Sense anchor. If any of those differ, you are comparing different things; switch to Bridge talk, not label talk.

F.18:6 - What belongs in the label—and what does not

Belongs (keeps the label clean and durable):

• The core head word that names the thing (the Kind is recorded on the Card; the string need not encode it) (e.g., “Pump”, “Standard”, “Requirement”, “Surgeon”, “Cooling”).
• A purpose qualifier if it is essential to the local sense and stable across editions (e.g., “Cooling” vs “Fuel”).
• A scope qualifier only if it is part of the meaning rather than the current plan (“Surgical Ward” rather than dates or batch numbers).

Does not belong (move elsewhere):

• Numbers and thresholds (put on steps, capabilities, acceptance clauses).
• States (use Role State Graphs and checklists).
• Temporal windows (work plans and history).
• Organisational authorisations (speech acts and assignments).
• Imported acronyms from other Contexts (use Bridges with loss notes instead).

Quick litmus for authors. If removing a number, date, or state does not change the meaning of the thing, it should not be in the label.

F.18:7 - Worked triad (three short, context‑local examples)

(Names below are illustrative; the same words in other Contexts may mean something else. The point is how the Name Card keeps them clear.)

F.18:7.1 - Industrial operations Context: “Thermal Management - 2026”

• Kind: Service
• Purpose / use‑domain: industrial thermal utilities; line‑level planning and operations
• Unified Tech label: Cooling Supply
• Plain label: Chilled water for line B
• Sense anchor: supply of water at defined temperature/flow to boundary B
• Concept‑Set: “Utility service” row; local variant recorded
• Alignment note: Bridge to “Plant Utilities - 2026” notes that “Cooling Supply” there bundles filtration; loss: filtration is not guaranteed in this Context
• Version: 20 Feb 2024
• NQD‑front (seed candidates): Cooling Supply, Chilled Water Service, Process Cooling, Cooling Utility. Chosen: Cooling Supply (neutral, morphology‑stable).

Why it’s good. The label doesn’t encode temperature or flow limits (those live in acceptance). It names a Service; nobody will confuse it with a pump System or a Method.

F.18:7.2 - Clinical Context: “Hospital OR - 2026”

• Kind: Role
• Purpose / use‑domain: OR governance and staffing; credentialing and checklists
• Unified Tech label: Surgeon Role
• Plain label: Operating surgeon
• Sense anchor: person who is authorised to perform surgical steps under defined checks
• Concept‑Set: “Clinical roles” row
• Alignment note: Bridge to “Training & Credentialing - 2026” shows partial overlap; loss: that Context’s “Senior Surgeon” carries teaching duties that do not apply here
• Version: Feb 2025; renamed‑from “Lead Surgeon” (2025) with rationale: avoided “lead” vs “operating” ambiguity
• NQD‑front (seed candidates): Surgeon Role, Operating Surgeon, Primary Surgeon, Operating Physician. Chosen: Surgeon Role (Kind‑neutral string; Plain clarifies). Lexical Q snapshot (PSOA‑style, informative).

Why it’s good. No fatigue thresholds or readiness states in the name; those live in the Role’s state graph and checklists.

F.18:7.3 - Public service Context: “Civic Services - 2026”

• Kind: Requirement
• Purpose / use‑domain: service performance management; public service SLAs
• Unified Tech label: Passport Lead‑Time
• Plain label: Time to issue a passport
• Sense anchor: elapsed time from complete application to issuance
• Concept‑Set: “Service quality requirements” row
• Alignment note: Bridge to “Legal Framework - 2026” records that legal “deadline” has different remedies; loss: legal exemptions not carried into this Context
• Version: current
• NQD‑front (seed candidates): Passport Lead‑Time, Issuance Time, Service Turnaround, Time to Issue Passport. Chosen: Passport Lead‑Time (neutral; Plain remains didactic).

Why it’s good. Target values (e.g., ≤ 20 days) are not in the label; they live in acceptance clauses.

F.18:8 - Conformance Checklist (editor aid) — Part I: naming & cards (non‑normative)

CCE‑F18.1 (Context pairing). Every name used in normative text must be paired with its Context of meaning. If you cannot name the Context, you do not have a valid name.

CCE‑F18.2 (Kind clarity). Every Name Card must state the kind (System, Episteme, Role, Service, Method, Work, Objective, Requirement, Decision, Characteristic, …). Using labels that hide kind is non‑conformant.

CCE‑F18.2a (Purpose declared). Every Name Card must state the Purpose / use‑domain (families of contexts where the concept is expected to be used). Omitting Purpose is non‑conformant.

CCE‑F18.3 (Sense anchoring). A minted name must resolve to a Local‑Sense in its Context. If a sense cannot be stated, label minting is deferred.

CCE‑F18.4 (Twin registers). Each Name Card carries a Unified Tech and a Plain label (E.10). Tech appears in Core prose; Plain in teaching/examples.

CCE‑F18.5 (No thresholds/states in labels). Numeric limits, readiness states, and separation‑of‑duties must not appear in labels. Put them on steps, checklists, and role algebra.

CCE‑F18.6 (Bridge‑only travel). Cross‑context reuse of a name must go through an Alignment Bridge with an explicit relation and loss/fit notes. Label matching alone is forbidden.

CCE‑F18.7 (Lifecycle visibility). Renames, splits/merges, and retirements must be recorded on the Name Card with dates and rationale. Past occurrences remain valid as historical facts.

CCE‑F18.8 (Mint‑or‑Reuse gate). Before minting, authors must check the Context’s Concept‑Set table; if a row exists, reuse it with a local label unless a documented reason compels a new row.

CCE‑F18.9 (UTS entry). Names used in normative artefacts must appear on the Unified Term Sheet with the specified Name‑Card fields; include Notes when present).

CCE‑F18.10 (No cross‑kind labels). Do not reuse the same Unified Tech label for different kinds inside one context (e.g., “Cooling” as a Service and as a Method). If unavoidable, add a stable qualifier to disambiguate and record the decision on both Name Cards.

CCE‑F18.11 (Manager’s clip). Each Name Card should carry a one‑line “use/avoid” note to guide everyday speech. Where omitted, editors add it during review.

CCE‑F18.12 (Anti‑explosion check). If three or more near‑synonyms for the same Local‑Sense appear in drafts, authors must either consolidate to one label or record an intentional synonym pair with use/avoid notes and a plan to converge.

F.18:9 - Normative Standard (what must be true)

This section is binding. It specifies the publication Standard for unification‑oriented names in the Unification Suite (Part F), with local‑first authority, bounded context clarity, and one‑way unification upwards along the ladder. It complements, and does not replace, the structural and epistemic Standards elsewhere in FPF.

9.1 Local authority & home. Every unification name has a single home: exactly one Bounded Context that authors and stewards it. The home is responsible for the definition, examples, and lifecycle of the name. Cross‑context reuse happens by bridges, not by relocating the home.

9.2 Minimum definitional payload. A published name MUST ship with a human‑readable Minimal Definitional Statement (MDS) that states the intended sense in the home context, and a Didactic Subtitle (≤ 12 words) that signals its pragmatic use. The MDS must be free of process slang and implementation jargon.

9.3 Row ID + label surfaces. For each adopted name, the home supplies:

• a Row ID (the opaque UTS identifier — the identity anchor), and
• two label surfaces: a Unified Tech label (for Core prose) and a Plain label (for teaching). Both labels refer to the same underlying sense; Plain may simplify terms, not premises.

9.4 One‑way dependencies. Each rung on the ladder depends only downwards: a name at rung n can rely on names ratified at rungs ≤ n, never sideways or upwards. Cycles are prohibited. If a dependency is not yet ratified at the required rung, the new name remains Draft or Pilot.

9.5 Local‑first before reuse. Teams MUST first identify and stabilize the local sense (within their Bounded Context). Within the home, reuse existing Concept‑Set rows where they fit (§4.2 P1). Across contexts, reuse occurs via Alignment Bridges that map the local sense to an existing sense elsewhere—without collapsing the local home.

9.6 Sense, not string. Publication concerns sense (intended meaning in context), not the literal string. Synonyms are allowed as Plain labels or aliases only if they point to the same Row ID and pass the conformance checks in §15 (“CC‑F18”). Strings must not be treated as identity.

9.7 Relation-kind discipline (structural vs epistemic). If the public name surfaces a structural relation, its intended sense MUST be backed by exactly one Constructive trace in the structural calculus (Compose-CAL) and SHALL declare validationMode=axiomatic (see E.14). If the name surfaces an epistemic relation, Constructive backing is optional; declare validationMode ∈ {inferential, postulate} and use Logical/Mapping and/or Empirical Validation as appropriate. Do not mix relation kinds inside a single name. (Do not use “Tier-1/2”; formality is expressed via F per C.2.3.)

9.8 Member vs Component. Names that describe collection membership MUST NOT be used to imply part‑whole structure, and vice versa. If both aspects are needed, publish two names with their own MDS and an explicit bridge.

9.9 Lifecycle states. A name travels through Idea → Draft → Pilot → Ratified → Deprecated. Transitions require explicit human review gates. Ratified names carry a clear stewardship contact and date.

9.10 Anti‑duplication duty. Before ratification, the home MUST perform a near‑neighbor review: identify adjacent names, record the decision to align, merge, or keep separate, and publish the rationale in the name’s record.

9.11 Local clarity over global neatness. When in doubt, prefer local intelligibility for practitioners over global symmetry. Global neatness can be achieved later via bridges; loss of local sense is hard to repair.

9.12 No imported tool terms in Core names. Names and their MDS must not carry terms whose only meaning is tied to operating tools or pipelines. If such terms are unavoidable in pedagogy, confine them to Working-Names and examples with disclaimers.

9.13 Human‑only conformance. Conformance for this protocol is judged by trained human reviewers using the author/reviewer checklists in §14 and the conformance criteria in §15 (“CC‑F18”). Automated heuristics, if any exist in an organization, have no standing in the Core.

F.18:10 - Rationale (why this exists and why these rules)

10.1 Local‑first unlocks velocity without lexical debt. Centralized naming regimes seem tidy but slow learning and create brittle compromises. Local‑first minting lets teams speak clearly now; unification comes from disciplined bridges and one‑way dependencies, not from premature centralization.

10.2 One home lowers ambiguity. Names with “many owners” drift. A single home concentrates accountability for sense, examples, and lifecycle, while still enabling broad reuse via alignment bridges.

10.3 Unified Tech + Plain serve two audiences. Engineers need precise wording; managers and stakeholders need approachable wording. Splitting the surfaces keeps the same sense while protecting accuracy and pedagogy; both are anchored by the Row ID.

10.4 One‑way ladder prevents conceptual knots. Acyclic dependencies cut off circular definitions and policy deadlocks. The ladder provides a simple mental model: build on what is already firm.

10.5 Relation-kind discipline prevents category errors. Part-whole claims (structural) must rest on Constructive grounds (tv:groundedBy → Γₘ.sum|set|slice, validationMode=axiomatic). Experience-based or evaluative relations (epistemic) follow assurance rules (Logical/Mapping, and Empirical Validation when postulate), with an explicit validationMode ∈ {inferential, postulate}. Mixing relation kinds inside a single name confuses review and invites hidden assumptions.

10.6 Sense over string reduces false conflicts. Disputes often orbit the string (“we hate that word”). By separating sense (what we mean) from string (how we say it), the protocol enables peaceful coexistence: keep the Row ID constant; use one Plain label and, where helpful, a budgeted alias per register.

F.18:11 - Application Guidance (how to apply, step by step)

11.1 Prepare (30–60 min).

• Clarify your Bounded Context and audience.
• Collect 2–3 typical user stories that require the name.
• Scan near‑neighbors in adjacent contexts (see §14.2 Reviewer checklist).

11.2 Mint locally.

• Write the MDS in plain language, one paragraph.
• Draft a Didactic Subtitle (≤ 12 words): “what this name buys you.”
• Decide whether the intended relation kind is structural or epistemic (do not mix), and declare validationMode.

11.3 Choose surfaces.

• Unified Tech label: concise, morphology‑stable, neutral; avoid metaphor.
• Plain label: approachable phrasing for non‑specialists.
• How to choose: pick both from a small NQD‑frontier (see §4.2 P1 (candidate set), P2(read-through)): diversify by tradition, novelty/familiarity, and lexical form; record discarded contenders and rationale on the Card.

11.4 Place on the ladder.

• Verify all dependencies are at the same rung or below.
• If a dependency is still Draft/Pilot, keep this name at most Pilot.

11.5 Align, don’t erase.

• Where overlap exists with another context, propose an alignment bridge.
• Keep your home; record the mapping and any known divergence in reading.

11.6 Publish and steward.

• Publish the name with MDS, subtitle, rung, home contact, examples.
• Schedule a first refresh: when should the home examine usage and drift?

11.7 Deprecate gracefully.

• If the sense is superseded, publish Deprecation Notes: what to use instead, and why. Keep old Working-Names visible long enough to allow safe migration.

11.8 The “Friday test.”

• On a busy Friday, could a competent colleague apply the name correctly using only the MDS, subtitle, and two examples? If not, refine before ratification: it too overloaded with meanings to be helpful.

F.18:12 - Examples (worked mini‑cases for engineer‑managers)

These examples are deliberately simple. They show how local‑first minting, one‑way unification, and tier discipline operate together.

12.1 “Module” vs “Component” (engineering structure).

• Home A (Platform) mints Component with MDS: “A physically or logically integrated part whose removal would alter the integrity of the whole.” Structural.
• Home B (App Team) mints Module with MDS: “A deployable bundle of functionality maintained as a unit.” Epistemic (usage practice), not a structural claim.
• Unification: An alignment bridge states: “In Platform, every Component may host one or more Modules; Modules are not Parts.” Dependencies are one‑way: Module depends on Component; Component does not depend on Module. No synonymy asserted. Both names remain in their homes.

12.2 “Incident” vs “Event” (operational sense).

• Home C (Operations) mints Incident with MDS: “An unplanned interruption or reduction in the quality of a service.” Epistemic.
• Home D (Monitoring) mints Event with MDS: “A recorded observation of a state change in a system.” Epistemic.
• Unification: Bridge notes: “Some Events are Incidents when they degrade service; not all Events are Incidents.” Plain labels (and at most one alias per register) may vary (e.g., “Outage” as an alias for Incident), but the Row IDs stay distinct. No part‑whole claims are implied.

12.3 “Customer” vs “Account Holder” (business roles).

• Home E (Sales) mints Customer: “A party that receives value from an offering in exchange for consideration.” Epistemic.
• Home F (Finance) mints Account Holder: “A party legally responsible for an account.” Epistemic.
• Unification: Bridge states overlaps and divergence: “A Customer can be an Account Holder; an Account Holder may not be a Customer (e.g., trustee).” The homes retain stewardship; a shared Working-Name “Client” may be used in executive materials with a clear note: Working-Name only; see Concept-IDs for decisions.

12.4 “Batch” vs “Lot” (collection vs integration).

• Home G (Manufacturing) mints Batch: “A collection of items produced under shared conditions.” Epistemic membership.
• Home H (Quality) mints Lot: “An integrated whole packaged and tracked as one item.” Structural whole.
• Unification: Bridge notes: “A Lot may originate from a single Batch or a slice of a Batch; not every Batch yields a single Lot.” Relation mapping: MemberOf (Batch membership) vs ComponentOf/Whole (Lot integration). Loss note: membership evidence does not imply part‑whole structure; part‑whole structure does not imply shared production conditions.

F.18:13 - Anti‑Patterns & Failure Modes (what to avoid)

13.1 “Global name first.” Trying to coin a single global string before local understanding is mature. Fix: mint locally, publish MDS, then align.

13.2 “Synonym storm.” Collecting many strings without stabilizing the Concept-ID. Fix: one Concept-ID per sense; multiple Working-Names only if they truly help didactics.

13.3 “Process leakage into names.” Burying workflow or tool steps inside the MDS. Fix: keep process in method descriptions; keep names about sense, not procedure.

13.4 “Member‑implies‑part.” Letting collection names induce part‑whole claims. Fix: separate names, separate MDS; don’t smuggle structure into membership.

13.5 “Sideways dependency.” Defining a name by appealing to another Draft at the same rung or higher. Fix: depend only downward or postpone ratification.

13.6 “Alias/Plain drift.” Letting a Plain label or alias accumulate extra meanings absent in the underlying row. Fix: periodic label review; prune metaphors that start bending sense; respect the alias budget.

F.18:14 - Assurance & Conformance (human‑only checks)

F.18:14.1 - Author checklist (before requesting review).

• I identified the home Bounded Context and audience.
• I wrote a clear MDS (≤ 1 paragraph) and a Didactic Subtitle (≤ 12 words).
• I declared the relation kind (structural vs epistemic) and the validationMode; no mixing.
• If structural, I can point to exactly one Constructive trace that backs the structural claim.
• I surveyed near‑neighbors and recorded my decision to align, merge, or keep separate.
• I produced both Unified Tech and Plain labels (per E.10), with the same sense and pointing to the same Row ID.
• Dependencies point only downward; no sideways or upward pulls.
• I scheduled a refresh date and listed 2–3 usage examples.

F.18:14.2 - Reviewer checklist (at the gate).**

• One home is declared; stewardship contact is clear.
• The MDS is free from process jargon and implementation slang.
• The declared relation kind is justified; structural claims are constructively grounded; epistemic claims declare validationMode and evidential posture.
• Member vs Component is respected where relevant.
• Alignment bridges are proposed where overlap exists, with explicit reading of convergence/divergence.
• The ladder discipline holds: acyclic, downward‑only dependencies.
• The Plain label does not smuggle extra commitments; Unified Tech and Plain remain co‑referential and point to the same Row ID.
• Lifecycle state is accurate (Idea/Draft/Pilot/Ratified/Deprecated) and dated.

F.18:14.3 - Lightweight outcomes.**

• Ratify (meets all checks).
• Pilot (publish with explicit questions and a refresh date).
• Revise (return to author with targeted gaps).
• Merge (replace with an alignment to an existing name).
• Deprecate (publish successor guidance and sunset plan).

F.18:15 - Conformance Criteria (normative “CC‑F18”)

These are language‑level obligations for authors and reviewers. They ensure every unified name is local‑first, bridge‑aware, and teachable.

CC‑F18‑1 (Context first). Every unified name SHALL be grounded in local senses that were harvested and clustered inside named Contexts (“context of meaning”) prior to unification. No name may be minted from free‑floating glosses or Cross‑context intuition. Use F.1–F.3 first.

CC‑F18‑2 (Bridge‑only sameness). Claims of sameness across Contexts SHALL be expressed only via explicit Bridges with a stated congruence and loss note. Mere spelling similarity never licenses a unified name. Use F.9.

CC‑F18‑3 (Twin‑register naming). Each unified concept SHALL carry two labels—a Unified Tech label (used in Core prose) and a Plain label (used for teaching). Labels are chosen per the naming discipline of F.5 and the register rules of E.10.

CC‑F18‑4 (Neutrality of the Tech label). The Unified Tech label SHALL NOT be borrowed wholesale from any single source Context where that borrowing would re‑import that Context’s private distinctions. Prefer a neutral term; Cross‑context reuse occurs only via the UTS row and explicit Bridges. (See F.5 “allowed/forbidden forms”.)

CC‑F18‑5 (One concept per row, one Tech label per row). A unified concept SHALL be captured as one Concept‑Set row in the UTS. Exactly one Unified Tech label is normative for that row; additional legacy strings are aliases in Annex (budgeted). Use F.7 with F.17.

CC‑F18‑6 (SenseCell citations). For each unified name, the SenseCells (Context × Local‑Sense) that justify it SHALL be cited in the UTS row with Context name + edition. Omit edition only if the Context has a single stable edition. See F.17 §6.

CC‑F18‑7 (Sheet‑level coverage). Within a thread’s UTS, the set of rows carrying unified names SHALL collectively cite ≥ 3 distinct Contexts, ensuring breadth of evidence. Coverage is a property of the sheet, not of every single row. See F.17 §6 constraint.

CC‑F18‑8 (No global words). In Core text, “Context” always means U.BoundedContext; discipline columns may be used in teaching layouts but is not a bearer of meaning. Do not write context‑free claims of sameness. See E.10 and F.17 §5.

CC‑F18‑9 (Didactic primacy). A unified name SHALL be teachable on one page: its UTS row + a short narrative that a careful reader can replay (F.16 template). If it cannot be taught concisely, the naming attempt is premature.

CC‑F18‑10 (No lifecycle connotations). Names SHALL NOT encode imagined “maturity stages” or time‑ordering unless those are part of the concept’s intension. Stages belong in state‑space and dynamics narratives, not in names. (See A‑series CHR patterns.)

CC‑F18‑11 (Strict distinction guard). Names SHALL respect A.7 Strict Distinction: do not collapse Role ↔ Method ↔ Work or Status ↔ Description into one word. Align with F.11/F.12 where relevant.

CC‑F18‑12 (Change control via F.13). Renames, splits, merges, and retirements SHALL follow F.13’s lexical continuity rules; the UTS remains the canonical public surface for these changes.

CC‑F18‑13 (Lexical Pareto discipline). When a Name Card uses NQD‑CAL (C.18) to score label candidates, the chosen Unified Tech label SHALL lie on the Pareto frontier of the lexical Q‑tuple {SemanticFidelity, CognitiveErgonomics, OperationalAffordance, AliasRisk} (per C.16 ordinal discipline and P1’s NQD‑front definition), unless an explicit exception is recorded. If authors deliberately select a dominated candidate (e.g., to honour legacy regulation or user muscle memory), the Name Card’s notes MUST state the reason for stepping off the frontier.

CC-F18-13 (NQD-front surfaced, with honest diversity).
When a Name Card is in MintNew mode, the candidate label set and the resulting NQD-front of non-dominated label candidates over the lexical Q-tuple {SemanticFidelity, CognitiveErgonomics, OperationalAffordance, AliasRisk} SHALL be explicitly recorded on the Card (at least as a small table or list), together with the NQD evidence hooks (DescriptorMapRef, DistanceDefRef, and a brief Diversity_P / coverage summary).
Each candidate SHALL carry a head-term family tag; morphological or prepositional variants built on the same head (e.g. “X plane”, “plane of X”, “planar X”) MAY NOT be counted as distinct for Diversity_P. The Card SHALL indicate how many distinct head-term families are represented on the NQD-front.
An NQD-front with fewer than three head-term families is permitted only if the Card records why no lexically more diverse alternatives survived the SemanticFidelity / AliasRisk filters (e.g., very narrow domain, frozen legacy idiom).

CC-F18-14 (Selection from the front only).
The Unified Tech and Plain labels published on the UTS row for a unified concept SHALL be drawn from the currently recorded NQD-front on the Name Card. Publishing a Tech/Plain pair that is not on that front (or that is dominated with respect to the declared lexical Q-axes plus NQD) is non-conformant, except in explicit DocumentLegacy mode as defined in §5.1.

CC-F18-15 (Mode declaration).
Every Name Card SHALL declare its CardMode ∈ {MintNew, DocumentLegacy}. For Core-surface naming of U.Types and other canonical FPF concepts, MintNew is the default; DocumentLegacy is permitted only when recording pre-existing external names and MUST (i) cite the legacy source, and (ii) either attach an NQD-front over viable FPF variants or record a short rationale why NQD search is out-of-scope.

F.18:16 - Anti‑patterns & safe rewrites (normative)

Each item names a speaking error and a local‑first repair. Use this as an author’s lint pass before proposing a unified name.

F.18:16.1 - Canonical semantic unpacking for “contract” language (normative; used across FPF)

In FPF, everyday “contract” talk is treated as shorthand for a bundle of distinct roles. When precision matters (architecture, audit, compliance), authors SHALL avoid mapping “contract” to a single concept and instead disambiguate at least:

• Service / promise clause (U.ServiceClause) — the promised external effect + acceptance criteria (a spec/Standard), not a run (U.Work).
• Utterance (U.SpeechAct) — the published statement (a Description) that declares or invokes the service clause.
• Commitment (U.Commitment) — the deontic bond that binds an accountable agent/role to the service clause.
• Work & evidence (U.Work + carriers) — the actual enactment and the traces/metrics used to adjudicate fulfilment.

A “contract” bundle typically spans the whole A.6.B square; route each piece explicitly:

• L-*: definitions/invariants of the signature (“what it means”).
• A-*: admissibility/entry predicates (“when it can be applied”).
• D-*: duties/SLAs/penalties and who is accountable (“who is bound to what”).
• E-*: evidence/observability claims (“how fulfilment/violation is adjudicated”).

Example 2 (§F.18:18.2) shows one naming instantiation of this unpacking.

F.18:17 - Migration notes (renames, splits, merges, retirements)

M1 — Start from Contexts, not from the old global word. When inheriting legacy names, first re‑harvest terms inside the chosen Contexts (F.2–F.3). Only then decide whether to reuse or mint (F.8).

M2 — Preserve reader muscle memory without duplicating meaning. Keep the Plain label close to familiar speech, but make the Tech label precise. If a legacy term is overloaded, publish it as a deprecated alias in Annexes, not as a second Tech label. (F.13; Part H “Deprecated Aliases”.)

M3 — Prefer split‑then‑bridge over vague merges. If one legacy word covers two distinct concepts, split into two rows and add a short relation note between them (e.g., “recipe vs run”). Do not hide the split under a wide new name. (F.7; F.16.)

M4 — Keep identifiers stable; move rows between blocks. When the Block Plan evolves, move rows rather than renumbering; record the move in the row’s Notes field. (F.17 §16.)

M5 — Upgrade rationale quality with worked examples. Every rename or split should be accompanied by a one‑page example that shows the new row in action across at least two Contexts. (F.16; “tell‑show‑show”.)

F.18:18 - Worked examples (compact)

Each example shows how the Protocol steers naming so engineers and managers can communicate without hidden Cross‑context leaks.
Card hygiene shown explicitly: each example states the Kind and the Purpose/use‑domain and chooses Tech/Plain labels from a small NQD‑frontier (seed set diversified by traditions, novelty/familiarity, and lexical form; see Part G (G.18)). Head-term diversity: each example MUST also state the distinct head-term families represented in its NQD candidate set (lexical “roots” such as Recipe, Run, Episode, not prepositional/morphological variants). This prevents faking Diversity_P with near-clones of one head.

F.18:18.1 - Example 1 — MethodDescription vs Work (recipe vs run)

• Context harvest: BPMN 2.0 (2011): “Process model” (recipe) and “Activity instance” (run). PROV‑O (2013): prov:Plan vs prov:Activity. ITIL: “Work instruction” vs “Change implementation record.”
• Kind: U.MethodDescription (design‑time artifact) and U.Work (run‑time occurrence).
• Purpose / use‑domain: planning/scheduling vocabulary across BPMN, PROV‑O, ITIL; separates design recipe from execution episode for governance and telemetry.
• NQD‑front (seed candidates):
  design‑time: Procedure, ProcessModel, MethodSpec, WorkflowDefinition, Recipe, MethodScript
  run‑time: Run, Execution, Enactment, ActivityInstance, Job, Episode
• Head-term families used (design/run):
  design-time heads: {Procedure, ProcessModel, MethodSpec, WorkflowDefinition, Recipe, MethodScript}
  run-time heads: {Run, Execution, Enactment, ActivityInstance, Job, Episode}
• Chosen from frontier (Unified Tech / Plain):
  U.MethodDescription / “recipe”; U.Work / “run”.
  Discarded highlights: Procedure (collides with governance “procedure/policy”); Execution (overloaded in CS/security);
• Anti-pattern (for illustration only, non-conformant).

Bad CandidateSet (lexically narrow): {“Reference plane”, “Plane of reference”, “Planar reference”, “Ref. plane v2”}.
All four are one head-term family (plane). Even if Diversity_P over raw strings looks high (four labels), head-term diversity is 1, so this set fails the F.18 diversity intent. A conformant Card would either: (a) add labels with other heads (e.g., Layer, Track, Band), or (b) explicitly record why other heads are rejected (AliasRisk, domain idiom) and accept low lexical Diversity_P with a rationale.

• Enactment (speech‑act nuance).
• Bridges: recipe↔run related, not identical; loss note “control‑flow vs. execution.”
• Why it matters: Managers can schedule Work while authors improve the MethodDescription—no category errors. The NQD‑front preserves tradition‑diverse, lexically stable options until a reasoned choice is made. (F.11/F.16; F.17 rows.)

F.18:18.2 - Example 2 — Service (promise) vs SpeechAct (utterance) vs Commitment (deontic)

• Context harvest: IT service canon: “SLA/OLA clause”, “ticket approved”. Speech‑act theory: “performative utterance”. Org governance: “approval signature”.

• Kind: U.ServiceClause (promise), U.SpeechAct (utterance), U.Commitment (deontic bond).

• Purpose / use‑domain: ops/governance vocabulary connecting ITSM, organizational policy, and pragmatics; separates saying, binding, and promising.

• NQD‑front (seed candidates):
  promise: Service, Offering, Provision, CapabilityOffer
  utterance: SpeechAct, Performative, Utterance, Declaration
  deontic bond: Commitment, Obligation, Binding, Duty

• Chosen from frontier (Unified Tech / Plain):
  U.ServiceClause / “service (promise)”; U.SpeechAct / “utterance”; U.Commitment / “commitment”.
  Discarded highlights: Offering (business‑model connotations); Declaration (too narrow for performatives); Obligation (legalese; narrower than commitment envelope).

• Ontology note (informative): U.SpeechAct and U.Commitment are defined normatively in Part A (A.2.9 and A.2.8 respectively). This F.18 card is a lexical/NQD anchor, not the ontology definition site.

• Bridges: utterance institutes commitment; commitment binds service clause; no synonymy claimed.

• Why it matters: Status tracking becomes intelligible without pretending that a “service” acts; the NQD‑front yields neutral, cross‑tradition readable labels. (F.12; F.17 blocks D/R.)

F.18:18.3 - Example 3 — Characteristic names without lifecycle bias

• Context harvest: Quality canon: “maturity level”; Performance canon: “throughput”. Kind: U.Characteristic (measurement names).
• Purpose / use‑domain: CHR‑compatible measurements for planning and performance; bridgeable across engineering and management.
• NQD‑front (seed candidates):
  readiness (ordinal): MaturityLevel, ReadinessLevel, PhaseReadiness, TRL, ReadinessScore
  throughput (ratio): Throughput, Rate, ProcessingRate, OpsPerSecond, FlowRate
• Chosen from frontier (Unified Tech / Plain):
  U.ReadinessLevel / “readiness level” (ordinal); U.Throughput / “throughput” (ratio).
  Discarded highlights: TRL (tied to a specific scale/tradition); Rate/OpsPerSecond (over‑specific units baked in).
• Narrative: Dynamics are shown as movement in state‑space, not via lifecycle‑laden names such as “pre‑production process”.
• Why it matters: Prevents lifecycle/time from leaking into labels; the NQD‑front ensures neutrality and recognizability. (A‑series CHR rationale; F.17 §4–§6.)

F.18:19 - FAQ (authoring hygiene)

Q1. How many Contexts must a naming proposal cite? A. The sheet for a thread should cite ≥ 3 distinct Contexts overall; an individual row may cite fewer if the concept appears in fewer Contexts. The point is breadth at the UTS level, not token‑stuffing rows. (F.17 §6 constraint.)

Q2. Can a Source Context’s term ever become the Tech label? A. Only if its form is already neutral and does not smuggle in that Context’s private commitments. When in doubt, pick a fresh neutral Tech label and keep the Source term in SenseCells. (F.5.)

Q3. Where do we put discipline‑vantage views like “Operations” vs “Research”? A. Use the discipline columns in a teaching layout if helpful, but remember: discipline columns are not Context columns and carry no editions. (F.17 §5.)

Q4. How do we keep names stable while the story evolves? A. Keep row ids stable; evolve placement via the Block Plan and record moves in Notes. Use F.13 for renames/splits/merges. (F.17 §16; F.13.)

Q5. What if two teams insist on different Tech labels for the same concept? A. Publish one Tech label; treat the other as a deprecated alias (Annex). Bridge their local senses on the row. (F.13; Part H.)

F.18:20 - 90‑second teaching script (for engineer‑managers)

“Local‑first means we start in context of meaning—we harvest terms inside each Context and only then unify. A unified name is a teachable promise: one Tech label for precision, one Plain label for outreach. Its row in the UTS shows where the idea lives in real disciplines (the SenseCells) and how those Contexts connect (explicit Bridges with a brief loss note). We never equate terms by spelling; we argue sameness with a bridge. We also never bake stages or actors into names—those belong to dynamics and roles, not labels. When the story changes, we evolve names with lexical continuity rather than re‑inventing words. The result is a vocabulary managers and engineers can hold on one page and use the same way across projects.”

F.18:21 - Acceptance Harness (SCR/RSCR) for F.18

Purpose. Provide auditable, notation‑independent checks that a proposed unified name (and its publication on a UTS line) satisfies the local‑first unification discipline. The harness extends the general unification checks in F.15 with naming‑specific obligations.

F.18:21.1 - Static Conformance Rules (SCR‑UNIFY)

F.18:21.2 - Regression Rules (RSCR‑UNIFY)

F.18:21 - Migration & Deprecation Notes (informative, naming‑specific)

1. Start from rows, not strings. When consolidating legacy labels, build or revisit the Concept‑Set row first; only then pick the Unified Tech/Plain names. This keeps meaning primary. (F.7, F.17)
2. Prefer alias over merge. If the sense is stable but the label misleads, rename and retain one alias; if the sense changed, mint a new row (no retrofits). (F.13)
3. Resist modifier types. New adjectives (e.g., Peak, Remote, Night) usually belong to windows or examples, not to the unified name. (F.10/F.12/F.14)
4. Keep neutrality visible. If stakeholders push a brand‑coloured label, document why the chosen Unified Tech is neutral and include the brand as an alias in Glossary/Annex. (F.5, F.17)
5. Don’t globalise a Context. Never move a Context label into the unified name as if it were universal. Use Bridges to relate Contexts, with an explicit loss note. (F.0.1, F.9)

F.18:22 - FAQ (authoring hygiene for engineer‑managers)

Q1. Can we reuse a dominant industry term as the Unified Tech name? A. Only if the row’s Concept‑Set shows exact identity across Contexts; otherwise pick a neutral Unified Tech and list the industry label as an alias in the Glossary. (F.5, F.17)

Q2. Two terms look identical across Contexts—may we skip Bridges? A. No. Sameness is argued, not spelled. Publish a Bridge with relation kind and CL plus a short loss/fit note. (F.9, F.0.1)

Q3. When do we mint a new U.Type vs. add a new row vs. add an alias? A. Use F.8 Mint‑or‑Reuse: if the intension changes, new U.Type; if the same thing spans new Context, new row; if only the label misleads, alias/rename.

Q4. Our team keeps proposing “qualified roles” (e.g., Night‑Operator). What do we do? A. Keep the Role unified and express qualifiers as windows on Statuses or as example context. This follows F.14 and F.12.

Q5. Can we compress two near‑equivalent rows into one to “simplify the sheet”? A. Only if the one‑breath rationale remains true after review and the Bridges support equivalence with the same or stronger CL; otherwise keep two rows with explicit differences. (F.17, F.9)

F.18:23 - Didactic distillation (90‑second script)

“Name on a row, never on a whim.” In FPF we speak on rows, not on vibes: a Name Card ties each Tech/Plain pair to a concrete Context, Concept‑Set row, and SenseCells, with a small NQD‑front of rejected alternatives. This gives you bridged precision without losing local comfort. Your UTS is the one page a careful mind can hold.

F.18:24 - SoTA‑Echoing (post‑2015 practice alignment)

• Neural WSD & sense evaluation (2015→). P2’s sense‑seed read‑through is a human‑scale analogue of modern word‑sense disambiguation evaluation, where models are scored by the fraction of examples assigned the correct sense and by error profiles across sense inventories. Post‑2015 neural WSD benchmarks (e.g., multi‑domain evaluations reported in ACL venues) motivate the explicit {too‑narrow, on‑target, too‑wide, wrong‑prototype} labelling and the θ_P threshold for SemanticFidelity.
• Quality‑Diversity & multi‑objective search (MAP‑Elites, NSGA‑II families, 2015→). P1’s NQD‑front and CC‑F18‑13 follow the same discipline as QD/NSGA‑style archives in optimisation: maintain a set of non‑dominated candidates over a vector of objectives rather than a single scalar score. The lexical Q‑tuple {SemanticFidelity, CognitiveErgonomics, OperationalAffordance, AliasRisk} is deliberately small so that human authors can inspect a Pareto frontier in the same way QD methods expose illumination archives.
• Design‑space exploration & idea ranking (mechanical/industrial design, 2018→). The PSOA‑style Name‑Card tables echo contemporary design‑space ranking practice, where candidate concepts are compared on diversity and quality rather than on a single “score”. Explicitly surfacing why one candidate dominates another improves auditability and supports teaching, mirroring recent work on ranking ideas for both diversity and quality in engineering design.
• Semantic transparency & morphology in interfaces and code (HCI and PL practice, 2015→). The strengthened OperationalAffordance guidance aligns with empirical results on semantic transparency of labels and identifier names: morphology that cues “actor vs activity vs artifact” improves comprehension and reduces error rates in both UIs and source code. F.18 turns these findings into a simple naming discipline (agentive forms for Roles, verbal forms for Methods, result nouns for Work/Artifacts) that can be enforced on Name Cards.

F.18:25 - Relations

Builds on: F.0.1 Contextual Lexicon Principles (local meaning; bridge‑only Cross‑context claims). F.1–F.3 Contexts → term harvesting → local sense clustering. F.5 Naming discipline. F.7 Concept‑Set construction. F.8 Mint‑or‑Reuse decision lattice. F.13 Lexical continuity (renames/aliases/splits/merges). F.14 Anti‑explosion controls (bundles, SoD, windows). F.15 SCR/RSCR harness. F.17 UTS as the publication surface.

Constrains: All patterns that propose or consume unified names and rows in Part F; any Part A/C pattern that cites U.Types on UTS rows inherits these naming duties (through the UTS linkage), while keeping structural/epistemic/temporal aspects distinct per Part E authoring rules.

Coordinates with. A.17/A.18 for measurement lexicon when rows concern measurable notions (Characteristic/Scale/Level/Coordinate vocabulary), ensuring neutral naming aligns with canonical terms and eases external alignment via Bridges.

F.18:End