#Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

Preface node heading:part-f-the-unification-suite-u-suite-concept-sets-sensecells-contextual-role-assignment:89212

#What this page is

This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

#Methodology

Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

#Content

#Contextual Lexicon Principles

One‑sentence summary. All meanings in FPF are local to a U.BoundedContext (“Context of meaning”); terms are spoken with their Context, and any relation across Contexts exists only as an explicit Alignment Bridge with stated loss/fit.

Status. Architectural pattern. Builds on: A.1.1 U.BoundedContext (formal frame); A.7 Strict Distinction (C‑6); A.8 Universal Core (C‑1); A.11 Ontological Parsimony (C‑5); A.4 Temporal Duality (C‑7); E.10.D1 D.CTX (lexical discipline for “Context”). Coordinates with. F.1 (Context Map via Context Cards), F.2 (local term capture), F.3 (intra‑Context clustering), F.7 (Concept‑Set Table), F.9 (Alignment & Bridge), B.3 (Trust & Assurance; CL penalties).

Didactic note. In the Tech register, Context ≡ U.BoundedContext (per E.10.D1). We use “Context of meaning” as a metaphor only; Context remains the normative short form for U.BoundedContext. The word anchor is not used in FPF. The word plane is reserved to CHR:ReferencePlane only.

Terminology guard (normative, Part F). The row classifier is senseFamily: {Role | Status | Measurement | Type‑structure | Method | Execution}. Characteristic (MM‑CHR) names measurable aspects only (A.17–A.19) and MUST NOT be used for row typing in Part F. Avoid the generic word facet in Part F; when unavoidable, reference C.3.5 KindAT (informative facet) or Compose‑CAL U.Facet explicitly. Only CHR:ReferencePlane is permitted (no bare “plane”); use EntityOfConcern / Description episteme / specification-use boundary for entity-description-specification-use discipline; use stance for design vs run.

#Problem Frame

Trans‑disciplinary modelling fails without an explicit discipline for where words mean what.

• Semantic drift. The same string (“process”, “role”, “service”) slides between domains and editions.
• Homonym collisions. One label carries incompatible senses across fields.
• Hidden synonymy. Different labels point to the same local sense, but the identity is unstated.
• Implicit globalism. Meaning is treated as universal; integration silently re‑writes models.

FPF resolves this by localising meaning first, then explicitly translating across locales.

#The Three Principles (normative)

#P‑S - Source Localisation Principle — Speak with the Context.

Rule. Every term in a normative FPF publication unit MUST be bound to a specific U.BoundedContext (its “Context of meaning”). The binding is explicit in text, notation, or table headers (e.g., process (BPMN 2.0)).

Implications.

• No free‑floating “global terms”.
• A finite Context Map (see F.1) is chosen before naming work starts.
• If a source intrinsically fixes time stance, the DesignRunTag is carried by the Context (C‑7).

Reasoning move (conceptual). Context(C) ∧ says(C, term t) ⊢ usable(t@C)

Illustration (Enactment line). activity @ PROV‑O (run) vs task @ IEC 61131‑3 (run) vs process @ BPMN 2.0 (design).

#P‑L - Local Meaning Principle — Meaning lives inside the Context.

Rule. The intended sense of a term is established inside its Context as a SenseCell: a small, reconstructible unit of local meaning with Tech/Plain labels and a concise gloss. SenseCells are lexical only (C‑6): no behaviours, no deontics, no equations.

Implications.

• SenseCells are Context‑scoped; they do not cross Contexts.
• Minimal generality (G‑1) and contextual specification (G‑2) govern naming inside the Context.
• Intra‑Context clustering of raw mentions precedes any Cross‑context act (see F.3).

Reasoning move (conceptual). usable(t@C) ∧ fits(gloss, C) ⊢ SenseCell⟨t@C⟩

Illustration (KD‑CAL). observation @ SOSA/SSN: Tech “observation”, Plain “measurement act”; gloss “Result‑bearing act applying a Procedure…”.

#P‑B - Explicit Bridge Principle — across Contexts, only with a bridge.

Rule. Any relation between terms from different Contexts MUST be stated as an Alignment Bridge (see F.9): a named mapping between SenseCell⟨-⟩ items with a declared relation kind (e.g., overlaps, broader‑than, near‑equivalent) and a Congruence Level (CL) for trust calculus (B.3).

Implications.

• No by‑name identity across Contexts; string equality ≠ sense equality.
• Bridges carry loss/fit notes and are auditable; they can be revised by edition.
• Concept‑Sets (F.7) are built from bridged cells, not from lexical strings.
• When the prose wording uses umbrella sameness/alignment tokens (“same/equivalent/align/map/…”), treat it as an RPR trigger and repair it via A.6.9 (RPR‑XCTX) before granting any naming or substitution licence.

Reasoning move (conceptual). SenseCell⟨x@A⟩ ↔⟨rel, CL⟩ SenseCell⟨y@B⟩ ⊢ translatable(x@A, y@B, rel, CL)

Illustration (Sys‑CAL × Enactment). actuation @ CTRL‑Text ↔⟨near‑equiv, CL=2⟩ control‑output @ IEC 61131‑3.

#Minimal Conceptual Objects (conceptual, notationally neutral)

These conceptual objects are thought‑objects; they specify what must exist conceptually, not how it is stored.

#Context Card (for each U.BoundedContext)

A terse descriptor used in the Context Map (F.1):

• id (stable local handle) - title - edition/year
• family (discipline family; informal) - scope gist
• timeStance? (design / run, if inherent)
• trip‑wires (few lexical caveats that often mislead, e.g., “process≠thermo process”)

#SenseCell (unit of local meaning, inside one context)

• label.tech / label.plain (two registers)
• gloss (minimal generality, Context‑true)
• notes? (warnings, edition shifts)
• No behaviour/deontics/equations (C‑6)

Where it comes from. F.2 describes how SenseCells can be derived from local term evidence; F.0.1 only requires that local meaning be expressible as a SenseCell.

#Alignment Bridge (between SenseCells from different Contexts)

• left: SenseCell⟨-@A⟩, right: SenseCell⟨-@B⟩
• relation (e.g., equivalent‑under‑assumptions, overlaps, broader‑than)
• CL (Congruence Level; feeds B.3 Trust & Assurance)
• loss/fit (explicit statement of what is lost or assumed)

#Invariants (normative)

1. I‑1 - Context‑qualified usage. Every normative use of a term is Context‑qualified (directly or via table/section headers).
2. I‑2 - Local‑only cells. A SenseCell belongs to exactly one Context.
3. I‑3 - senseFamily hygiene. SenseCells are lexical; behaviour, deontics, measurements, proof steps live in their respective patterns (C‑6).
4. I‑4 - Time stance fidelity. If a source fixes a DesignRunTag, the Context Card carries it and SenseCells inherit it.
5. I‑5 - No implicit Cross‑context identity. Cross‑context relations exist only as F.9 Bridges with relation and CL.
6. I‑6 - Parsimony & heterogeneity hook. The Context Map is finite, heterogeneous (≥ 3 families per unification line), and parsimonious (F.1).

#Reasoning Primitives (judgement schemata; pure, side‑effect‑free)

These capture allowable mental moves; they do not prescribe storage, APIs, or workflow.

• Context qualification Context(C) ∧ mentions(C, s) ⊢ uses(s@C) Reading: If a string s is used under Context C, we treat it as the local term s@C.

• Local sense formation uses(t@C) ∧ gloss_C(t) ⊢ SenseCell⟨t@C⟩ Reading: A Context‑true gloss yields a SenseCell for t inside C.

• Admissible Cross‑context relation SenseCell⟨x@A⟩ ∧ SenseCell⟨y@B⟩ ∧ declare(rel, CL) ⊢ Bridge(x@A, y@B, rel, CL) Reading: Only an explicit declaration generates a Bridge; no name‑matching inferences.

• Bridge‑to‑Concept‑Set hint (for F.7) Bridge(x@A, y@B, rel≈equiv, CL≥k) ⊢ candidate_same_row(x, y) Reading: High-CL, near‑equivalence bridges can nominate cells for one Concept‑Set row (final decision in F.7).

#Didactic Metaphor (informative)

• Contexts. Each U.BoundedContext is a Context; its Context Card is a published boundary marker (name, edition, time stance, trip‑wires).
• Words in a Context. A SenseCell is a dictionary entry pinned to that Context’s wall.
• Door‑to‑door links. An Alignment Bridge is a labelled passage connecting two Contexts; a CL placard says how trustworthy that passage is.

We first speak inside Contexts; only then decide which doors to connect—and with what warnings.

#Placement & Flow

F.0.1 is the front door of Part F. It enables: F.1 (choosing Contexts with Context Cards) → F.2 (deriving SenseCells inside each Context) → F.3 (stabilising local senses) → F.7 (building Concept‑Set rows) → F.9 (stating Bridges).

#Anti‑patterns & remedies

#Compact worked examples

Each vignette shows (1) two Context Cards (abridged), (2) SenseCells inside Contexts, (3) the Bridge with relation & CL, and (4) a Concept‑Set hint (if any).

#F.0.1:9.1 Enactment × Provenance — process vs activity

• Context A: BPMN_2_0 - Business Process Model and Notation v2.0 (2011) - design SenseCell⟨process@BPMN⟩: Tech “process”; Plain “workflow process”; Gloss “graph of flow nodes/events executed by participants.”

• Context B: PROV_O_2013 - W3C PROV‑O (2013) - run SenseCell⟨activity@PROV⟩: Tech “activity”; Plain “provenance activity”; Gloss “time‑bounded occurrence using/generating entities.”

• Bridge: ⟨process@BPMN⟩ ↔⟨design‑spec‑of, CL=2, loss: “no concurrency semantics in trace”; fit: “maps to execution plan”⟩ ⟨activity@PROV⟩

• Concept‑Set hint: No same‑row nomination (relation ≠ near‑equiv); instead, record a design↔run linkage.

#Control × PLC runtime — actuation vs control output

• Context A: CTRL_Text_Classic - control theory primers - design SenseCell⟨actuation@CTRL⟩: Tech “actuation”; Plain “control output”; Gloss “signal applied to plant actuators.”

• Context B: IEC_61131_3 - PLC languages - run SenseCell⟨q‑output@IEC⟩: Tech “control‑output”; Plain “PLC output”; Gloss “program‑produced output variable to field I/O.”

• Bridge: ⟨actuation@CTRL⟩ ↔⟨near‑equivalent, CL=2, loss: “hardware/scan‑cycle specifics absent in CTRL”; fit: “semantics align under linear regime”⟩ ⟨q‑output@IEC⟩

• Concept‑Set hint: Candidate same‑row (F.7) with note: “merge permitted at CL≥2 threshold.”

#F.0.1:9.3 Measurement × Service — observation vs service metric

• Context A: SOSA_SSN_2017 - sensing/observations - run SenseCell⟨observation@SOSA⟩: Tech “observation”; Plain “measurement act”.

• Context B: ITIL4_2020 - services - (mixed) SenseCell⟨slo‑metric@ITIL⟩: Tech “service‑level metric”; Plain “service measure”; Gloss “quantity used to evaluate SLOs.”

• Bridge: ⟨observation@SOSA⟩ ↔⟨provides‑value‑for, CL=2, loss: “organizational context not in SOSA”; fit: “metric results are measurement results.”⟩ ⟨slo‑metric@ITIL⟩

• Concept‑Set hint: Not a same‑row case; this is a role‑in‑use relation (measurement feeds status evaluation).

#F.0.1:9.4 Type reasoning — subclass‑of (OWL) vs is‑a (plain)

• Context A: OWL2_Profiles - description logics SenseCell⟨subclass@OWL⟩: Tech “subclass‑of”; Plain “is‑a”.

• Context B: ENG_Glossary - engineering plain usage compendium SenseCell⟨is‑a@ENG⟩: Tech “is‑a (engineering)”; Plain “kind‑of”; Gloss “informal subsumption in specs.”

• Bridge: ⟨subclass@OWL⟩ ↔⟨near‑equivalent, CL=1, loss: “OWL formal constraints absent in ENG”; fit: “intended subsumption semantics.”⟩ ⟨is‑a@ENG⟩

• Concept‑Set hint: Keep separate rows unless the consuming artefact demands formal semantics.

#F.0.1:9.5 Deontics × Access — permission vs role (RBAC)

• Context A: ODRL_2_2 - policy/deontics SenseCell⟨permission@ODRL⟩: Tech “permission”; Plain “allowed action”.

• Context B: NIST_RBAC_2004 - access control SenseCell⟨role@RBAC⟩: Tech “access‑role”; Plain “permission set”.

• Bridge: ⟨permission@ODRL⟩ ↔⟨member‑of‑set‑in, CL=2, loss: “contextual obligations not preserved”; fit: “RBAC roles aggregate permissions.”⟩ ⟨role@RBAC⟩

• Concept‑Set hint: Not same row (different kinds); useful linkage for Enactment when binding duties to sessions.

#Extended reasoning moves (pure judgement schemata)

Judgements are conceptual entailments over Contexts, SenseCells, and Bridges. They carry no storage, workflow, or governance semantics.

#Context‑qualified use

Context(C) ∧ mentions(C, s) ⊢ uses(s@C) If s is used under Context C, we treat it as the local term s@C.

#Sense formation (local)

uses(t@C) ∧ gloss_C(t) ⊢ SenseCell⟨t@C⟩ A Context‑true gloss yields a SenseCell inside C.

#Admissible Bridge (creation predicate)

SenseCell⟨x@A⟩ ∧ SenseCell⟨y@B⟩ ∧ A≠B ∧ rel∈R ∧ cl∈{0,1,2} ⊢ Bridge(x@A,y@B,rel,cl) Only explicit relation rel with Congruence Level cl constitutes a Bridge.

Canonical relation set R (didactic catalogue): equivalent‑under‑assumptions - near‑equivalent - overlaps - broader‑than - narrower‑than - design‑spec‑of - run‑trace‑of - representation‑of - member‑of‑set‑in - provides‑value‑for.

#Bridge composition (minimum CL and relation loss)

Bridge(a,b,rel₁,cl₁) ∧ Bridge(b,c,rel₂,cl₂) ⊢ Bridge*(a,c,rel*,cl*)

• cl* := min(cl₁, cl₂) (do not inflate confidence)
• rel* := conservativeRel(rel₁, rel₂) (e.g., near‑equiv composed with overlaps yields overlaps)

Reading: Chained passages inherit the minimum CL and the relation that remains admissible after composition.

#Non‑identity by stance

SenseCell⟨x@A(design)⟩ ∧ SenseCell⟨y@B(run)⟩ ∧ ¬declared(Bridge(x,y,near‑equiv,_)) ⊢ ¬same‑row(x,y) Different time stances forbid same‑row unless an explicit near‑equiv Bridge exists.

#Row viability (Concept‑Set candidacy)

Cells = {c₁…cₙ} ⊢ row‑viable(Cells) ⇔ connected(Cells, Bridges_{rel∈{equiv,near‑equiv}, cl≥k}) ∧ ¬contradiction(Cells)

Reading: A row is viable if its cells form a connected subgraph via Bridges with sufficient CL and contain no mutually exclusive links.

#Contradiction sieve

Bridge(a,b,broader) ∧ Bridge(a,b,narrower) ⊢ contradiction(a,b) Incompatible relations across the same pair flag a contradiction for review (conceptually).

#Non‑bridge implication ban

name(x) = name(y) ∧ A≠B ⊢ ¬Bridge(x@A, y@B, _, _) String equality across Contexts never implies a Bridge.

#SCR/RSCR acceptance checks (conceptual)

These checks are content‑oriented; they validate that a manuscript/model respects Part F principles. No process/tool assumptions are implied.

#SCR — Static conformance

• SCR‑F01 (Context‑qualified). Every normative term is Context‑qualified (directly, or via a scoped header that unambiguously fixes the Context).
• SCR‑F02 (Local cells). Each SenseCell belongs to exactly one Context; no cell aggregates Cross‑context senses.
• SCR‑F03 (senseFamily hygiene). SenseCell glosses contain no behaviours/deontics/equations; those appear only in their patterns.
• SCR‑F04 (Bridges explicit). Every Cross‑context relation appears as a Bridge with relation and CL and a short loss/fit note.
• SCR‑F05 (No string identity). There is no use of string equality to stand in for Cross‑context identity.
• SCR‑F06 (Time stance fidelity). Where a Context fixes a DesignRunTag, the SenseCells and any Bridges reflect that stance explicitly.
• SCR‑F07 (Row viability). Any Concept‑Set row shown is supported by a connected subgraph of Bridges with CL ≥ threshold and no contradictions.

#RSCR — Regression & evolution

• RSCR‑F01 (Edition split). When a source edition changes materially, SenseCells tied to the old edition remain; new cells bind to the new Context; Bridges are re‑assessed.
• RSCR‑F02 (Bridge stability). If any Bridge endpoint changes gloss/stance, downgrade or retire the Bridge, documenting the loss/fit change.
• RSCR‑F03 (Composition guard). When composing Bridges in a chain, the resulting CL never exceeds the minimal link; relation CL drops monotonically.
• RSCR‑F04 (Heterogeneity + QD guard): requires ≥3 domain‑families AND MinInterFamilyDistance ≥ δ_family (per the active F1‑Card edition), with QD‑triad evidence (publish Diversity_P and IlluminationSummary on the declared grid/kernel). Near‑alias pairs (per dSig rule) SHALL be flagged and excluded or merged before the guard is evaluated. Record the F1‑Card edition id.

#Publish‑ready summary

An artefact is ready with respect to F.0.1 when:

1. SCR‑F01…F07 hold for all terms, cells, rows, and bridges it presents;
2. RSCR‑F01…F04 hold under simulated edition/stance changes;
3. Every Cross-context statement can be read as a Bridge or as a composition of Bridges with stated CL and relation loss.

#Quick reference (didactic)

• Context = a U.BoundedContext with edition, scope, and (if inherent) time stance.
• SenseCell = the minimal, lexical unit of meaning inside a Context (Tech/Plain labels + gloss).
• Bridge = the only Cross‑context relation, labelled with relation and CL, plus a short loss/fit note.
• Concept‑Set row = a didactic table row collecting SenseCells that are sufficiently the‑same‑thing under declared Bridges.

Mental checklist: Name the Context → speak in the Context → connect Contexts only by labelled bridges → build rows from bridged cells.

#F.0.1:End

#Domain‑Family Landscape Survey

“Fix the context of meaning before you name anything.” Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); F.0.1 Contextual Lexicon Principles; A.7 Strict Distinction (Clarity Lattice); A.11 Ontological Parsimony. Coordinates with. F.2 Term Harvesting & Normalisation; F.3 Intra‑Context Sense Clustering; F.4 Role Description; F.9 Alignment & Bridge Across Contexts; G.0–G.1 (Scope/entityOfConcern handoff). (Bridges live only in F.9.)

Aliases (informative). Contexts‑first survey; Context cut.

#Intent & applicability

Intent. Establish a finite set of U.BoundedContext (“context of meaning”), each tied to an authoritative source or canon within a domain family, so that all later moves (term harvesting, clustering, role naming, cross‑context bridges) operate on local meanings rather than on drifting, globalised words.

Applicability. Use at the start of any unification effort for any FPF pattern (role assignment and performed-work attribution, Sys-CAL, KD-CAL, Kind-CAL, LCA-CAL…) and whenever a discipline canon materially changes (new edition, re-framing, seminal result).

Non‑goals. No tooling, workflow, or editorial roles. No global ontology. No cross‑context equations. This pattern describes how to think, not how to store.

#Problem frame

Without explicit context of meaning:

1. Word‑drift. Common words (process, role, service, model) silently change sense across disciplines.
2. Scope mirages. One influential standard is mistaken for the domain.
3. Retro‑lock. Old editions become the implicit truth simply because they were “there first”.
4. Category bleed. Behavioural roles, epistemic statuses, deontic permissions mix because their contexts were never fixed.
5. Name inflation. Convenience root kind labels or global names appear just to "stabilise" unstable words.

#Forces

#Core idea (didactic)

Think in Contexts, not in words. A Context of meaning is a U.BoundedContext (per D.CTX) that encloses a coherent vocabulary and its rules from a specific, citable canon (standard, BoK, seminal paper, textbook tradition). You name and reason inside the Context. When you must step between Contexts, you will declare a bridge later (F.9) with explicit losses or mismatches.

#Minimal vocabulary (this pattern only)

• U.BoundedContext (short: Context in Tech register). The formal Context of meaning.
• Context (Tech register alias for U.BoundedContext). Use Context for pedagogy, U.BoundedContext for formal references.
• Domain family. An informative shelf‑label grouping related Contexts (e.g., workflow & provenance; services & deontics; sensing & measurement; types & taxonomies; control & actuation). No semantics attach; Domain ≠ Context.
• Context Card. A one‑screen conceptual sketch of a Context (see §7.2).
• SenseCell (appears downstream). A (Context × Local‑Sense) address; F.3 will mint these after clustering. Mentioned here only to keep the destination in view.

#Solution — the Contexts‑first survey (conceptual, notation‑free)

Step 1 — Declare your unification line(s). State which FPF pattern threads are in play (e.g., Enactment + KD‑CAL sensing + Sys‑CAL execution). This keeps the cut purposeful.

Step 2 — Cut the landscape by domain families. For each line, select at least three distinct domain families (heterogeneity guard). Examples:

• Workflow & provenance (BPMN 2.0; W3C PROV‑O)
• Services & deontics (ITIL 4; ODRL 2.2)
• Sensing & measurement (SOSA/SSN; ISO 80000‑1)
• Types & taxonomies (OWL 2; FCA corpus)
• Control & actuation (state‑space control texts; IEC 61131‑3)

Step 3 — For each family, sketch 1–3 Context Cards. Prefer canonical, widely cited canons. If a field is fragmented, choose one exemplar and one counter‑voice to surface heterogeneity.

Step 4 — Make locality explicit. Treat words as context‑local. Process (BPMN) ≠ process (thermodynamics) ≠ process (PROV). Do not reconcile. Do not average. Just fix the Contexts.

Step 5 — Bound the set. Small enough to hold in working memory. As a rule of thumb:

• per unification line: ≥ 3 families;
• per family: 1–3 Contexts. More only if a missing Context hides a known sense‑split you will certainly need.

