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

#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 (Enactment (U.RoleAssignment + U.RoleEnactment), 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. New U.Types 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: Enactment (U.RoleAssignment + U.RoleEnactment) 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 Enactment (U.RoleAssignment + U.RoleEnactment) with sensing & 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‑CAL + 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 U.Type; 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. Extention patterns in Part C (Sys‑CAL, KD‑CAL, Kind-CAL, Method‑CAL, LCA‑CAL) 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. You do not claim sameness with any other Context; you do not embed behaviour or deontics; you do not mint U.Types here. These local lexical units will become Local‑Senses in F.3 and later addressable SenseCells (Context × Local‑Sense).

#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‑CAL + 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 U.Type, 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.Type 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.Type or other cross-context concept admitted through a Concept-Set row; 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.Type, 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.Type, 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: Concept-Set row for a U.Type; 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.Type 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.Type 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 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.Type or similar cross-context concept gets its name from a Concept-Set row. The name should be neutral with respect to the witnesses and should name the least shared kind that the row 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.Type 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 proof that someone 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 or interface slot names borrow role morphology and collide with U.Role.
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.Type, 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.Type, 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 Concept-Set row for U.Type; 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.Type 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/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.

| CC-F5-10 | Public or cross-context reuse invokes F.18, F.17, or F.9 as needed. |

#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.Type 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.Type 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.Type names and RoleDescription labels so that Part F does not preserve role and status fusion.

#SoTA-Echoing and 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 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. 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.Type 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.

#Footer Marker

#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. Role-assignment and work-attribution check.

Use this pattern when a project has a role description, role label, assignment notation, or work record and needs to decide whether it can make a work-facing U.RoleAssignment claim or attribute performed work through that assignment.

Typical moments:

• a method description names ReviewerRole, OperatorRole, InspectorRole, TransformerRole, or another required role, and the project must decide which holder bears that role in the bounded context;
• a work record says "Alice reviewed", "Robot-7 inspected", "the operations team approved", or "the CI service deployed", but the holder, role, bounded context, assignment window, or performed-by relation is not explicit;
• a source text uses Holder#Role:Context@Window, RoleEnactment, "assigned role", "played role", or "acted as" and the project must recover the typed assignment relation rather than preserve source notation as ontology;
• a status, evidence, requirement, source, standard, dashboard, model card, publication, or report is being described with role language, and the project must decide that this is not a work-facing role assignment;
• a cross-context role-like word appears, and the project must keep the local role assignment separate from any F.9 bridge or F.5 naming question.

Primary EntityOfConcern. The EntityOfConcern is the role-assignment and performed-work attribution check: a bounded check over a candidate U.RoleAssignment and, when current, a U.Work occurrence that may cite that assignment through Work.performedBy or RoleEnactmentFact. The check is not the role value, not the role description, not the work occurrence, not a status assertion, not evidence, and not a publication form.

Primary working reader. The first reader is an engineer-manager, analyst, method author, or FPF author who must keep a role label, role description, assignment relation, method requirement, work occurrence, status-use relation, and evidence-use relation from becoming one under-typed "enactment" claim.

First useful move. Recover the candidate holder, role value, bounded context, and assignment window or window disposition. Then decide whether the current claim is only assignment admission, performed-work attribution under an assignment, or a status, evidence, source, or publication claim governed outside F.6.

What goes wrong if missed. A role description becomes proof that a holder has a role. A work record names a person or label but not the role assignment that made the work attributable. A report, standard, requirement, or dashboard is made into a role holder because it constrained, evidenced, justified, displayed, or described work. Source U.RoleEnactment wording grows back into a second run-time ontology beside U.Work and U.RoleAssignment.

What this buys. The reader gets one small local check: who or what can bear the role, in which context and window, and whether a specific work occurrence may be attributed through that assignment. Status, evidence, source, publication, method, capability, and bridge claims remain with their direct patterns.

Not this pattern when.

• If the current claim is the role value itself, use A.2.
• If the current claim is the role-description episteme, use F.4.
• If the current claim is durable naming of a role or type label, use F.5 or F.18.
• If the current claim is the U.RoleAssignment relation value itself and its SlotSpecs, use A.2.1.
• If the current claim is role state or enactable-state admission, use A.2.5.
• If the current claim is capability, use A.2.2.
• If the current claim is method, method description, work plan, performed work, or role-method-work alignment beyond the assignment check, use A.15 and its subpatterns.
• If the current claim is status, evidence, source, standard, requirement, publication, assurance, gate, or decision use of an episteme, use the direct pattern for that relation, such as F.10, A.10, B.3, C.28, E.17, or E.10.D2.
• If the current claim is cross-context sameness, translation, or substitution, use F.9.
• If "role" means a relation position, use A.6.5 SlotSpec discipline.

#Problem Frame

Role assignment sits between a role description and performed work. A role description lets a reader recognize InspectorRole or ReviewerRole; it does not assign a holder. A work occurrence may be performed by a holder under a role assignment; it is not the assignment itself. A status value, evidence relation, standard-use relation, requirement-use relation, or publication cue may constrain, evidence, qualify, or display a work-admission relation; it is not a role holder and not performed work.

A common source shape mixes these questions into one "role assignment and enactment cycle" with a status branch. That made the pattern convenient but ontologically noisy. A status assertion and a work-facing role assignment have different subjects, slots, evidence, windows, and direct governing patterns. Putting them into one cycle made status look like a kind of role assignment and made RoleEnactment look like a durable run-time object.

F.6 therefore becomes a check pattern. It asks whether the current local claim can use a recovered U.RoleAssignment, and whether a current U.Work occurrence can cite that assignment. If the current claim is status, evidence, source, publication, bridge, capability, or method, F.6 names the direct governing pattern and stops.

#Problem

Without this pattern:

1. Role-description proof. A role-description episteme or role label is treated as proof that a holder bears the role.
2. Assignment and work collapse. A work occurrence is treated as if it were the assignment, or an assignment is treated as if work already happened.
3. RoleEnactment reification. RoleEnactment becomes a second durable U-kind beside U.Work and U.RoleAssignment.
4. Status branch returns. Status assertions are processed as if they were the same kind of result as role assignment.
5. Episteme-role drift. Standards, reports, datasets, requirements, model cards, dashboards, and publications become "role holders" because they are useful in project reasoning.
6. Window and state loss. A holder-role-context statement is used for current work without saying whether assignment currentness or role-state admission matters.
7. Cross-context overreach. A familiar role-like label from another canon is used to justify local assignment without a bridge.
8. Notation replaces relation. Holder#Role:Context@Window is copied as if the string were the assignment value.

#Forces

#Solution

Use F.6 as a local check over candidate assignment and optional work attribution.

RoleAssignmentAttributionCheck:
  CandidateRoleDescriptionRef:
  CandidateHolderRef:
  CandidateRoleValueRef:
  BoundedContextRef:
  AssignmentWindowDisposition:
  HolderAdmissionDisposition:
  RoleStateAdmissionRef:
  CapabilityRequirementRef:
  MethodOrMethodDescriptionRef:
  WorkOccurrenceRef:
  PerformedByRelation:
  AssignmentJustificationRef:
  EvidenceOrSourceUseRefs:
  BridgeRef:
  NotCarried:
  Result:

This check is not a new root kind. It is an application relation over values governed elsewhere. [A.2.1](/generated/patterns/A.2.1) governs U.RoleAssignment; [A.15.1](/generated/patterns/A.15.1) governs the U.Work occurrence; [F.10](/generated/patterns/F.10), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [E.17](/generated/patterns/E.17), [E.10.D2](/generated/patterns/E.10.D2), and direct governing patterns govern status, evidence, assurance, publication, and source-use relations.

#Slot Meanings

#The Check Sequence

Use these questions in order. They are judgement questions, not a U.WorkPlan, registry procedure, or tool protocol.

1. Role meaning recovered? Does the role label point to a U.Role in one bounded context, usually through F.4 and A.2?
2. Holder admitted? Is the candidate holder a system or acting holon admitted by A.2.1 and by the local role description?
3. Context and window adequate? Is the bounded context explicit, and is the assignment window filled, inherited, unknown, not asserted, or not current for the claim?
4. Related prerequisites current? Does this use need role state, capability, method, method description, work plan, evidence, gate, decision, or source-currentness?
5. Work occurrence current? Is there a U.Work occurrence to attribute? If not, stop at assignment admission or blocker.
6. Performed-by relation admissible? Can the work occurrence cite the assignment by Work.performedBy = RoleAssignment or RoleEnactmentFact?
7. Claim governed outside F.6? If the current claim is status, evidence, source, publication, requirement, assurance, bridge, method, capability, or gate use, apply the direct governing pattern and do not encode that claim as role assignment.

#Assignment Result vs Work-Attribution Result

Keep two local results separate.

AssignmentAdmission:
  CandidateHolderRef bears CandidateRoleValueRef in BoundedContextRef
  with AssignmentWindowDisposition and HolderAdmissionDisposition.

PerformedWorkAttribution:
  WorkOccurrenceRef performedBy RoleAssignmentRef
  with RoleEnactmentFact only when a named fact is useful.

An assignment admission does not prove that work happened. A performed-work attribution does not prove that the method was valid, the capability was sufficient, the evidence is adequate, or the gate passed. Those claims use their governing patterns.

#RoleEnactmentFact

Use RoleEnactmentFact only as a name for the derived fact that a work occurrence was performed under a role assignment.

RoleEnactmentFact:
  workOccurrence: U.Work
  performedBy: U.RoleAssignment
  methodTrace?: U.Method or U.MethodDescription reference when current
  window?: inherited from work occurrence or role assignment when current

Do not write U.RoleEnactment as a durable root kind. If a log, table, database row, or publication stores a role-enactment entry, treat it as a record of this fact unless a direct governing pattern admits record-as-value for that use.

#Status and Evidence Claims Governed Outside F.6

Status and evidence claims often sit next to role assignment. They do not become role assignment.

#Compact Notation and Shortcut Boundary

Holder#Role:Context@Window is allowed as a compact reading aid after the typed relation is recoverable.

Baseline relation:

RoleAssignment:
  HolderSlot:
  RoleValueSlot:
  BoundedContextSlot:
  AssignmentWindowSlot:

Compact notation:

Holder#Role:Context@Window

The compact notation saves reader effort in examples, tables, and short work records. It weakens the representation by hiding SlotSpec names and any current assignment justification, role state, capability, method, evidence, source, or provenance relation. Therefore it is admitted only for local reading, examples, and compact citations after the typed slots are either filled, inherited, or explicitly not current for the claim.

Do not use the compact notation as proof of assignment, proof of performed work, proof of capability, proof of method validity, proof of status, or proof of gate passage. If reliance-bearing use depends on any hidden slot, unfold the notation to the typed relation or lower the claim.

#Invariants

1. Role assignment is local. Every assignment check names one U.Role, one admitted holder, and one U.BoundedContext.
2. Role description is not assignment. A role-description episteme may identify the role value; it does not assign a holder.
3. Assignment is not work. A U.RoleAssignment can be admitted without any U.Work occurrence.
4. Work attribution is direct. Performed work cites the role assignment through Work.performedBy = RoleAssignment; RoleEnactmentFact is only a named fact over that relation.
5. No durable U.RoleEnactment. Source U.RoleEnactment wording is repaired to direct performed-by wording or RoleEnactmentFact.
6. Status is not a role branch. Status-use statements are governed by F.10 or the direct status pattern, not by F.6.
7. Epistemes are not role holders by use. Evidence, source, standard, requirement, definition, explanation, publication, assurance, and gate uses of epistemes go to their direct relations.
8. Window honesty. If a stronger claim depends on assignment currentness, role state, or work time, missing window content lowers or blocks that claim.
9. Bridge restraint. Cross-context role-like labels need F.9; a bridge does not mutate a local assignment.
10. Notation restraint. Holder#Role:Context@Window is source or shorthand notation for a typed assignment relation, not the relation's ontology.

#Reasoning Primitives

RoleDescription RD describes Role R in Context C
  and Holder H is admitted for R in C
  -> candidate RoleAssignment(H, R, C).

RoleAssignment RA is admitted
  and Work W is a current U.Work occurrence
  and W performedBy RA is admitted
  -> RoleEnactmentFact(W, RA) may be named.

Source episteme E is used as evidence, standard, requirement, source, publication, or status bearer
  -> no RoleAssignment holder is recovered from that use alone.

Role-like label L comes from another bounded context
  -> no assignment substitution without F.9 bridge and local A.2.1 check.

#Archetypal Grounding

#Robot Inspection

A maintenance line has a role-description episteme for InspectorRole. A shift note says Robot-7 inspected Pump-12.

F.6 recovers:

CandidateHolderRef: Robot_7
CandidateRoleValueRef: InspectorRole
BoundedContextRef: MaintenanceLine_A
AssignmentWindowDisposition: filled by shift window
WorkOccurrenceRef: InspectionWork_2026-06-15-09
PerformedByRelation: InspectionWork_2026-06-15-09 performedBy Robot_7#InspectorRole:MaintenanceLine_A@shift
Result: workAttributionAdmitted, if A.2.1 and A.15.1 checks pass

This does not prove the robot's sensor capability, the inspection method's adequacy, or the quality of the result. Those claims use capability, method, evidence, and assurance patterns.

#Review Report and Reviewer

A review report is an episteme. The reviewer is a person, service, or team modeled as an acting holon.

The sentence "Report R has reviewer role" is repaired by asking two questions:

• Who or what performed the review work under ReviewerRole?
• How is report R being used now: as evidence, source, publication, or result?

The reviewer holder may be assigned a U.RoleAssignment. The report does not hold the role. Evidence use of the report goes to the evidence-use pattern.

#Standard Used in Safety Work

A safety method description cites ISO 26262. The source phrase says that the standard has the "normative role" in the safety case.

F.6 result:

Result: claimGovernedOutsideF6
NotCarried: no HolderSlot, no U.RoleAssignment, no performed work

The standard is an episteme used through standard-use, source-use, requirement-use, or specification-use relations. A safety engineer or tool service may separately hold SafetyAnalystRole when performing work with that standard.

#Access Label and Actual Approval Work

An RBAC directory says Alice has DB-Admin. That directory state is an access or policy status in its own bounded context. It is not automatically a work-facing ApproverRole.

If Alice approves a database migration, F.6 can check a separate assignment and work attribution:

Alice#ApproverRole:MigrationApprovalContext@approval-window
ApprovalWork_481 performedBy Alice#ApproverRole:MigrationApprovalContext@approval-window

The RBAC status may justify or constrain the approval only through the direct access, policy, evidence, source, or gate pattern that admits that use.

#Bias Annotation

#Conformance Checklist

Use this checklist when applying F.6.

1. The candidate role is a U.Role in one bounded context, not only a source label.
2. The candidate holder is a system or acting holon admitted by A.2.1.
3. The assignment window is filled, inherited, unknown, not asserted, or not current for this claim.
4. If role state matters, an A.2.5 role-state admission or blocker is named.
5. If capability matters, an A.2.2 capability relation or blocker is named.
6. If method or method description matters, A.3.1, A.3.2, or A.15 is named.
7. If actual work is claimed, the U.Work occurrence is named under A.15.1.
8. Performed work uses Work.performedBy = RoleAssignment or RoleEnactmentFact, not U.RoleEnactment.
9. Status, evidence, source, standard, requirement, publication, assurance, gate, and decision uses are not encoded as role assignment.
10. Cross-context role-like reuse is represented by F.9 and does not mutate the local assignment.
11. Compact notation is unfolded to typed assignment slots before reliance-bearing use.
12. NotCarried names the strongest tempting overclaim that this F.6 check does not make.

#Common Anti-Patterns and Repairs

#Consequences

Using F.6 makes role-assignment reasoning narrower and more reliable. A project can still use compact assignment strings and familiar role words, but reliance-bearing claims must expose the holder, role, bounded context, assignment-currentness disposition, and performed-by relation when actual work is claimed.

The cost is one extra split. A source sentence that says "role enacted" may become two or three typed statements: assignment admitted, work performed by that assignment, and evidence or status relation used for downstream reliance. That split is intentional. It prevents duplicate role ontologies and makes audit, bridge, capability, method, and status checks local.

#Rationale

U.RoleAssignment is first-class because work attribution needs a stable holder-role-context relation. RoleEnactmentFact is not first-class because the fact is derived from a work occurrence and its performedBy assignment. Status-use and evidence-use relations are not branches of role assignment because their EntityOfConcern and slot discipline differ: they qualify claims, epistemes, standards, requirements, publications, gates, or decisions rather than assigning acting holders to work-facing roles.

The pattern is deliberately thinner than A.15. It does not rebuild the full role-method-work alignment. It gives Part F a local check that keeps role-description, naming, bridge, status, and work-attribution uses from crossing wires.

#SoTA-Echoing and Source-Use

External traditions such as RBAC, BPMN, PROV, service management, safety standards, and process-notation traditions use "role", "activity", "participant", "status", "approval", and "execution" in different ways. F.6 does not treat any one tradition as semantic authority. The FPF role-assignment ontology recovers the bounded context and local role value first; assigns acting holders only through U.RoleAssignment; represents performed work through U.Work; and represents evidence, status, source, publication, and bridge claims through their own patterns.

When a source tradition is current, cite it through the direct source-use or bridge relation. Do not let source prestige, familiar vocabulary, or a popular notation collapse FPF kinds.

#Relations

Builds on: A.2 for U.Role, A.2.1 for U.RoleAssignment, F.4 for role-description epistemes, and F.5 for role and type naming.

Uses when current: A.2.5 for role-state and enactable-state admission; A.2.2 for capability; A.15, A.15.1, A.3.1, and A.3.2 for method, method description, work plan, and performed work; A.6.5 when role-like words are relation positions.

Direct governing patterns: F.10, A.10, B.3, C.28, E.17, E.17.0, E.17.2, E.10.D2, gate, decision, publication-use, source-use, standard-use, requirement-use, and assurance patterns when the current claim is not work-facing role assignment or performed-work attribution.

Coordinates with: F.9 for cross-context bridge claims; F.18 for durable public names; E.10 and E.10.ARCH for wording-use recovery when source language hides the current kind.

#Footer Marker

F.6 closes when the project knows whether the current local claim is:

• an admitted or blocked U.RoleAssignment;
• an admitted or blocked performed-work attribution through Work.performedBy = RoleAssignment or RoleEnactmentFact;
• a lowered claim with missing holder, role, context, window, role state, capability, method, work, or source-currentness;
• or a non-F.6 status, evidence, source, publication, bridge, method, capability, gate, decision, or assurance claim.

#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 U.Types, 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. New U.Types 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 that U.RoleEnactment points to 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.Type 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.Type, 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.Type, 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.Type 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.Type 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 proof that a holder 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.Type 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;
• proposeUTypeCandidate;
• 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.Type only rarely. Use this only when the candidate is cross-family, irreducible to existing FPF values, and governed by an accepted decision record.
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.Types.
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 or prove performed work.
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.Type candidates are rare. Cross-family recurrence and irreducibility are necessary; an accepted decision record governs the change.
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.Type
  -> require irreducibility, cross-family recurrence, and an accepted decision record.

#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. It sends the case to evidence-use, source-use, or publication-use patterns.

#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.Type 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, or bridge relation under current patterns. If it is still cross-family, irreducible, and needed by several domain families, the proposal goes to A.8, 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, prove review work, 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

#Conformance Checklist

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

#Common Anti-Patterns and Repairs

#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.Type becomes harder to justify.

Reopen F.8 when 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, 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 and 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, 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, 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 type case. Mint only after reuse, alias, direct-pattern naming, and row options have failed.

#Footer Marker

#F.8:End

#Alignment and Bridge across Contexts

Status: Stable

"Translate across contexts; never collapse them."

Type. Architectural pattern. Status. Stable. Normativity. Normative. Builds on: E.10.D1 (context discipline: Context = U.BoundedContext); F.0.1 (senseFamily and status-modality guard; bridge-only crossing); F.1 (contexts fixed); F.2 and F.3 (SenseCells exist); F.7 (Concept-Set rows depend on bridges); F.8 (mint-or-reuse decision consumes bridge results without strengthening them).

Coordinates with: A.2, A.2.1, F.4, F.5, F.6, and A.15.1 for work-facing role, role-description, role-assignment, and performed-work claims; A.6.5 for relation-slot discipline; C.29 for mathematical-lens use; B.3 for assurance penalties; 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. Provide a conceptual discipline for relating SenseCells from different U.BoundedContexts. A Bridge states what relation holds, which direction matters, how much congruence is admitted by CL, what is lost, and which cross-context use remains admissible.

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 row in the Concept-Set table.

Primary EntityOfConcern in plain terms. One Bridge Card relating two SenseCells across different U.BoundedContexts. The EoC is not a transport chain, not a work process, not a role assignment, and not one global meaning layer.

Admissible move in plain terms. Declare bridge kind, direction, CL, loss, and admitted use so cross-context sense use stays inspectable without collapsing local meanings into silent equivalence.

Primary working reader. An author, checker, or practitioner preparing one bridge card, comparative bridge note, or concept-set row that depends on cross-context sense use.

Use this when. Use F.9 when the same term, role name, quality label, status label, measurement label, method label, or structural label appears in more than one context and the team is about to treat that overlap as if it were already equivalence or safe substitution.

What goes wrong if missed. Teams fall back to shared labels, string-equals shortcuts, or informal analogies, then quietly smuggle equivalence, substitution, structural inference, or role assignment across contexts without stating kind, direction, CL, or loss.

What this buys. One explicit bridge discipline that lets a team compare contexts and reuse names while keeping direction, loss, and the limits of admissible substitution visible.

Not this pattern when. Not F.9 when the case is still only one local context, when the needed claim is a role assignment, performed-work attribution, evidence use, status use, source use, publication use, assurance claim, gate claim, decision claim, or mathematical-lens use. Use the direct governing pattern first; cite F.9 only when cross-context sense alignment itself is live.

Recognition versus assurance note. Intent, applicability, this boundary, and the first worked case are the recognition block. Bridge kinds, CL, conformance, and relation sections are assurance blocks; they tighten the same Bridge Card claim instead of widening F.9 into role assignment, work execution, governance, or one global meaning layer.

#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. Scope creep. A naming convenience is stretched into role assignment, status transfer, work attribution, evidence use, or structural inference.
3. Design-run jumping. Design artefacts are substituted for run-time occurrences, or run-time occurrences are treated as design definitions.
4. Direction amnesia. Narrower and broader relations are treated as symmetric.
5. Loss blindness. Differences in unit, granularity, precondition, time stance, enforcement locus, or viewpoint are left unstated.

F.9 answers these failures by making relation, direction, loss, CL, and admitted use explicit.

#Forces

#Core idea

A Bridge is a declared correspondence between two local senses. It always names:

1. the two SenseCells,
2. bridge kind,
3. direction if direction matters,
4. CL,
5. Loss Notes,
6. counter-example or invariant evidence,
7. admitted use.

Some Bridges admit naming or bounded substitution of sense. Interpretation Bridges admit explanation only. A Bridge never creates a U.RoleAssignment, never attributes performed work, never turns an episteme into evidence by itself, and never mints a universal type.

#Minimal vocabulary

• Context - shorthand for U.BoundedContext per E.10.D1.
• SenseCell - the pair (Context, Local-Sense) from F.3.
• Bridge - a declared relation between two SenseCells with kind, direction, CL, Loss Notes, and admitted use.
• CL (Congruence Level) - ordinal congruence class 0..3 for one Bridge.
• Admitted use - what the Bridge lets a downstream claim do without overclaim.
• Naming-only - cross-context prose label or Concept-Set row label only.
• Role-description naming - a row or label may inform a RoleDescription name for one local U.Role; it does not assign that role and does not attribute performed work.
• Type-structure - structural inference across contexts; admissible only at CL = 3 with named invariants.
• Explanation-only - interpretation relation across sense families; no row substitution and no direct role, status, work, evidence, gate, or decision effect.
• senseFamily - the local meaning family used by Part F, such as Role, Status, Measurement, Type-structure, Method, Work occurrence, Evidence-use, or Policy-use. A senseFamily label is not a durable U.Type by itself.

#Bridge kinds

F.9 distinguishes substitution bridges from interpretation bridges.

#Substitution bridges

These relate SenseCells in the same senseFamily and may admit bounded substitution of sense.

1. Equivalence - near-identity of sense. Symmetric and rare. Use: may admit Type-structure rows only when CL = 3 and invariants match. Loss Notes: none or profile-level differences, with the invariant evidence stated.

2. Narrower-than and Broader-than - proper inclusion of sense. Directional. Use: narrower-to-broader may admit Naming-only and, at CL >= 2, role-description naming or other same-family name reuse. Broader-to-narrower is not admitted unless a separate Bridge states it. Loss Notes: special cases, enforcement conditions, or local constraints that fail to carry.

3. Partial-overlap - non-empty intersection where neither sense includes the other. Use: Naming-only at best. It never admits role assignment, performed-work attribution, or Type-structure inference. Loss Notes: A-only sense and B-only sense.

4. Disjoint - explicit contrast. Use: contrastive explanation only. Loss Notes: not applicable; the claim is incompatibility.

#Interpretation bridges

These explain connections across senseFamily boundaries. They do not admit substitution or Concept-Set rows beyond local explanation.

5. Design-spec-to-run-occurrence - a design sense relates to a run-time occurrence sense. Example: BPMN:Process to PROV:Activity. Use: explain design-to-run correspondence. Loss Notes: process model versus occurrence, control structure versus temporal extent.

6. Measurement-evidence-for - a measurement sense evidences or quantifies another sense. Example: SOSA:Observation to ITIL:SLO fulfilment. Use: explain evaluation; direct evidence-use remains with A.10, B.3, E.17, F.10, or the local status pattern.

7. Policy-constraint-on - a policy or deontic sense constrains another sense. Example: ODRL:Duty to service behavior. Use: explain a constraint relation; direct policy, gate, or authority claims remain with the governing pattern.

8. Viewpoint-correspondence - one view, report, model, dashboard, or viewpoint-bound episteme corresponds to another view over an EntityOfConcern. Use: explain cross-view comparison; direct architecture-description, episteme, publication, or source-use claims remain with their governing patterns.

#CL scale and admitted-use thresholds

Thresholds:

• A Naming-only row requires CL >= 1.
• A Role-description naming row requires CL >= 2, the same Role senseFamily, and stated local-role losses. It still does not create a U.RoleAssignment.
• A Type-structure row requires CL = 3 and matched invariants such as acyclicity, anti-symmetry, unit transform, cardinality, or signature-preserving relation shape.
• Interpretation Bridges remain Explanation-only regardless of CL.

B.3 may convert CL into an assurance penalty when a cross-context claim uses a Bridge.

#Bridge Card

Use this compact record when a Bridge claim matters:

BridgeCard:
  CellA:
  CellB:
  senseFamilyA:
  senseFamilyB:
  BridgeKind:
  Direction:
  CL:
  LossNotes:
  CounterExampleOrInvariantEvidence:
  AdmittedUse:
  NonAdmittedUse:
  DirectGoverningPatternIfNotF9:
  RevisionTrigger:

AdmittedUse states the strongest use the Bridge permits. NonAdmittedUse names the tempting overclaim, such as role assignment, work attribution, structural inference, source authority, or evidence use. DirectGoverningPatternIfNotF9 points to the pattern that must govern that overclaim before it may become a claim.

BridgeId and policy or edition identifiers cited by a Bridge Card are registry references, not semantic symbols exported by signatures. Do not demand them through SignatureManifest.provides; validate that referenced registry entries exist and are edition-pinned when required.

#Boundary to coarsening and quantum-like export

Use F.9 first when meaning, label, relation, field, record, model output, report, or representation crosses a bounded context or publication context. A bridge does not become quantum-like because it is lossy, approximate, contextual, or hard to translate. It becomes quantum-like only when the bridge or export claim still depends on order sensitivity, incompatible frames, a probe that changes represented state, or no faithful-enough export for the intended use.

Boundary sequence:

1. Build the ordinary Bridge Card first: cells, sense families, kind, direction, CL, loss, counter-example or invariant evidence, and admitted use.
2. State which state, relation, evidence, metric, option, or viability claim is said to survive the crossing.
3. State what the crossing omits, coarsens, re-keys, reframes, makes incomparable, or makes unsafe for the intended downstream use.
4. If the bridge or export claims to preserve action, intervention, manipulation, explanation, or cross-scale structure, state the causal-abstraction or approximate-causal-abstraction mapping before treating the coarsened bridge as a C.26 issue.
5. If asking, measuring, exporting, rendering, or bridging changes the represented state itself, coordinate with C.26.1.
6. If coordinated work or live state is not exported faithfully enough for the intended use by any one report or bridge, coordinate with C.26.2.
7. If the crossing is a state representation with declared source-loss mode or reduced recoverability, coordinate with A.6.3.CSC, A.6.3.RT, and C.26.

When the bridge result will be reused for decision, comparison, assurance, release, audit, or cross-context action, add a state-export line to the Bridge Card: