#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:87583

#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 inside one U.BoundedContext.

Typical moments:

• a project has a role name such as ReviewerRole, OperatorRole, InspectorRole, TransformerRole, ShipyardCoordinatorRole, or ModelCardReviewerRole, but the bounded context, admissible holder kind, role invariants, capability expectations, 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 EntityOfConcern is the role-description episteme: a U.Episteme that describes one U.Role value in one bounded context. It is not the role value itself, not the holder, not a role assignment, not a capability, not a method description, not performed work, not a status-use relation, and not a 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 being described, the bounded context that gives it meaning, the kind of holder admitted for role assignment, and the smallest set of role invariants that matters for 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 holder bears which role in which context and window, 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 cross-context sameness or translation, 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 requirement. A role such as InspectorRole is not self-explanatory. The project needs to know which bounded context gives it meaning, what kind of holder can bear it, which role invariants matter, and which neighboring checks 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

Use a role-description episteme to describe one U.Role in one bounded context. The description gives readers enough to recognize and check the role, while sending neighboring claims to their governing patterns.

RoleDescriptionCore:
  DescribedRoleSlot:
  BoundedContextSlot:
  HolderAdmissionSlot:
  RecognitionTextSlot:
  RoleInvariantSetSlot:
  RoleStateRequirementRefs:
  CapabilityRequirementRefs:
  MethodRequirementRefs:
  WorkUseBoundarySlot:
  NamingRefs:
  BridgeRefs:
  NonRoleUseBoundarySlot:

This is a description episteme shape, not a new assignment relation. Its publication may be a card, table row, method appendix, standard clause, or pattern section. The publication form is not the role description by default; it publishes or carries the description episteme.

#Core Slot Meanings

The slot list is an open-world discipline. A quick local description may fill only the role, context, recognition text, holder admission, and non-role boundary. A safety-critical work-admission use may need role-state, capability, method, assignment-window, and evidence references through neighboring patterns.

#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 and bounded context.
2. State the admitted holder kind 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, cross-context, or Core-facing, settle it through F.18; if the sense crosses contexts, use F.9.

#Invariants

1. One described role. A role description describes exactly one U.Role value in the current application.
2. One bounded context. The role description is local to one U.BoundedContext; cross-context reuse 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 admitted by a role assignment is a system or acting holon admitted by the governing work or method pattern. An episteme is not a role holder because it is used as evidence, source, standard, requirement, definition, explanation, status bearer, publication, or assurance input.
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 role value, context, and local sense are recovered.

#Reasoning Primitives

Use these judgement schemas as thinking checks.

RoleDescription RD describes Role R in Context C
  -> RD is a description episteme about R, not R itself.

RoleDescription RD admits holder kind HK for Role R
  -> A RoleAssignment may use a holder of HK only if A.2.1 and neighboring checks admit it.

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

RoleDescription:
  DescribedRoleSlot: PumpInspectorRole
  BoundedContextSlot: PlantMaintenance_2026
  HolderAdmissionSlot: maintenance technician, inspection robot, or service team admitted as acting holon by the maintenance context
  RecognitionTextSlot: the role used for inspecting pump condition before maintenance work is admitted
  RoleInvariantSetSlot:
    - concerns inspection of pump condition in PlantMaintenance_2026
    - does not perform repair work by itself
    - requires current assignment before work attribution
  CapabilityRequirementRefs: PumpInspectionCapability when the work claim depends on ability
  MethodRequirementRefs: PumpInspectionMethodDescription when the work claim depends on method
  NonRoleUseBoundarySlot: inspection report is evidence use, 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](/generated/patterns/A.2.1), [A.2.2](/generated/patterns/A.2.2), [A.15](/generated/patterns/A.15), and evidence patterns.

#Reviewer Role and Review Report

ReviewerRole in PatternReview_2026 may have a role description 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#ReviewerRole:PatternReview_2026@Window;
• 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 Requirement Source

The sentence "ISO 42010 has the architecture-standard role in this work" is unsafe if it makes the standard a role holder.

Repair it as:

ISO/IEC/IEEE 42010 is used as a standard-use or requirement-use episteme
for architecture-description claims in this bounded context.

Only a system or acting holon can hold a work-facing role. The standard may constrain, evidence, or source a claim through direct episteme-use relations.

#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 bounded context explicitly introduces 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, bounded context, 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 in PatternReview_2026";
• "holder admission for ReviewerRole 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 a direct pattern admits an acting holon 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 in a bounded context. 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 admitted through E.24.UK, a Concept-Set row, or a direct governing pattern; or
• a label used by a role-description episteme for one work-facing U.Role in one U.BoundedContext.

Typical moments:

• a Concept-Set row has enough witnesses to admit a reusable FPF name, 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 bounded context 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 named value kind and its source of meaning: E.24.UK, Concept-Set row, or direct governing pattern for a U-kind; role-description episteme, described U.Role, bounded context, 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.

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 stay local to their bounded context 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, context, window, 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-context sameness or translation 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 the value is admitted by E.24.UK, a Concept-Set row, or a direct governing pattern. The name should be neutral with respect to the witnesses and should name the least shared kind that the admission source actually admits.

Second, a role-description episteme labels one work-facing U.Role in one bounded context. The label should fit the local idiom 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 editions or contexts. Labels such as Task-IEC61131 or Participant-BPMN fossilize provenance inside the label instead of using Context, SenseCell, or Concept-Set evidence.
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.

NamingDisciplineRecord:
  NamedValueSlot:
  NamedValueKindSlot:
  MeaningSourceSlot:
  BoundedContextSlot:
  TechLabelSlot:
  PlainLabelSlot:
  AliasRefs:
  MorphologyCheckSlot:
  NeutralityCheckSlot:
  MinimalGeneralityCheckSlot:
  NeighboringUseBoundarySlot:

This record is not a registry requirement. It is the smallest relation a reader should be able to reconstruct from the pattern text, a Name Card, a table row, or a role-description episteme when the name is used.

#Name Families Governed Here

#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 context makes the coupled role-method meaning recoverable, but it must not replace the method record or work record.

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, the admitted name may be Result, Reading, or another head only if the Concept-Set row admits it by value.

#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 E.24.UK, Concept-Set row, or a direct governing pattern for U-kind admission; role-description episteme and bounded context for role labels; A.2.7 for role-relation expressions; 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; 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 context out of the label string. Context, edition, source, and witness provenance belong in Context, SenseCell, Concept-Set row, or Name Card fields, 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-context. Use F.18, F.17, and F.9 when the name crosses local use, public publication, or context boundary.

#Neighboring Use Boundary

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

The name is admitted 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;
• a dashboard value exported for subsequent comparison.

The row does not justify naming the U-kind Observation merely because one source tradition uses that word. It also does not justify DashboardValue if the dashboard is only one publication form. A name such as Reading or Result is admissible only if the row shows the shared invariant: produced value or record admitted for comparison in the declared context.

#Work-Facing Role Label

In PlantMaintenance_2026, the role-description episteme describes PumpInspectorRole.

NamedValueSlot: PumpInspectorRole
NamedValueKindSlot: U.Role
MeaningSourceSlot: RoleDescription for PlantMaintenance_2026
TechLabelSlot: PumpInspectorRole
PlainLabelSlot: pump inspector role
NeighboringUseBoundarySlot: inspection report is evidence use; inspection method is method; assigned technician is RoleAssignment holder.

The label helps readers identify the role. It does not say Robot-7 holds the role, can inspect pumps, followed the inspection method, or produced an admissible report.

#Evidence Use Is Not a Role Name

Source text may say ModelFitEvidenceRole. The repair is not to invent a prettier role name. The project first recovers the current claim: a dataset, report, or model-output episteme is being used as evidence for a target claim under a scope, polarity, relevance window, assurance use, weight model, and provenance constraints.

The durable name, if needed, is a name for that evidence-use relation or status-use value under the direct governing pattern. It is not a work-facing U.Role and not a RoleDescription 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 are evidence for local meaning or common practice, not automatic FPF Tech labels. A source term becomes the selected label only after E.24.UK, the governing Concept-Set row, role-description episteme, or direct relation pattern admits it.

#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 for role-method-work alignment; F.8 for mint-or-reuse; F.9 for cross-context bridges; 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 while role state, capability, method fit, 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.

#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.

#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. Sensor capability, 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.

#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 a candidate expression and must decide whether it should stay local, reuse an existing name, become an alias, reuse a Concept-Set row, name a role-description episteme, introduce a new Concept-Set row, introduce a policy id, or become 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 names a work-facing U.Role, a status-use relation, an evidence-use relation, an access or policy term, a relation position, or only a local phrase;
• a source tradition uses a convenient name, but the name would import one context's ontology if promoted as an FPF name;
• a Concept-Set row seems reusable, but its scope may be only naming, not substitution, role assignment, measurement, or structural inference;
• a project wants a new U-kind, policy id, role-description label, or public term because no existing name feels comfortable;
• an E.10 repair discovers that a smoother word would still hide the current kind or relation.

Primary EntityOfConcern. The EntityOfConcern is one mint-or-reuse decision for one candidate expression or proposed durable name. The pattern governs the decision relation. It does not define the named U-kind, does not describe the U.Role, does not assign a holder, does not assert status, does not provide evidence, and does not make a publication authoritative.

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. Recover what the candidate expression is trying to name in the current bounded context. Then choose the smallest admissible decision: local phrase, alias, local name reuse, Concept-Set row reuse, RoleDescription label, direct-pattern name, policy id, new row, or rare U-kind candidate.

What goes wrong if missed. A convenient label becomes a new ontology. A source word becomes global. A status, evidence, access, requirement, source, publication, or relation-position use gets named as a role. A Concept-Set row is used beyond the scope admitted by its bridge evidence. FPF then accumulates duplicate kinds 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 actually current; other expressions go to their direct patterns before any durable naming.

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 a good label after the mint-or-reuse decision is already made, use F.5 for the local name family and F.18 for the fuller public naming protocol.
• 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 cross-context sameness, use F.9 and F.7.
• If the issue is status, evidence, source, standard, requirement, publication, assurance, gate, or decision use, use the direct pattern before naming.

#Problem Frame

Name pressure is often a sign of unresolved ontology. A project wants one short expression, but the expression may stand for several different values: a local sense, a reusable row, a role-description label, a status value, a method name, a work occurrence label, a policy id, or a new U-kind candidate.

The dangerous shortcut is to decide by word form. If the word contains Role, it is treated as a role. If the word appears in two contexts, it is treated as the same concept. If a source standard uses the name, the name is promoted. If the expression is short and readable, it becomes public vocabulary.

F.8 delays naming until the current kind and use are recovered. It is the gate between local expression and durable name, not the naming style guide itself.

#Problem

Without this pattern:

1. Local phrases become durable names. A temporary phrase outlives its context and looks like FPF vocabulary.
2. Source names capture FPF. One tradition's word becomes the selected FPF name before cross-context fit is 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. Concept-Set rows overreach. A row admitted for naming is reused for assignment, measurement, or structural inference.
6. Aliases change meaning. A prettier label is introduced but silently changes kind, scope, or use.
7. Kernel inflation follows comfort. A new U-kind is proposed because existing names feel awkward.
8. Policy ids appear as strings. A policy identifier is reused or introduced without a resolvable policy specification and decision trace.

#Forces

#Solution

Treat mint-or-reuse as a typed decision over a recovered candidate, not as a vote on wording. Use this compact relation:

MintReuseDecision:
  CandidateExpressionSlot:
  BoundedContextSlot:
  RecoveredKindOrRelationSlot:
  LocalSenseRefSlot:
  ProposedUseSlot:
  ReuseCandidateRefSlot:
  DecisionKindSlot:
  DirectPatternRefs:
  NameDisciplineRefs:
  NonAdmissibleOverreadSlot:
  ReopenConditionSlot:

DecisionKindSlot is a local field for the result of this pattern. It does not create a new U.* kind.

Admissible decision kinds:

• localPhraseOnly;
• reuseLocalSenseLabel;
• aliasOnly;
• reuseConceptSetRow;
• nameRoleDescription;
• nameDirectPatternValue;
• introducePolicyId;
• proposeConceptSetRow;
• proposeUKindCandidate;
• blockOrLowerUse.

#Decision Targets

#Decision Sequence

Use this order. Stop at the first result that fits the recovered kind and use.

1. Recover the current claim. Name the bounded context, local sense if known, and the kind or relation being claimed.
2. Split mixed candidates. If one expression covers role, status, evidence, work, method, measurement, or structure at once, split it before deciding.
3. Check local reuse. If one bounded context already has the needed local sense, reuse its label inside that context.
4. Check role expression. If the candidate describes one work-facing U.Role, use F.4 and F.5. If it asserts assignment or performed work, use A.2.1, F.6, or A.15.1. If it is evidence, status, access, requirement, source, publication, assurance, gate, decision, or relation-position use, use the direct pattern.
5. Check cross-context reuse. If more than one context is current, use F.9 bridge discipline and F.7 Concept-Set row discipline. Reuse a row only for the row's admitted use.
6. Check alias. If the meaning is the same and only wording changes, use alias discipline. Do not let an alias change kind or scope.
7. Check policy id. If the candidate is a policy identifier, require PolicyIdRef discipline in F.8:8.1.
8. Propose new row. If the need recurs across contexts and bridges admit the intended use but no row exists, propose a small Concept-Set row.
9. Propose new U-kind only rarely. Use this only when the candidate is cross-family, irreducible to existing FPF values, governed by E.24.UK, and then accepted under the relevant A.8, A.11, C.3, E.9, and F.18 law.
10. Block or lower. If none of the above is true, 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 it names one work-facing U.Role or the role-description episteme for that role in one bounded context.

#Row Scope Consumption

F.8 consumes row scope; it does not define bridge strength. F.9 declares bridges and F.7 declares Concept-Set rows. F.8 asks whether the row's declared use is enough for the proposed name.

If the row does not admit the intended use, lower the name's use or open the direct bridge or row repair. Do not strengthen a name because the wording is attractive.

#Invariants

1. Kind before name. The candidate's recovered kind or relation comes before the label decision.
2. One decision, one current use. Mixed uses are split into separate decisions.
3. Local before cross-context. Reuse local sense labels before proposing cross-context rows or new U-kinds.
4. Aliases are meaning-preserving. An alias cannot change kind, scope, use, or authority.
5. Role names are work-facing. A role name or RoleDescription label must point to a work-facing U.Role; status, evidence, access, source, publication, requirement, assurance, gate, decision, and relation-position uses are direct-pattern names.
6. Role assignment is not naming. A name does not assign a holder and does not show that work was performed.
7. Rows do not exceed their admitted use. F.8 may reuse a row only at the use declared by F.7 and admitted by F.9.
8. New U-kind candidates are rare. Cross-family recurrence, irreducibility, E.24.UK admission, and accepted decision basis are necessary.
9. Policy ids are resolvable. A policy id needs a policy specification reference and, when introduced, a mint decision reference.
10. Source labels are not semantic authority. A source term can be evidence for a local sense or alias, not automatic FPF vocabulary.

#Reasoning Primitives

Candidate expression E has no recovered kind or relation
  -> do not mint; run E.10 or direct precision restoration first.

E names one local sense in context C
  -> reuse local label in C unless durable public use is current.

E names one work-facing Role R in context C
  -> use F.4 and F.5 for RoleDescription naming; use A.2.1 for assignment.

E names an episteme-use, status-use, policy-use, source-use, or relation-position case
  -> recover the direct pattern before any durable name is selected.

E needs cross-context reuse
  -> use F.9 bridge plus F.7 row; F.8 only consumes the admitted row use.

E is a proposed new U-kind
  -> require irreducibility, cross-family recurrence, and an accepted decision record.

#Archetypal Grounding - worked cases

#Reviewer Role vs Review Report

The expression ReviewerRole in PatternReview_2026 names a work-facing role value. F.8 admits nameRoleDescription: use F.4 for the role-description episteme and F.5 or F.18 for the label.

The expression "review report has reviewer role" is different. The report is an episteme. It may be used as evidence or source for an adequacy claim about the reviewed pattern; it does not hold the work-facing role. F.8 does not mint a role name for the report. The evidence-use, source-use, or publication-use claim remains governed by its direct pattern.

#Actor Across BPMN and PROV

A manager wants one word, "actor", for BPMN participant and PROV agent in a diagram. F.8 asks for the intended use. If the Bridge Card and Concept-Set row admit only naming use, the result is reuseConceptSetRow for prose and diagram labels only.

No role assignment follows. If the project subsequently needs a work-facing role in one context, it creates or reuses the local role-description episteme for that context.

#Access Role

An access-control source says ApproverRole. In that source, the expression may name a permission grouping. F.8 first recovers the access or policy relation. Only if the project also defines a work-facing U.Role for approval work in a bounded context does a RoleDescription label become current.

Otherwise the durable name, if needed, belongs to the access, policy, status, or gate pattern, not to role ontology.

#Policy Id

A gate profile introduces Aut-Guard-2026. F.8 treats this as a policy-id decision. Reuse requires a resolvable PolicySpecRef. New introduction also needs a MintDecisionRef or equivalent accepted decision record.

The policy id is not a role, method, gate result, evidence value, or source authority by itself. It is a reference to a policy specification used by the pattern that governs the 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 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 is still 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.

#Filled Decision Records

MintReuseDecision:
  CandidateExpressionSlot: ReviewerRole
  BoundedContextSlot: PatternReview_2026
  RecoveredKindOrRelationSlot: U.Role described by one RoleDescription episteme
  LocalSenseRefSlot: review-work role in PatternReview_2026
  ProposedUseSlot: durable local RoleDescription label
  ReuseCandidateRefSlot: no existing local role-description label fits
  DecisionKindSlot: nameRoleDescription
  DirectPatternRefs: F.4, F.5; F.18 if public reuse becomes current
  NameDisciplineRefs: role label must not encode assignment, capability, method, work, evidence, or status
  NonAdmissibleOverreadSlot: this decision does not assign Alice, show that review work occurred, or make a review report evidence
  ReopenConditionSlot: reopen if the label is used for evidence, status, access, source, publication, or cross-context row claims

MintReuseDecision:
  CandidateExpressionSlot: EvidenceRole
  BoundedContextSlot: PatternReview_2026
  RecoveredKindOrRelationSlot: evidence-use relation around a review-report episteme
  LocalSenseRefSlot: review report used as evidence for an adequacy claim about the reviewed pattern
  ProposedUseSlot: durable name requested for repeated evidence-use wording
  ReuseCandidateRefSlot: no U.Role candidate, because the episteme is not a role holder
  DecisionKindSlot: nameDirectPatternValue or blockOrLowerUse
  DirectPatternRefs: A.10, B.3, G.6, or direct evidence-use pattern
  NameDisciplineRefs: F.5 or F.18 only after the evidence-use relation is recovered
  NonAdmissibleOverreadSlot: do not mint EvidenceRole as RoleDescription or U.Role
  ReopenConditionSlot: reopen if the evidence-use relation changes target claim, polarity, provenance, assurance use, or validity window

#Bias-Annotation

F.8 blocks minting-bias: the existence of a convenient candidate expression, suffix, title, source term, or memorable public phrase does not prove that FPF needs a new name, row, policy id, or U-kind. The decision starts from the recovered governed object, admissible use, bounded context, and direct pattern. Naming is allowed only after the smallest adequate decision target is found.

#Policy-Id Mint-or-Reuse Discipline

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

PolicyIdRef:
  PolicyId:
  PolicySpecRef:
  MintDecisionRef?:
  ScopeOrNamespaceRef:

PolicySpecRef is a resolvable reference to the policy definition. It identifies the policy id, pins an edition or equivalent digest when needed, and can be found from the same publication family or cited source relation.

MintDecisionRef is a resolvable reference to the decision that introduced the policy id in the declared namespace. For FPF normative policy ids this is usually an accepted [E.9](/generated/patterns/E.9) decision record. For local non-exported policy ids, the governing gate, decision, or publication pattern may admit a smaller decision record when the local scope is explicit.

Rules:

1. No silent policy-id introduction. A newly introduced policy id carries both PolicySpecRef and MintDecisionRef.
2. Reuse is reference use. Reusing an existing policy id cites PolicySpecRef; it does not restate policy semantics as if a new policy had been introduced.
3. Gate checkability. A gate, crossing, bridge, assurance, or publication claim that depends on policy ids includes PolicyIdRef or an equivalent resolvable structure admitted by its governing pattern.
4. Policy authority stays with the governing pattern. F.8 decides introduction or reuse of the identifier; it does not decide whether the policy permits work, passes a gate, or gives evidence.

#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;
• Concept-Set rows keep their declared scope;
• F.5 and F.18 are used with better naming inputs because mint-or-reuse has already settled the decision kind;
• policy identifiers become checkable references instead of decorative strings.

Costs:

• authors must do kind recovery before naming;
• some attractive names remain local phrases or aliases;
• public and cross-context names may require bridge, row, naming, and decision records;
• a new U-kind becomes harder to justify because minting now 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, F.4, F.5, F.6, F.7, F.9, F.18, A.6.5, E.10, E.9, A.8, A.11, or policy-id publication discipline changes enough that the decision kinds or boundaries would change.

#Rationale

F.8 is placed before naming style because a naming mistake is often a kind mistake. A project should not ask "what name should we use?" until it has asked "what kind of value or relation is this, and does it deserve durable naming?"

The pattern is intentionally narrower than F.18. F.18 can run a full candidate search, Name Card, public term sheet, lineage, and bridge-facing naming protocol. F.8 supplies the prior admission decision: should this expression become a durable name at all, and if so, under which direct governing pattern?

The strict role decision is central. A role expression names a work-facing role only when U.Role is 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 a source phrase used "role".

#SoTA-Echoing - Source-Use

Source-use boundary: a source tradition may supply candidate words and current practice pressure. It does not select the FPF decision kind. The decision kind follows the recovered value or relation and the direct governing pattern.

#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.7, F.9, 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.14, F.15, F.17, C.3, E.9, E.24.CD, E.24.PUB, and direct status-use, evidence-use, source-use, publication-use, requirement-use, assurance, gate, decision, method, work, characteristic, and architecture patterns.

Constrains.

• F.5 names only after F.8 has decided what kind of naming case is current.
• F.4 governs only work-facing role-description naming cases.
• F.9 and F.7 govern cross-context row admission before F.8 reuses the row label.
• F.18 expands durable public naming after F.8 has admitted the name decision.
• F.14 and F.15 use F.8 to avoid role, status, row, and alias explosion.

Does not replace. Direct governing patterns for the named value, role assignment, performed work, status, evidence, source, publication, requirement, assurance, gate, decision, method, work, relation-slot, characteristic, architecture, or mathematical-lens claims.

#Didactic Memory

Do not ask for a better name first. Ask what the expression is trying to name, whether that value already exists locally, whether any cross-context row admits the intended use, and whether the expression is really a role, status, evidence, policy, source, slot, method, work, or kind case. Mint only after reuse, alias, direct-pattern naming, and row options have failed.

#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.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 relation separate from a claim that it suits a proposed use, the evidence or assurance on which a reader relies, an optional Bridge Card, and any object created when the 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 context is Plain shorthand for the bounded interpretation basis recovered from one cell's <ReferenceScheme, LocalSenseClaim> projection. It is not a U.Entity, U.BoundedContext, selected model-use structure, project, scope, viewpoint, description, designator, or reference. Two expressions under the same projection are a designation question first. 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:

No context, proposed use, use direction, correspondence rule for that use, permitted-loss tolerance, assertion, evidence item, policy, time value, card, publication, registry id, or carrier is a third participant.

An F.9-local BridgePredicateProfile is a by-value predicate declaration, not a U-kind, participant, card, claim, or evaluation result. 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 correspondence or difference condition;
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.

The occurrence is identified by the exact endpoint cells together with the exact profile. For an asymmetric kind, the ordered source-to-receiving relation tuple is identity-bearing and an inverse claim requires another profile and 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 occurrence candidate. A changed proposed use, use direction, rule, tolerance, evidence path, reliance disposition, assurance claim, card, registry entry, publication, form, or carrier does not reidentify 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 Card - an optional C.2.1 claim-bearing episteme about an actual Bridge or a proposed relation candidate; it is not the relation.
• 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:

CL may summarize evidence strength for a stated correspondence: 0 contradicted, 1 weakly comparable, 2 bounded support with explicit counterexamples, and 3 matched stated invariants with no current material counterexample. It is optional and never serves as a use threshold. A CL=3 label does not make a type-structure use suitable; the separate claim must still name the rule and tolerance, and reliance must still pass under A.10 or B.3.

Observed losses, unit differences, counterexamples, and invariant checks belong in the evidence path or card. The proposed use's permitted-loss tolerance belongs in its ClaimGraph. A loss observation can change without reidentifying either the fixed Bridge or the bounded-use claim; it may instead reopen the claim's polarity or the current reliance disposition.

#Bridge occurrence and Bridge Card

Recover the direct relation before describing it. A Bridge may obtain without any card. Use a card only when durable reuse, delayed handoff, evidence review, audit, publication, or costly reversal makes a reusable claim package worthwhile.

BridgeCard:
  ClaimMode: actual | candidate | negative
  BridgeOccurrenceRef?: exact ref, actual mode only
  EntityOfConcern: exact obtaining Bridge, or admitted F.9 Bridge relation kind for candidate or negative mode
  ProposedSourceSenseCellRef?: SenseCellAddressRef
  ProposedReceivingSenseCellRef?: SenseCellAddressRef
  ProposedBridgePredicateProfile?: by-value profile
  BoundedUseClaims?: each with u, d, r, t, polarity, and effective ReferenceScheme
  A10EvidenceUse?: exact evidence-provenance relation plus local RelianceDisposition
  B3Use?: positive assurance claim plus sufficient record, or exact non-positive disposition
  ObservedLossAndCounterexamples?:
  EvidenceWarrantAndCurrentness?:
  NearestNonUse?:
  CardReferenceScheme:

For ClaimMode: actual, the card's exact EntityOfConcern is the already individuated Bridge occurrence. The card may package the Bridge claim, one or more bounded-use propositions, their evidence and polarity, the exact A.10 relation and local disposition or the selected B.3 branch, currentness, and nearest non-use.

For ClaimMode: candidate or negative, no positive occurrence reference exists. The card's EntityOfConcern is the admitted F.9 direct Bridge relation kind. Its ClaimGraph designates the proposed endpoints and profile. candidate states that the proposed Bridge may obtain; negative states that its predicate does not obtain. Any bounded-use proposition in the same graph keeps its own polarity. Completing, approving, registering, or publishing this card creates no Bridge.

The exact <ClaimGraph, EntityOfConcern, effective ReferenceScheme> triple identifies the card episteme. A changed card edition, evidence path, reliance disposition, assurance claim or disposition, registry record, publication occurrence, form, carrier, or layout does not reidentify a fixed Bridge.

#Boundary to coarsening and quantum-like export

Open F.9 when a receiving use needs an actual semantic relation between exact local senses. A lossy or approximate export is not thereby a Bridge, and an actual Bridge is not thereby a quantum-like state transition.

Use this order:

1. resolve the exact F.17 cells, state the relation-semantic profile, and test whether the Bridge obtains;
2. state the proposed use separately as <u,d,r,t> and give the C.2.1 claim its polarity;
3. recover the exact A.10 evidence-provenance relation and local disposition, or the B.3 claim or disposition selected for that use;
4. if the use happened, identify the actual governed object and apply its direct owner;
5. add a Bridge Card only if durable packaging pays;
6. open A.6.3.CSC, C.26.1, or C.26.2 only when coarsening, probe effects, or failure of any faithful-enough report is the live question.

When a state, metric, option, causal reading, or viability claim crosses the semantic boundary, its direct owner states what survives and what is lost. The Bridge supplies only the semantic-correspondence premise; the bounded-use claim supplies only the named suitability proposition.

#Invariants

1. Exact endpoints first. A Bridge has exactly two F.17 SchemeSenseCell participants.
2. No context object. Semantic context is recovered from endpoint content and is not a relation participant.
3. Different context is not enough. Different projections trigger the question but do not establish the relation.
4. Profile contains relation semantics only. Receiving use, direction, use rule, loss tolerance, polarity, reliance, authorization, and receiving objects are absent from profile identity.
5. Obtaining before occurrence reference. A positive Bridge reference appears only after the fixed predicate is true and its dependencies are present.
6. Use claim is separate. Every proposed use names u, d, r, t, and polarity in a C.2.1 claim about the exact Bridge.
7. Reliance is separate. A.10 or B.3, not F.9 or the card, says whether current evidence or assurance supports relying on that claim.
8. Role is not occurrence. The named receiving-use role is ClaimGraph content; any actual Work, assertion, publication, relation, or operation application keeps its own identity and owner.
9. Card separation. Card identity, completion, approval, registration, and publication neither make the relation obtain nor make the use happen.
10. Loss separation. Observed semantic loss is evidence; permitted loss is tolerance inside the bounded-use claim.
11. No authorization by implication. Semantic suitability, evidence reliance, and assurance are not legal, policy, or deontic permission.
12. No silent inverse or composition. An inverse asymmetric relation and any direct A-to-C relation are tested independently.

#Micro-examples

The labels below are readable aliases. An actual case resolves exact F.17 cells and tests one profile before stating a proposed use.

1. Participant versus Agent. A Partial-overlap Bridge may obtain between the exact BPMN and PROV senses. A separate claim may affirm use of the label "actor" in one orientation table under a rule that preserves the stated participation distinction. That claim creates no role assignment.
2. Process design versus Activity occurrence. A Design-spec-to-run-occurrence Bridge may explain the semantic connection. A separate claim can bound an explanatory use; it does not identify a run occurrence from a design artefact.
3. Observation versus SLO fulfilment. A Measurement-evidence-for Bridge can relate the exact senses. A separate claim asks whether the observation sense is suitable for interpreting one named SLO comparison; A.10 or B.3 governs reliance on the evidence.
4. Subtype across OWL and a curated taxonomy. An Equivalence Bridge obtains only under a profile whose relation condition includes the required class-level invariants. A separate claim asks whether one exact type-structure row may use that Bridge under its stated rule and zero material-loss tolerance.
5. Accuracy in metrology versus data quality. A Partial-overlap Bridge can make the shared word intelligible. A bounded-use claim may affirm that the label is suitable in one explanatory table while rejecting transfer of measurement methods or values.

#Worked examples

#Service target and monitoring observation

A service team resolves two exact cells: the ITIL sense of an availability target and the SOSA sense of an availability observation. Profile P-SLO-OBS-v2 states a Measurement-evidence-for semantic relation: the observation sense concerns a measured availability quantity relevant to the target sense, while observation and target remain different kinds of claim. The profile names the endpoint readings, direction of the semantic relation, applicability to the cited editions, Boolean condition, and required quantity-definition dependency. Current meanings satisfy it, so Bridge b-slo-obs obtains.

The team next proposes use u-slo-check: compare one observation result with the target. Direction d-slo is observation-to-target; rule r-slo requires the same quantity kind, aligned windows, and the stated unit conversion; tolerance t-slo permits the named rounding loss but no quantity-kind change. A C.2.1 claim with EntityOfConcern b-slo-obs states affirmative polarity for <u-slo-check,d-slo,r-slo,t-slo>.

Because this is an ordinary bounded evidence use below the B.3 threshold and no assurance claim is made, the team recovers the exact A.10 evidence-provenance graph relation for the observation record and states RelianceDisposition=pass only for u-slo-check. That supports relying on the claim within its boundary. It does not make the SLO fulfilled, authorize acceptance, or prove that comparison Work occurred. Those claims remain with their direct owners.

#Behavioral participant and access role

An exact Partial-overlap Bridge obtains between a BPMN participant sense and a named RBAC role sense when the profile's overlap and difference conditions are satisfied. A separate bounded-use claim proposes the label "actor" for one glossary row, in the stated direction, under a rule that preserves assignment moment, enforcement locus, multiplicity, and accountability differences, with zero tolerance for reading the label as a role assignment. Current evidence can support that label use under A.10.

If a project later says an RBAC role counts for a work step, it must recover an exact U.RoleAssignment under A.2.1 or F.6. The Bridge, affirmative label-use claim, and passing evidence disposition establish no assignment and no performed-work attribution.

#Subtype notions in one structural row

The endpoint senses are OWL2:SubClassOf under a cited OWL profile and curated-taxonomy is-a under one named taxonomy edition. The Bridge profile states Equivalence and makes its direct relation predicate true only when both endpoint meanings use compatible class-level reasoning and satisfy the stated acyclicity and anti-symmetry conditions. When those facts and dependencies are current, the exact Bridge obtains.

A second premise is still required. The C.2.1 claim names the proposed type-structure row, its source-to-receiving direction, the rule that preserves the three invariants, and zero material-loss tolerance. Only an affirmative current claim with passing A.10 reliance, or the positive B.3 assurance branch when that pattern is triggered, supports relying on the row. A contradicted relation invariant makes the Bridge predicate false; a use-specific tolerance failure can instead make the bounded-use claim negative while the Bridge remains unchanged.

#Setpoint versus service target

CTRL:setpoint and ITIL:target share a familiar word but usually have only Partial-overlap or are Disjoint under the exact readings. A proposed substitution in a control calculation receives a negative bounded-use claim because its rule and tolerance cannot preserve the physical-reference meaning. A didactic comparison may receive a different affirmative claim. Neither claim changes which Bridge obtains.

#Common Anti-Patterns and How to Avoid Them