Step 6 — Postpone bridges. If two Contexts seem “close”, resist collapsing. Note the tension and leave any bridge claim to F.9 Alignment & Bridge.

#What to record (conceptual, not clerical)

7.1 The two‑minute memory. Everything you need to think correctly later fits on an eight‑line card. No registries, no workflows, no storage choices.

7.2 The Context Card (one‑screen sketch). (Each bullet is a thought, not a field.)

• Name & edition. “BPMN 2.0 (2011)” • “W3C PROV‑O (2013)” • “ITIL 4 (2020)”.
• Domain family. workflow / provenance / services / deontics / sensing / types / control … (informative only; never used to infer meaning).
• Scope gist (didactic; ≠ USM.ScopeSlice(G)). One line that marks the inside/outside (“workflow graphs & participants”, “provenance entities/activities/agents”).
• Time stance (if inherent). Does the canon speak design (specifications, models) or run (occurrences, acts)?
• Lexical trip‑wires. Known homonyms or false friends in this Context (“process ≠ thermodynamic process”, “role (RBAC) ≠ behavioural role”).
• Neighbour Contexts (informative). Close cousins that people often conflate (BPMN ↔ PROV‑O, ITIL ↔ ODRL).
• Recency note. Current / superseded / candidate (only as a reminder to yourself which text you mean).
• Why this Context matters here. One sentence linking to your unification line (“we will name Executions later; PROV‑O keeps them run‑time”).
• Diversity signature (dSig). A 5-characteristics discrete signature for U.BoundedContext: [Sector, Function, Archetype, Regime, MetricFamily]. Authors SHOULD pick from local discipline taxonomies. Publish a dSigSource list (five refs/URIs, one per characteristic) on every Card, falling back to free-text only where no canonical term exists. Two Contexts are flagged as Near-Duplicate when ≥3 characteristics match. Publish dSig and dSigSource on every Card.

If your Card spills beyond a screen, you are collecting facts, not fixing meaning.

F1‑Card (normative artefact): { taxonomyRef, embeddingRef, DistanceDef, δ_family, confidenceBand, calibrationSet, edition, subFamilyDef? }. subFamilyDef (optional): declares the stable partitioning below a domain‑family (e.g., taxonomic sub‑fields or CVT clusters with parent family anchors). When HET‑FIRST quotas refer to “sub‑family”, they MUST use this declared subFamilyDef. Declare DomainDistance policy (cosine or transport) and δ_family threshold; version as part of DescriptorMapRef. Publish confidenceBand (e.g., CI90%) for the calibrated δ_family; treat numbers in examples as illustrative, not normative.

#Invariants (normative, lightweight)

1. Context ≡ U.BoundedContext. In this pattern, Context always means U.BoundedContext (per E.10.D1).
2. Locality. Words are local to their Context; no global meaning is implied or imported.
3. Heterogeneity. Each unification line considers ≥ 3 distinct Domain families (labels are informative only).
4. Parsimony. Prefer few, canonical Contexts per family (1–3) that jointly expose the key sense splits.
5. No bridging here. No equivalence or mapping is asserted between Contexts in F.1. (Bridges live in F.9.)
6. DesignRunTag honesty. If a canon fixes a DesignRunTag, note it. Do not reinterpret.
7. Didactic primacy. Each Context Card must be readable by a thoughtful engineer in under two minutes.
8. Domain‑family neutrality. Domain families carry no semantics; they SHALL NOT be used for inheritance, inference, or bridge implication.
9. Scope naming separation. Scope gist on Cards is didactic only; formal Scope/entityOfConcern (=USM.ScopeSlice(G) ⊕ entityOfConcern(GroundingHolon, ReferencePlane)) is declared in G.0–G.1, not in F.1.
10. Diversity signature present. Each Context Card PUBLISHES a dSig in the 5‑characteristics form.
11. Collision rule. If any pair of Cards has dSig matching on ≥3 characteristics, mark Near‑Duplicate and either merge into one slot or replace one by a Context from a different domain‑family. Record action in SCR.

#Self‑checks (mental, not procedural)

• The mirror test. Can you explain why each Context is inside your cut in one breath? If not, you are surveying for comfort, not for meaning.
• The homonym ping. For each frequent word (process, role, service, model, execution), can you immediately list the Contexts where it differs? If not, add the missing Context.
• The bridge itch. Feel the temptation to say “these are the same”? Good. Write the itch down and refuse to scratch it here. That’s F.9’s job.
• The memory rule. If your entire survey cannot be recalled without opening a document, it is too large.

#Micro‑examples (illustrative only)

One unification line: role assignment and performed-work attribution with sensing and execution.

• BPMN 2.0 (2011) — workflow family. Scope gist: flow nodes, sequence flows, participants (design‑time). Trip‑wires: “process” here is a graph; not a run.
• W3C PROV‑O (2013) — provenance family. Scope gist: Activity that uses/generates entities (run‑time). Trip‑wires: “activity/process” here is a temporal occurrence.
• ITIL 4 (2020) — services family. Scope gist: service as value co‑creation; SLO/SLA (deontic talk nearby). Trip‑wires: “incident/problem/practice” don’t equal workflow tasks.
• ODRL 2.2 — deontics family. Scope gist: permissions, prohibitions, duties (design). Trip‑wires: “duty/obligation” ≠ service guarantee mechanics.
• SOSA/SSN (2017) — sensing family. Scope gist: Observation as an act yielding a Result for a property. Trip‑wires: “observation” ≠ “state”; it’s an act with a procedure.
• IEC 61131‑3 — control languages family. Scope gist: tasks that execute programs (run‑time). Trip‑wires: “task/execution” ≠ “workflow process”.

With only these Contexts fixed, later steps become almost mechanical: F.2 harvests terms inside each Context; F.3 clusters within each Context; F.4 names roles or statuses pointing to SenseCells; F.9 draws the bridges you refused to draw here.

#Anti‑patterns & remedies

#Worked examples

Each example shows the cut (the Contexts you keep in view) and the thinking pay‑off you get before any harvesting, clustering, or bridging.

#F.1:12.1 Role assignment and performed-work attribution with sensing and execution (service acceptance)

Unification line. Enactment + KD‑CAL (sensing) + Sys‑CAL (execution).

Contexts (six Cards).

1. BPMN 2.0 (2011) — workflow family; design; graph of flow nodes, participants.
2. PROV‑O (2013) — provenance family; run; Activity uses/generates Entities; Agents.
3. ITIL 4 (2020) — services family; design; service, SLO/SLA vocabulary.
4. ODRL 2.2 — deontics family; design; permission / prohibition / duty.
5. SOSA/SSN (2017) — sensing family; run; Observation as act with Result.
6. IEC 61131‑3 — control languages; run; tasks execute control programs.

Thinking pay‑off (examples).

• You stop saying “process uptime” and think Execution (IEC) measured by Observation (SOSA) compared against SLO (ITIL)—three Contexts, three senses.
• You mark a trip‑wire: RBAC role (not in this cut) is not a behavioural role (BPMN participant).
• You resist equating PROV Activity with BPMN workflow; later F.9 may relate them with explicit loss.

#F.1:12.2 Method quartet with types & measurement (model state graph)

Unification line. Method/work stack (A.3/A.15/B.1.5) + Kind-CAL + KD‑CAL.

Contexts (five Cards).

1. SPEM 2.0 / ISO 24744 — methods family; design; Method and MethodDescription language.
2. OWL 2 (profiles) — types family; design; class, subclass, equivalent class.
3. FCA corpus — types family; design; concept lattices.
4. SOSA/SSN (2017) — sensing family; run; Observation / Procedure.
5. ISO 80000‑1 (2022) — metrology family; design; quantity kinds, units.

Thinking pay‑off.

• You keep Method (abstract how‑to) separate from MethodDescription (epistemic recipe) and Execution (run) because the Contexts already split design vs run.
• You avoid treating FCA "concept" as a root kind; later F.9 can bridge OWL classes to FCA concepts with cautions.

#F.1:12.3 Control & actuation with services (operational SLOs in plants)

Unification line. Sys‑CAL + LCA‑CAL (planned) + services/deontics.

Contexts (five Cards).

1. State‑space control texts — control family; design; controller/plant, feedback.
2. IEC 61131‑3 — control languages; run; task, program execution.
3. ISA‑95 — integration family; design; levelled layers, interfaces.
4. ITIL 4 (2020) — services family; design; SLO/SLA.
5. SOSA/SSN (2017) — sensing family; run; Observation.

Thinking pay‑off.

• “Actuation” is recognised as control output (Sys‑CAL), not a service promise.
• “Incident” (ITIL) is not a plant fault (Sys‑CAL); Contexts deter category errors.

#Reasoning primitives (judgement schemas, notation‑free)

These are mental moves, not queries. They read “given these thoughts, this conclusion is safe to hold (conceptually).”

1. Context set for a line line L declared ⊢ Contexts(L) = {C₁,…,Cₙ} Reading: For a unification line L, the Contexts you deliberately keep in view are {C₁,…,Cₙ} (from your Cards).

2. Heterogeneity check families(L) = F ⊢ heterogeneous(L) ≡ (|distinct(F)| ≥ 3) Reading: Your cut is heterogeneous if it spans at least three domain families.

3. Parsimony check Contexts(L)=R, families(L)=F ⊢ parsimonious(L) ≡ (∀f∈F: 1≤|R∩f|≤3) Reading: Each family contributes a few Contexts, not a phonebook.

4. Locality assertion term w, C∈Contexts(L) ⊢ meaning(w)@C is local Reading: A word’s sense is context‑local; no global meaning is implied.

5. Time‑stance guard C has stance s∈{design,run} ⊢ claims@C must respect s Reading: If a Context is design‑time, do not make run‑time claims in it (and vice versa).

6. Trip‑wire recall C lists tripWires T ⊢ for any w∈T, require Context‑prefix when speaking Reading: Words on the trip‑wire list must be spoken with the Context name.

7. Bridge embargo C₁≠C₂ ⊢ no‑equivalence(C₁,C₂) within F.1 Reading: F.1 never asserts equivalence across Contexts; postponement is principled, not procrastination.

8. Context sufficiency probe common‑word w used in L ∧ w not covered by any trip‑wire ⊢ consider adding a Context that makes w differ Reading: If a frequent word has no deliberate sense‑split in your cut, you may be missing a Context.

9. Memory rule |Contexts(L)| too large ⊢ reduce until a careful mind can recite them unaided Reading: The survey should live in memory, not in a registry.

#F1‑Card example (informative)

F1-Card v2025‑Q3:
  taxonomyRef: OpenAlex topics/fields (snapshot 2025‑08)
  embeddingRef: SPECTER2(2023) fine‑tuned@OA‑2025‑08
  DistanceDef: cosine on centroid embeddings (window 36 mo)
  δ_family: 0.35 (calibrated on control set; CI90% [0.33,0.37])
  calibrationSet: 120 labeled pairs (same vs different families)
  edition: 2025‑Q3

#Relations (with other patterns)

Builds on: E.10.D1 Lexical Discipline for “Context” (D.CTX) — ensures Context ≡ U.BoundedContext and reserves “Problem Frame” for narrative use. A.7 Strict Distinction — guards EntityOfConcern/Description-episteme/publication-carrier and DesignRunTag splits while you cut Contexts. A.11 Ontological Parsimony — motivates the small cut.

Constrains: F.2 (Term Harvesting): harvest inside Contexts named here; every occurrence carries a Context name. F.3 (Intra‑Context Sense Clustering): cluster per Context; no Cross‑context sense claims. F.4 (Role Descriptions): any role template or status template must cite a SenseCell that lives in a Context from this cut. F.9 (Alignment & Bridge): only F.9 may relate Contexts; never F.1–F.4.

Used by. Extension patterns in Part C (Sys‑CAL, KD‑CAL, Kind-CAL, LCA‑CAL) plus the method/work stack (A.3/A.15/B.1.5) as the lexical starting grid for their examples and definitions.

#Migration notes (conceptual)

1. New edition appears. Keep the old Card; add a new Card with the new edition. If the sense shifts, treat it as a new Context; if it is strictly editorial, mark recency but keep one context.
2. New family emerges. If a missing family explains recurrent confusion in your line, admit it with one exemplar Context; remove a less informative Context to keep parsimony.
3. Language variants. Treat language editions as separate Contexts unless the canon itself declares a single normative bilingual mapping.
4. Trip‑wire growth. When you notice a recurring confusion, add a crisp trip‑wire to the relevant Card (one line; no essays).
5. Bridges discovered later. Do not back‑port bridges into F.1; leave the Cards untouched and record the mapping in F.9.
6. Dormant Contexts. If a Context no longer contributes to any active line, move it to a parking shelf (informative note on the Card) rather than deleting it.

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

#Static conformance checks (SCR)

• SCR‑F1‑S01 (Heterogeneity). For each unification line, the set of Cards spans ≥ 3 distinct domain families.
• SCR‑F1‑S02 (One‑screen Cards). Each Card fits on one screen: name+edition; family; scope gist; time stance (if inherent); 1–3 trip‑wires; neighbour Contexts (optional); recency note.
• SCR‑F1‑S03 (Locality pledge). Nowhere in F.1 are Cross‑context equivalences or merges asserted.
• SCR‑F1‑S04 (Parsimony). In every family, 1–3 Contexts are kept; if more, a clear sentence justifies each extra Context’s unique sense contribution.
• SCR‑F1‑S05 (Context discipline). “Context” is used only as a synonym of U.BoundedContext; “domain” appears only as an informative family label.
• SCR‑F1‑S06 (Temporal honesty). If a canon fixes DesignRunTag, the Card states it.
• SCR‑F1‑S07 (Family neutrality). No claim, classification, or relation in F.1 relies on Domain‑family membership; families appear only as shelf labels on cards.
• SCR‑F1‑S08 (dSig present). Every Context Card has a 5‑characteristics dSig.
• SCR‑F1‑S09 (Collision policy). Any pair with dSig match on ≥3 characteristics is either merged or replaced; SCR records the action.

#Regression checks (RSCR)

• RSCR‑F1‑E01 (Edition churn). When a new edition is added, prior Cards remain; no silent replacement.
• RSCR‑F1‑E02 (Family balance). Adding/removing Cards does not drop any line below three families.
• RSCR‑F1‑E03 (Trip‑wire coverage). After introducing a new Context, the trip‑wire lists of neighbouring Contexts are reconsidered and updated if needed.
• RSCR‑F1‑E04 (No creep). Periodically apply the memory rule: if the cut no longer fits in working memory, shrink it.

#Didactic distillation (90‑second teaching script)

“Before you name anything, fix the context of meaning. A Context is a U.BoundedContext tied to a specific canon—BPMN 2.0, PROV‑O, ITIL 4, SOSA/SSN, IEC 61131‑3, OWL 2. Words are local to Contexts: process (BPMN) is a workflow graph, activity (PROV) is a run‑time occurrence, service (ITIL) is a promise vocabulary. Cut the landscape so each unification line sees at least three domain families, with one‑screen Cards per Context (scope gist, time stance, trip‑wires). Do not bridge Contexts here—just write down the itch to bridge as an F.9 bridge question. Keep the cut small enough to remember. With Contexts fixed, harvesting (F.2), local clustering (F.3), role template or status templates (F.4), and explicit Cross‑context bridges (F.9) become straightforward—and you avoid naming ghosts that come from words floating without walls.”

#F.1:End

#F.2 — Term Harvesting & Normalisation

“Harvest words inside Contexts, name them in the Context’s own idiom, and stop there.” Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); F.0.1 Contextual Lexicon Principles (Source - Local Meaning - Bridge‑Only Crossing); A.7 Strict Distinction; A.11 Ontological Parsimony. Coordinates with. F.1 Context Map via Context Cards; F.3 Intra‑Context Sense Clustering; F.4 Role Description; F.9 Alignment & Bridge Across Contexts. Aliases (informative). context‑local harvesting; Local normalisation.

#Intent & applicability

Intent. Provide a conceptual (notation‑free) discipline for turning Context‑internal usage into context‑local lexical units ready for later reasoning—without Cross‑context merging and without slipping into governance or tooling. The result is a small, auditable set of context‑local names and glosses that faithfully reflect how the canon speaks.

Applicability. Use whenever a unification line (from F.1) needs actual words to be referenced by patterns in Part C (Extention patterns) or by Role Descriptions (F.4). Re‑enter F.2 when a canon/edition changes or when a new Context is admitted in F.1.

Non‑goals. No global labels; no Cross‑context equivalence; no workflow or role descriptions; no storage/API talk. F.2 specifies how to think, not how to “run a pipeline”.

#Problem Frame

Even with Contexts fixed (F.1), three mistakes recur:

1. Word‑centrism. Treating a string as if it carried its meaning across Contexts (process, role, service).
2. Over‑normalisation. Forcing one spelling/morphology across different canons, erasing Context‑specific cues.
3. Premature structure. Smuggling behaviour, deontics, or type structures into what should remain lexical.

F.2 prevents these by localising meaning and naming strictly inside each Context.

#Forces

#Core idea (didactic)

Harvest inside each Context; name in that Context’s idiom; do not cross Contexts. For every Context (a U.BoundedContext from F.1), you gather attested phrases as thought-cues, choose a Local Normal Form (LNF) that matches the Context's idiom, attach a two-register label (Tech/Plain), and write a one-sentence gloss. That's all. These local lexical units become Local-Senses in F.3 and later addressable SenseCells (Context x Local-Sense). Cross-context sameness, behavioural claims, deontics, and durable kindhood are handled by F.9, A.15, E/E-LOG, or admission under E.24.UK and C.3 when those claims are being made.

#Minimal vocabulary (this pattern only)

• Context — Tech‑register alias for U.BoundedContext (per E.10.D1).
• Attested phrase — A short, verbatim cue from the canon that shows how a word is used in this Context (citation idea, not a record format).
• Local Normal Form (LNF) — The Context‑specific canonical surface you will use when referring to the term in this Context (minimal editing: spelling/hyphenation/casing per the canon).
• Two‑register label — Tech (engineer‑facing) and Plain (pedagogic) forms for the same Context‑local meaning.
• Gloss (one‑sentence) — A Context‑faithful description of how the canon uses the term, at minimal generality.
• Local lexical unit — The quintet (Context, LNF, Tech, Plain, Gloss). This is F.2’s only outcome.
• Homonymy (signal) — Awareness that the same string has different local lexical units across Contexts (no relation asserted).
• SenseCell (appears downstream) — Address (Context × Local‑Sense) minted in F.3; mentioned here so you know what you’re preparing.

Everything above is a way of thinking. None of it implies a database, statuses, or roles.

#Solution — three mental moves (notation‑free)

#Move A — Localise the word

Question to ask. “In which Context am I hearing this word?” Action (mental). Point to a specific Context (from F.1). Grab 1–2 attested phrases that are representative in this Context. Outcome. You stop thinking “global word” and start thinking “context‑local usage”.

Micro‑cue. If you cannot name the Context, do not harvest the word.

#F.2:6.2 -Move B — Name it in the Context’s idiom

Question to ask. “How would this Context itself write it?” Action (mental). Choose the LNF (Context‑conformant spelling/hyphenation). Then write the two‑register label and a one‑sentence gloss that says what the canon means here—nothing more. Outcome. You have a local lexical unit (Context, LNF, Tech, Plain, Gloss).

Micro‑cues. • Prefer the canon’s head noun; keep canonical hyphens; avoid invented compounds. • The Plain label should help a non‑specialist; the Tech label should match engineers’ eyes. • The Gloss must fit on a single line; put details in F.3.

#Move C — Fence it off

Question to ask. “What must I refuse to conclude here?” Action (mental). Explicitly refuse to: (1) compare across Contexts, (2) fold morphology that the canon treats as meaningful, (3) embed behaviour, deontics, or type structure. Outcome. A clean, context‑local lexical unit that will be safe to cluster in F.3 and safe to bridge (or not) in F.9.

#Guard‑rails (normative, lightweight)

1. context‑locality. Every local lexical unit MUST cite a Context (U.BoundedContext from F.1).
2. Context‑idiom normalisation. LNF MUST respect the Context’s idiom (spelling/hyphenation/casing) and use minimal edits.
3. Two registers. Each unit SHOULD carry both Tech and Plain labels for didactics; if one is missing, justify.
4. Minimal generality (G‑1). The gloss MUST be as specific as the Context’s canon requires—no broader.
5. EntityOfConcern / Description / specification-use hygiene (A.7). MUST NOT include behaviour equations, deontic rules, measurement math, or type axioms; those belong to patterns.
6. No Cross‑context claims. MUST NOT assert equivalence, subsumption, or similarity with terms in other Contexts (F.9 only).
7. Edition honesty. If the Context’s canon has multiple editions with shifting usage, treat them as distinct Contexts in F.1 before harvesting.
8. Parsimony. Prefer few, telling lexical units over long tails; keep head terms that will power F.3/F.4/F.9.

#Micro‑examples (illustrative, context‑local)

Each line is one local lexical unit. No relations are implied across lines.

• Context: BPMN 2.0 (2011) — LNF: process Tech: process - Plain: workflow process Gloss: “Directed graph of flow nodes and sequence flows enacted by participants.”

• Context: PROV‑O (2013) — LNF: activity Tech: activity - Plain: temporal occurrence Gloss: “Time‑bounded occurrence that uses and generates entities and is linked to agents.”

• Context: ITIL 4 (2020) — LNF: service‑level‑objective Tech: service‑level‑objective - Plain: service target Gloss: “Target value for a service characteristic within a service promise vocabulary.”

• Context: NIST RBAC (2004) — LNF: role Tech: access‑role - Plain: permission role Gloss: “Named grouping of permissions assignable via sessions.”

• Context: SOSA/SSN (2017) — LNF: observation Tech: observation - Plain: measurement act Gloss: “Act applying a procedure to a feature of interest to produce a result.”

• Context: IEC 61131‑3 — LNF: task Tech: task - Plain: runtime program execution Gloss: “Cyclic or event‑driven execution unit for control programs.”

#Didactic heuristics (informative)

• Keep the Context prefix in your inner speech. Say “process (BPMN)”, “activity (PROV)”.
• Prefer head nouns. If the canon says “service‑level objective”, do not shorten it to “objective”.
• Resist elegance that erases signal. Hyphens and case often carry the Context’s culture; keep them.
• Gloss from use, not from opinion. Quote in your mind, then compress; avoid importing definitions from neighbouring Contexts.

#Anti‑patterns & remedies

#Worked examples (context‑local only)

Each line is a local lexical unit (Context, LNF, Tech, Plain, Gloss). No Cross‑context relation is implied. Later clustering (F.3) and bridges (F.9) may connect them.

#F.2:11.1 Enactment + sensing

• Context: BPMN 2.0 (2011) — LNF: process Tech: process - Plain: workflow process Gloss: “Directed graph of flow nodes and sequence flows enacted by participants.”

• Context: PROV‑O (2013) — LNF: activity Tech: activity - Plain: temporal occurrence Gloss: “Time‑bounded occurrence that uses and generates entities and links to agents.”

• Context: SOSA/SSN (2017) — LNF: observation Tech: observation - Plain: measurement act Gloss: “Act applying a procedure to a feature of interest to produce a result.”

• Context: ITIL 4 (2020) — LNF: service‑level‑objective Tech: service‑level‑objective - Plain: service target Gloss: “Target value for a service characteristic within a service promise vocabulary.”

Thinking pay‑off: you can phrase “compare observation to service‑level‑objective” without importing workflow or provenance semantics.

#F.2:11.2 Sys‑CAL / LCA‑CAL + services

• Context: State‑space control texts — LNF: actuation Tech: actuation - Plain: control output Gloss: “Signal applied to the plant to influence state or output.”

• Context: IEC 61131‑3 — LNF: task Tech: task - Plain: runtime program execution Gloss: “Cyclic or event‑driven execution unit for control programs.”

• Context: ITIL 4 (2020) — LNF: incident Tech: incident - Plain: reported disruption Gloss: “Unplanned interruption or reduction in the quality of a service.”

Thinking pay‑off: avoids calling a plant fault an “incident” unless you cross Contexts later with an explicit bridge.

#F.2:11.3 Kind-CAL + method/work stack + KD‑CAL

• Context: OWL 2 (profiles) — LNF: subclass‑of Tech: subclass‑of - Plain: is‑a (type hierarchy) Gloss: “C ⊑ D: every instance of C is an instance of D.”

• Context: FCA corpus — LNF: formal‑concept Tech: formal‑concept - Plain: extent–intent node Gloss: “Maximal (objects, attributes) pair under a Galois connection.”

• Context: SPEM 2.0 / ISO 24744 — LNF: method Tech: method - Plain: abstract way of doing Gloss: “Abstract how‑to independent of specification or execution.”

• Context: SOSA/SSN (2017) — LNF: procedure Tech: procedure - Plain: measurement recipe Gloss: “Specification guiding how an observation is produced.”

Thinking pay-off: discourages treating an FCA "concept" as a root kind, or a procedure as a method without later proof.

#Reasoning primitives (judgement schemas, notation‑free)

Read each as a permitted mental move over the outcomes of F.2. Symbols: R = Context (U.BoundedContext), u = local lexical unit, s = lexical string.

1. Localisation heard(s) ∧ R chosen ⊢ localize(s,R) You decide to hear s only in Context R.

2. Context‑idiom normalisation localize(s,R) ⊢ LNF_R(s) = ℓ Within R, the Local Normal Form for s is ℓ.

3. Unit formation LNF_R(s)=ℓ ∧ labelTech=t ∧ labelPlain=p ∧ gloss=g ⊢ unit(u) = ⟨R,ℓ,t,p,g⟩ A local lexical unit is formed (quintet).

4. Lexical‑only guard unit(u) ⊢ lexicalOnly(u) No behavioural/deontic/type math is attached to the gloss.

5. Homonymy signal (Cross‑context) LNF_Ra(s)=ℓa ∧ LNF_Rb(s)=ℓb ∧ Ra≠Rb ⊢ homonymy(s) ⊇ {Ra,Rb} Same string across Contexts is flagged as different by default.

6. Minimal generality check unit(u) ⊢ minimal(u) ⇔ gloss(u) says no more than the Context’s usage requires The gloss fits the Context; broader claims are withheld.

7. Two‑register adequacy unit(u) ⊢ didactic(u) ⇔ (tech(u) faithful) ∧ (plain(u) explanatory) Tech stays canonical; Plain helps non‑specialists.

8. No Cross‑context conclusion unit(u@Ra), unit(v@Rb), Ra≠Rb ⊢ ¬(u ≡ v) (within F.2) F.2 never asserts Cross‑context equivalence.

9. Ready‑for‑F.3 signal lexicalOnly(u) ∧ minimal(u) ∧ didactic(u) ⊢ readyF3(u) A unit is suitable input for intra‑Context clustering in F.3.

#Relations

Builds on: F.1 (Contexts fixed; heterogeneity/parsimony in place). E.10.D1 D.CTX (Context ≡ U.BoundedContext; “Problem Frame” reserved for narrative). F.0.1 (Source - Local Meaning - Bridge‑Only Crossing).

Constrains: F.3 (Intra‑Context Sense Clustering): operates only on units from one Context; produces Local‑Senses and addressable SenseCells. F.4 (Role Description Definition): may cite SenseCells, not raw strings. F.9 (Alignment & Bridge): consumes homonymy signals; declares explicit Cross‑context mappings with loss policies.

Used by. Extention patterns in Part C when referencing domain idioms (labels stay context‑local).

#Migration notes (conceptual)

1. New edition appears. Add a Context in F.1; harvest afresh in F.2 using that Context; do not overwrite earlier units.
2. Idiomatic update discovered. If your LNF fought the canon’s idiom, re‑LNF within the same context; keep labels/glosses steady unless the canon itself differs.
3. Ambiguity inside a Context. If use splits, mint two units with distinct glosses; F.3 will sort their relation (same/different Local‑Sense).
4. Language split. Treat each language canon as its own Context; resist cross‑language merges in F.2.
5. Tail pruning. If units accumulate without feeding F.3/F.4/F.9, drop them from the working set; keep head terms that carry bridges.
6. DSL quarantine. If a tool dialect is unavoidable, keep it as one context among others; never let it define the idiom for other Contexts.

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

#Static conformance (SCR)

• SCR‑F2‑S01 (context‑locality). Every unit cites a Context from F.1.
• SCR‑F2‑S02 (Idiomatic LNF). Each LNF reflects the Context’s spelling/hyphenation/casing with minimal edits.
• SCR‑F2‑S03 (Two registers). Each unit carries both Tech and Plain labels; if not, a reason exists tied to didactics.
• SCR‑F2‑S04 (Lexical‑only). No gloss contains behaviour, deontics, measurement math, or type axioms.
• SCR‑F2‑S05 (No Cross‑context claims). Nowhere does F.2 assert equivalence/similarity/subsumption across Contexts.
• SCR‑F2‑S06 (Minimal generality). Glosses match the Context’s use; no globalisation.
• SCR‑F2‑S07 (Temporal honesty). For Contexts with fixed DesignRunTag, units and glosses respect it.

#Regression (RSCR)

• RSCR‑F2‑E01 (Edition split). Introducing a new edition yields new units under a new Context; earlier units persist unchanged.
• RSCR‑F2‑E02 (Normaliser stability). Adjusting an LNF does not silently widen/narrow the gloss.
• RSCR‑F2‑E03 (Language split). Adding a second language yields a second Context; no bilingual collapse in F.2.
• RSCR‑F2‑E04 (No stealth bridges). After updates, F.2 still contains zero Cross‑context identity claims; any mapping appears only in F.9.
• RSCR‑F2‑E05 (Head‑term focus). Periodic check shows the unit set remains small and oriented to F.3/F.4/F.9 needs.

#Didactic distillation (60‑second script)

“In F.2 you harvest inside Contexts. For each Context, pick the canon’s own phrasing, choose a Local Normal Form in that idiom, add Tech and Plain labels, and write a one‑sentence Gloss that matches how that Context talks. Stop there. No bridging, no behaviour, no equations. If the same string appears in another Context, treat it as a different unit. These units feed F.3, where you’ll sort senses within a Context, and F.9, where you’ll relate Contexts explicitly. This keeps meaning local, names faithful, and later reasoning clean.”

#F.2:End

#Intra‑Context Sense Clustering

“Within one context, decide what ‘the same sense’ really is—before you ever cross Contexts.” Status. Architectural pattern. Depends on. F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting & Normalisation; E.10.D1 Lexical Discipline for “Context” (D.CTX); A.7 Strict Distinction; A.11 Ontological Parsimony. Coordinates with. F.4 Role Description; F.7 Concept‑Set Table; F.8 Mint or Reuse Decision; F.9 Alignment & Bridge Across Contexts. Aliases (informative). context‑local clustering; Sense consolidation.

#Intent & applicability

Intent. Consolidate the context‑local lexical units from F.2 into a small set of Local‑Senses that actually operate in that one context (U.BoundedContext). Each Local‑Sense receives a crisp, didactic label pair (Tech/Plain) and a short sense statement. The result is an addressable basis for later uses (Role Assignment, tables, bridges) that is still strictly context‑local.

Applicability. Apply after F.2 for any Context that will feed naming (F.4/F.5), decision gates (F.8), Cross‑context bridges (F.9), or exemplars in Part C. Use again whenever the canon (edition) shifts usage enough to split or merge senses within the same context.

Non‑goals. No Cross‑context comparison or merging. No behaviour/deontics/type mathematics. No storage schemas or workflows. This is pure sense‑making inside one context.

#Problem Frame

context‑local units (LNF + labels + gloss) from F.2 often over‑ or under‑differentiate meaning:

1. Over‑split: superficial variants (service‑level‑objective vs SLO) treated as different “things”.
2. Under‑split: one gloss covering two selectional frames or incompatible use‑cases.
3. Drift within a canon: multi‑chapter texts use the same head differently unless the reader consolidates the intended sense.
4. Didactic mismatch: engineer‑friendly label and plain label drift apart when units remain too granular.

F.3 repairs this inside the Context by clustering “same sense” and distinguishing “different sense”, with parsimony.

#Forces

#Core idea (didactic)

Cluster by usage, not by string. Inside one context:

• Same sense → Local‑Sense: a small, coherent usage‑region the canon treats as one idea (even if it has aliases or minor surface variation).
• Different sense → two Local‑Senses: incompatible selectional frames, entailments, or role in the canon’s own statements.

Each Local‑Sense becomes addressable when paired with its Context: SenseCell = (Context × Local‑Sense). SenseCells are context‑local coordinates; they do not pre‑judge any Cross‑context mapping.

#Minimal vocabulary (this pattern only)

• Context — short for U.BoundedContext (per D.CTX).
• Unit — a context‑local lexical unit from F.2 (LNF + Tech/Plain + gloss).
• Local‑Sense — the conceptual cluster of Units deemed “same sense” within that Context.
• SenseCell — the address for a Local‑Sense: (Context, Local‑Sense). This is what later patterns will cite.
• Counter‑example — a short, canonical sentence or use that must not be covered by the Local‑Sense; it sharpens the boundary.
• Usage cue (informative) — a clue from usage (collocational patterns, paraphrases, entailments in the canon) that suggests merge or split. Cues do not decide; the canon’s intent does.

#Solution — how to think the clustering (notation‑free)

What follows are mental moves, not steps for a team. Use them as probes until the Context’s usage partitions itself naturally.

6.1 Consolidate aliases into one Local‑Sense. If Units differ only by orthography, abbreviation, or canon‑blessed synonymy and are used interchangeably in the Context’s own sentences, treat them as one Local‑Sense. Example (ITIL): service‑level‑objective and SLO → one Local‑Sense.

6.2 Split on incompatible selectional frames. If the same head pairs with different kinds of arguments or plays different roles in the canon’s statements (and those roles cannot both be true at once), split. Example (BPMN): event as node type vs as occurrence narrative in a tutorial → two Local‑Senses; adopt the node type sense if that is the normative layer.

6.3 Split on entailments that pull apart. If paraphrases lead to different entailments (e.g., one implies temporality, another structural position), you have two senses. Example (PROV): activity implies time‑bounded use/generate; it cannot be the same sense as a static capability.

6.4 Prefer sense minimality. If two candidate Local‑Senses never lead to different conclusions in the Context’s own use, merge them. If they sometimes do, split them—and record a counter‑example to keep the boundary crisp.

6.5 Keep Tech label idiomatic; Plain label helpful. Tech label stays as the canon speaks; Plain label conveys the function of the sense to a careful newcomer. Neither label may broaden the sense beyond usage.

6.6 Name only as much as you will use. If a fine-grained split has no downstream consequence (Role Descriptions, tables, bridges), prefer the coarser Local-Sense.

#Outputs (conceptual, not clerical)

F.3 yields, per Context:

1. A small set of Local‑Senses, each with:

   • Label pair: Tech (idiomatic) - Plain (didactic).
   • Sense line: one‑sentence usage statement, in the Context’s voice.
   • Inside list (informative): which Units from F.2 it consolidates.
   • Counter‑example (optional but powerful): a short use that must not be included.

2. A SenseCell address for each Local‑Sense: (Context, Local‑Sense).

These are thinking reference points (cognitive only), not records or files. Later patterns cite SenseCells by name; nothing about storage is implied.

#Invariants (normative, lightweight)

1. context‑locality. Every Local‑Sense belongs to exactly one context. No Cross‑context clustering.
2. Parsimony. Local‑Senses are few; prefer the coarsest partition that preserves the canon’s distinctions.
3. Idiomatic Tech. The Tech label must stay in the Context’s idiom; no house‑style overrides.
4. Didactic Plain. The Plain label must aid comprehension without adding scope.
5. Usage‑first. Sense lines reflect the canon’s usage, not imported taxonomies or external theories.
6. Counter‑examples rule. If a counter‑example exists that the sense would wrongly include, split.
7. No behaviour math. Sense lines contain no behavioural, deontic, metrological, or type calculus; those live in Part C.
8. Temporal honesty. If the Context fixes DesignRunTag, the sense line respects it (e.g., PROV activity is run‑time).

#Self‑checks (mental probes)

• Same‑conclusion test. Do two candidate senses ever lead to different conclusions in the canon? If not, merge.
• Argument‑slot probe. Replace arguments in canonical sentences; do both candidates still read true? If one fails, split.
• Label inversion. Read the Plain label alone: does it tempt you to over‑generalise? If yes, tighten it.
• Counter‑example ping. Can you state a ten‑word use that the sense must exclude? If you can, write it; if you cannot, your sense may be too broad.
• Memory rule. Can you recall the Context’s Local‑Senses without notes? If not, you split too finely.

#Anti‑patterns & remedies

#Local‑Sense Cards (one‑glance form)

A Local‑Sense Card is a one‑glance sketch per sense in a Context. It teaches faster than prose lists and keeps senses crisp.

Fields (thought‑items, not fields to fill):

• Context (U.BoundedContext, edition)
• Label pair — Tech (idiomatic) - Plain (didactic)
• Sense line — one sentence in the Context’s voice
• Inside — which F.2 Units it consolidates (names only)
• Counter‑example — a short use that must not be included

#Worked examples (all intra‑Context)

#BPMN 2.0 (workflow Context)

Card A — “process (graph)”

• Label: Tech process - Plain workflow graph
• Sense line: A BPMN graph of flow nodes and sequence flows specifying orchestration among participants (design‑time).
• Inside: process, process model, business process (when used as diagram).
• Counter‑example: “This process took 5 minutes” ← runtime occurrence, not this sense.

Card B — “event (node‑type)”

• Label: Tech event (node) - Plain event symbol
• Sense line: A node-type that marks starts, ends, and intermediates; typed by trigger and result.
• Inside: start event, message event, end event.
• Counter‑example: “The outage event happened at 13:05” ← narrative occurrence, not the node‑type.

Outcome: “Process uptime” is rejected as a BPMN sense; Execution belongs to another Context.

#PROV‑O (provenance Context)

Card C — “activity (run)”

• Label: Tech activity - Plain time‑bounded execution
• Sense line: An occurrence that uses and generates entities; linked to agents; has start/end.
• Inside: activity, execution (when PROV authors use it).
• Counter‑example: “Sorting algorithm” ← capability/method, not an occurrence.

Card D — “agent (provenance)”

• Label: Tech agent - Plain provenance actor
• Sense line: Thing that bears responsibility for an activity’s effects (person, org, software).
• Inside: agent.
• Counter‑example: “RBAC role” ← access status, not a PROV agent.

#ITIL 4 (services Context)

Card E — “service‑level objective”

• Label: Tech SLO - Plain service target
• Sense line: A target value/range for a service characteristic used to define acceptable service.
• Inside: service‑level objective, SLO.
• Counter‑example: “Actual availability 99.5%” ← observation, not the target.

Card F — “incident”

• Label: Tech incident - Plain service disruption
• Sense line: An unplanned interruption or reduction in quality of a service.
• Inside: incident.
• Counter‑example: “Fault in plant sensor” ← Sys‑CAL fault; different Context.

#SOSA/SSN (sensing Context)

Card G — “observation (act)”

• Label: Tech observation - Plain measurement act
• Sense line: An act applying a Procedure to a FeatureOfInterest to yield a Result for a property.
• Inside: observation.
• Counter‑example: “Temperature is 20 °C” ← result value, not the act.

#OWL 2 (types Context)

Card H — “subclass‑of”

• Label: Tech subclass‑of (⊑) - Plain is‑a (class)
• Sense line: A class inclusion: every instance of C is an instance of D.
• Inside: SubClassOf, is‑a (when authors use it for classes).
• Counter‑example: rdf:type (instance‑of) — not class inclusion.

Card I — “equivalent‑class”

• Label: Tech equivalent‑class - Plain same class extension
• Sense line: Mutual class identity by extension; two labels for the same set of instances.
• Inside: EquivalentClasses.
• Counter‑example: owl:sameAs (individual identity), different predicate.

#IEC 61131‑3 (control‑runtime Context)

Card J — “task (runtime)”

• Label: Tech task - Plain program runner
• Sense line: A cyclic or event‑driven execution unit that invokes programs on schedule or trigger.
• Inside: task.
• Counter‑example: “Control algorithm” ← design/method, not the runtime task.

#Reasoning primitives (judgement schemas, notation‑free)

Each schema captures a safe mental move. It implies no storage, API, or workflow.

1. Alias‑to‑sense consolidation Context C ⊢ interchangeable(U₁,…,Uₖ) ⇒ Local‑Sense σ Reading: If Units are used interchangeably by the canon in C, consolidate them into one Local‑Sense σ.

2. Selectional‑frame split C ⊢ frames(U) = F, frames(V) = G, F ∩ G = ∅ ⇒ split(U,V) Reading: In C, if the argument/role patterns do not overlap, treat as different senses.

3. Entailment divergence C ⊢ entail(U) ≠ entail(V) on canonical paraphrases ⇒ split(U,V) Reading: If paraphrases lead to different conclusions in the canon, split.

4. Parsimony merge C ⊢ no‑test distinguishes {U₁,…,Uₖ} ⇒ merge(U₁,…,Uₖ) Reading: If no canonical test yields a difference, merge into one sense.

5. Counter‑example trigger C ⊢ ∃e: e should not be covered by σ ⇒ refine(σ) Reading: A crisp counter‑example forces a narrower sense (split or relabel).

6. Idiomatic Tech, faithful Plain C ⊢ labelTech(σ) in idiom(C) ∧ labelPlain(σ) ⊆ usage(σ) Reading: Tech label speaks the canon; Plain label does not widen the sense.

7. SenseCell address C ⊢ σ ⇒ SenseCell ⟨C,σ⟩ Reading: Pair each Local‑Sense with its Context to form an address used downstream.

8. Temporal guard stance(C)=design ⇒ forbid(run‑claims in σ) (and symmetrically) Reading: Sense lines must not cross the Context’s DesignRunTag.

9. Edition guard C≠C′ (different editions with usage shift) ⇒ no‑merge(σ@C, τ@C′) Reading: Do not merge senses across Contexts when editions shift usage.

10. Completeness ping (optional) frequent head w in C ∧ no Local‑Sense on w ⇒ consider(sense for w) Reading: If a common head lacks a sense, you may be missing a useful consolidation (within C).

#Relations

Builds on: F.1 Domain‑Family Landscape Survey (Contexts fixed); F.2 Term Harvesting (Units ready); E.10.D1 D.CTX (Context discipline); A.7 Strict Distinction.

Constrains:

• F.4 Role Description. Role Descriptions cite SenseCells; they do not invent senses.
• F.7 Concept‑Set Table. Rows are built from SenseCells (later Cross‑context assembly); intra‑Context clarity here prevents row bloat.
• F.8 Mint or Reuse Decision. Decisions compare proposed names to existing SenseCells to avoid type inflation.
• F.9 Alignment & Bridge. Bridges connect SenseCell ↔ SenseCell across Contexts; F.3 provides the stable endpoints.

Is used by. Part C Extention Patterns to ground examples and invariants in Context‑true language.

#Migration notes (conceptual)

1. Usage clarifies → merge. If two Local‑Senses never lead to different conclusions in the Context’s canon, merge and keep the narrower sense line.
2. Usage diverges → split. If new reading reveals incompatible roles/entailments, split and attach a counter‑example to each side.
3. Edition change → new Context. When a new edition reframes usage, treat it as a separate Context (F.1) and re‑cluster there.
4. Label upkeep. If the Plain label tempts broadening, tighten it; if the Tech label drifts from idiom, restore the canon term.
5. Dormant sense. If a Local‑Sense ceases to matter for any active line, leave it listed but mark it low‑use in your own notes; do not fold it into another unless rule 1 holds.
6. Bridge temptation. Record tensions to bridge elsewhere; F.3 never resolves Cross‑context relations.

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

#Static conformance (SCR)

• SCR‑F3‑S01 (context‑locality). Every Local‑Sense is paired with exactly one context; no Cross‑context clustering appears.
• SCR‑F3‑S02 (Label pair). Each Local‑Sense has Tech (idiomatic) and Plain (didactic) labels; neither widens usage beyond the sense line.
• SCR‑F3‑S03 (Sense line fidelity). Each sense line is grounded in canonical statements of the Context; no behaviour/deontic/math content.
• SCR‑F3‑S04 (Parsimony). The set of Local‑Senses per Context is small enough to recall unaided by a careful mind.
• SCR‑F3‑S05 (Counter‑example presence). For any ambiguous head, at least one counter‑example is recorded to guard the boundary.
• SCR‑F3‑S06 (Temporal honesty). Where the Context has a declared stance, sense lines respect the DesignRunTag.

#Regression (RSCR)

• RSCR‑F3‑E01 (Merge soundness). Every merge is justified by a failed distinction test (no selectional or entailment difference).
• RSCR‑F3‑E02 (Split necessity). Every split cites a role/entailment conflict or a concrete counter‑example.
• RSCR‑F3‑E03 (Edition guard). No Local‑Sense spans Contexts that differ by edition with usage shift.
• RSCR‑F3‑E04 (Label stability). Changes to labels do not change sense; if they do, the change is treated as a split/merge per E01/E02.
• RSCR‑F3‑E05 (Downstream continuity). After splits/merges, SenseCell references in F.4/F.7/F.9 remain referentially clear (new addresses are explicit; no silent aliasing).

#Didactic close (60‑second recap)

Within one context, collect how the canon actually uses a head, not how we wish it did. Merge aliases that never lead to different conclusions; split uses that do. Give each consolidated use a crisp Tech label in the Context’s idiom and a faithful Plain label. The pair (Context, Local-Sense) is your SenseCell—the address later cited by Role Descriptions, tables, and bridges. No Cross‑context mergers here; that job belongs to F.9. Keep senses few, boundaries sharp, and labels honest.

#F.3:End

#Role Description - Description Episteme for U.Role

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Role-description episteme.

Use this pattern when a project needs a short, reusable description that makes one work-facing U.Role recognizable, teachable, and checkable under one named role-taxonomy episteme and effective U.ReferenceScheme.

Typical moments:

• a project has a role name such as ReviewerRole, OperatorRole, InspectorRole, TransformerRole, ShipyardCoordinatorRole, or ModelCardReviewerRole, but the governing role-taxonomy episteme, effective reference scheme, admitted holder kind, role invariants, capability conditions, or work-facing boundary are unclear;
• a method description names required roles, but readers cannot tell what role value is required before a U.RoleAssignment can be checked;
• a role name is starting to carry method, capability, work, permission, evidence, publication, or status claims that belong to neighboring patterns;
• a former source phrase says that a report, standard, dataset, theorem, dashboard, publication, or requirement has a "role" and the text must decide whether that phrase is a real work-facing role description or a direct episteme-use relation.

Primary EntityOfConcern. The exact C.2.1 EntityOfConcern of the role-description episteme is the described U.Role value. The governed object is one U.Episteme constituted under C.2.1 by its exact ClaimGraph, that role value, and the effective U.ReferenceScheme; its claims name the role-taxonomy episteme that supplies the vocabulary. The role-description episteme is not the role value itself, holder, role assignment, capability, method description, performed work, status-use relation, or publication form.

Primary working reader. The first reader is an engineer-manager, analyst, method author, or pattern author who must let people recognize a role while keeping role value, holder, assignment, capability, method, work, evidence use, status use, and publication use distinct.

First useful move. Name the role value, its role-taxonomy episteme, the effective reference scheme, the admitted holder kind, and the smallest role invariants needed by the next assignment, method, work, naming, or bridge claim.

What goes wrong if missed. A role-description card becomes a hidden method, access policy, permission badge, evidence relation, status assertion, staffing plan, or work log. Then FPF grows one role ontology for acting holons and a second role-like ontology for epistemes, publications, statuses, and relation positions.

What this buys. A project can publish a compact, human-readable role description while keeping operational claims in their direct patterns. The role remains recognizable; the assignment remains checkable; capability, method, work, evidence, status, and publication claims stay inspectable instead of being smuggled into the role name.

Not this pattern when.

• If the current claim is the role value itself or role taxonomy, use A.2.
• If the current claim is which admitted system holds which role and during which uninterrupted assignment occurrence, use A.2.1.
• If the current claim is role state or enactable-state admission, use A.2.5.
• If the current claim is role-requirement substitution, role incompatibility, role-factor qualification, or bundle expression, use A.2.7.
• If the current claim is capability, use A.2.2.
• If the current claim is method, method description, work plan, or performed work, use A.15 and its neighbors.
• If the current claim is evidence use, status use, source use, standard use, requirement use, publication use, assurance use, gate use, or decision use of an episteme, use the direct pattern for that relation. Do not call that episteme a role holder.
• If the current issue is only a durable name, use F.18.
• If the current issue is correspondence between role meanings under different taxonomies or reference schemes, use F.9.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.

#Problem Frame

Role descriptions are useful because a role value needs a recognizable description before people can assign it, name it, compare it, or use it in a method condition. A role such as InspectorRole is not self-explanatory. The project needs the exact role-taxonomy episteme and effective reference scheme that give the value its current meaning, the admitted holder kind, the role invariants that matter, and the neighboring checks that may become current.

The recurring failure is to make the role description carry too much. A compact card is tempting: put role, status, permission, evidence, capability, method, assignment, work, and publication cues into one "assignable" template. That looks convenient but creates duplicate ontology. A standard used as a requirement source becomes a "standard role"; a report used as evidence becomes an "evidence role"; an access-control label becomes a behavioral role; a role name becomes proof of capability or proof that work occurred.

F.4 therefore treats a role description as a description episteme about a work-facing U.Role. It may mention neighboring relations, but it does not absorb them.

#Problem

Without this pattern:

1. Role description and role value collapse. The description is treated as if it were the U.Role value.
2. Role description and assignment collapse. A role name or card is treated as proof that a holder has the role.
3. Role description and capability collapse. A role name is treated as evidence that the holder can do the work.
4. Role description and method collapse. Role invariants become a hidden procedure or method description.
5. Role description and performed work collapse. A role card is treated as evidence that work happened.
6. Status and evidence uses become roles. Epistemes, publications, standards, datasets, and claims are put into role language because they are used in project reasoning.
7. Relation positions become roles. Slot positions in signatures, interfaces, evidence relations, or status-use relations are called roles.
8. Cross-context labels overreach. The same role-like word in two contexts is treated as one role description without a bridge.

#Forces

#Solution

Constitute one role-description episteme through C.2.1: its exact ClaimGraph describes one U.Role, that role is the EntityOfConcern, and one effective U.ReferenceScheme governs interpretation. The ClaimGraph names the exact role-taxonomy episteme that supplies the role vocabulary. The description gives readers enough to recognize and check the role while routing neighboring claims to their direct patterns.

The following is a content checklist, not a relation signature or a mandatory record:

Always make recoverable:

• the described U.Role;
• the role-taxonomy episteme and effective reference scheme;
• a short recognition explanation;
• the independently admitted U.System holder kind and, when needed, a reference to its separately governed admission claim;
• the smallest role-invariant set needed by the current use;
• the non-role boundary: what this description does not assert about assignment, capability, method, work, evidence, status, permission, publication, or relation slots.

Add only when the current use depends on them:

• role-state predicate references under A.2.5;
• capability-condition references under A.2.2;
• method or method-description references under A.3.1, A.3.2, or A.15;
• durable-name or alias references under F.18;
• bridge references under F.9;
• a selected BoundedModelUseStructure designated by the receiving assertion or use when it changes that interpretation.

These are claims and neighboring references in an episteme. They are not SlotSpec declarations and do not add participants to U.RoleAssignment or another generic role relation. A card, table row, method appendix, or pattern section may publish the description; publication form and carrier remain separate from the episteme.

#Content Meanings

A quick local description can stop after the always-recoverable content. A consequence-bearing work-admission use opens only the neighboring relations it actually needs.

#Role Description vs Neighboring Values

Keep these distinctions:

F.4 may point to these patterns; it does not copy their ontology.

#Positive Construction Rule

Write a role description in this order:

1. Name the described U.Role, its role-taxonomy episteme, and effective reference scheme.
2. State the independently admitted holder kind eligible for role assignment.
3. Give one short recognition paragraph.
4. List the role invariants that make the role different from neighboring roles.
5. State the non-role boundary: what this description does not say about assignment, capability, method, work, evidence, status, permission, publication, or slot positions.
6. Add neighboring references only when the current use depends on them.
7. If the name is durable, public, or Core-facing, settle it through F.18; if role meanings must be compared across taxonomies or schemes, use F.9.

#Invariants

1. One described role. A role description describes exactly one U.Role value in the current application.
2. One interpreted role meaning. Name one role-taxonomy episteme and effective reference scheme; correspondence to another taxonomy or scheme needs F.9.
3. Description boundary. The role description is a U.Episteme; it is not the role value, assignment relation, holder, capability, method, work, or status-use relation.
4. Work-facing holder boundary. The holder participating in an obtaining role assignment is an independently admitted U.System; the assignment does not perform that admission. An episteme is not a role holder because it is used as evidence, source, standard, specification, definition, explanation, status bearer, publication, or assurance basis.
5. No hidden capability. Capability requirements may be referenced, but the role description does not prove capability.
6. No hidden method. Method requirements may be referenced, but the role description is not a method description.
7. No hidden work. A role description may enable work attribution checks, but it is not evidence that work occurred.
8. No status-template fusion. Status-use and evidence-use relations are direct relations, not a second branch of role description.
9. Slot discipline. If a source says "role" for a relation position, recover SlotKind, ValueKind, and RefKind through A.6.5.
10. Name after meaning. Durable naming follows F.18 only after the role value, role-taxonomy episteme, effective scheme, and local sense are recovered.

#Reasoning Primitives

Use these judgement schemas as thinking checks.

RoleDescription RD describes Role R under taxonomy episteme T and scheme S
  -> RD is a C.2.1 episteme about R, not R, T, or S themselves.

RoleDescription RD names independently admitted U.System holder kind HK for Role R
  -> A RoleAssignment may use a holder of HK only after that exact holder satisfies A.1 and the assignment's exact participants satisfy A.2.1; RD establishes neither.

RoleDescription RD lists capability requirement CapReq
  -> capability claim is governed by A.2.2, not by RD.

RoleDescription RD lists method requirement MReq
  -> method or method-description claim is governed by A.15, A.3.1, or A.3.2.

Source says "X has role Y" and X is an episteme
  -> recover direct episteme-use relation before considering U.Role.

#Worked Cases

#Pump Inspector Role

PumpInspectorRoleDescription is a C.2.1 episteme whose EntityOfConcern is PumpInspectorRole, whose effective scheme is Plant-A-Maintenance-Scheme, and whose ClaimGraph names PlantMaintenanceRoles-2026 as the governing role-taxonomy episteme. Its recognition explanation says that the role is used for inspecting pump condition before maintenance work is admitted. It names maintenance-technician, inspection-robot, or service-team U.System kinds as eligible holder kinds only when each exact system kind and any current holder entity are independently admitted; the description itself admits neither a system nor an assignment.

Its role invariants say that the role concerns pump-condition inspection, does not itself perform repair, and requires a current assignment before work attribution. It references pump-inspection capability conditions or the inspection method only when a receiving work claim needs them. Its non-role boundary states that an inspection report is an episteme used through direct evaluation, evidence, source, or publication relations, not a role holder.

The description makes PumpInspectorRole recognizable. It does not say that Robot-7 holds the role, can inspect, followed the method, or performed work. Those claims go to A.2.1, A.2.2, A.15, and the direct evaluation or evidence patterns.

#Reviewer Role and Review Report

ReviewerRole under PatternReviewRoles-2026 and Pattern-Review-Scheme may have a role-description episteme with invariants about checking a pattern against declared scales. A review report produced by a reviewer is an episteme used as evidence or source for a pattern-quality claim. The report is not the role holder and does not hold an evidence role.

Use:

• A.2 for ReviewerRole;
• F.4 for the role-description episteme;
• A.2.1 for Alice's exact ReviewerRole assignment under that taxonomy and scheme;
• A.15.1 for the review work occurrence;
• A.10, B.3, G.6, or a direct evidence-use pattern for the review report as evidence.

#Standard Used as a Specification or Source

The sentence Standard S has the architecture-standard role in this work is unsafe if it makes the standard episteme a role holder. Repair it by naming the direct relation: the exact edition of Standard S is used as a specification, external rule, premise, or source for named claims in the receiving work. Only an admitted U.System can hold a work-facing role. The standard may constrain or support a claim through its direct episteme-use relation.

#Access Role Is Not Automatically Work-Facing Role

RBAC role often names a permission grouping. If the current claim is permission or access standing, use the status, policy, or deontic governing pattern. Do not describe it as U.Role unless the role taxonomy and effective scheme explicitly introduce a work-facing role value and the holder, assignment, method, and work claims are current.

#Anti-Patterns and Repairs

#Consequences

Benefits.

• Role descriptions become short enough for practical use while preserving ontology.
• Part F naming and bridge patterns can rely on role descriptions without inheriting assignment, capability, method, work, evidence, or status claims.
• Episteme-use relations stay direct and do not become a parallel role ontology.
• Method and work checks can cite role descriptions without treating them as work evidence.

Costs.

• Former "role-or-status template" material must move to F.10, A.2.4, B.3, A.10, E.17, G.6, or direct use patterns.
• A stronger claim may require several neighboring patterns instead of one overloaded role card.
• Durable names require F.18 when the role name is public, Core-facing, or cross-context.

#SoTA-Echoing and Source-Use

Current best-known pressure for this problem is not a larger universal role taxonomy. It is explicit separation of local role value, assignment, attributes or capability, permission or policy standing, performed work, and evidence or status use. RBAC, ABAC, zero-trust authorization, safety independence practice, method engineering, and FPF slot discipline all push in that direction, while F.4 keeps only the role-description episteme and hands the neighboring claims to direct patterns.

Currentness and reopen condition: reopen this pattern when A.2, A.2.1, A.2.5, A.2.7, A.15, A.6.5, C.2.1, F.9, F.10, F.18, or the accepted episteme-use and status-use discipline changes enough that role-description, holder admission, or non-role-use boundaries would be stated differently.

#Relations

Builds on. A.2, A.2.1, A.6.5, A.7, C.2.1, E.10.D2, and E.24.

Coordinates with. A.2.2, A.2.5, A.2.7, A.15, A.15.1, A.15.2, F.9, F.10, F.14, F.15, F.18, evidence-use, status-use, source-use, publication-use, requirement-use, and assurance patterns.

Constrains.

• F.5 must name role descriptions after the described U.Role, role-taxonomy episteme, effective reference scheme, and local sense are recovered.
• F.8 must decide durable role-name minting or reuse without turning status-use or episteme-use relations into role descriptions.
• F.14 must treat bundles and separation-of-duties as role relation structure or neighboring role-description claims, not as hybrid role descriptions.
• F.15 must check role-description single-role and non-role-use boundaries.

#Conformance Checklist

#Phrasebook

Prefer:

• role-description episteme describing ReviewerRole under ReviewRoles-v5 and Review-Scheme-A;
• "holder-system admission is established under A.1 and E.24.UK; any actual ReviewerRole assignment is governed by A.2.1";
• "capability requirement referenced by the role description";
• "method requirement referenced by the role description";
• "review report used as evidence for the claim";
• "standard used as requirement source";
• "relation position governed by SlotSpec discipline".

Avoid as live vocabulary:

• "evidence role" for an episteme;
• "status role" for a badge or status-use relation;
• "standard role" for a standard used as source;
• "holder" for a publication, report, standard, dataset, or theorem unless the exact entity is independently admitted as a U.System and a current U.RoleAssignment names it as holder;
• "role" for a SlotKind;
• "role description" for a method, capability, work record, access policy, or status-use relation.

#Didactic Memory

A role description is the readable episteme that tells people what a role value means under one named role-taxonomy episteme and effective reference scheme. It helps someone assign, check, name, or compare the role. It does not assign the role, prove capability, define the method, perform the work, grant permission, carry evidence, publish itself, or turn every useful episteme into a role holder.

#F.4:End

#Naming Discipline for U-kind Names and RoleDescription Labels

Type: Definitional (D) Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Meaning-first naming discipline.

Use this pattern when a project needs a durable name for either:

• a U-kind or other cross-context concept already admitted through E.24.UK or its direct governing pattern; a Concept-Set row may cite comparison evidence but does not admit the value; or
• a label used by a role-description episteme for one work-facing U.Role interpreted under one named role-taxonomy episteme and effective U.ReferenceScheme.

Typical moments:

• a Concept-Set comparison has enough witnesses for a naming question and an E.24.UK or direct-pattern decision has already admitted the reusable value, but the candidate names import one source tradition too strongly;
• a role-description episteme names a role such as ReviewerRole, OperatorRole, InspectorRole, or TransformerRole, and the label must stay faithful to the exact role-taxonomy episteme and effective reference scheme without smuggling capability, permission, method, work, evidence, or status;
• a role-like external phrase must be named for local use, but the project has not yet decided whether it is a work-facing U.Role, a status-use relation, an access or policy term, a relation slot, or only a local phrase;
• two similar names threaten to make a U-kind, a U.Role, a status value, a method, and a work occurrence look like one object.

Primary EntityOfConcern. The EntityOfConcern is the naming discipline for these two name families. It governs the relation between a recovered meaning and its Tech and Plain labels. It does not define the named U-kind, does not define the described U.Role, does not assign a holder to a role, does not assert status, does not provide evidence, and does not make a publication form authoritative.

Primary working reader. The first reader is an engineer-manager, analyst, pattern author, or terminology steward who already has a candidate meaning and must choose a name that remains usable by readers without creating a second ontology.

First useful move. Before choosing the label, recover the exact named value and its direct source of meaning: E.24.UK or the direct governing pattern for a U-kind, with any Concept-Set row retained only as comparison evidence; or the role-description episteme, described U.Role, exact role-taxonomy episteme, effective reference scheme, and local sense for a role label. Then choose Tech and Plain labels whose morphology matches that kind and whose scope does not exceed the recovered meaning. Keep the selected label as a designator distinct from both the role value and its role-description episteme.

Smallest useful result and stop. Stop with one already-governed value, one Tech label, and a short Plain gloss as soon as the label resolves unambiguously for the named local use. Do not create a NameCard, public row, Bridge, or new kind merely to complete a naming form. Return to the direct subject owner when the value or kind is unresolved; open F.18 or F.17 only for a durable or public naming need, and open the F.9 bounded-use path only when an actual cross-scheme correspondence is consumed. If the proposed label starts carrying assignment, work, result, provenance, assurance, or publication claims, stop naming and recover those objects under their direct governors.

What goes wrong if missed. Names become arguments. A role label starts implying permission or capability. A status phrase becomes a role. A U-kind name imports one context's private ontology. A pretty global word hides that the Concept-Set witnesses do not agree. Downstream patterns then repair "semantics" that were actually broken at naming time.

What this buys. Readers can use short names without guessing the ontology. U-kind names stay neutral across their witnesses. RoleDescription labels remain interpretable through their named role-taxonomy episteme and effective reference scheme and point to work-facing roles. Status, evidence, access, requirement, source, publication, assurance, and gate names remain governed by their direct patterns instead of becoming "roles" by naming accident.

Not this pattern when.

• If the current problem is ordinary phrase repair rather than a durable name, use E.10, E.10.ARCH, A.6.P, or the direct governing pattern.
• If the current issue is whether a U.* spelling or structural name should survive as a durable U-kind, use E.24.UK before F.5.
• If the current issue is the broader local-first naming protocol, Name Cards, candidate fronts, lineage, or public naming governance, use F.18.
• If the current issue is a role-description episteme itself, use F.4.
• If the current issue is role assignment, holder, role-taxonomy episteme, effective reference scheme, assignment extent, or performed-work attribution, use A.2.1.
• If the current issue is status classification, use F.10 or the direct status-use pattern.
• If the current issue is evidence, source, standard, requirement, publication, assurance, gate, or decision use of an episteme, use the direct pattern for that relation.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.
• If cross-taxonomy or cross-scheme correspondence is current, use F.9.

#Problem Frame

FPF needs names that humans can use without dragging the wrong ontology behind them. A good name is short enough to be used in documents and conversations, but it is not free-floating. It belongs to a recovered meaning.

This pattern keeps two recurrent naming families separate.

First, a U-kind or similar cross-context concept gets its name only after E.24.UK or its direct governing pattern admits the exact value. A Concept-Set row may preserve witness comparison and evidence for that decision; it neither admits nor identifies the value. The name should be neutral with respect to the witnesses and should name the least shared kind that the direct admission source actually admits.

Second, a role-description episteme labels one work-facing U.Role interpreted through one exact role-taxonomy episteme and effective U.ReferenceScheme. The label should fit the admitted role meaning and make the role recognizable. It should not make a holder assignment, capability, method, work occurrence, status, evidence relation, permission, publication, or relation slot look like part of the role value.

The tempting shortcut is to make "Role Description" cover both roles and statuses because both need labels. That is convenient wording, but it creates duplicate ontology. Statuses and evidence uses need names too; they do not become roles because they are named.

#Problem

Without this pattern:

1. Context-local terms look global. A name such as Observation, Activity, or Process is promoted to a U-kind name even though it carries one witness tradition's private commitments.
2. Role names become hidden assignments. A label such as ReviewerRole is treated as if someone already holds the role.
3. Role names become capability claims. A holder is assumed able because the role label sounds competent.
4. Role names become methods. A noun label hides a method or method family.
5. Status names become roles. Approved, AccessRole, ModelFitEvidenceRole, or RequirementRole becomes a role-name family instead of a status-use, evidence-use, access-policy, requirement-use, or source-use relation.
6. Relation positions become roles. Signature, relation, or argument-position names borrow role morphology and collide with U.Role; interface wording is used only when a governing boundary or interface pattern makes that meaning current.
7. Names carry interpretation metadata. Labels such as Task-IEC61131 or Participant-BPMN fossilize an edition, source vocabulary, taxonomy, or scheme inside the label instead of keeping those facts in the governing admission, Concept-Set, role description, reference scheme, or Name Card.
8. Aliases become silent renames. Several labels circulate for one meaning without lineage or bridge discipline.

#Forces

#Solution

Name after meaning. For each candidate name, first recover the named value, its meaning source, and its intended use. Then choose labels that preserve that meaning.

For each naming decision, make the following facts recoverable in the prose, governing admission, role-description episteme, Concept-Set row, or Name Card. This is a naming checklist, not a new relation signature or mandatory record:

• the exact named value and its admitted kind;
• the direct source of its meaning;
• for a role label, the described U.Role, exact role-taxonomy episteme, and effective U.ReferenceScheme;
• the selected Tech label and its Plain teaching gloss;
• any aliases or previous labels with lineage;
• the morphology, neutrality, and minimal-generality checks;
• the neighboring-use boundary that prevents the name from absorbing assignment, capability, method, work, status, evidence, permission, publication, or relation-slot claims.

#Name Families Governed Here

For every role-facing name, keep three objects distinct: the selected label or designator L, the described U.Role value R, and the F.4 role-description episteme RD. Under the effective U.ReferenceScheme, L designates R; under C.2.1, RD has R as its exact EntityOfConcern and names the governing role-taxonomy episteme in its ClaimGraph. Spelling, a Role suffix, a NameCard, a public row, or a source citation creates none of L's governed referent, R, RD, a role assignment, dated work, a result or claim-bearing episteme, provenance, or publication occurrence.

#Tech and Plain Labels

Use two human-facing labels when the name is durable enough to be reused:

For a role-description label, the Tech label may be an agentive noun, local role term, or role phrase such as ReviewerRole, PumpInspectorRole, Participant, or Approver. The suffix Role is a disambiguator, not a universal law. Use it when it prevents confusion with a status, method, work occurrence, organization unit, publication, or access-policy term. Do not add it merely to make the name look formal.

For a coupled role-method label, recover the role expression and the method value or work value separately before naming. RoboticsEngineerRole may be a durable Tech label for a robotics-qualified engineering role value. RobotEngineeringMethod names a method or method family. The ordinary label "engineer-roboticist" can be useful when the role taxonomy, effective scheme, and method relation make the coupled meaning recoverable, but it must not replace the method description or work description.

For a U-kind, the Tech label should be neutral enough that no witness context wins by vocabulary alone. If witnesses disagree between Observation, Reading, and MeasurementResult, a Concept-Set row can preserve that comparison, but the selected head is admissible only when E.24.UK or the direct governing pattern has already admitted the exact shared value and invariants. The row, a source title, or the selected spelling does not perform admission.

#Positive Naming Rules

Use these rules when choosing or checking a name.

1. Recover kind first. State whether the named value is a U-kind, U.Role, role-description episteme, role-relation expression, method, work, status-use value, evidence-use relation, relation slot, lens description, or another named kind.
2. Recover meaning source. Use the exact E.24.UK or direct-pattern admission for a U-kind, retaining any Concept-Set row only as witness-comparison evidence; use the role-description episteme, described U.Role, exact role-taxonomy episteme, and effective reference scheme for role labels; use A.2.7 for role-relation expressions; use A.3.1, A.3.2, A.15, G.5, or a direct method-composition pattern for method, method-family, method relation structure, or work names; use the direct governing pattern for statuses, evidence, source, requirement, publication, assurance, gate, decision, and relation slots.
3. Use minimal generality. The name's scope stays no wider than the admitted invariants.
4. Keep interpretation metadata out of the label string. Edition, source, witness, role taxonomy, and effective reference scheme belong in their governing admission, Concept-Set row, role-description episteme, reference-scheme relation, or Name Card, not inside the main label.
5. Make morphology kind-sensitive. Agentive role names fit work-facing roles. State or level forms fit statuses. Verbal or gerund forms fit methods only when the method pattern admits them. Slot names should say Slot, Argument, Endpoint, or another declared slot or position head when current.
6. Keep coupled role-method names typed. A phrase like "engineer-roboticist" may be the ordinary label for a qualified role expression; "robot engineering" may be a method or work name. Do not make one label carry holder assignment, role value, method, work, and capability at once.
7. Do not encode thresholds or windows in the name. Put time, state, threshold, capability envelope, or admission window in the governing pattern.
8. Use aliases only with lineage. A source term, previous term, symbol, or translation can be an alias; it does not create a second Tech label.
9. Escalate when reuse becomes public or cross-scheme. Use F.18 and F.17 for durable or public naming. When an actual cross-taxonomy or cross-scheme correspondence is consumed, first name the exact obtaining F.9 Bridge occurrence, then keep the separate current C.2.1 claim that it is suitable for the named bounded use. Reliance follows F.9's two branches. Ordinary below-threshold use with no assurance claim requires the exact A.10 evidence-provenance graph relation and RelianceDisposition=pass for that same use. When an assurance claim is made or B.3's material-reliance threshold is met, enter B.3 and first decide whether a current assurance claim exists; positive reliance requires a positive current assurance claim carrying the same bounded assurance use with its sufficient minimum reliance safety assurance record, while an exact no-assurance-claim, insufficient-record, narrowed, rejected, withdrawn, abstaining, or blocked disposition stops or narrows the use. A Bridge, profile, NameCard, row, label, evidence path, assurance record, or publication neither authorizes the use nor establishes assignment, work, result, provenance, assurance, or publication occurrence.

#Neighboring Use Boundary

When a label contains a tempting word, recover the current claim instead of replacing words mechanically.

Select the name only after this recovery. A cleaner string is not a repair if it hides the same kind error.

#Archetypal Grounding

#Cross-Context Type Name

A Concept-Set row compares SOSA Observation, metrology measurement result, ML practice metric reading, and a dashboard value exported for later comparison. The row is a comparison and evidence surface, not the admission or identity of a common result value.

Keep its concrete exemplars under their direct owners. Work_MeasurePump14_2026-07-14T10-42Z is one exact dated measurement U.Work occurrence under A.15.1. Pump14PressureReading_2026-07-14T10-42Z is the separately constituted domain-local measurement-result episteme under C.16 and C.2.1. Pump14CalibrationTrace_2026-07-14 is the exact provenance record whose G.6 and A.10 relations make the calibration and source path recoverable. A dashboard publication may cite the reading, and the Concept-Set row may cite all three objects; neither publication nor row is the Work occurrence, result episteme, provenance record, or a generic relation that establishes them.

The row therefore justifies neither Observation nor DashboardValue as a U-kind name. Only an exact E.24.UK or direct-pattern admission can establish a shared value and its invariants. After that admission, F.5 may select Reading, Result, or another neutral head no wider than that exact governed value; the selected spelling still creates no result or provenance identity.

#Work-Facing Role Label

Under Plant-A-Maintenance-Scheme, label PumpInspectorRole designates the exact role value PumpInspectorRole; it is not that value. PumpInspectorRoleDescription-v3 is a separate C.2.1 episteme whose exact EntityOfConcern is that role value and whose ClaimGraph names PlantMaintenanceRoles-2026 as the governing role-taxonomy episteme. The Tech label is PumpInspectorRole; the Plain label is pump inspector role.

Robot7-PumpInspector-Assignment-2026Q3 is the separate A.2.1 role-assignment occurrence. Work_InspectPump14_2026-07-14T11-05Z is the exact dated inspection U.Work under A.15.1. Pump14InspectionFinding_2026-07-14T11-18Z is the separately constituted domain-local claim-bearing result episteme under its inspection-result governor and C.2.1. Pump14InspectionTrace_2026-07-14 is the exact provenance record connected through its G.6 and A.10 relations. Any current method enactment, production or inception claim, and evidence use remains under its direct owner.

The role label helps readers recover the role; the role-description episteme describes it. Neither says Robot-7 holds the role, performs the inspection, produces the finding, or supplies its provenance. A Role suffix, NameCard, row, pattern section, or source citation identifies none of the assignment, dated Work, result episteme, provenance record, or their direct relations.

#Evidence Use Is Not a Role Name

Source text may say ModelFitEvidenceRole. The repair is not to invent a prettier role name. Recover the exact objects: Work_EvaluateModelFit_2026-07-15T09-00Z is the dated evaluation U.Work; ModelFitResult_2026-07-15T09-22Z is a separately constituted domain-local result episteme; ModelFitTargetClaim-v5 is the exact claim for which that result may be used; and ModelFitRunTrace_2026-07-15 is the provenance record connected through exact G.6 and A.10 relations. The actual operation-result binding, any result-episteme inception claim, evidence use, provenance, and assurance remain distinct under their direct governors.

A durable name, if needed, names an already recovered evidence-use relation, local status-use value, work occurrence, result episteme, or provenance value under that object's direct pattern. ModelFitEvidenceRole, a NameCard, a row, or a source citation creates none of those objects and supplies no generic evidence/result relation. It is not a work-facing U.Role and not a role-description label.

#Relation Position Is Not a Role Name

In a relation signature, "provider role" may mean "the provider argument position". F.5 does not make ProviderRole a U.Role name. Use A.6.5 to recover ProviderSlot, its admitted ValueKind, and its reference mode. If a provider system also has a work-facing role in a method, that is a separate U.Role claim and, when assigned, a separate U.RoleAssignment claim.

#Bias-Annotation

This pattern protects against four naming biases.

1. Semio-bias. A name, card, table row, publication, or source label is mistaken for the named value or for authority to use it.
2. Role-bias. Useful relation words such as evidence, status, access, source, requirement, or argument position are put into Role language because role words sound familiar.
3. Source-vocabulary capture. One source context's term becomes the FPF Tech label without proving cross-context fit.
4. Suffix formalism. Adding Role, Status, Record, Graph, or Map makes a label look precise while leaving the kind unresolved.

The repair is always kind recovery first, label second.

#Conformance Checklist

Use this checklist on each durable name governed by F.5.

#Common Anti-Patterns and How to Avoid Them

#Consequences

Good consequences:

• durable names become shorter because the ontology is carried by the right pattern, not by compound labels;

• role-description labels stay usable without becoming assignment, capability, method, or evidence claims;

• U-kind names become easier to bridge because their Concept-Set row is explicit;

• E.10 repair cases that uncover durable naming issues use the direct F.5 or F.18 naming discipline instead of inventing ad hoc word replacements.

Costs:

• authors must recover kind and meaning source before naming;
• some familiar source labels cannot be promoted as FPF Tech labels;
• public or cross-context names may require F.18, F.17, and F.9 even when the local name looks obvious;
• source text that used Role for status, evidence, access, or relation position must be repaired by ontology, not by suffix editing.

Reopen F.5 when role-description label morphology, U-kind neutrality rules, Tech and Plain label relation, alias lineage, or cross-context naming boundaries change. Reopen neighboring patterns when the dispute is about the named object itself.

#Rationale

Naming is late ontology, not early decoration. FPF can tolerate many local phrases, but durable names become references used in reasoning, search, publications, and pattern relations. If a name is wrong, subsequent users inherit a false kind claim.

The key design choice is to split naming by meaning source rather than by source spelling. Role in a source phrase may refer to a work-facing role, a policy term, a status label, an evidence-use relation, a relation position, or ordinary English. F.5 does not decide by suffix. It recovers the current value and then applies naming discipline.

This also keeps F.5 smaller than F.18. F.18 governs the fuller local-first naming protocol, Name Cards, candidate fronts, lineage, and public naming. F.5 supplies the special discipline needed by U-kind names and RoleDescription labels so that Part F does not preserve role and status fusion.

#SoTA-Echoing - Source-Use

Source-use boundary: external labels, Concept-Set rows, and source citations are evidence for local meaning or common practice, not automatic FPF Tech labels, admission decisions, or work/result/provenance identities. A source term becomes the selected label only after E.24.UK or the direct governing pattern admits the exact value, or after F.4 constitutes the exact role-description episteme about an already governed role value; naming changes none of those objects.

#Relations

Builds on. A.2, F.4, F.7, F.18, E.10, and E.10.ARCH.

Coordinates with. E.24.UK for U-kind admission and structural U.* repair; A.2.1 for role assignment; A.2.2 for capability; A.2.5 for role state; A.2.7 for role relation structure and role-algebra lens use; A.6.5 for relation-slot names; A.15 and A.15.1 for role-method-work alignment and dated work; C.2.1 and direct result patterns for claim-bearing and result epistemes; G.6 and A.10 for provenance and ordinary evidence reliance; B.3 for assurance-bearing reliance; F.8 for mint-or-reuse; F.9 for exact cross-taxonomy and cross-scheme Bridge occurrences; F.10 for status mapping; F.13 for aliases and continuity; F.14 for anti-explosion; F.15 for harness checks; F.17 for public term-sheet use.

Used by. Part F unification patterns, role-description authors, Concept-Set authors, E.10 repairs that uncover naming rather than only phrase-use issues, and any FPF pattern that creates a durable local name for a U-kind or work-facing role label.

Does not replace. Direct evidence-use, status-use, requirement-use, source-use, publication-use, assurance, gate, decision, relation-signature, method, work, or architecture patterns.

#F.5:End

#RoleAssignment and Performed-Work Attribution Check

Type: Boundary and use pattern Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Check who performed this work under which role assignment.

Use this pattern when deciding whether one exact dated Work individual W : U.Work was performed under one exact obtaining assignment occurrence RA : U.RoleAssignment. When it was, the direct world-side relation performedUnderAssignment(W, RA) obtains. A separate attribution assertion or record may designate W and RA and state that the relation obtains.

Typical moments include:

• a work record says "Alice reviewed", "Robot-7 inspected", or "the operations team approved", but the exact assignment episode is missing;
• a method description names a work-facing role and the project must connect performed work to the system that held that role;
• source wording says RoleEnactment, "played the role", or Holder#Role:Context@Window, and the direct work-to-assignment relation must be recovered;
• a report, standard, dashboard, access label, or other episteme is described with role language even though it did not perform the work;
• a role label is reused under another role taxonomy or reference scheme and local attribution would be unsafe without an explicit bridge.

Primary EntityOfConcern. One obtaining direct performedUnderAssignment relation occurrence between one exact U.Work occurrence and one exact U.RoleAssignment occurrence.

Primary working reader. An engineer, operator, method author, manager, or FPF author deciding whether a performed-work attribution is grounded strongly enough for the next use.

First useful move. Name the Work occurrence and the assignment occurrence that may participate in the attribution relation. Recover the assignment's holder system, role value, role-taxonomy episteme, effective reference scheme, and assignment window before deciding whether performedUnderAssignment(W, RA) obtains.

What goes wrong if missed. Assignment is treated as proof that work happened; a work log names a person but not the assignment episode; a context-like word hides the role taxonomy and interpretation scheme; or an episteme is made the performer because it described, constrained, or evidenced the work.

What this buys. Work attribution becomes a direct, inspectable relation: the admitted holder system remains the actor, the dated Work separately enacts one exact U.Method, and role value, assignment, capability, method, method description, evidence, source use, result, publication, and cross-scheme correspondence remain with their own governing patterns.

Not this pattern when. Use A.2 for the role value, A.2.1 for the assignment occurrence, A.2.5 for a current role-state predicate, A.2.2 for capability, and A.15.1 for the work occurrence. Use A.10, A.15.4, E.17, or another direct pattern when the current claim is evidence use, source reliance, publication, status, gate, or decision. Use A.6.5 when "role" means a relation position rather than a work-facing U.Role.

#Problem Frame

U.RoleAssignment admits assignment-relation occurrences; U.Work admits Work individuals. One exact RA : U.RoleAssignment is a world-side assignment-relation occurrence that relates an admitted holder System to one role value, one role-taxonomy episteme, and one effective reference scheme and obtains throughout one assignment episode. One exact W : U.Work is a dated world-side Work occurrence. The existence of RA and W does not by itself establish the additional world-side attribution between them: performedUnderAssignment(W, RA) must separately obtain. A distinct assertion or record may designate RA and W, state that RA obtains, state that W occurred, or state that the attribution relation obtains.

F.6 governs the missing direct relation. The assignment is one participant and the work occurrence is the other. A roster row may assert the assignment; a work log may assert the work and attribution; evidence may support either assertion. Those epistemes help a system know or use the relation, but they do not become relation participants and do not make the world-side relation obtain merely by being recorded.

This separation matters because assignment, state, ability, performance, evidence, and acceptance can vary independently. A system can hold a role and do no work. It can perform poor work under a valid assignment. A report can accurately describe the work without performing it. One compact "enactment" label hides these distinctions.

#Problem

Without the direct attribution relation, recurring engineering failures appear:

1. Assignment-as-work. Current role holding is treated as evidence that the assigned system performed a particular occurrence.
2. Performer by label. A name such as Reviewer or Operator is used without the assignment episode that fixes holder, role interpretation, and time.
3. Assignment-episode mismatch. The assignment interval does not cover the work interval, yet attribution is accepted.
4. Support-as-constitution. A log, report, standard, dashboard, or decision is treated as what makes the attribution obtain rather than as an assertion or support relation.
5. Duplicate enactment ontology. RoleEnactment or RoleEnactmentFact becomes a second object beside the dated work and its direct performedUnderAssignment relation.
6. Hidden locality. A generic context field replaces the role-taxonomy episteme, effective reference scheme, assignment window, or an independently selected model-use structure.

#Forces

#Solution

Govern performed-work attribution as one direct relation species under U.Relation.

#Direct Relation Declaration

performedUnderAssignment : U.Relation
  WorkOccurrenceSlot: U.Work, U.EntityRef
  RoleAssignmentSlot: U.RoleAssignment, U.EntityRef

when performedUnderAssignment(W, RA) obtains:
  actualPerformerSystem(W, RA) := RA.HolderSystemSlot

WorkOccurrenceSlot names the dated performed occurrence governed by [A.15.1](/generated/patterns/A.15.1). RoleAssignmentSlot names the obtaining assignment occurrence governed by [A.2.1](/generated/patterns/A.2.1).

For an obtaining attribution, the readable actual-performer cue is S = actualPerformerSystem(W, RA) = RA.HolderSystemSlot: S is the admitted U.System that acts, while RA is the assignment under which that action is attributed. The projection exposes the actor already carried by the assignment participant; it does not assert attribution when the relation fails to obtain and is not another relation kind or occurrence.

performedBy(W, RA) is a deprecated compatibility spelling of performedUnderAssignment(W, RA). Existing claims or records may be read through that alias only after resolving S = RA.HolderSystemSlot. New practitioner-facing claims, examples, and conformance statements MUST use S performed W under RA or performedUnderAssignment(W, RA), never wording that makes RA the performer.

No evidence, log, status, method description, result, publication, context record, or role-state assertion is a generic participant in this relation.

performedUnderAssignment also has no method participant. Because W is an admitted Work occurrence, an assertion or description about it must separately make recoverable the actual enactsMethod(W, M) relation governed by [A.15.1](/generated/patterns/A.15.1), for one exact M : U.Method. The holder system acts and performs W; neither RA, its role value, a capability or algorithm-possession phrase, M, nor a method-description episteme D thereby acts or performs the work. Citing D may identify, constrain, or justify M for a receiving use, but it neither enacts D nor establishes that D : U.MethodDescription; apply [A.3.2](/generated/patterns/A.3.2) to that membership question independently.

#Obtaining and Occurrence Identity

The relation performedUnderAssignment(W, RA) obtains when:

1. W is one exact dated U.Work occurrence governed by A.15.1;
2. RA is one obtaining U.RoleAssignment occurrence;
3. the holder system in RA.HolderSystemSlot actually performed W under RA.RoleValueSlot;
4. the assignment predicate for RA obtains throughout the temporal extent of W.

If the performer attribution concerns only a temporal, episode, or operational part of a larger work whole, first identify that part as the U.Work occurrence under A.15.1 and use it in WorkOccurrenceSlot. Do not hide an unidentified work portion inside the attribution relation.

When a receiving use needs an explicit relation-occurrence reference, use:

PerformedUnderAssignmentOccurrenceKey = <WorkOccurrenceSlot, RoleAssignmentSlot>

The temporal extent is inherited from WorkOccurrenceSlot. Extending an open work interval or later recording its end does not create another attribution occurrence while both participants remain the same. A separately identified work occurrence, including a separately identified work part, or a different assignment episode yields a different relation occurrence.

An evidence gap leaves a relied-on attribution assertion unresolved. It does not demonstrate that performedUnderAssignment failed to obtain. A demonstrated different performer or non-covering assignment episode can support the stronger negative claim.

#Recover the Exact Assignment

Before relying on the attribution, recover the four direct participants of the exact assignment occurrence RA that fills RoleAssignmentSlot:

RoleAssignmentRelationSignature:
  HolderSystemSlot: U.System, U.EntityRef
  RoleValueSlot: U.Role, ByValue
  RoleTaxonomyEpistemeSlot: U.Episteme, U.EpistemeRef
  EffectiveReferenceSchemeSlot: U.ReferenceScheme, ByValue

One assignment occurrence is the maximal continuous period during which the assignment predicate obtains for those fixed four participants. A supporting assertion or occurrence description may state assignmentInterval, including an open end, but that field is not a participant and does not establish temporal coverage. Verify coverage for performedUnderAssignment from the actual obtaining history of the exact assignment occurrence and the exact work extent.

Do not replace these participants with one Context value. If source notation contains Context, recover what that token denotes and send it to its direct pattern. It may denote an actual system or work locus, a claim scope, or an independently selected BoundedModelUseStructure; those objects have different kinds and relations. A selected model-use structure can qualify the receiving attribution assertion, but it is not an optional participant of generic U.RoleAssignment.

#Attribution Check Sequence

Use this short sequence for the current attribution claim:

1. Name the exact U.Work occurrence whose performer is being asserted.
2. Name or recover the exact U.RoleAssignment occurrence through its four fixed participants and uninterrupted obtaining extent.
3. Check that the holder system named by the assignment is the system claimed to have performed the work.
4. Check that the assignment episode covers the attributed work interval.
5. State the direct performedUnderAssignment(WorkOccurrenceSlot, RoleAssignmentSlot) relation, or keep the attribution assertion unresolved when support is insufficient.
6. Send role state, capability, method fit, evidence, source use, result, acceptance, publication, and bridge questions to their direct governing patterns.

The sequence is application guidance, not a new check record, work plan, or workflow object. Its useful result is the repaired direct relation or an explicit stop at the missing relation participant or support claim.

#Direct Neighboring Relations

#Source Shorthand and RoleEnactment

Holder#Role:Context@Window is readable source notation only. Before reliance-bearing use, recover the assignment's holder system, role value, role-taxonomy episteme, effective reference scheme, and assignment window. Recover the object denoted by Context separately.

When source wording says RoleEnactment or RoleEnactmentFact, recover the dated U.Work occurrence and the direct performedUnderAssignment relation. Do not retain a second enactment kind, fact object, or relation occurrence.

#Lightweight Use

Ordinary use can stop at a readable assertion:

InspectionWork-17 was performed by Robot-7 under RoleAssignment-17.

Expose the relation declaration and occurrence key only when a receiving use must distinguish attribution occurrences, cite one as a participant, compare assertions, or preserve provenance. If the assignment cannot be recovered, lower the claim to "Robot-7 is named as performer in record R" and route that reliance through [A.15.4](/generated/patterns/A.15.4) or the direct source and evidence patterns.

#Invariants

1. Every performed-work attribution relates one exact U.Work occurrence to one exact U.RoleAssignment occurrence.
2. The assignment occurrence RA in RoleAssignmentSlot keeps exactly four fixed participants and one maximal continuous obtaining extent; no mandatory U.BoundedContext, generic context slot, or optional model-use participant is added.
3. The actual maximal continuous extent of the assignment occurrence covers the attributed portion of the work interval; a declared or recorded window alone does not establish coverage.
4. Assignment does not prove performance, and performance attribution does not prove capability, state, method validity, result quality, or acceptance.
5. RoleEnactment wording is repaired to dated work plus direct performedUnderAssignment; no duplicate enactment object is retained.
6. Assertions, logs, rosters, evidence, identifiers, and publications remain epistemic or representational objects distinct from world-side relation obtaining.
7. An evidence gap yields unresolved reliance, not an inferred non-attribution interval.
8. An episteme does not fill HolderSystemSlot merely because it describes, constrains, or supports the work claim.
9. Cross-scheme role correspondence uses a direct bridge relation and does not change either assignment identity.
10. Reduced prose remains admissible until a receiving use needs explicit relation-occurrence identity.
11. For admitted Work W, actual enactsMethod(W, M) remains a separately obtaining relation to one exact U.Method; only the admitted holder system acts, while assignment, role value, capability, method, and method description do not perform the work.

#Reasoning Primitives

RA : U.RoleAssignment is one exact obtaining assignment-relation occurrence
  and W : U.Work is one exact dated Work occurrence
  and RA.HolderSystemSlot actually performs W under RA.RoleValueSlot
  and the assignment predicate for RA obtains throughout the attributed work interval
  -> performedUnderAssignment(W, RA) obtains.

An attribution assertion lacks adequate current support
  -> reliance on the assertion is unresolved;
  -> do not infer that performedUnderAssignment(W, RA) is false.

A source episteme names a performer or role
  -> do not claim that performedUnderAssignment obtains until exact W and RA are recovered.

#Archetypal Grounding

#Robot Inspection

RoleAssignmentAssertion@RoleAssignment17:
  participantDesignations:
    HolderSystemSlot: Robot-7
    RoleValueSlot: InspectorRole
    RoleTaxonomyEpistemeSlot: MaintenanceRoles-2026
    EffectiveReferenceSchemeSlot: Maintenance-Scheme-A
  assignmentInterval: [2026-07-13T09:00, 2026-07-13T17:00]

performedUnderAssignment:
  WorkOccurrenceSlot: InspectionWork-17
  RoleAssignmentSlot: RoleAssignment-17

The assertion interval describes the known extent of RoleAssignment-17; the direct assignment predicate must actually obtain throughout InspectionWork-17 before performedUnderAssignment obtains. The relation attributes the inspection occurrence to Robot-7 under that assignment. Separately, enactsMethod(InspectionWork-17, TurbineInspection@Maintenance-2026) names the exact enacted method, while TurbineInspectionProcedure-v3 may be cited as a distinct description episteme only if the receiving use needs it. Robot-7 is the actor; InspectorRole, a sensor capability or statement that Robot-7 possesses an inspection algorithm, the method, and the procedure do not perform the inspection. Algorithm-possession wording alone establishes neither the work attribution nor TurbineInspectionProcedure-v3 : U.MethodDescription. Calibration state, inspection-method adequacy, report quality, and acceptance remain separate claims.

#Reviewer and Review Report

Engineer Alice is identified as the exact holder and satisfies the A.1 U.System criterion. ReviewAssignment-82 assigns her ReviewerRole under ReviewRoles-v5 and Review-Scheme-A for one uninterrupted review assignment episode. ReviewWork-82 performedUnderAssignment ReviewAssignment-82 attributes the dated work.

ReviewReport-82 is a separately identified U.Episteme. When ReviewWork-82 first constitutes that exact episteme and the inception claim matters, A.15.PROD recovers the local work/change/identity claim. A later evidence relation may use the report for a decision. The report never fills HolderSystemSlot and never becomes the attribution relation.

#Standard Used During Safety Work

A safety method description cites a standard, and source prose says that the standard has a "normative role". F.6 does not create a work-facing assignment for the standard. The standard is an episteme used through the exact external-rule, source-use, specification-use, or evidence relation selected by the claim.

A safety engineer or tool system may separately hold SafetyAnalystRole and perform dated safety work. That attribution names the engineer's or tool system's assignment; it does not use the standard as performer.

#Access Label and Approval Work

An access directory says Alice has DB-Admin. That entry describes an access or policy relation under its own scheme. It is not automatically a work-facing ApproverRole assignment.

If Alice performs ApprovalWork-481, recover a separate U.RoleAssignment under the role taxonomy used by the approval method and relate the work through performedUnderAssignment. The directory entry may support authorization or gate reasoning through its direct pattern; it does not substitute for the work assignment.

#Bias Annotation

#Conformance Checklist

1. WorkOccurrenceSlot names one admitted dated U.Work occurrence.
2. RoleAssignmentSlot names one obtaining U.RoleAssignment occurrence.
3. The assignment exposes holder system, role value, role-taxonomy episteme, and effective reference scheme as participants; its maximal continuous assignment extent is checked separately.
4. The assignment holder is the system claimed to have performed the work.
5. The assignment episode covers the selected work occurrence's interval; attribution to only one part first selects that part as U.Work.
6. The attribution uses direct performedUnderAssignment wording and introduces no RoleEnactmentFact.
7. Role state, capability, method, result, evidence, source reliance, publication, gate, and decision claims use their direct patterns.
8. Any selected model-use structure is designated by the receiving attribution assertion or use, not by an optional slot in generic U.RoleAssignment.
9. Missing evidence leaves the relied-on assertion unresolved rather than proving non-attribution.
10. Compact source notation is unfolded before a receiving use depends on hidden assignment positions.
11. The work assertion makes a separately obtaining actual enactsMethod(W, M) relation to one exact U.Method recoverable; it does not make the role value, assignment, capability, method, or method description the actor, and it does not infer U.MethodDescription membership from a label or algorithm-possession phrase.

#Common Anti-Patterns and Repairs

#Consequences

Benefits. Assignment and performed work remain independently identifiable, while attribution becomes a direct relation that can be cited, compared, supported, corrected, or left unresolved. The pattern works for people, organizations, machines, and software systems because the holder is always an admitted U.System, not a domain-specific performer category.

Costs. Reliance-bearing use must recover the exact assignment episode rather than stopping at a familiar role label. A compact source sentence may split into an assignment assertion, a work occurrence, the direct attribution relation, an exact change or production claim, an operation-result binding or result episteme, and any evidence relation current for the use.

Limits. F.6 does not determine capability, readiness, method validity, work success, result acceptance, authorization, or evidence sufficiency. It only governs the relation by which one performed work occurrence is attributed to one role assignment.

#Rationale

The direct relation is needed because U.RoleAssignment and U.Work admit different kinds of world-side occurrence. One obtaining assignment occurrence RA relates its holder System to a role value under one interpretation and throughout one episode; one Work individual W : U.Work is the dated Work occurrence. performedUnderAssignment(W, RA) either obtains or does not obtain as the additional world-side attribution between them. A distinct assertion or record may designate RA and W, state that RA obtains, state that W occurred, or state that the attribution relation obtains.

Making a log, status, decision, or evidence item a relation participant would confuse world-side attribution with knowledge of attribution. Creating RoleEnactmentFact would duplicate the same pair under a second identity. The two-participant relation preserves realism and keeps correction local: changing an evidence use does not rewrite work or assignment; discovering a different performer changes the attribution assertion and, when demonstrated, the selected relation occurrence.

#SoTA-Echoing and Source Use

These lines discipline the examples rather than supply a foreign ontology. FPF takes the useful separation pressure and retains its own constructive relation, work, role-assignment, episteme, and evidence distinctions.

#Relations

Builds on: A.6.REL for relation obtaining and occurrence identity; A.2 for U.Role; A.2.1 for U.RoleAssignment; and A.15.1 for dated U.Work.

Uses when current: A.2.5 for role state; A.2.2 for capability; A.3.1, A.3.2, and A.15 for method and work alignment; A.10 for evidence; A.15.4 for reliance on encountered project material; F.9 for cross-scheme correspondence; and A.1.1 only when an independently selected model-use structure changes assignment interpretation.

Coordinates with: F.4 for role-description epistemes; F.5 and F.18 for durable names; E.17 for publication; and E.10 for source-word precision repair.

#Completion Conditions

F.6 use is complete when the reader has either:

• one direct performedUnderAssignment relation between an exact work occurrence and an exact assignment occurrence;
• an unresolved attribution assertion with the missing assignment, interval, or support relation named;
• or a corrected exit to the direct pattern because the encountered claim concerns assignment, state, capability, method, evidence, source reliance, result, publication, gate, or decision rather than performed-work attribution.

#F.6:End

#Concept‑Set Table

“Show one thing across Contexts—only where explicit bridges allow it.”

Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for ‘Context’ (Context ≡ U.BoundedContext); F.0.1 senseFamily (normative); F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting; F.3 Intra‑Context Sense Clustering (SenseCells); F.5 Naming Discipline; F.9 Alignment & Bridge Across Contexts. Coordinates with. F.4 Role Description; F.6 Role Assignment & Enactment Cycle (Six-Step); Part C patterns (for examples), MM‑CHR (for Characteristic); A.6.9 (RPR‑XCTX for repairing umbrella cross‑Context sameness/alignment prose before it justifies rows). Aliases (informative). Concept‑Set table, comparison grid.

#Intent & applicability

Intent. Provide a single, didactic page where each row presents one Concept‑Set—a set of SenseCells from different Contexts that we are licensed (by explicit Bridges) to treat as “the same for a stated scope”. Columns are Contexts; cells carry local labels. The table does not invent equivalences: it summarises already declared F.9 Bridges, exposing scope, losses, and counter‑examples at a glance.

Applicability. Use whenever cross-context reading is necessary (naming admitted U-kinds, roles, methods, characteristic terms, teaching contrasts, assignment/enactment-adjacent terminology). It is a reading lens, not a data model: notation-free, governance-free, Context-loyal.

Non‑goals. No hidden merges. No “global terms”. No workflows or tool schemas. The table is a conceptual display of licensed sameness and honest non‑sameness.

#Problem frame

Without a disciplined Cross‑context view:

1. Silent equivalence. Readers assume sameness by name alone (e.g., process).
2. Loss denial. Mappings hide what is dropped (DesignRunTag, units, agency).
3. Name inflation. Convenience root kind labels are coined to avoid facing heterogeneity.
4. Cognitive scatter. Concepts drift across documents without one compact, teachable “where‑what‑how‑same” view.

#Forces

#Core idea (didactic)

A Concept‑Set is a finite set of addresses

$$ \text{CS}={\langle \text{Context}_i,\ \text{SenseCell}i\rangle}{i=1..n} $$

that FPF treats as one for a declared scope because there exist F.9 Bridges connecting these SenseCells pairwise (directly or via a short chain) with congruence level $\text{CL}$ above a threshold suitable for that scope. The table row shows:

• FPF Label (Tech/Plain) — the didactic, FPF‑level name chosen per F.5.
• Row Scope — where “being one” is safe (e.g., Naming-only, assignment/enactment-eligibility, KD-CAL metric, Type‑structure).
• Row CL(min) — the minimum CL of the Bridges that justify the row.
• Context columns — each cell: the local label + (optional) short cue.
• Rationale (one line) — why sameness is warranted for this scope.
• Counter‑examples (one line) — where/why sameness breaks.

Memory hook. A Concept‑Set row is a promise: “You may read across these Contexts this far—and no farther.”

#Minimal vocabulary (this pattern only)

• Context — shorthand for U.BoundedContext (per E.10.D1).
• senseFamily — referenced from F.0.1; not redefined here; used to type rows and to require uniformity within a row.
• SenseCell — a (Context × Local‑Sense) address from F.3.
• Bridge (F.9) — an explicit, declarative Cross‑context mapping with a congruence level CL and loss note.
• Characteristic (MM‑CHR) — measurable comparandum defined in MM‑CHR; may be referenced in Measurement/KD‑metric rows; do not use “axis” only as a euphemism.
• Concept‑Set (row) — a licensed sameness across Contexts, bounded by Row Scope and Row CL(min).
• Contrast row — a non‑sameness row: same surface across Contexts with no sufficient Bridges; teaches difference, not unity.

#The table (conceptual layout)

One page. Fixed column order by Context. Each row fits in five lines max.

FPF Label (Tech / Plain) | Row Scope | Row CL(min) | [Context A] local label | [Context B] local label | [Context C] local label | Rationale | Counter‑examples

Reading rules (didactic):

1. Cells are local. A cell is not a translation; it is the Context’s own label for its SenseCell.
2. Scope is king. The FPF label only licenses sameness within its Row Scope. Outside that scope, treat cells as different.
3. Row CL(min) governs trust. Lower CL ⇒ narrower applicability; never up‑scope a row without revisiting Bridges.
4. Rationale & counter‑examples are obligatory one‑liners; if you need paragraphs, you need an F.9 walkthrough, not a row.

Didactic name rationale “Giants' table’” that alludes to standing on the shoulders of giants: each row explicitly leans on authoritative context of meaning (U.BoundedContext) established by prior disciplines and not imagined. It does not mean a physically large table; the name signals epistemic humility and traceable reliance on those sources. "We are like dwarfs on the shoulders of giants, so that we can see more than they, and things at a greater distance, not by virtue of any sharpness of sight on our part, or any physical distinction, but because we are carried high and raised up by their giant size." by Bernard of Chartres , d. c.1130, French philosopher.

#Conceptual construction (thought moves, not workflow)

The table is derived from earlier patterns; it creates nothing new.

• Sourcing. Candidate cells come only from SenseCells (F.3).
• Licensing. A row exists iff the relevant Bridges (F.9) already justify sameness at the chosen Row Scope.
• Bounding. Prefer 2–4 Contexts per row (parsimony); add more only if each adds a distinct necessity for the sameness claim.
• Typing. A row is typed by senseFamily: Role, Status, Type‑structure, Measurement, etc. Do not mix senseFamilies in one row.
• Temporal honesty. A row’s cells must share compatible DesignRunTag; if not, either split into two rows or mark a contrast row.

#Invariants (normative)

1. Context‑loyal cells. Every non‑empty cell is a SenseCell address; no minted paraphrases.
2. Bridge sufficiency. For a Concept‑Set row, every pair of filled cells is connected by an F.9 Bridge path whose bottleneck CL ≥ Row CL(min) printed for the row.
3. Scope declaration. Each row MUST declare a Row Scope chosen from a small controlled set (e.g., Naming-only, assignment/enactment-eligibility, KD-metric, Type-structure).
4. senseFamily uniformity. All cells in a row belong to the same senseFamily (Role or Status or Type-structure or Measurement…).
5. Temporal compatibility. Either all cells share the same stance, or the row is a contrast row (no sameness claim).
6. Loss disclosure. If any Bridge in the row has a loss note, the row MUST include a counter‑example that illustrates that loss in one line.
7. No stealth expansion. Adding a new cell to a row MUST NOT lower the printed Row CL(min) without updating Row Scope or splitting the row.
8. Parsimony. A row with only one filled cell is forbidden (that would be local talk, not a Cross‑context concept).
9. Didactic bound. A row that cannot be read in ≤ 30 seconds violates didactic primacy and must be split.

#Micro‑illustrations (safe patterns)

Illustrative only; these presume corresponding F.9 Bridges exist with stated CL and losses.

(a) Subtyping across type‑formalisms (Type‑structure row)

(b) “Observation result value” (Measurement row)

(c) Contrast row: “process” (no sameness)

#Anti‑patterns & remedies

#Worked examples

Each example gives a row (compact), then a reading explaining scope and limits. All sameness claims presuppose suitable F.9 Bridges with the stated CL.

#Behavioural actor across Contexts (naming‑only)

Reading. The row licenses a glossary‑level sameness for didactic prose (“the actor”). It does not license modelling identity or inference across Contexts.

#Execution occurrence (assignment/enactment-eligibility)

Reading. Safe to use as the run-time occurrence referenced by performed-work attribution when we say “this Work was performed under an assignment”. Not safe to equate all PROV Activities with all PLC task runs for analytics.

#Result value as KD‑metric (measurement)

Reading. Licences metric tables that join observations to service targets; warns that composite KPIs may violate unit fidelity.

#Subtype relation (type‑structure)

#Contrast: “role” (access vs behaviour)

Reading. This row teaches difference; it deliberately does not license sameness.

#Reasoning primitives (judgement schemas, notation‑free)

All judgements are pure (no side effects). “Contexts” are U.BoundedContext. SC(C) denotes a SenseCell in Context C. CL(X↔Y) is the congruence level of the best Bridge path (F.9) between SenseCells X and Y (bottleneck along that path).

#Row licensing

Form. S = {SC(C₁), …, SC(Cₙ)}, Scope = s, τ(s) = requiredCL ⊢ licensable(S,s) ⇔ (∀ i<j: CL(SC(Cᵢ)↔SC(Cⱼ)) ≥ requiredCL ∧ senseFamily (S) is uniform ∧ stance(S) compatible)

Reading. A set of cells licenses a row of scope s iff every pair is bridged at or above the required CL for that scope, all cells sit in the same senseFamily, and DesignRunTag is compatible.

#Bottleneck CL for a row

Form. RowCL(S) = min_{i<j} CL(SC(Cᵢ)↔SC(Cⱼ))

Reading. The row’s CL is the minimum congruence level across all pairs (the weakest link).

#Scope guard

Form. licensable(S,s) ∧ s ⊑ s' ⊢ licensable(S,s') only if RowCL(S) ≥ τ(s')

Reading. You may tighten scope (use the row for a higher-scope purpose) only if the row’s CL meets the higher threshold for that scope.

#Contrast decision

Form. (∃ i<j: CL(SC(Cᵢ)↔SC(Cⱼ)) < τ(Naming‑only)) ⊢ publish‑contrast(S)

Reading. If even Naming‑only cannot be licensed, publish a contrast row instead of forcing sameness.

#Row extension guard

Form. licensable(S,s) ∧ add SC(Cₖ) ⊢ licensable(S∪{SC(Cₖ)}, s) iff ∀ i: CL(SC(Cᵢ)↔SC(Cₖ)) ≥ τ(s)

Reading. You may add a new cell only if it bridges to every existing cell at the row’s scope.

#Loss disclosure obligation

Form. licensable(S,s) ∧ (∃ i<j: lossNote on Bridge(SC(Cᵢ),SC(Cⱼ))) ⊢ row must carry ≥1 counter‑example

Reading. Any loss note on any supporting Bridge obliges the row to include a counter‑example one‑liner.

#Relations (with other patterns)

Builds on: F.1 Contexts fixed → defines the column set; F.2 Harvest → supplies harvested terms; F.3 SenseCells → provide cell addresses; F.5 Naming Discipline → provides the two‑register FPF labels; F.9 Bridges → justify each row.

Constrains: F.4 Role Description — when a template cites an FPF label from the table, it inherits the Row Scope; no template may claim semantics beyond the row’s licence. F.6 Role Assignment & Enactment Cycle (Six-Step) — Move M‑4 (“choose label”) must reference a row if it wants Cross‑context reading.

Used by. Part C patterns for didactic alignment pages; Part B trust calculus (B.3) may consume Row CL(min) when computing translation penalties.

#Migration notes (conceptual)

1. Bridge update. If any supporting Bridge’s CL changes, recompute Row CL(min). If it drops below the printed value, either lower Row Scope, split the row, or retire it.
2. New Context appears. Do not auto‑expand rows. Test with 12.5; add only if it brings a distinct necessity.
3. Sense revision inside a Context. If a SenseCell splits (F.3), decide which child cell (if any) remains in the row; the rest may require new rows or a contrast.
4. Scope promotion. To use a row for a higher-scope purpose (e.g., from Naming-only to assignment/enactment-eligibility), first ensure Row CL(min) ≥ τ(new scope); otherwise construct new Bridges or decline promotion.
5. Deprecation. If a row no longer meets its invariant, mark its FPF label as retired in F.5 and point to successor rows (if any).
6. Edition churn. When a Context is superseded (F.1), either keep the cell (if semantics stable) or treat the successor as a new Context and re‑evaluate licensability.

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

#Static conformance checks (SCR)

• SCR‑F7‑S01 (Context‑loyal cells). Every non‑empty cell references an existing SenseCell (F.3) in a declared Context (F.1).
• SCR‑F7‑S02 (Closure & bottleneck). For each Concept‑Set row, every pair of cells has a Bridge path with CL ≥ Row CL(min) printed; Row CL(min) equals the minimum pairwise CL.
• SCR‑F7‑S03 (Typed & scoped). Each row declares a Row Scope from the controlled set and is senseFamily‑uniform (Role or Status or Measurement or Type‑structure…).
• SCR‑F7‑S04 (Temporal compatibility). Non‑contrast rows have compatible DesignRunTag across cells.
• SCR‑F7‑S05 (Loss disclosure). If any supporting Bridge has a recorded loss, the row includes ≥1 counter‑example line.
• SCR‑F7‑S06 (Parsimony). Rows contain 2–4 Contexts unless a one‑line necessity is stated for each extra Context.

#Regression checks (RSCR)

• RSCR‑F7‑E01 (Bridge drift). After any Bridge change (F.9), recompute Row CL(min); flag rows whose scope is now overstated.
• RSCR‑F7‑E02 (Sense split). After a SenseCell splits (F.3), ensure rows referencing it either pick a child cell or retire.
• RSCR‑F7‑E03 (Scope integrity). No consumer pattern uses a row outside its declared Row Scope.
• RSCR‑F7‑E04 (No stealth growth). Additions of cells never lower Row CL(min) silently; if they do, either split the row or reduce scope.

#Didactic distillation (60‑second teaching script)

“A Concept-Set row shows one idea across Contexts—but only where explicit Bridges license it. Columns are Contexts; cells are their own labels. The row prints a scope (‘Naming-only’, ‘assignment/enactment-eligibility’, ‘Type-structure’, ‘KD-metric’) and the weakest CL that justifies reading across. A one‑line rationale says why sameness is safe here; a counter‑example warns where it breaks. Keep rows small (2–4 Contexts), typed (don’t mix senseFamilies), and temporally honest (design vs run stance). If Bridges don’t suffice, publish a contrast row instead. The table doesn’t invent meaning; it summarises licensed sameness so readers can cross disciplines without smuggling assumptions.”

#F.7:End

#Mint-or-Reuse Decision

Type: Architectural pattern Status: Stable Normativity: Normative unless marked informative

#Use This When

Plain name. Name admission decision.

Use this pattern when a project has one candidate expression, has independently recovered the exact governed value or relation that the expression might designate, knows that value's direct governing pattern, and must choose the smallest naming disposition for one proposed use. The expression may stay local, reuse an existing designation, become an alias, reuse a direct-pattern name or an admitted Unified Term Sheet row, name a RoleDescription episteme, open a durable naming settlement, introduce a policy identifier, propose a new public row, or remain only a rare U-kind candidate.

Typical moments:

• a role-like expression such as ReviewerRole, AccessRole, EvidenceRole, RequirementRole, ProviderRole, or "actor" appears and the project must decide whether it designates a work-facing U.Role, a status-use relation, an evidence-use relation, an access or policy value, a relation position, or only a local phrase;
• a source tradition supplies a convenient name, but its local sense would import that tradition's ontology if promoted as an FPF designation;
• an F.17 row seems reusable, but its admitted use may be only naming rather than substitution, role assignment, measurement, or structural inference;
• a project wants a new U-kind, policy identifier, RoleDescription label, NameCard, or public term row because no existing expression feels comfortable; or
• an E.10 repair discovers that a smoother word would still hide the current kind or relation.

Primary working object. The working object is one mint-or-reuse decision occurrence concerning one candidate expression, one independently governed value or relation, and one proposed naming use. If another claim needs to cite that occurrence, identify it through the direct decision or work owner. A separately constituted C.2.1 decision-result episteme may describe the occurrence, and a displayed record may designate that episteme; neither the episteme nor its record performs the decision. F.8 introduces no generic decision kind.

Primary working reader. The first reader is an engineer-manager, analyst, method author, pattern author, or terminology steward deciding whether a candidate expression deserves durable FPF treatment.

First useful move. Write four things before judging the wording: the candidate expression, the exact governed value or relation already recovered under its direct pattern, that direct pattern, and one proposed use. Then apply F.14 and try, in order, a local phrase, an existing designation, an alias, a current direct-pattern name, and an admitted F.17 row. Create no SchemeSenseCell, NameCard, row, policy identifier, or U-kind candidate until every lighter sufficient disposition has failed.

What goes wrong if missed. A convenient label becomes new ontology. A source word becomes global. A status, evidence, access, requirement, source, publication, or relation-position use gets named as a role. A public row is used beyond its admitted scope. A review label is treated as a context object, performed Work, role assignment, evidence use, or authority. FPF then accumulates duplicate kinds and naming records where it needed a smaller decision.

What this buys. Teams can reuse names without growing FPF by accident. Durable names become harder to mint but easier to trust. Role expressions become work-facing role names only when the role ontology is independently current; other expressions return to their direct patterns before naming. The effective naming ReferenceScheme and exact local-sense basis stay visible without inventing a universal context object.

Not this pattern when.

• If the issue is ordinary phrase repair with no durable name, use E.10, E.10.ARCH, A.6.P, or the direct governing pattern.
• If the issue is choosing labels after the mint-or-reuse disposition is already settled, use F.5 for the local name family and F.18 for the fuller durable naming settlement.
• If the issue is describing one work-facing role, use F.4.
• If the issue is assigning a holder to a role or attributing performed work, use A.2.1, F.6, and A.15.1.
• If the issue is an actual relation between two different local-sense projections, use F.9; use F.17 only when a public, Core-facing, durable, or cross-local row is current.
• If the issue is status, evidence, source, standard, requirement, publication, assurance, gate, decision, policy use, method, work, or another subject claim, use its direct pattern before naming.

#Problem Frame

Name pressure is often a sign of unresolved ontology. A project wants one short expression, but that expression may stand for several different governed values or uses: one local sense, an already selected designation, a public row, a RoleDescription label, a status value, a method name, a Work occurrence label, a policy identifier, or a new U-kind candidate.

The dangerous shortcut is to decide by word form or administrative setting. If the word contains Role, it is treated as a role. If the same spelling appears under two schemes, it is treated as the same concept. If a source standard uses the name, the name is promoted. If a record says a decision was made, the record is treated as the decision occurrence. If a label such as PatternReview_2026 surrounds the work, it is treated as a context, role, assignment, evidence source, or authority without recovering the actual object and relation.

F.8 delays naming until the exact governed value, effective naming ReferenceScheme, local-sense basis, and proposed use are recovered. It is the gate between a local expression and a stronger naming disposition, not the naming style guide and not the direct owner of the named value.

#Problem

Without this pattern:

1. Local phrases become durable names. A temporary phrase outlives its use and looks like FPF vocabulary.
2. Source names capture FPF. One tradition's word becomes the selected FPF name before its local sense and cross-local fit are shown.
3. Role expressions become role ontology. EvidenceRole, RequirementRole, AccessRole, or ProviderRole is promoted without checking whether a work-facing U.Role exists.
4. Role names hide assignments. A RoleDescription label is treated as if a holder already has the role.
5. Public rows overreach. A row admitted for naming is reused for assignment, measurement, equivalence, or structural inference.
6. Aliases change meaning. A prettier label is introduced but silently changes kind, scope, occurrence identity, or use.
7. Kernel inflation follows comfort. A new U-kind is proposed because existing names feel awkward.
8. Policy identifiers appear as strings. A policy identifier is reused or introduced without a separately resolvable policy specification and mint decision.
9. Decision records act by proxy. A filled card or record is treated as if it performed the decision or created its governed value.
10. Locality labels become objects. A review, team, project, or date label is made into a generic context and then used to manufacture work, roles, evidence, status, or authority.

#Forces

#Solution

Treat mint-or-reuse as a typed disposition over an already recovered candidate, never as a vote on wording. Keep the following objects distinct:

• the exact governed value or relation and its direct pattern;
• the candidate expression, any selected designation, and any alias;
• the effective naming U.ReferenceScheme, exact local-sense claim, optional SchemeSenseCell, and any actual two-participant LocalSenseBasisRelation;
• the mint-or-reuse decision occurrence;
• any C.2.1 decision-result episteme and any record or carrier that designates it;
• any F.18 NameCard, F.17 row, policy specification, policy identifier, publication occurrence, form, or carrier; and
• an independently selected bounded-model-use Structure only when its organization changes interpretation for this exact naming use.

Ordinary use may stop with a readable disposition and no durable decision object. Materialize a decision occurrence reference or result episteme only when a receiving claim needs citation, replay, or accountability. When a C.2.1 result episteme is current, use this compact readable projection of its claim graph:

MintReuseDecisionResultEpisteme:
  DecisionResultEpistemeId:
  EntityOfConcernRef: [the separately identified mint-or-reuse decision occurrence]
  CandidateExpression:
  GovernedValueOrRelationRef:
  GovernedKindOrRelationKindRef:
  DirectGoverningPatternRef:
  ProposedNamingUse:
  EffectiveNamingReferenceScheme: [U.ReferenceScheme carried by value]
  LocalSenseClaim:
  LocalSenseCellRef?: [only when an independently current SchemeSenseCell is needed]
  LocalSenseBasisRelationRef?: [only when the exact cell-to-basis-episteme relation obtains]
  SelectedModelUseStructureRef?: [only when an independently selected Structure changes this use]
  ReuseCandidateRefs?:
  SelectedDisposition:
  ResultingNamingRefs?: [only objects independently current after the disposition]
  NonAdmissibleOverread:
  ReopenCondition:

The block describes the result episteme; it is not the decision occurrence. EntityOfConcernRef resolves to that occurrence, while the remaining fields designate claims in the episteme's U.ClaimGraph. A record identifier, completed field set, NameCard, row, or publication creates neither the decision occurrence nor the governed value. If no result episteme is needed, apply the same distinctions in prose without creating a record.

Admissible dispositions are:

• localPhraseOnly;
• reuseExistingDesignation;
• aliasOnly;
• reuseDirectPatternName;
• reuseAdmittedTermRow;
• nameRoleDescription;
• openDurableNamingSettlement;
• proposePublicTermRow;
• introducePolicyIdentifier;
• proposeUKindCandidate; and
• blockOrLowerUse.

These are F.8 result labels, not new U.* kinds. A stronger result opens its direct owner; it does not itself mint the corresponding card, row, identifier, policy specification, relation occurrence, or U-kind.

#Decision Targets

#Decision Sequence

Use this order and stop at the first disposition that supports the exact proposed use without hiding a governed distinction.

1. Recover the four starting facts. Name one candidate expression, one exact already-governed value or relation, its direct pattern, and one proposed use. If the value or obtaining relation is not independently current, stop and return to the direct pattern; F.8 cannot establish it.
2. Split mixed candidates. If one expression covers role, status, evidence, Work, method, measurement, policy, source, publication, or structure at once, split it into separate <governed value, proposed use> decisions.
3. State exact semantic locality. Carry the effective naming U.ReferenceScheme by value and state the local-sense claim. Cite a SchemeSenseCell and its exact LocalSenseBasisRelation only when those independently governed objects are current. Cite a selected bounded-model-use Structure only when its organization changes interpretation for this use.
4. Apply F.14 and try a local phrase. If ordinary local wording supports the use, choose localPhraseOnly and stop.
5. Try an existing designation. Reuse it only when exact value, kind, scope, occurrence identity, local-sense claim, and proposed use match.
6. Try an alias. Use aliasOnly when the governed meaning is unchanged and lineage can expose the wording variation. An alias may not change kind, scope, occurrence identity, use, or authority.
7. Try the direct-pattern name. Use the name already supplied by the exact role, status, evidence, policy, method, Work, relation, or other subject owner. Route work-facing role labels through A.2, F.4, and F.5; route assignment or performed Work through A.2.1, F.6, and A.15.1 rather than naming.
8. Try one admitted F.17 row. Reuse only the row's declared AdmissibleUse. Local-sense reuse does not imply cross-local sameness; a row and equal spelling create no F.9 Bridge.
9. Open only the next naming object that pays for itself. A stable local address may justify a cell; an enduring naming settlement may justify a NameCard; a public/Core/durable/cross-local need may justify an F.17 row. None implies the next object.
10. Introduce a policy identifier only for a recovered policy specification. Keep the identifier, specification, mint decision occurrence, and result episteme or record distinct.
11. Propose a new U-kind only rarely. Require cross-family recurrence, irreducibility to existing FPF values or relations, E.24.UK, and the relevant A.8, A.11, C.3, E.9, and F.18 admission basis. F.8 only routes the proposal.
12. Block or lower. If no disposition is justified, keep the expression local, quote it as source wording, or lower the claim.

#Role Expression Boundary

A role expression becomes a durable role name only when the direct role owner has independently recovered one work-facing U.Role, or F.4 has constituted the RoleDescription episteme for that role. The naming ReferenceScheme interprets the expression; it neither supplies a role value nor assigns a holder.

#F.17 Row-Scope Consumption

F.8 consumes one exact F.17 row and its declared use; it does not constitute the row or define Bridge strength. F.17 keeps the row episteme, governed value, designations, cell, basis relation, any F.9 Bridge, edition relation, and publication package distinct. F.8 asks only whether the row's AdmissibleUse covers the proposed naming use.

If the row does not admit the proposed use, lower the name's use or repair the exact F.17 row and any required F.9 relation. Do not strengthen a name because the wording is attractive, and do not infer cross-local sameness from local-sense reuse.

#Invariants

1. Governed value before disposition. The candidate expression, exact governed value or relation, direct pattern, and one proposed use are named before any F.8 result.
2. One decision, one exact use. Mixed expressions are split by governed value and use before deciding.
3. Lightest sufficient result. Local phrase, existing designation, alias, direct-pattern name, and admitted row reuse are tried before a cell, NameCard, new row, policy identifier, or U-kind candidate.
4. Reuse preserves identity. Reuse cannot change kind, scope, occurrence identity, local-sense claim, admitted use, or authority.
5. Local senses do not globalize. Reusing a designation under one effective ReferenceScheme establishes neither sameness with another cell nor an F.9 Bridge.
6. Role names are work-facing. A role name or RoleDescription label points to an independently recovered work-facing U.Role; status, evidence, access, source, publication, requirement, assurance, gate, decision, policy, and relation-position uses remain direct-pattern values.
7. Role assignment and Work are not naming. A name, decision result, NameCard, cell, row, or identifier neither assigns a holder nor demonstrates performed Work.
8. Rows stay within admitted use. F.8 may reuse an F.17 row only at its declared use and gains no equivalence from the row.
9. Decision occurrence and description stay distinct. A C.2.1 result episteme or displayed record can describe a separately identified decision occurrence but cannot perform it.
10. Naming objects stay distinct. Governed value, designation, alias, cell, basis relation, NameCard, row, identifier, publication occurrence, form, carrier, and currentness relation imply none of the others.
11. Selected structure is conditional. A bounded-model-use Structure is cited only when independently selected organization changes interpretation for this exact use; it is not a generic locality or identity slot.
12. New U-kind candidates are rare. Cross-family recurrence, irreducibility, E.24.UK admission, and accepted decision basis are necessary; F.8 itself admits no U-kind.
13. Policy identifiers are resolvable. A policy identifier remains distinct from its policy specification, mint decision occurrence, and decision-result episteme or record.
14. Labels grant no authority. Source titles, review labels, suffixes, rows, records, and identifiers create no ontology, evidence, status, equivalence, permission, or publication authority.

#Reasoning Primitives

candidateExpression(E) and not(independentlyRecoveredGovernedValueOrRelation(V))
  -> stop F.8; run E.10 or the direct subject pattern before naming.

candidateExpression(E) and governedValueOrRelation(V) and directPattern(P) and proposedUse(U)
  -> choose the lightest naming disposition for <V,U>; not(establish(V)) and not(makeObtain(V)).

existingDesignationOrLocalPhrase(V, U) is sufficient
  -> reuse or stay local; do not mint a cell, NameCard, row, identifier, or U-kind candidate.

alias(E2, designation(E1,V))
  -> preserve kind(V), scope(V), occurrenceIdentity(V), admittedUse(V), and lineage(E1,E2).

localSense(E, ReferenceScheme S, LocalSenseClaim L)
  -> not(crossLocalSameness) and not(Bridge) without an independently obtaining F.9 relation.

E names one work-facing Role R
  -> use A.2/F.4/F.5 for role-description naming; use A.2.1 for assignment and A.15.1/F.6 for performed Work.

E names an episteme-use, status-use, policy-use, source-use, publication-use, or relation-position case
  -> recover the direct pattern before selecting any durable designation.

F17Row(Row) and admittedUse(Row,U)
  -> F.8 may reuse Row for U only; not(equivalence) and not(widerUse).

DecisionResultEpisteme(R) and entityOfConcern(R,D)
  -> R describes decision occurrence D; not(R = D) and not(recordPerformsDecision(R)).

E is a proposed new U-kind
  -> require irreducibility, cross-family recurrence, E.24.UK, and an accepted direct admission basis; F.8 only routes.

#Archetypal Grounding - worked cases

#Reviewer Role vs Review Report

The source label PatternReview_2026 is not a context object. Classify the actual claim before using it:

• ReviewWork-82 can be one dated U.Work occurrence under A.15.1;
• ReviewPlan-2026-v3 can be a separately constituted plan episteme or edition under its direct owner;
• PatternReviewReferenceScheme-2026 can be an effective by-value U.ReferenceScheme for interpreting review terminology; and
• "used while deciding the label for the 2026 review method" can be claim content describing the decision-use setting without minting any context entity.

If the independently governed ReviewerRole value is work-facing, F.8 may return nameRoleDescription: use F.4 for the RoleDescription episteme and F.5 or F.18 for the label when its durability is current. The review label does not create that role, assign a reviewer, or demonstrate review Work.

The expression "review report has reviewer role" is a different case. ReviewReport-82 is an episteme. A direct evidence, source, or publication relation may later use it for an adequacy claim about a reviewed pattern; the report does not hold the work-facing role, and its title does not make any evidence use or publication authority obtain.

#Actor Across BPMN and PROV

A manager wants one word, "actor", for a BPMN participant and a PROV agent in a diagram. First recover the two exact local senses under their effective ReferenceSchemes. If an actual F.9 Bridge relates the exact cells and one F.17 row admits naming-only use, F.8 returns reuseAdmittedTermRow for prose and diagram labels only.

No governed-value identity, substitution, role assignment, or Work follows. If the project later needs a work-facing role under one scheme, it creates or reuses the local RoleDescription episteme for that independently recovered role value.

#Access Role

An access-control source says ApproverRole. Under the source's effective naming ReferenceScheme, the expression may designate a permission grouping or exact policy relation. F.8 first returns to the access, policy, status, or deontic owner. Only if A.2 independently governs a work-facing approval role does a RoleDescription naming decision become current.

Otherwise the durable designation, if needed, belongs to the direct access, policy, status, or gate pattern. The Role suffix, a source card, or a selected model-use Structure creates no work-facing role or assignment.

#Policy Identifier

A gate profile proposes Aut-Guard-2026. F.8 treats this as a policy-identifier question only after an exact policy specification is independently recoverable. Reuse resolves the existing identifier, its separate specification, and the original mint decision. New introduction identifies a new mint decision occurrence and, when durable trace is needed, its separate result episteme or record.

The identifier is not the specification, role, method, gate result, evidence value, permission, or source authority. It is a reference used by the pattern that governs the exact policy claim.

#New U-kind Candidate

A team proposes U.InfluenceEdge because many documents use "influence". F.8 blocks immediate minting. The team must show that the candidate is not an existing relation, causal claim, evidence relation, characteristic, method relation, Bridge relation, structural name, publication form, or local frame under current patterns. If it remains cross-family, irreducible, and needed by several domain families, the proposal goes to E.24.UK, A.8, A.11, C.3, E.9, and F.18. F.8 neither creates nor admits the kind.

#Filled Decision Result and Explicit Pre-F.8 Stop

The first projection records a result about a separately identified naming decision. PatternReviewReferenceScheme-2026 is the effective naming scheme; the actual review Work, any review plan, and this decision-use setting remain separate.

MintReuseDecisionResultEpisteme:
  DecisionResultEpistemeId: MRD-ReviewerRole-2026-v1
  EntityOfConcernRef: ReviewerRoleNamingDecision-2026-07-31
  CandidateExpression: ReviewerRole
  GovernedValueOrRelationRef: ReviewerRoleValue
  GovernedKindOrRelationKindRef: U.Role
  DirectGoverningPatternRef: A.2
  ProposedNamingUse: durable local label for the RoleDescription episteme used by the review method
  EffectiveNamingReferenceScheme: PatternReviewReferenceScheme-2026
  LocalSenseClaim: work-facing role whose holder may perform exact pattern-review Work under a separately governed assignment
  LocalSenseCellRef: omitted; no receiving use needs a stable cell address yet
  LocalSenseBasisRelationRef: omitted; the direct local-sense claim and A.2/F.4 basis are sufficient at this gate
  SelectedModelUseStructureRef: omitted; no independently selected Structure changes this naming use
  ReuseCandidateRefs: no existing designation or alias supports the exact proposed use
  SelectedDisposition: nameRoleDescription
  ResultingNamingRefs: F.4 RoleDescription authoring next; F.18 only if durable reuse remains current
  NonAdmissibleOverread: the decision and its result episteme do not assign Alice, show that review Work occurred, make a review report evidence, or publish the label
  ReopenCondition: reopen if the expression is used for evidence, status, access, source, publication, or cross-local row claims

The second case does not enter F.8. The proposed EvidenceRole wording has exposed an evidence-use question, but no exact governed relation, relation kind, or single direct owner has yet been recovered. The review label again supplies no context, evidence, or authority.

PreF8RecoveryStop:
  CandidateExpression: EvidenceRole
  KnownSubject: ReviewReport-82 : U.Episteme
  ProposedNamingUse: reusable wording for one exact evidence-use relation
  EffectiveNamingReferenceScheme: PatternReviewReferenceScheme-2026
  RecoveredFact: ReviewReport-82 is proposed for evidence use concerning an adequacy claim; it is not a role holder
  MissingEntryFacts: the exact target claim and polarity; the exact evidence-use relation and relation kind; provenance, assurance or reliance use, and validity window when current; one direct governing pattern
  RequiredDirectOwnerAction: recover those facts under the single pattern that directly governs the exact evidence-use claim
  LocalSenseState: no stable cell address or independently current LocalSenseBasisRelation is needed for this blocked role reading
  SelectedModelUseStructureState: none; no independently selected Structure changes this use
  DirectTerminologyProbe: test the eventual direct evidence-pattern terminology only after recovery
  StopResult: do not enter F.8 and do not mint EvidenceRole; keep the expression local until the governed relation, exact kind, one direct pattern, and proposed naming use are present
  NonAdmissibleOverread: this stop creates no evidence relation, role, RoleDescription, assignment, authority, or publication
  ReopenCondition: enter F.8 only after one exact governed relation, its exact relation kind, one direct governing pattern, and the proposed naming use are independently present; reopen the direct claim first if its target claim, polarity, provenance, assurance or reliance use, or validity window changes

#Bias-Annotation

F.8 blocks minting bias and record-first bias. A convenient expression, suffix, title, source term, review label, stable identifier, filled card, or memorable public phrase proves neither that FPF needs a new name nor that the named object or decision exists. Start from the exact governed value or relation, direct pattern, proposed use, effective naming ReferenceScheme, and local-sense basis. Choose the smallest adequate disposition. Treat a selected bounded-model-use Structure, decision result, NameCard, row, and publication package as separate objects only when their own direct conditions are current.

#Policy-Identifier Mint-or-Reuse Discipline

FPF treats policy identifiers such as Phi(CL), Phi_plane, Psi(CL^k), Aut-Guard, EmitterPolicyRef, insertion-policy identifiers, and acceptance-clause identifiers as versioned references whose meaning must be recoverable. They are not "just strings", role names, gate decisions, permissions, or policy specifications.

PolicyIdentifierReference:
  PolicyIdentifier:
  PolicySpecificationRef:
  MintDecisionOccurrenceRef:
  MintDecisionResultEpistemeRef?:
  ScopeOrNamespaceRef:

PolicyIdentifier is the selected designator. PolicySpecificationRef resolves to the separate policy-definition episteme, pins an edition or equivalent digest when needed, and remains findable through the same publication family or an exact cited source relation; it does not identify or mint the identifier. MintDecisionOccurrenceRef resolves to the separate decision that introduced the identifier in the declared namespace. MintDecisionResultEpistemeRef, when current, resolves to a C.2.1 episteme or accepted record describing that occurrence; the record does not perform the decision.

For FPF normative policy identifiers, the durable result episteme is usually an accepted [E.9](/generated/patterns/E.9) decision record. For a local non-exported identifier, the direct gate, decision, or publication pattern may admit a smaller result episteme when local scope is explicit. In either case, the policy specification, identifier, decision occurrence, and record remain distinct.

Rules:

1. No silent policy-identifier introduction. A newly introduced identifier resolves both the separate PolicySpecificationRef and mint decision occurrence; when durable trace is needed, it also resolves the separate result episteme or record.
2. Reuse is reference use. Reusing an existing identifier resolves the same identifier, its policy specification, and its original mint decision; it does not restate policy semantics or silently create another decision.
3. Gate checkability. A gate, crossing, Bridge, assurance, or publication claim that depends on a policy identifier includes PolicyIdentifierReference or an equivalent resolvable structure admitted by its governing pattern.
4. Policy authority stays with the governing pattern. F.8 selects introduction or reuse of the identifier; it does not decide whether the policy permits Work, passes a gate, makes a relation obtain, or provides evidence.
5. The identifier grants nothing by itself. Name, namespace, suffix, source prestige, specification publication, or decision record grants no permission, status, equivalence, or authority beyond the exact direct policy claim.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Good consequences:

• durable vocabulary grows more slowly and with clearer justification;
• role, status, evidence, access, source, requirement, publication, and slot-position cases stop forming duplicate role ontology;
• effective ReferenceSchemes and exact local-sense claims replace generic context slots without erasing real locality;
• F.17 rows keep their declared scope, and local-sense reuse no longer masquerades as cross-local equivalence;
• F.5 and F.18 receive better naming inputs because F.8 has already selected the smallest disposition;
• decision occurrences and result records become independently inspectable; and
• policy identifiers become checkable references instead of decorative strings.

Costs:

• authors must recover kind, direct owner, use, scheme, and local-sense basis before naming;
• mixed expressions require separate decisions;
• some attractive names remain local phrases or aliases;
• durable public or cross-local names may require independently justified cell, NameCard, Bridge, row, reliance, decision-result, and publication objects; and
• a new U-kind becomes harder to justify because minting waits for E.24.UK and the relevant admission law rather than naming comfort.

Reopen F.8 when E.24.UK, A.2, A.2.1, A.15.1, F.4, F.5, F.6, F.9, F.14, F.17, F.18, A.6.5, C.2.1, E.10, E.9, A.8, A.11, or policy-identifier discipline changes enough that the dispositions or object boundaries would change.

#Rationale

F.8 is placed before naming style because a naming mistake is often a kind, locality, or use mistake. A practitioner should not ask "what name should we use?" until the exact governed value or relation, its direct owner, proposed use, effective ReferenceScheme, and local-sense claim are recoverable.

The pattern is intentionally narrower than F.18. F.18 can run a durable naming settlement, candidate comparison, NameCard, lineage, and later F.17 row gate. F.8 supplies the prior disposition: should this expression remain local, reuse something already current, or open one stronger naming path? It does not create the value or perform the stronger path.

The strict role boundary is central. A role expression names a work-facing role only when U.Role is independently recovered. Epistemes, publications, standards, requirements, evidence, statuses, permissions, gates, decisions, methods, Work, and relation positions may need names, but they do not become roles because source prose used role.

The decision-description boundary is equally important. A mint-or-reuse decision occurrence, a C.2.1 result episteme about it, and a rendered record answer different questions. Keeping them distinct provides traceability without letting administrative artifacts perform content decisions.

#SoTA-Echoing - Source-Use

Source-use boundary: a source tradition may supply candidate expressions, aliases, and current practice pressure. It does not select the FPF disposition, establish the governed value, make a relation obtain, or confer authority. Those claims follow the direct pattern and independently recovered facts.

#Relations

Builds on. A.7, E.24.UK, A.8, A.11, E.10, E.10.ARCH, F.1, F.2, F.3, F.5, F.9, F.14, F.17, and F.18.

Coordinates with. A.2, A.2.1, A.2.5, A.2.7, A.6.5, A.15, A.15.1, F.4, F.6, F.10, F.13, F.15, C.2.1, C.3, E.9, E.24.CD, E.24.PUB, and the direct status-use, evidence-use, source-use, publication-use, requirement-use, assurance, gate, decision, policy, method, Work, characteristic, and architecture patterns.

Constrains.

• F.5 names only after F.8 has selected the exact naming case.
• F.4 governs only work-facing RoleDescription naming cases.
• F.9 governs an actual Bridge between exact cells; F.17 governs any admitted public-row use before F.8 reuses it.
• F.18 expands durable naming only after lighter dispositions have failed.
• F.14 supplies the anti-explosion stop before every stronger F.8 disposition.
• F.15 may check the resulting distinctions; it neither chooses the disposition nor creates a naming object.

Does not replace. The direct governing patterns for the value or relation, decision occurrence, RoleAssignment, performed Work, status, evidence, source, publication, requirement, assurance, gate, policy, method, relation slot, characteristic, architecture, selected Structure, or their descriptions.

#Didactic Memory

Do not ask for a better name first. Recover one exact governed value or relation and one use; state the effective naming ReferenceScheme and local-sense claim; then try local phrase, existing designation, alias, direct-pattern name, and admitted F.17 row. Mint only the next object that pays for itself. A label, card, row, identifier, publication, or decision record creates none of the ontology, Work, assignment, evidence, status, equivalence, or authority it mentions.

#F.8:End

#Alignment and Bridge across Contexts

Type: Pattern Status: Stable

"Translate across contexts; never collapse them."

Type: Architectural pattern. Status: Stable. Normativity: Normative. Builds on: F.17 for exact scheme-based SchemeSenseCell identity and SenseCellAddressRef; F.18 for designation selection; C.2.1 for assertion and description-episteme identity; F.0.1 for senseFamily and bridge-only crossing discipline; F.7 and F.8 for downstream naming and reuse decisions.

Coordinates with: A.6.REL for demand-driven occurrence individuation; C.2.1 for assertion, occurrence-description, and Card identity; E.24.PUB for publication occurrence, form, and carrier; A.10 for evidence-provenance relations and local reliance dispositions; B.3 for assurance claims and minimum assurance records; A.2, A.2.1, F.4, F.5, F.6, and A.15.1 for work-facing role and performed-work claims; A.6.5 for relation-slot discipline; C.29 for mathematical-lens use; A.6.3.CSC for controlled coarsening; C.26.1 and C.26.2 for quantum-like export boundaries.

Plain entry cues (informative). Context-to-context translator; sense bridge.

#Intent and applicability

Intent. Govern one actual semantic Bridge relation between two exact F.17 SchemeSenseCell values from different semantic contexts. Keep that occurrence separate from every assertion, Bridge description episteme, Bridge Card, registry record, publication occurrence, publication form, presentation carrier, bounded-use claim, evidence or assurance relation, and object created when a proposed use is actually performed.

Applicability. Use this pattern when an author needs to compare local senses across contexts, reuse a familiar label, connect design-time and run-time senses, compare two standards' terms, or justify a cross-context row. A shared word or available mapping is only a reason to ask whether a Bridge obtains.

Primary EntityOfConcern in plain terms. One actual correspondence or difference between two exact local senses. The governed object is the direct Bridge occurrence, not a card, context, transport chain, work process, role assignment, evidence item, or global meaning layer.

Admissible move in plain terms. First resolve the two local senses. Then state what semantic correspondence or difference holds between them and test that relation. If it obtains, identify the Bridge. Only after that, state the proposed use separately: what the reader will do, in which direction, by which correspondence rule, and how much semantic loss that use tolerates. A current affirmative C.2.1 claim answers whether this Bridge is suitable for that bounded use. Check the evidence for relying on that claim under A.10, or use B.3 when an assurance claim is made or its material-reliance threshold is met. If the use actually happened, recover the resulting Work, assertion, publication, relation, operation application, or other object under its direct owner. Add a Bridge Card only when a reusable package is worth maintaining.

Primary working reader. An author, checker, or practitioner deciding first whether a cross-local semantic relation actually obtains and then whether it supports one named use.

Use this when. Use F.9 when a receiving claim needs an exact semantic relation between two local senses whose <ReferenceScheme, LocalSenseClaim> interpretation bases differ. Different schemes, identical spelling, a mapping implementation, or a request for comparison does not establish that relation.

What goes wrong if missed. Teams turn shared labels and convenient mappings into silent equivalence, substitution, structural inference, status transfer, or role assignment. They also mistake evidence about a proposed use, or a polished card, for the relation itself.

What this buys. A reader can see which relation is true, which proposed use is being judged, what evidence supports reliance on that judgement, and whether any downstream act actually happened. Those facts can change independently without silently merging local meanings.

Not this pattern when. Not F.9 when the case is still inside one semantic context, or when the live question is role assignment, performed-work attribution, evidence use, status use, source use, publication, assurance, authorization, a gate, a decision, or a mathematical-lens operation. Use the direct governing pattern for that object; cite F.9 only when cross-context semantic correspondence is also needed.

Recognition versus assurance note. Resolving the endpoint senses and testing the direct Bridge predicate recognizes the semantic relation. A separate C.2.1 claim judges one bounded use. A.10 or B.3 governs whether a reader may rely on that claim for the named use. None of those steps supplies legal, policy, or deontic authorization.

#Problem frame

Cross-context work fails in predictable ways:

1. String-equals fallacy. Identical spellings such as "process", "role", "accuracy", or "ready" are taken as identical meaning.
2. Relation-to-use jump. A true semantic correspondence is treated as sufficient for whatever comparison, substitution, translation, or publication is wanted next.
3. Design-run jumping. Design artefacts are substituted for run-time occurrences, or run-time occurrences are treated as design definitions.
4. Direction amnesia. A symmetric relation is read as two use licences, or narrower and broader senses are used in the unsafe direction.
5. Loss blindness. The proposed use does not name which differences it tolerates.
6. Evidence and permission collapse. A score, card, or assurance record is treated as the semantic relation, authorization, or proof that the use occurred.

F.9 answers these failures by separating the direct relation, the bounded-use proposition, reliance on that proposition, optional packaging, authorization, and any actual receiving object.

#Problem

A shared label across contexts can look like identity or permission before any semantic relation is tested. Even after a Bridge obtains, its truth does not answer whether one particular comparison or substitution is suitable. The problem is to preserve useful cross-context work while keeping the relation, the proposed use, its evidence, and the downstream act individually testable.

#Forces

#Solution

Start with the two exact local senses, not with a context object, mapping table, or card. Resolve each endpoint as an F.17 SchemeSenseCell coordinate:

<ReferenceScheme by value, LocalExpression, LocalSenseClaim>

For F.9, semantic bounded context is a Plain practice name for the local interpretation basis recovered from one exact cell's <ReferenceScheme, LocalSenseClaim> projection. It is not an entity, relation participant, selected model-use structure, project situation, scope, viewpoint, description, designator, or reference. Two expressions under the same projection remain with ordinary designation and scope operations. Different projections make a Bridge question possible but do not make a Bridge obtain.

When the two cells are from different semantic contexts, declare one relation-semantic BridgePredicateProfile and test it against their current meanings. Shared spelling, different schemes, a mapping implementation, a card, a registry entry, evidence, an assessment score, or publication establishes none of those facts by itself.

#Direct Bridge relation

Bridge is a direct species of U.Relation. Its reusable RelationSignature has exactly two participant meanings:

Only the two endpoint meanings are RelationSignature participants. CL, Loss Notes, U.ClaimScope, an admitted-use qualifier, evidence, counterexamples, policy, time or as-of values, BoundedModelUseStructure, description, Card, publication, registry identifier, form, and carrier are qualifiers or neighboring objects. No proposed-use role, use direction, use-specific rule, permitted-loss tolerance, assertion, or reliance result is a third participant.

The reusable Bridge declaration is one independently constituted C.2.1 episteme whose exact EntityOfConcern is the direct Bridge relation kind. The same declaration episteme is used relation-facing as the compatible RelationSignature; its two SlotSpecs declare participant meanings but create neither endpoint nor occurrence. The relation kind, declaration episteme, RelationSignature use, SlotSpecs, actual cells, obtaining occurrence, assertion, occurrence-description episteme, Card, and publication remain distinct.

An F.9-local BridgePredicateProfile is a by-value predicate declaration, not a U-kind, participant, card, claim, or evaluation result. Direction is stated in the Bridge kind and endpoint orientation when the predicate is asymmetric. Its identity-bearing content is only:

1. the BridgeKind and its kind-defined symmetry or endpoint orientation;
2. the exact source and receiving endpoint-sense readings, including their senseFamily readings where material;
3. the relation-kind-specific congruence, difference, or loss condition, distinct from observed Loss Notes and a proposed use's permitted-loss tolerance;
4. the applicability and as-of basis for testing that condition;
5. the Boolean truth condition; and
6. every stop dependency whose absence prevents a truthful result.

The profile contains no receiving-use role, use direction, use-specific correspondence rule, permitted-loss tolerance, bounded-use proposition, assertion polarity, evidence-reliance classification, assurance claim, authorization, or receiving object.

Bridge(SourceSenseCell, ReceivingSenseCell; BridgePredicateProfile) obtains exactly when:

• both endpoint references resolve to exact F.17 SchemeSenseCell values;
• their semantic-context projections differ;
• the profile applies to those endpoint readings at its stated as-of basis;
• the current endpoint meanings satisfy its kind-specific correspondence or difference condition and Boolean truth condition; and
• every required dependency is present.

If an endpoint is unresolved, the projections are the same, a dependency is missing, or the predicate is false or unresolved, assert no positive occurrence and state the exact exit: ordinary designation, unresolved SenseCell endpoint, same semantic context, missing Bridge dependency, Bridge predicate false, or Bridge predicate unresolved.

Admitted-use qualifier. The Bridge declaration admits this relation only as the exact semantic-correspondence or semantic-difference premise for a separately governed comparison, explanation, translation, naming, or other bounded-use claim. Its nearest non-use is equally explicit: the Bridge alone licenses no substitution and creates no scope result, model-use crossing, role assignment, Work, evidence authority, status transfer, U-kind admission, publication, or other subject relation. This readable use boundary is a declaration or description qualifier; it is neither a participant nor profile identity and grants no specific use.

Non-optional occurrence identity and recurrence rule. BridgeOccurrenceIdentityRule identifies the occurrence by the exact endpoint cells together with the exact profile. For an asymmetric kind, the ordered source-to-receiving tuple is identity-bearing and an inverse relation requires another profile and directed occurrence. For a symmetric kind, swapping only the readable presentation of the same canonical endpoint pair does not create another occurrence. A changed endpoint or changed relation-semantic profile identifies another candidate.

A Bridge is non-recurrent for one fixed canonical endpoint tuple and exact profile: at most one occurrence has that identity. Repeated tests, assertions, descriptions, Cards, registry rows, or publications neither split nor repeat it. A later applicability or as-of basis changes the profile and therefore opens another occurrence candidate. If a claimed lapse and resumption cannot be represented by an endpoint or profile change, stop at missing Bridge recurrence basis rather than inventing two occurrences with one identity. Changed proposed use, direction, rule, tolerance, evidence path, reliance disposition, assurance claim, Card, registry entry, publication, form, or carrier never reidentifies or recurs the fixed Bridge.

#Judge a bounded use separately

Once exact Bridge b obtains, state the proposed use in ordinary language before introducing FPF terms. Name:

• u: what the reader proposes to compare, substitute, translate, publish, or otherwise do;
• d: the exact source-to-receiving direction for that use;
• r: the use-specific correspondence rule;
• t: the semantic-loss tolerance for that use; and
• whether the claim is affirmative or negative.

The resulting C.2.1 claim asks whether b is suitable for <u,d,r,t>. Its exact EntityOfConcern is b; its ClaimGraph designates u, d, r, t, and polarity; its effective ReferenceScheme makes those designations interpretable. That C.2.1 triple identifies the claim episteme. Changing u, d, r, or t changes the claim, not the Bridge.

An affirmative claim is one premise for the proposed use. It is not a permission, authorization, evidence-provenance relation, reliance classification, assurance claim, decision, or occurrence of that use. A negative claim says that the Bridge is not suitable for the named use; it does not make the Bridge cease to obtain.

For ordinary evidence reliance below B.3's material-reliance threshold and with no assurance claim, recover the exact A.10 evidence-provenance graph relation by value and state its local RelianceDisposition for the same bounded use. Only RelianceDisposition=pass supports reliance on the affirmative claim for that exact use; degrade supports only its named narrower use, while abstain, reopen, evidence-needed, blocked-current-use, or safety-case-required supplies no passing classification for the attempted use.

Enter B.3 when the receiver makes an assurance claim or the proposed use meets B.3's material-reliance threshold. Decide first whether a current assurance claim exists. A met threshold requires the minimum reliance safety assurance record and contest boundary but creates no positive claim. Use a positive current B.3 assurance claim only when it exists, its record is sufficient, and it carries the same bounded assurance use. Otherwise state the exact no-assurance, insufficient-record, narrowed, rejected, withdrawn, abstaining, or blocked disposition and stop or narrow the use accordingly.

Neither an A.10 passing disposition nor a positive B.3 assurance claim is legal, policy, or deontic authorization. If authorization is needed, recover it under its direct governor. If a later claim says the use happened, recover the actual Work, assertion episteme, publication occurrence, direct relation, operation application, or other object under its own pattern; the role u in the bounded-use claim is not that occurrence.

#Minimal vocabulary

• Semantic context - Plain shorthand for the interpretation basis <ReferenceScheme, LocalSenseClaim> recovered from an exact F.17 cell; it is not a separate entity or participant.
• SchemeSenseCell - the exact F.17 local composite value <ReferenceScheme by value, LocalExpression, LocalSenseClaim>.
• SenseCellAddressRef - an address that resolves one exact SchemeSenseCell; the address is not the cell.
• Bridge - an obtaining direct semantic relation between two exact SchemeSenseCell values from different semantic contexts under one exact profile.
• BridgePredicateProfile - the F.9-local by-value declaration of the direct relation's kind, symmetry or orientation, endpoint readings, correspondence or difference condition, applicability and as-of basis, Boolean truth condition, and stop dependencies.
• Bounded-use claim - an ordinary C.2.1 claim that says whether one exact obtaining Bridge is suitable for one named use, direction, use-specific rule, and loss tolerance. This phrase is descriptive, not a new public kind name.
• Relation orientation - how the Bridge kind orders or symmetrically relates its endpoint slots; it is not a use licence.
• Use direction - the ordered <UseSourceSenseCell, UseReceivingSenseCell> designated inside one bounded-use claim.
• Observed semantic loss - a difference or counterexample found in evidence. It can bear on a bounded-use claim but is not the use's permitted-loss tolerance.
• Permitted-loss tolerance - the maximum named loss accepted by one proposed use; it is content of that use's C.2.1 claim.
• Bridge occurrence description - an independently constituted C.2.1 episteme whose exact EntityOfConcern is one already individuated Bridge occurrence. It describes; it neither makes the predicate true nor supplies occurrence identity.
• Bridge Card - optional claim-bearing packaging. A filled Card may itself be a Bridge description episteme when its C.2.1 triple concerns an actual occurrence; a candidate Card instead modally describes the admitted relation kind and proposed endpoints. The reusable Card layout, registry row, publication form, and carrier remain separate.
• CL (Congruence Level) - optional F.9-local shorthand for the strength of evidence about a stated correspondence. It is neither a participant nor a use threshold and never grants a use.
• senseFamily - the local meaning family used by Part F. A senseFamily label is not a durable U-kind.

#Bridge kinds

A Bridge kind classifies the direct semantic relation tested by a profile. It says what correspondence or difference obtains; it does not settle any proposed use.

#Same-family relation kinds

1. Equivalence - the endpoint senses have the same extension and relevant intension under the stated relation condition. The relation is symmetric and should be rare. A later use still names its direction, rule, and tolerance.
2. Narrower-than - the source sense is properly included in the receiving sense. The relation is asymmetric.
3. Broader-than - the source sense properly includes the receiving sense. The relation is asymmetric.
4. Partial-overlap - the senses have a non-empty intersection, while each has cases excluded by the other. The relation is symmetric.
5. Disjoint - the senses have no common admissible case under the stated readings. The relation is symmetric.

For inclusion, a narrower-to-broader proposed use is usually easier to justify than the reverse, but neither direction follows from the relation alone. A broader-to-narrower proposal normally needs refined endpoint cells and a separately tested Bridge plus a separately warranted bounded-use claim.

#Cross-family relation kinds

These kinds state semantic correspondence across different senseFamily readings. They explain a connection; they do not create substitution, evidence authority, policy force, or a receiving occurrence.

6. Design-spec-to-run-occurrence - a design sense corresponds to a run-time occurrence sense while remaining different in temporal and realization status.
7. Measurement-evidence-for - a measurement sense corresponds to the measured aspect of another sense. The kind is semantic; actual evidential support remains with A.10 or B.3.
8. Policy-constraint-on - a policy or deontic sense corresponds to a constrained behavioral sense. Actual obligation, permission, or authority remains with the policy or deontic governor.
9. Viewpoint-correspondence - a sense used in one view corresponds to a sense used in another view over an EntityOfConcern. View, description, publication, and source-use claims keep their direct owners.

#Evidence about relation and use

Evidence must answer the question it actually bears on: