fpf-local-first-unification-naming-protocol

name: fpf-local-first-unification-naming-protocol description: FPF Pattern F.18: Local‑First Unification Naming Protocol license: Apache-2.0 metadata: fpf_id: F.18 fpf_title: "Local‑First Unification Naming Protocol" allowed-tools: []

F.18 - Local‑First Unification Naming Protocol

Status: normative (Part F, Unification Suite). Audience: engineer‑managers, lead architects, editors of FPF artefacts.

F.18:1 - Context

Names must carry enough signal for everyday use, yet never smuggle in Cross‑context identities, hidden assumptions, or role/metric clutter. F.18 supplies that naming discipline and weaves it through F.1–F.17: Term Harvesting, Sense Clustering, Role Descriptions, Concept‑Sets, Bridges, Lexical Continuity, Anti‑Explosion control, and the Unified Term Sheet (UTS).

Scope. This protocol applies to naming of any concepts authored in Part F (U.Types and local concepts alike: kinds, roles, services, methods, works, relations, characteristics, states/statuses, etc.). The U.Types norms in this section are a specialization, not a restriction of scope.

Purpose of this pattern. Provide a human‑legible, context‑anchored naming protocol that:

• keeps local meaning first and prevents Cross‑context conflation;
• makes the kind of thing explicit (System, Episteme, Role, Service, Method, Work, Decision, Requirement, etc.);
• integrates smoothly with Concept-Sets, U.RoleDescription, and Bridges without requiring any special notation or tooling;
• supports lifecycle actions (mint, reuse, align, deprecate, split/merge) with a paper trail that managers can audit.

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 **edi