#Cluster F.I — context of meaning & Raw Material

Preface node heading:cluster-f-i-context-of-meaning-raw-material:47294

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

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 I/D/S layer for intension/description/specification; 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 artefact 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 design/run tag 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 surface strings.
• When the surface prose 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 Artefacts (conceptual, notationally neutral)

These artefacts 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 design/run, 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: Strong, 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 sign on the door (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 (attenuating)

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

• cl* := min(cl₁, cl₂) (do not inflate confidence)
• rel* := weaken(rel₁, rel₂) (e.g., near‑equiv ∘ overlaps → overlaps)

Reading: Chained passages degrade to the weakest link.

#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 sufficiently strong Bridges 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 design/run, 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 weakens 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 attenuation.

#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/describedEntity 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 defer 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 axis) 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. Design/run 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/describedEntity (=USM.ScopeSlice(G) ⊕ describedEntity(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 a strong urge 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/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 / 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 object/description/carrier and design/run 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/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 and defer it. Keep the cut small enough to remember. With Contexts fixed, harvesting (F.2), local clustering (F.3), role/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; defer details to 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. I/D/S layer 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/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 = surface 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/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 design/run.

#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 (RCS + RoleStateGraph + Checklists)

“Name the mask or the badge — and say what it commits to — but only inside a Context.” Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); E.10.D2 Intension–Description–Specification Discipline; F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting; F.3 Intra‑Context Sense Clustering; A.2.1 U.RoleAssignment; A.7 Strict Distinction; A.11 Ontological Parsimony. Coordinates with. F.5 Naming Discipline for U.Types & Roles; F.7 Concept‑Set Table; F.9 Alignment & Bridge Across Contexts; B.3 Trust & Assurance Calculus (for later status evaluation). Aliases (informative). Mask/Badge card; role card (plain only).

#Intent & applicability

Intent. Provide a conceptual template for two kinds of assignables:

• Role Template — a behavioural mask that a holder can wear in a specific Context (U.BoundedContext), shaping how it acts (via Method/Execution relations).
• Status Template — an epistemic or deontic badge that a holder (or artefact, event, claim) can bear inside a Context, shaping how it is treated (evaluation, permission, standing).

Each template is grounded in a SenseCell ⟨Context, Local‑Sense⟩ from F.3 and declares minimal invariants that later assignments must satisfy. No Cross‑context meaning is imported here.

Applicability. Whenever you need to speak precisely about what it means to be a Participant (BPMN), hold an access‑role (RBAC), be an Incident (ITIL), or carry a Verified status (evidence line), before minting U.Types or drawing Cross‑context bridges.

Non‑goals. No workflows, no storage, no editors. No equations for assurance or control; those live in Part B/C. This pattern describes how to think and speak about assignables — not how to manage files.

#Problem frame

Without explicit Role Descriptions:

1. Role/status conflation. Access role (RBAC) treated as behavioural mask (BPMN participant); deontic duty treated as runtime effect.
2. Context drift. A “role” quietly starts meaning different things across canons; later assignments contradict each other.
3. Hidden commitments. We name a role/status but never state what must hold when it is assigned; downstream reasoning becomes arbitrary.
4. Premature unification. A single template tries to straddle several Contexts; losses remain implicit.

#Forces

#Minimal vocabulary (this pattern only)

• Context — U.BoundedContext (per E.10.D1).
• Local‑Sense — a consolidated sense in a Context (F.3).
• SenseCell — the address ⟨Context, Local‑Sense⟩.
• Role Template — behavioural mask defined in a Context, later bound by U.RoleAssignment.
• Status Template — epistemic/deontic badge defined in a Context, later asserted as a claim about a holder/artefact.
• Holder — the thing that may wear a mask or carry a badge (e.g., a U.System, U.MethodDescription, U.Work, U.Episteme).

#Core idea (didactic)

A Role Description is a small card that says: (i) which Context’s sense it relies on (SenseCell), (ii) what label we use to speak about it (Tech & Plain), and (iii) what must hold when someone wears the mask (Role) or bears the badge (Status).

It is not a definition by prose alone; it is a pledge of invariants — minimal, Context‑true, and later checkable.

#The Role Description Card (one‑screen sketch)

Each bullet is a thought‑item, not a file field.

Header

• Template kind: Role | Status
• Label pair: Tech (idiomatic) - Plain (didactic) (naming discipline in F.5)
• SenseCell: ⟨ContextId, Local‑Sense label⟩

Applicability

• Holder scope: what can wear/bear it (e.g., U.System, U.Work, U.MethodDescription, U.Episteme).
• Time stance: design / run aligned to the Context (F.1).
• Preconditions (Context‑true): crisp conditions that must already be true in the Context’s idiom.

Invariants (minimal)

• Behavioural invariants (Role) or Evaluation invariants (Status) — 2–5 short lines stating what must hold after assignment/assertion, using the Context’s vocabulary and SenseCells where needed.
• Separation guard: a one‑line reminder of what this template does not imply (prevents senseFamily mixing).

Consequences (informative)

• Typical interactions: which Method/Execution/Observation constructs (by SenseCell) this template usually touches — names only.
• Common misreads (trip‑wire): 1–2 bullets to prevent known confusions.

Memory rule: If your card can’t be read in under two minutes, you are writing a manual, not a template.

Autonomy hooks (when Role may act autonomously)

• RCS additions (illustrative): AgencyLevel ∈ {None, Assisted, Delegated, Autonomous}, SafetyCriticality ∈ {SC0..SC3}.
• RSG gate: mark which states are enactable under autonomy (cf. A.2.5); link to AutonomyBudgetDeclRef.
• References: If autonomy is claimed for this Role, the Role Description MUST reference: AutonomyBudgetDeclRef (id, version), Aut-Guard policy-id (PolicyIdRef), OverrideProtocolRef.
• Checklist: include a pre‑enactment checklist item “Autonomy Green‑Gate passed” (guard verdicts present).

#Normative invariants (template discipline)

1. context‑local grounding. Every Role Description MUST cite exactly one SenseCell as its semantic locus.
2. I/D/S layer separation.
   • A Role Template MUST NOT encode deontic, access, or measurement rules.
   • A Status Template MUST NOT encode behaviour or control flow.
3. Time honesty. The card’s stance (design/run) MUST match the Context’s stance (F.1).
4. Minimality. Invariants SHOULD be the fewest that decide the assignment; avoid procedural sequences.
5. No Cross‑context smuggling. A single card MUST NOT import foreign semantics; if two Contexts are needed, the relation is handled later in F.9.
6. Label fidelity. Tech label MUST be idiomatic to the Context; Plain label MUST not widen the sense (F.3).
7. Binding Standard (roles). A Role Template is the design‑time mask; at run‑time, a U.RoleAssignment creates System‑in‑Role instances that are subject to the card’s invariants.
8. Assertion Standard (statuses). A Status Template is a badge; asserting it commits to the card’s evaluation invariants and to the Context’s way of checking them (later anchored via SenseCells, not formulas here).

#Reasoning primitives (judgement schemas, notation‑free)

Conceptual moves only; no APIs, no data stores.

1. Template grounding Template T cites SenseCell ⟨C,σ⟩ ⊢ meaning(T) is local to C Reading: The template’s meaning is context‑local.

2. Role assignability holder h, RoleTemplate T, preconds_T(h) ⊢ assignable(h,T) Reading: If the preconditions hold for h, it is eligible to wear the mask T.

3. Role assignment obligation assignable(h,T) ∧ bind(h,T: C) ⊢ invariants_T(h) must hold Reading: Once bound (via U.RoleAssignment), h must satisfy T’s behavioural invariants.

4. Status assertability StatusTemplate S, evidence_in_C supports S for x ⊢ assertable(x,S) Reading: If evidence in the Context C supports S for x, the badge is assertable (details of evidence logic live in Part B).

5. Status consequence assertable(x,S) ∧ assert(x,S) ⊢ evaluation_invariants_S(x) Reading: Once asserted, S’s evaluation invariants constrain how x is treated.

6. Separation guard RoleTemplate T ⊢ not(deontic_implied(T)) - StatusTemplate S ⊢ not(behaviour_implied(S)) Reading: Wearing a mask doesn’t grant permissions; carrying a badge doesn’t define behaviour.

7. Bridge embargo T cites ⟨C,σ⟩ ∧ C≠C′ ⊢ no‑equivalence(T@C, −) inside F.4 Reading: No Cross‑context equivalence is asserted here; use F.9 later.

#Worked examples (Context‑true)

Illustrative cards only; names are tech/plain labels, not final U.Type IDs (F.5 will govern naming).

#Role Template: participant (workflow actor) — Context: BPMN 2.0 (2011)

• Kind: Role

• Label: Tech participant - Plain workflow actor

• SenseCell: ⟨BPMN_2_0, participant (actor in workflow)⟩

• Holder scope: U.System (organisation, team, service)

• Time stance: design

• Preconditions: Holder is addressable as a lane/pool in the workflow model.

• Behavioural invariants:

  1. Activities assigned to the participant appear in its lane/pool.
  2. The participant interacts through message flows at its boundaries.
  3. The participant does not define run‑time occurrence; it structures the model.

• Separation guard: No permissions implied; no execution logs implied.

• Typical interactions (informative): BPMN process (graph); message event (node).

• Common misreads: ≠ RBAC role; ≠ PROV Activity.

#Status Template: access‑role membership — Context: NIST RBAC (2004)

• Kind: Status

• Label: Tech access‑role - Plain permission role

• SenseCell: ⟨NIST_RBAC_2004, role (permission grouping)⟩

• Holder scope: U.System (user/session)

• Time stance: run

• Preconditions: A defined set of permissions exists for the role.

• Evaluation invariants:

  1. If x carries this badge, x’s session inherits exactly the role’s permissions.
  2. The badge does not describe behaviour in a workflow; it determines access.

• Separation guard: No commitment about BPMN assignment; no deontic duties.

• Typical interactions (informative): permission, session (RBAC).

• Common misreads: ≠ participant (BPMN); ≠ person as an ontological type.

#Status Template: incident (service disruption) — Context: ITIL 4 (2020)

• Kind: Status

• Label: Tech incident - Plain service disruption

• SenseCell: ⟨ITIL4_2020, incident (service quality drop)⟩

• Holder scope: U.Work (recorded occurrence affecting a service)

• Time stance: run

• Preconditions: A service exists with declared SLOs/quality metrics.

• Evaluation invariants:

  1. The occurrence reduces service quality below acceptable levels.
  2. It triggers restoration activities per service practice (names only).

• Separation guard: Not a plant fault; not a BPMN event node.

• Typical interactions: SLO (ITIL), Observation (SOSA) — names only.

• Common misreads: ≠ problem (root cause category).

#Role Template: task runner (control runtime) — Context: IEC 61131‑3

• Kind: Role

• Label: Tech task - Plain program runner

• SenseCell: ⟨IEC_61131_3, task (runtime execution unit)⟩

• Holder scope: U.System (controller CPU/task scheduler)

• Time stance: run

• Preconditions: A program is registered for cyclic/event execution.

• Behavioural invariants:

  1. Invokes assigned program according to cycle/trigger.
  2. Provides schedule constraints (period/priority) to its program.

• Separation guard: No claim about deontic guarantees or service targets.

• Typical interactions: Execution (A.15 family), Actuation (Sys‑CAL).

• Common misreads: ≠ workflow task; ≠ algorithm (design).

#Anti‑patterns & remedies

#Concept‑level operators (refinement & compatibility)

Judgement schemas — pure reasoning moves over cards. No APIs, no storage, no workflow.

Let sense(T) denote the SenseCell cited by template T. Let inv(T) denote the set of invariants on T. Let senseFamily(T) ∈ {Role, Status}. Let stance(T) ∈ {design, run} (from the Context).

#Same‑Context equivalence

Form. sense(T₁) = sense(T₂) ∧ inv(T₁) ⇔ inv(T₂) ⊢ T₁ ≡ T₂

Reading. Two cards in the same Context with logically equivalent invariants co‑designate the same assignable.

Tech cue. Use this to merge duplicates conceptually without changing labels.

#Refinement (strictness order)

Form. sense(T₁) = sense(T₂) ∧ inv(T₁) ⇒ inv(T₂) ⊢ T₁ ⪯ T₂

Reading. T₁ is a refinement of T₂ if its invariants imply those of T₂ (same Context).

Effects. Assigning T₁ automatically satisfies T₂; the converse need not hold.

#Incompatibility (mutual exclusion)

Form. sense(T₁) = sense(T₂) ∧ (inv(T₁) ∧ inv(T₂) ⇒ ⊥) ⊢ incompatible(T₁,T₂)

Reading. Two cards in the same Context are mutually exclusive if their invariants cannot co‑hold.

Use. A conceptual Separation‑of‑Duty signal without governance.

#Co‑wearability / co‑bearability

Form. senseFamily(T₁)=senseFamily(T₂)=Role ∧ stance(T₁)=stance(T₂) ∧ ¬incompatible(T₁,T₂) ⊢ coWearable(T₁,T₂) senseFamily(T₁)=senseFamily(T₂)=Status ∧ ¬incompatible(T₁,T₂) ⊢ stackable(T₁,T₂)

Reading. Within a Context, two Roles can be worn together (or two Statuses carried) when they do not conflict.

#Time‑stance alignment

Form. stance(T)=design ⊢ inv(T) may not assert run‑facts stance(T)=run ⊢ inv(T) may not assert design‑commitments

Reading. Invariants must respect the Context’s DesignRunTag (F.1).

#Binding/Assertion admissibility

Form. (Roles) holder h ∧ preconds_T(h) ⊢ assignable(h,T) assignable(h,T) ∧ bind(h,T) ⊢ inv(T)(h)

Form. (Statuses) evidence_in_Context(C) supports S for x ∧ sense(S)=⟨C,σ⟩ ⊢ assertable(x,S) assertable(x,S) ∧ assert(x,S) ⊢ inv(S)(x)

Reading. Preconditions and evidence gate the act of wearing a mask or bearing a badge; once done, invariants apply.

#Cross‑context embargo (inside F.4)

Form. sense(T₁)=⟨C,−⟩, sense(T₂)=⟨C′,−⟩, C≠C′ ⊢ no‑relation(T₁,T₂) here

Reading. F.4 never asserts Cross‑context relations. If a relation is desired, it becomes a Bridge in F.9.

#Relations (where this card sits)

Builds on: E.10.D1 D.CTX (Context ≡ U.BoundedContext); F.1 (Contexts cut); F.2 (harvested terms); F.3 (Local‑Sense → SenseCell); A.2.1 U.RoleAssignment; A.7 Strict Distinction.

Constrains: F.5 (Naming): pairs Tech/Plain must reflect the Context idiom and avoid Cross‑context overreach. F.7 (Concept-Set Table): rows reference SenseCells; Role Description cards point to those rows but never create cross-context identity. F.8 (Mint or Reuse?): prefer refinement (⪯) over new cards; split cards rather than mixing senseFamilies. F.9 (Alignment & Bridge): any relation across Contexts is declared there; Role Description cards remain context-local.

Is used by. A.15 family (Role–Method–Work alignment) to interpret System‑in‑Role and Work; Part B evidence/status checks to interpret evaluation invariants.

#Migration notes (conceptual playbook)

1. Context update (edition split). If the Context’s Local‑Sense changes, fork the card per new SenseCell; keep the old card as historically valid.
2. Family correction (Role/Status). If a card mixes behaviour and deontics, split into one Role and one Status; move permission language to the Status.
3. Tighten by refinement. When practice reveals a stricter understanding, prefer T′ ⪯ T over replacing T; this preserves existing assignments conceptually.
4. Rename safely (labels only). If F.5 revises labels, change Tech/Plain wording; SenseCell and invariants remain untouched.
5. Scope correction. If Holder scope was too wide, split into parallel cards with disjoint Holder scopes; avoid complex conditional invariants.
6. Bridge discovery. Do not inject Cross‑context text into cards; record the relation as an F.9 Bridge (with CL policy), leaving the cards as they are.

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

#Static conformance (SCR)

• SCR‑F4‑S01 (Uni‑Context grounding). Each card cites exactly one SenseCell.
• SCR‑F4‑S02 (Family honesty). senseFamily(T) is either Role or Status; invariants match the family; a separation guard line is present.
• SCR‑F4‑S03 (Time honesty). stance(T) matches the Context’s stance; no opposing‑stance claims appear.
• SCR‑F4‑S04 (Minimality). Card lists 2–5 invariants; none are procedural step lists.
• SCR‑F4‑S05 (Label fidelity). Tech label is idiomatic to the Context; Plain label does not widen meaning.
• SCR‑F4‑S06 (No Cross‑context import). Invariants reference only the Context’s idiom or other SenseCells by name (no identity claims).
• SCR‑F4‑S07 (Holder clarity). Holder scope is a single coherent kind (e.g., U.System or U.Work), not a grab‑bag.
• SCR‑F4‑S08 (No tooling/governance). Card contains no mentions of manifests, pipelines, editors, or workflows.

#Regression (RSCR)

• RSCR‑F4‑E01 (Edition churn). When a Context edition changes, existing cards are not overwritten; new cards are added per SenseCell.
• RSCR‑F4‑E02 (Refinement safety). If T′ ⪯ T is introduced, prior usages of T remain conceptually valid; no backward contradictions arise.
• RSCR‑F4‑E03 (senseFamily integrity). No card changes senseFamily across revisions (Role↔Status) without an explicit split noted.
• RSCR-F4-E04 (Bridge discipline). After adding an F.9 Bridge, Role Description cards remain unchanged; cross-context meanings do not seep back into cards.
• RSCR‑F4‑E05 (Label updates). Label changes per F.5 preserve SenseCell and invariants; tests treat them as renames, not semantic edits.

#Didactic distillation (60‑second close)

A Role Description card is a Context-true way to speak about an assignable: a Role (behavioural mask) or a Status (epistemic/deontic badge). Each card names one SenseCell, gives a Tech/Plain label, states minimal invariants, and declares what it does not imply. Cards never mix Role/Status senseFamilies and never cross I/D/S layers, never flip time stance, and never import other Contexts. Inside one context, you can compare cards by equivalence (≡), refinement (⪯), incompatibility, and co‑wearability. across Contexts, say nothing in the card; use a Bridge later. Keep cards one‑screen simple: enough to decide assignments; nothing procedural; no tools; just clear thought.

#F.4:End

#Naming Discipline for U.Types & Roles

Status. Definitional pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); E.10.D2 Intension–Description–Specification (I/D/S); F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting & Normalisation; F.3 Intra‑Context Sense Clustering; F.4 Role Description Definition; A.7 Strict Distinction; A.11 Ontological Parsimony; F.0.1 context‑local Lexicon Principle (RLP). Coordinates with. F.7 Concept‑Set Table; F.8 Mint or Reuse?; F.9 Alignment & Bridge; F.13 Term Registry & Deprecation. Aliases (informative). Context‑true naming; Two‑register labels.

#Intent & applicability

Intent. Provide a small, normative code of naming so that U.Types (Cross‑context categories) and Role Descriptions (context‑local Roles/Statuses) are labelled clearly, locally faithful, and globally stable, without importing tooling, workflows, or editorial process. Names are consequences of meaning fixed earlier (F.1–F.4), not badges invented to “stabilise” drifting words.

Applicability. Use whenever you (a) mint or revise a U.Type name from a Concept‑Set row (F.7), or (b) assign labels to a Role Description (F.4). This pattern governs what a good name must be, not how a team produces it.

Non‑goals. No registries, reviews, or hand‑offs. No style‑police for punctuation beyond conceptual clarity. No bridging or synonym decisions across Contexts (F.9 does that).

#Problem frame

Naming errors cause structural errors:

1. Context denial. A label hides its Context, inviting Cross‑context misuse (“process” used for both BPMN and PROV senses).
2. senseFamily blur. Names conflate Role (behavioural mask) with Status (epistemic/deontic badge).
3. Over‑reach. U.Types inherit jargon from one canon and sound global while being parochial.
4. Under-reach. Role Description labels sound so generic that they pretend to be U.Types.
5. Unstable synonyms. Labels drift to placate readers rather than reflect meaning fixed in SenseCells.

This code resolves these by Context fidelity, senseFamily‑aware morphology, and two‑register pedagogy.

#Minimal vocabulary (this pattern only)

• Tech label — the Context‑idiomatic name engineers expect inside that Context.
• Plain label — a teaching gloss in simple English that does not broaden the sense.
• Symbolic alias (optional) — conventional symbol if the canon uses one (e.g., “≤”).
• SenseCell — the (Context × Local-Sense) address cited by a Role Description card (F.3–F.4).
• Concept‑Set row — the Cross‑context table row that supports minting a U.Type name (F.7).

#Core idea (didactic)

Name what the invariants already make true.

For Role Descriptions, speak like the Context (Tech), then teach it (Plain). For U.Types, speak like nobody’s Context: pick the neutral, minimal‑generality label that best fits the intersection shown by your Concept‑Set row.

#Normative rules — Role Descriptions (context‑local labels)

Let T be a Role Description in Context C with SenseCell sense(T)=⟨C,σ⟩.

R‑RD‑1 (Two registers). Provide both: Tech(T) = the Context‑idiomatic phrase (exact canon wording if possible). Plain(T) = a brief, neutral explanation that does not broaden meaning. Symbolic alias is optional and purely informative.

R‑RD‑2 (No Context tags in labels). Do not embed the Context name in the label (avoid “(BPMN)” in the label itself). Context is already carried by the SenseCell; keep labels clean.

R‑RD‑3 (senseFamily‑aware morphology). — Role names are countable nouns for masks (e.g., Participant, Operator, Reviewer). Avoid verbs and gerunds. Add the suffix “Role” only if the Context idiom risks confusion with a substance or a status (e.g., “Reviewer Role” in a Context that also has a “Reviewer Status”). — Status names are state nouns or adjectival‑noun collocations (e.g., Approved, Compliant, In‑Service, Access Role (RBAC)). If a family of levels exists, encode the level (Assurance L1, Readiness L2) rather than inventing decorative adjectives.

R‑RD‑4 (Local idiom first). Prefer the canon’s term of art even if it sounds narrower than a cross‑discipline cliché. The Plain label handles pedagogy; the Tech label honours the Context.

R‑RD‑5 (Minimal generality). Choose the narrowest label whose invariants you actually assert. Do not “upgrade” Task to Activity or Process just to sound universal.

R‑RD‑6 (No permissions by stealth). Role labels must not imply entitlement (“Privileged Operator” is a Status+Role mashup). Keep deontics in Status names in the deontics Context.

R‑RD‑7 (Edition‑neutral labels). Do not bake edition/profile into labels. Edition lives in the Context; the card binds to a SenseCell that already encodes edition where needed.

R‑RD‑8 (Short and stable). Favour 1–3 words. Avoid rhetorical adjectives (“robust, optimal, best‑practice”).

#Normative rules — U.Types (Cross‑context labels)

Let U be a U.Type minted from a Concept‑Set row (F.7) satisfying A.8 (≥3 domain families) AND MinInterFamilyDistance ≥ δ_family (from F1‑Card).

R‑UT‑1 (Witnessed neutrality). The Tech label must not be a term owned by one context when alternatives exist. Prefer discipline‑neutral head nouns (Result, Reading, Execution, Evidence, Requirement, State, Type Node). Use Characteristic/Scale/Value/Level/Coordinate/Score/ScoringMethod only when the U.Type denotes a measurement‑sense kind anchored in a declared CharacteristicSpace; otherwise avoid these measurement‑canon terms to prevent semantics bleed.

R‑UT‑2 (Minimal generality). Name the least upper sense that all row witnesses share. If Observation and Measurement disagree, perhaps the U.Type is Result or Reading, not Observation.

R‑UT‑3 (No senseFamily mixing in names). Do not name a U.Type with deontic or behavioural language (“PermittedService”, “ResponsibleAgent”). Role/Status/Method/Execution belong to Role Descriptions (F.4) or local senses; U.Types are what‑it‑is kinds, not what‑it‑does or what‑is‑allowed.

R‑UT‑4 (Head–modifier discipline). Prefer head nouns with light modifiers over stacked compounds. Good: Evidence Status, Requirement Status, Type Node. Risky: Multi‑stage‑workflow‑execution‑record (compresses a scenario into a name).

R‑UT‑5 (No Context tags in names). U.Types are Context‑agnostic; never append “(BPMN)”/“(PROV)”. Provenance for the row lives in F.7, not in the name.

R‑UT‑6 (Alias only for pedagogy). Allow Plain aliases for teaching; Tech label is unique and stable. Synonym management belongs to F.13; do not invent alternates ad hoc.

R‑UT‑7 (Family coherence). When minting a family, use parallel shapes (… Status, … Level, … Characteristic only for measurement families with a declared CharacteristicSpace) so related U.Types signal relation by form.

R‑UT‑8 (Symbolic names sparingly). Symbols may be listed as aliases for readers of formal sections; they are never the U.Type’s Tech label.

R‑UT‑9 (No edition/version in name). Versions live in the Concept‑Set evidence; the name denotes a time‑robust kind.

#Twin rules

Mandatory Tech name. Every U.Type/Role MUST declare a Tech name; plain twin is optional. Role suffix invariant. Role Tech names MUST end with Role; plain twin MUST keep “(role)” on first use. No head elision. Head terms MUST NOT be dropped in a way that changes expected Kind (e.g., “Approval” ≠ “Approver (role)”). One twin, one context. At most one plain twin per Context; register in E.10.P.

#Invariants (normative, lightweight)

INV-F5-1 (Pair). Every Role Description card and every U.Type MUST carry Tech and Plain labels; symbol is optional and informative.

INV-F5-2 (Context fidelity for Role Descriptions). Tech(T) MUST be idiomatic for its Context; Plain(T) MUST NOT broaden sense(T).

INV‑F5‑3 (Neutrality for U.Types). Tech(U) MUST be discipline‑neutral with respect to the witness Contexts in its Concept‑Set row.

INV‑F5‑4 (senseFamily honesty). Role Description Role labels are behavioural masks; Role Description Status labels are states/badges; neither sneaks in the other senseFamily.

INV‑F5‑5 (Minimality). Labels MUST reflect the minimal generality supported by invariants (F.4 for Role Description, F.7 for U.Types).

INV-F5-6 (No Context tags). Names MUST NOT embed Context/edition tags; that information resides in SenseCells (Role Description) and Concept-Set rows (U.Types).

#Reasoning primitives (judgement schemas, notation‑free)

Pure mental checks; no tools implied.

1. Context-idiom check (Role Description). T in Context C ⊢ idiomatic(Tech(T), C) Reading: The Tech label reads like the Context’s own term of art.

2. Plain‑safety check. sense(T)=⟨C,σ⟩ ⊢ ¬broadens(Plain(T), σ) Reading: The Plain label explains without enlarging the sense.

3. Neutral‑witness check (U.Type). witnessContexts(U)=R ⊢ neutral(Tech(U), R) Reading: The Tech label doesn’t privilege one witness Context’s jargon.

4. senseFamily form check (Role Description). senseFamily(T)=Role ⊢ nounMask(Tech(T)) senseFamily(T)=Status ⊢ stateForm(Tech(T)) Reading: The morphology matches the senseFamily.

5. Minimality proof. inv(T) ⇒ nameScope(Tech(T)) ⊆ senseScope(sense(T)) (Role Description) rowWitnesses(U) ⇒ nameScope(Tech(U)) ⊆ intersectionScope(row) (U.Type) Reading: The name’s scope is no wider than what the invariants/witnesses support.

6. Collision ping. similar(Tech(X), Tech(Y)) ∧ senseFamily(X)≠senseFamily(Y) ⊢ requireDisambiguatorOrSplit Reading: If two labels nearly coincide across senseFamilies, either add a minimal disambiguator (Role Description only, within Context idiom) or split concepts.

#Micro‑examples (illustrative)

Role Description (BPMN Context). Tech: Participant - Plain: actor in a workflow - senseFamily: Role (No “BPMN” in label; behaviour mask, not entitlement.)

Role Description (RBAC Context). Tech: Access Role - Plain: named permission set - senseFamily: Status (Deontic badge; not a behavioural mask.)

Role Description (ITIL Context). Tech: Service‑Level Objective - Plain: service target value - senseFamily: Status (Levelable family: SLO [target], SLI [indicator] handled in F.10/F.12 semantics, not in the label.)

U.Type (from Concept‑Set row: SOSA Observation, PROV Activity (result‑bearing), ML Metric Reading). Tech: Result - Plain: the produced value or record of a measurement/assessment (Neutral head noun when “Observation” is too Context‑coloured.)

U.Type (from OWL class, FCA concept, taxonomy nodes). Tech: Type Node - Plain: a node in a type hierarchy or lattice (Neutral across DL and FCA.)

#Anti‑patterns & remedies

#Worked examples

Each example shows the reasoning move that leads to the label; no procedures, no tooling.

#Role Description labels (context-local)

(a) BPMN Context — behavioural mask vs node word

• SenseCell. ⟨BPMN 2.0, local‑sense: lane/pool actor that enacts tasks⟩
• Decision. Tech = Participant (Context idiom); Plain = actor in a workflow
• Why. Participant is the mask; it is not the node (Task, Event). (R-RD-3, R-RD-4)

(b) RBAC Context — deontic badge

• SenseCell. ⟨NIST RBAC, local‑sense: named permission set assigned to sessions⟩
• Decision. Tech = Access Role; Plain = named permission set
• Why. It’s a Status, not a behavioural mask; deontic plane kept explicit. (R-RD-3, R-RD-6)

(c) ITIL Context — service target

• SenseCell. ⟨ITIL 4, local‑sense: target value for a service characteristic⟩
• Decision. Tech = Service‑Level Objective; Plain = service target value
• Why. Family will carry … Level, … Indicator in adjacent cards; avoids jargon drift. (R-RD-3, R-UT-7)

(d) IEC 61131-3 Context — run-time execution notion as Role Description?

• SenseCell. ⟨IEC 61131‑3, local‑sense: cyclic/event‑driven task unit⟩
• Decision. For a Role Description Status of a run, label Completed, Failed, Skipped (Context idiom); avoid naming the Work itself here.
• Why. The record of work is a U.Type elsewhere (A.15.1); Role Description in this Context carries badges of runs. (A.7 stance split; R-RD-3)

#U.Type labels (from Concept‑Set rows)

Row R₁ (measurement‑sense): SOSA: Observation • ML practice: metric reading • Metrology: measurement result

• Witness Contexts. sensing; ML metrics; metrology
• Decision. U.Type Tech = Result; Plain = the produced value or record of a measurement/assessment
• Why. Neutral head noun covering all witnesses; avoids privileging SOSA’s Observation. (R‑UT‑1, R‑UT‑2)

Row R₂ (type‑structure): OWL: class / subclass • FCA: formal concept (node in concept lattice)

• Witness Contexts. DL; FCA
• Decision. U.Type Tech = Type Node; Plain = a node in a type hierarchy or lattice
• Why. Neutral over DL vs FCA; head‑modifier shape is stable. (R‑UT‑1, R‑UT‑4, R‑UT‑7)

Row R₃ (status family): ITIL: incident status • Safety cert.: assurance level • QA: readiness level

• Witness Contexts. services; assurance; QA
• Decision. Two U.Types: Assurance Level, Readiness Level (family‑coherent), plus Requirement Status (for normative clauses)
• Why. Separates families; preserves level vs status distinction. (R‑UT‑7, R‑UT‑3)

#Mixed scenario (service acceptance over execution traces)

Contexts in play. IEC 61131‑3 (run), SOSA/SSN (sensing), ITIL 4 (services).

1. Role Description (ITIL) — Tech: Service-Level Objective; Plain: service target value.
2. U.Type (from R₁) — Tech: Result (to host measured values).
3. Role Description (IEC) — Tech: Completed / Failed (Status on a run).
4. Name discipline payoff. The sentence “Compare IEC run Results against the ITIL Service‑Level Objective” is Context‑true without tags, because each label encodes its senseFamily and neutrality.

#Migration notes (conceptual)

1. When a Context changes edition. Names stay; the SenseCell shifts to the new edition. Only change a label if the sense has changed; then split the card rather than mutate the name. (INV‑F5‑2, R‑RD‑7)

2. When a Concept‑Set row gains a new witness Context. Re‑ask neutrality: if the Tech label now privileges a Context, refactor to a more neutral head (e.g., Observation → Result). (R‑UT‑1, R‑UT‑2)

3. Collision emergence. If a Role card and a Status card converge phonetically (Approver vs Approved), keep both but add the minimal morphological disambiguator only where the Context idiom demands it (Reviewer Role). (R-RD-3)

4. Family hygiene. As families grow, keep parallel shapes (… Level, … Status). If a legacy label breaks shape, add a Plain alias for teaching; don’t rename the Tech label without Concept‑Set pressure. (R‑UT‑7, R‑UT‑6)

5. Language variants. Non-English canons keep their own Tech labels (idiomatic in that Context); the Plain label remains English in FPF unless the Part mandates localisation. (R-RD-4, INV-F5-1)

6. Symbol addition. You may add a symbolic alias later for readers of formal sections; never promote a symbol to the Tech label. (R‑UT‑8)

7. De‑jargonising the Plain label. If readers stumble, adjust Plain wording only; do not widen the sense. (Plain‑safety check)

8. Deprecation path. If a label must change, publish the new Tech + Plain, keep the old as an alias in the registry (F.13), and leave the reasoning trail in the Concept‑Set row that forced the rename. (R‑UT‑6, F.13 linkage)

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

#Static conformance (SCR)

• SCR-F5-S01 (Two registers). Every Role Description card and U.Type has both Tech and Plain labels; any symbol is marked alias.
• SCR-F5-S02 (Context fidelity for Role Descriptions). For any Role Description T in Context C, Tech(T) appears idiomatic in C; Plain(T) does not broaden sense(T).
• SCR‑F5‑S03 (Neutrality for U.Types). For any U.Type U, its Tech label does not coincide with a witness Context’s proprietary term when alternatives exist.
• SCR‑F5‑S04 (senseFamily morphology). Role labels are countable nouns; Status labels are state nouns / adjectival‑noun forms.
• SCR-F5-S05 (Minimal generality). For each label, there exists a reading where the name’s scope ⊆ invariant scope (Role Description) or ⊆ row intersection (U.Type).
• SCR‑F5‑S06 (No Context tags). No label embeds Context or edition strings.
• SCR‑F5‑S07 (Family coherence). Families that claim parity (e.g., Levels) show parallel shapes across members.

#Regression checks (RSCR)

• RSCR‑F5‑E01 (Witness drift). When a Concept‑Set row gains/removes a witness Context, re‑evaluate neutrality; if violated, refactor the Tech label to a more neutral head.
• RSCR-F5-E02 (Edition churn). When a Context updates, Role Description labels remain stable unless the sense changed; if sense changed, split the card and keep aliases in F.13.
• RSCR‑F5‑E03 (Collision guard). If two labels become confusable across senseFamilies, either add the minimal disambiguator (Role Description only, Context‑idiom) or separate the concepts.
• RSCR‑F5‑E04 (Rhetoric creep). Periodic skim for decorative adjectives; remove them unless they encode formal levels or families.

#Didactic distillation (60‑second recap)

Name what is already true. Role Description labels speak like the Context (Tech) and teach without widening (Plain). U.Type labels speak like nobody’s Context: neutral head nouns at minimal generality, shaped in parallel families. Never glue Context tags or editions into names. Never mix senseFamilies in morphology. If witnesses change, reconsider neutrality; if senses split, split names, don’t stretch them. The label is the last step of understanding, not the first.

#F.5:End

#Role Assignment & Enactment Cycle (Six-Step)

“Assign only what you can later justify by local meaning and observable facts.” Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); F.1 Domain‑Family Landscape Survey; F.2 Term Harvesting & Normalisation; F.3 Intra‑Context Sense Clustering; F.4 Role Description; F.5 Naming Discipline. Coordinates with. F.7 Concept‑Set Table; F.8 Mint or Reuse?; F.9 Alignment & Bridge; F.10 Epistemic Status Mapping; A.2.1 U.RoleAssignment; A.15.* Role–Method–Work alignment; KD‑CAL (observations, results). Aliases (informative). Assign-and-verify mental loop; six-step role cycle.

#Intent & applicability

Intent. Provide a minimal set of reasoning moves that turn a Role Description (F.4), anchored in a SenseCell, into a sound claim about a concrete holder—either a Role assignment or a Status assertion—with local meaning (within one context) and a clear path to evidence (KD‑CAL). These are mental moves, not workflows or tools.

Applicability. Any time you (a) bind a system to a Role mask, or (b) assert a Status about a system/artefact, inside one U.BoundedContext. Use when drafting models, reconciling vocabularies, or reading external canons.

Non‑goals. No process charts, no registries, no governance roles. No Cross‑context equivalences (that is F.9). No operational runbooks—only conceptual judgements.

#Problem frame

Without disciplined Role Assignment & Enactment reasoning:

1. Sense‑family slippage. Behavioural Roles and deontic/epistemic Statuses get mixed (keep them on distinct senseFamilies, per F.0.1).
2. Context drift. A label is lifted from one canon and used as if universal.
3. Evidence vacuum. Assignments are asserted with no thought to what could show they hold.
4. Time blur. Design‑time masks are judged by run‑time traces (or vice versa).
5. Name inflation. New labels are minted to patch noisy assignments.

#Forces

#Minimal vocabulary (this pattern only)

• Context — shorthand for U.BoundedContext (per E.10.D1).
• SenseCell σ — address ⟨Context C × Local‑Sense ℓ⟩ per F.3. (Informative: we write simply σ; it already contains C.)
• Role Description — a Role or Status card anchored in a SenseCell (F.4).
• Holder — the concrete system/artefact considered for a Role binding.
• Subject — the referent of a Status assertion; determined by the Template (may or may not be the Holder).
• subject_of(τ, H) — function yielding the Subject for Status assertions given Template τ (and, if needed, candidate H).
• Eligibility — conditions on the Holder that must hold to apply the Template (F.4 invariants).
• Window — the DesignRunTag or interval relevant to the claim (design/run; instant/period).
• Evidence shape — the Observation/Result/Procedure/Feature pattern (KD‑CAL) that could confirm/refute the claim in its Context.

#Pre‑conditions (lightweight)

1. The Context is in your F.1 cut; Context ≡ U.BoundedContext.
2. The Template references a SenseCell in that Context (F.4).
3. The Holder is identified (by type or instance) without relying on Cross‑context mappings.

#The six moves (judgement schemas, notation‑free)

Each move is a thought you can justify, expressed as premises ⊢ conclusion. All moves are context‑local and side‑effect free (they assert knowledge; they do not modify artefacts).

#M1 - Locate — Fix the Context and the Template

Form. Template τ anchored at SenseCell σ≡⟨C, ℓ⟩ ⊢ address(τ) = σ

Reading. Name the Context and the exact SenseCell that gives local meaning to the Template. Note. This forbids “floating” Roles/Statuses and prevents Context drift.

#M2 - Stance — Respect DesignRunTag

Form. stance(C)=s ∧ stance(τ)∈{s, both} ⊢ compatible_stance(τ,C)

Reading. The Template’s DesignRunTag is compatible with its Context’s stance (design vs run). Note. Guards against judging a design‑mask by run‑traces or judging a run‑status by design artefacts.

#M3 - Qualify — Check Holder eligibility

Form. Holder H ∧ eligibility(τ) holds in C ⊢ eligible(H, τ @ C)

Reading. Given the Template’s eligibility predicates (F.4), the Holder qualifies to be bound/assessed in this Context. Note. Typical predicates: type membership, capability present, scope fit; all context‑local.

#M4 - Bind/Assert — Make the Role Assignment / Status claim

Role assignment (behavioural mask). eligible(H, τ @ C) ∧ window W ⊢ plays_role(H, τ : C) @ W

Status assertion (epistemic/deontic state). eligible(H, τ @ C) ∧ window W ∧ S = subject_of(τ, H) ⊢ has_status(S, τ : C) @ W

Reading. Assert either a Role binding or a Status about the appropriate subject (system, artefact, service), within a Window. Note. The subject of a Status may differ from the Role holder (e.g., a service has SLO status; a team plays a Role).

#M5 - Evidence — Shape what would make it true/false

Form. plays_role/has_status κ in C ⊢ evidence_shape(κ) = Σ(C)

Reading. From the Context’s semantics, state the Observation/Result pattern (KD‑CAL) that would confirm or refute the claim (what, where, when). Note. This is not an execution plan: it is a conceptual test tied to the Context’s vocabulary.

#M6 - Conclude — Issue a defensible verdict with confidence

Form. evidence E fits Σ(C) ∧ invariants(τ) hold ⊢ holds(κ) with confidence γ ∈ [0,1]

Reading. If observed facts match the expected evidence shape and Template invariants stand, the assignment/status claim holds with some confidence (cf. B.3). Note. Confidence combines measurement adequacy (KD‑CAL) with any Context‑specific uncertainty; no Cross‑context boost is implied.

#Autonomy admission (Green‑Gate) and ledger

• Before enactment: If the Method step lists requiresAutonomyBudget, the enacting U.RoleAssignment MUST pass the Autonomy Green‑Gate: (i) active/enactable RSG state, (ii) budget tokens/envelope remain in the declared Γ_time window, (iii) all guards pass.
• On enactment: Write an AutonomyLedgerEntry attached to the U.Work, with deltas and guard verdicts.
• On depletion: Block further autonomy‑gated steps; emit a DepletionNotice (SpeechAct) and follow the OverrideProtocolRef.
• SoD: Enforce ⊥ between autonomy consumer Role and override caller Role.

#Core invariants (normative)

1. Locality. Every judgement is about one context. No Cross‑context equivalence is presumed or implied (that is F.9’s remit).
2. Strict splits. (a) senseFamily split: Role ≠ Status (per F.0.1); (b) stance split: design ≠ run (A.7). Each judgement names its senseFamily and stance.
3. Eligibility before claim. No binding or status without eligible(H, τ @ C).
4. Window honesty. Every claim states or inherits a Window consistent with stance(τ) and stance(C).
5. Evidence‑ability. Every claim must admit at least one evidence shape Σ in its Context (KD‑CAL compatible).
6. Name discipline. Labels used in judgements follow F.5 (Tech/Plain registers; no Context tags inside names).

#Reasoning aides (didactic)

• Context‑prefix speech. Think and speak with the Context prefix when ambiguity lurks: participant (BPMN), role (RBAC), activity (PROV).
• Window templates. Prefer short phrases: “during release‑R3 cutover”, “for the Q3 service period”, “at 2025‑08‑12T14:30Z”.
• Evidence as shape words. Result of Observation of ⟨Characteristic⟩ on ⟨Feature⟩ by ⟨Procedure⟩ within W—not a measurement script.

“Assign only what you can later justify by local meaning and observable facts.”

#Anti‑patterns & remedies

#Worked examples

Each example is a context-local assignment/status reasoning trace using M1…M6. cross-context relations, if any, are noted as optional bridges (F.9) but not relied upon.

#Service availability status (ITIL + KD‑CAL)

Context. ITIL 4 (services family; design) *Template (Status). SLO:availability≥99.9% anchored at SenseCell ⟨ITIL4, “SLO (availability)”⟩.

M1 Locate. address(τ)=⟨ITIL4, SLO(availability)⟩ M2 Stance. stance(ITIL4)=design, stance(τ)=design ⇒ compatible_stance(τ, ITIL4) M3 Qualify. eligible(Service S, τ@ITIL4) if S is a published service with declared availability target. M4 Assert. has_status(S, τ:ITIL4) @ W where W = Q1‑2025 (the evaluation period). M5 Evidence shape Σ(ITIL4). Observation of availability characteristic (MM‑CHR) for S, produced by a Procedure that samples uptime and computes the Result as ratio over W. (KD‑CAL/MM‑CHR terms only; no tool implied.) M6 Conclude. If Results across W give ≥ 99.9 % with adequate sampling and declared exclusions applied, holds( has_status(S, τ:ITIL4) @ W ) with γ≈0.9. Optional bridge. If uptime sensing vocabulary is expressed in SOSA/SSN, an F.9 Bridge may map ITIL’s “availability metric” to ObservableProperty(availability) with a declared CL penalty; the assignment/status claim itself remains ITIL-local.

#Behavioural operator role (IEC 61131‑3 + Enactment)

Context. IEC 61131‑3 (control languages; run) *Template (Role). Control‑Task‑Executor anchored at SenseCell ⟨IEC61131‑3, “task executes program”⟩.

M1 Locate. address(τ)=⟨IEC61131‑3, task‑execution⟩ M2 Stance. stance(IEC61131‑3)=run, stance(τ)=run ⇒ compatible. M3 Qualify. Holder PLC_7 qualifies if it hosts program P and is scheduled by task T. M4 Bind. plays_role(PLC_7, τ:IEC) @ W where W = [08:00, 18:00] 2025‑06‑05. M5 Evidence shape Σ(IEC). Observation of task schedule and program invocation logs as Results for features T/P during W; presence of expected cyclic/event‑driven triggers. M6 Conclude. If Results show the expected executions with no missed cycles beyond tolerance, holds( plays_role(PLC_7, τ:IEC) @ W ) with γ≈0.8. Trip-wire. Do not restate this as “PROV Activity” without F.9; keep the assignment/status claim IEC-local.

#Dataset accuracy status (ISO/IEC 25024 + KD‑CAL)

Context. ISO/IEC 25024 (data‑quality; design) *Template (Status). accuracy≥0.98 anchored at SenseCell ⟨ISO25024, “data accuracy”⟩.

M1 Locate. address(τ)=⟨ISO25024, data‑accuracy⟩ M2 Stance. stance(Context)=design, stance(τ)=design ⇒ compatible. M3 Qualify. Subject Dataset D has a defined reference set and sampling protocol. M4 Assert. has_status(D, τ:ISO25024) @ W where W = “snapshot v2025‑04”. M5 Evidence shape Σ(ISO25024). Observation of correctness of sampled records vs reference, Procedure per standard, Result as proportion correct with confidence interval. M6 Conclude. If CI lower bound ≥ 0.98, holds( has_status(D, τ) @ W ) with γ≈0.85.

#Access vs behavioural: two claims, two Contexts

Contexts. NIST RBAC (access; design) and BPMN 2.0 (workflow; design). Templates. DB‑Admin (RBAC status) vs Participant (BPMN role).

RBAC claim (Status). M1…M6 yield has_status(User U, RBAC:DB‑Admin) @ W_dir with Σ(RBAC) = Observation of assignment state in the access model at time W_dir.

BPMN claim (Role). M1…M6 yield plays_role(Team T, BPMN:Participant) @ W_proc with Σ(BPMN) = Observation that lanes/pools enact tasks during W_proc.

Lesson. Two separate context-local claims — one Status assertion and one Role assignment; no implication that holding RBAC status entails playing the BPMN Role.

#Relations (with other patterns)

Builds on: F.1 Domain‑Family Landscape Survey (Contexts fixed); F.2 Term Harvesting (local terms); F.3 Intra‑Context Clustering (SenseCells); F.4 Role Description (invariants, stance); F.5 Naming Discipline (labels).

Constrains: F.7 (Concept-Set Table): rows reference SenseCells; Role Description cards point to those rows but never create cross-context identity. F.8 Mint or Reuse? Uses outcomes of Role/Status claims to decide: a new Role/Status label only when existing Templates cannot express the claim with eligibility/Window adjustments. F.9 (Alignment & Bridge): any relation across Contexts is declared there; Role Description cards remain context-local. F.10 Epistemic Status Mapping. Consumes M6 confidences γ and Σ‑adequacy to roll up assurance.

Coordinates with. MM‑CHR (characteristics, scales) wherever Characteristic/Scale is used in evidence shapes.

Used by. Patterns (Part C) to anchor their examples: Sys‑CAL (execution/actuation roles), KD‑CAL (measurement statuses), Method‑CAL (execution claims for Methods/MethodDescription), Kind-CAL (typing claims remain outside Role Assignment & Enactment, but may inform eligibility predicates).

#Migration notes (conceptual)

1. Template refactor. If a Template’s invariants change, claims remain as‑is; re‑evaluate M6 on demand. Do not silently rewrite past claims.
2. Edition updates. When a Context’s canon updates, treat it as a new Context if sense shifts; Claims anchored to the old Context stay valid for their Window.
3. Name revisions. Renaming per F.5 does not alter address(τ)=⟨Context, SenseCell⟩; claims reference the address, not surface form.
4. Bridge introduction. Adding an F.9 Bridge never upgrades an existing Role/Status claim; at most it enables separate translations with declared loss.
5. From exception to Status. If recurring exceptions to a Role appear, prefer minting a Status Template that marks the exception rather than proliferating Roles.
6. Window tightening. If evidence shows drift, narrow future Windows; past claims remain tied to their original Windows.

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

#Static conformance (SCR)

• SCR-F6-S01 (Local address). Every assignment/status claim states address(τ)=σ where σ is a SenseCell (per F.3); no bare labels.
• SCR‑F6‑S02 (SenseFamily clarity). Each claim is typed Role or Status, never both; subjects are of the correct kind. Claim records both senseFamily and stance explicitly or by inheritance.
• SCR‑F6‑S03 (Stance compatibility). stance(Context) and stance(τ) are compatible (design/run).
• SCR‑F6‑S04 (Eligibility first). For each claim, eligible(H, τ@context) is derivable prior to assertion.
• SCR‑F6‑S05 (Window explicit). Each claim has a Window (explicit or inherited) consistent with stance.
• SCR‑F6‑S06 (Evidence‑ability). For each claim, an evidence shape Σ(Context) is stated using only that Context’s vocabulary plus KD‑CAL/MM‑CHR primitives.
• SCR‑F6‑S07 (Locality guard). No Cross‑context terms appear inside a claim; any reference to other Contexts is flagged as F.9 Bridge (informative), not used to justify the claim.

#Regression (RSCR)

• RSCR‑F6‑E01 (Edition stability). Adding a new edition/Context does not mutate existing claims’ Contexts or Windows.
• RSCR‑F6‑E02 (Name stability). Changing labels per F.5 leaves addresses and conclusions invariant.
• RSCR‑F6‑E03 (Bridge neutrality). Introducing or revising an F.9 Bridge does not auto‑flip claim truth values; at most it enables explicit translations with loss notes.
• RSCR‑F6‑E04 (Evidence refresh). When KD‑CAL procedures or MM‑CHR characteristic scales change, only γ is re‑evaluated; the claim’s semantics remain.

#Didactic distillation (60‑second recap)

Six moves. (M1) Locate the Context & SenseCell; (M2) check stance; (M3) test eligibility; (M4) bind/assert with a Window; (M5) sketch the evidence shape in that Context; (M6) conclude with confidence γ. Two iron rules. Keep it context‑local; keep Role and Status on their senseFamily. Pay-off. Assignment/status claims become small, auditable thoughts: easy to teach, easy to check, and easy to relate—later—via explicit Bridges when you truly must step between Contexts.

#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 stronger 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 term material; F.3 SenseCells → provide cell addresses; F.5 Naming Discipline → provides the two‑register FPF labels; F.9 Bridges → legally 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 stronger 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? (U.Type vs Concept-Set vs Role Description vs Alias)

“Name only what thinking requires, and reuse everything else.”

Status. Architectural pattern. Depends on. E.10.D1 Lexical Discipline for “Context” (D.CTX); A.7 Strict Distinction; A.11 Ontological Parsimony; A.8 Universal Core. Coordinates with. F.1 Contexts (Contexts); F.2 Harvest; F.3 SenseCells; F.4 Role Description; F.5 Naming Discipline; F.7 Concept‑Set Table; F.9 Alignment & Bridge. Aliases (informative). Mint‑vs‑Reuse gate; Naming governor.

#Intent & applicability

Intent. Provide a minimal, conceptual decision lattice that answers, for any modelling need:

“Do I reuse an existing label, add an alias, reference a Concept‑Set row, define a Role Description, or mint a new U.Type?”

The lattice enforces locality of meaning (Contexts), senseFamily separation (A.7), and parsimony (A.11) while remaining didactically simple.

Applicability. Use whenever a new name seems “needed” in any FPF pattern thread (Role Assignment & Enactment, Sys-CAL, KD-CAL, Kind-CAL, Method-CAL, LCA-CAL…).

Non‑goals. No workflows, no roles, no storage. This is thinking discipline, not process guidance.

#Problem frame

Modellers tend to mint names when they actually need reuse, aliasing, or explicit Cross‑context reading. Consequences:

1. Name inflation. Parallel labels for the same idea across Contexts.
2. senseFamily mixing. Behavioural Role names that smuggle in deontic Status or measurement talk.
3. Hidden bridges. Cross‑context sameness is implied by look‑alike words rather than declared (F.9).
4. Kernel sprawl. New U.Types appear to plaster over local vocabulary gaps.

#Forces

#Minimal vocabulary (used in this pattern only)

• Context — U.BoundedContext (per D.CTX).
• SenseCell — address of a local sense produced by F.3 (one context × one clustered sense).
• Concept‑Set row — a licensed Cross‑context reading (F.7) of cells in one senseFamily with a declared Row Scope and Row CL(min).
• senseFamily — as defined in F.0.1; here used as the typed discriminator for rows restricted to {Role | Status | Measurement | Type‑structure | Method | Execution}.
• Role Description — a Role/Status template anchored to a single SenseCell (F.4).
• Alias — an additional label for an existing FPF label (within F.5), no new semantics.
• CL threshold τ(scope) — the minimum congruence level needed for a row’s scope (e.g., τ(Naming-only) < τ(Assignment-eligibility) < τ(Type-structure)).

#The decision lattice (conceptual, notation‑free)

Read top‑to‑bottom; the first satisfied branch decides. At every step, state the senseFamily (Role / Status / Measurement / Type‑structure / Method / Execution) before you proceed.

#Q0 — What is the senseFamily of your need?

• If uncertain, return to F.1/F.3: stabilise the Context(s) and the local sense.
• If mixed, split the need: one decision per senseFamily (A.7).

#Q1 — Is there a single Context whose SenseCell already expresses it?

• Yes → Reuse the SenseCell’s label inside that Context.

  • If you need assignable behaviour or deontics on that sense: define a Role Description anchored to that SenseCell (F.4).

• No → go to Q2.

Example (engineer). You want “task execution” in control software. In IEC 61131‑3 there is a clear SenseCell for task execution. Reuse that label; if you need responsibilities (“who monitors runs”), define a Role Description anchored to this SenseCell.

#Q2 — Do you need to read across Contexts (same senseFamily)?

• No → stay within one context; if your desire is merely a nicer label, consider an Alias (Q3).

• Yes → check F.7 for a Concept‑Set row covering your cells in this senseFamily with adequate Row Scope and Row CL(min).

  • Found & sufficient → Reuse the row’s FPF label at that scope.
  • Not found or insufficient → either (a) publish a contrast (teach difference), or (b) propose a new row but only after F.9 Bridges exist at τ(scope).

Example (manager). You want one label for the actor in workflow and provenance prose. F.7 has a Naming‑only row mapping BPMN Participant ↔ PROV Agent at CL = 2. Reuse “actor” at Naming‑only scope; do not infer identity in models.

#Q3 — Is this only a wording preference for an existing FPF label?

• Yes → add an Alias in F.5 (Tech register and/or Plain register), no semantics changed.
• No → go to Q4.

Example (researcher). You prefer “is‑a” to “subclass‑of” in Type pages. That is an Alias for the same concept; no new row, no new U.Type.

#Q4 — Does your need recur across Contexts in a way not captured by current rows, with Bridges already available at the required CL?

• Yes → propose a new Concept‑Set row (F.7): small (2–4 Contexts), one senseFamily, declare Row Scope and Row CL(min), include a counter‑example if any Bridge has loss notes.
• No → go to Q5.

Example (engineer). You repeatedly compare runtime occurrence in PROV with PLC task runs. F.9 Bridges exist at CL = 2. Propose row “execution-occurrence” at assignment/enactment-eligibility scope (not Type-structure).

#Q5 — Are you describing a kernel‑level notion missing from the catalogue, not reducible to existing rows or Role Descriptions, and present across ≥ 3 domain families (A.8)?

• Yes → propose a new U.Type (rare). Supply: (i) the minimal intensional definition; (ii) cross‑family evidence (≥ 3 Contexts, distinct families); (iii) how it doesn’t duplicate an existing U.Type.
• No → you do not mint a new type. Re‑express the need in terms of Context reuse, row reuse, Alias, or a Role Description.

Example (researcher). You think we need U.InfluenceEdge (causal tendency). If it appears as a stable, senseFamily‑specific notion across control, epistemic inference, and methods (≥ 3 families), and cannot be formed from existing U.Relation subtypes, it may qualify. Otherwise, treat it as a pattern or a row.

#Scope thresholds (default τ) — how much sameness you’re allowed to claim

Guard. You may tighten scope (e.g., from Naming-only → Assignment-eligibility) only if the Row CL(min) meets the higher τ.

#Micro‑examples (didactic triad)

#For engineers — “Do we need a new Execution label?”

• Need. “We want to refer to what actually happened in both provenance logs and PLC runtime.”
• senseFamily. Execution - stance. run.
• Contexts. PROV‑O (Activity), IEC 61131‑3 (task run).
• Row? F.7 has execution-occurrence at assignment/enactment-eligibility, CL = 2.
• Decision. Reuse that row’s label at Assignment-eligibility; no new U.Type; define Role Descriptions anchored to each Context as needed.

#For managers — “Can we call them all actors?”

• Need. A single everyday word in the spec to denote “the responsible party”.
• senseFamily. Role (behavioural mask in prose).
• Contexts. BPMN 2.0 (Participant), PROV‑O (Agent).
• Row? Naming‑only row “actor”, CL = 2.
• Decision. Reuse “actor” in prose only; keep Context‑loyal labels in formal sections. No Role Description minted unless tied to one context.

#For researchers — “New U.Type for ‘Work Scope’?”

• Need. Kernel notion capturing feasible performance region across systems.
• Test A.8. Appears in control (reachable sets), services (operating envelope), measurement (confidence bands): ≥ 3 families?
• Reduction test. Can it be expressed as a row + existing U.Relation + KD‑CAL constructs?
• Decision. If not reducible and cross‑family stable, propose new U.Type with minimal definition; otherwise, prefer a row or a pattern.

#Invariants (normative, lightweight)

1. Context‑first. Every decision cites at least one Context; no global senses.
2. senseFamily purity. A single decision covers one senseFamily. Mixed needs are split.
3. Row honesty. Any Cross‑context reuse occurs via a Concept‑Set row at or above τ(scope); no stealth equivalence.
4. Role Description anchoring. Role Descriptions are single-Context, single-cell anchors (F.4).
5. Alias modesty. Aliases never change semantics and live under F.5.
6. Kernel restraint. New U.Types are rare; A.8 (≥ 3 families) is mandatory, and duplication with existing U.Types must be ruled out.

#Mint/Reuse discipline for policy-ids (normative addendum)

FPF treats policy-ids (e.g., Φ(CL), Φ_plane, Ψ(CL^k), Aut-Guard, EmitterPolicyRef, InsertionPolicyRef, Acceptance clause ids) as first-class, versioned tokens. They are not “just strings”, and they are not governed by tier ladders or implied authority.

PolicySpecRef. A resolvable reference to the normative definition of a policy-id (“what does this policy-id mean?”). At minimum it:

• identifies the policy-id,
• pins an immutable edition (or equivalent digest), and
• can be located from the same publication bundle (MVPK / UTS / EvidenceGraph anchors).

MintDecisionRef. A resolvable reference to the decision record that introduced (minted) a policy-id into a declared namespace/registry. For normative policy-ids this is typically a DRR id (E.9) or an equivalent change decision record. For purely local, non-exported policy-ids it MAY be a Gate DecisionLog entry (A.21) if that local-only scope is explicit.

PolicyIdRef (canonical bundle).
PolicyIdRef := { policy_id, PolicySpecRef, MintDecisionRef? }.

Rules.

1. No silent policy-id minting. If a publication introduces a new policy-id (not previously present in the declared namespace/registry), it MUST surface a PolicyIdRef whose:
   • PolicySpecRef is edition-pinned, and
   • MintDecisionRef is resolvable from the publication’s DRR/DecisionLog links.
2. Reuse is reference-only. If a publication reuses an existing policy-id, it MUST surface a PolicySpecRef (and SHOULD preserve the prior mint decision link where available). It MUST NOT restate policy semantics as if minting a new policy-id.
3. GateCrossing checkability. Any GateCrossing/CrossingBundle that surfaces policy-ids MUST include PolicyIdRef (or an equivalent “policy-id + resolvable refs” structure) so GateChecks can verify resolvability and pin consistency (E.18/A.21/G.6:7.5.8).
4. Authority is policy, not tiers. “Who may mint” vs “who may reuse” is expressed by the referenced policy specs and mint decisions (and enforced by the active GateProfile/GateChecks), not by fixed tier labels.

#Quick reference (one‑glance map)

#Anti‑patterns & remedies

#Reasoning primitives (judgement schemas, notation‑free)

Each item states a mental entailment. No storage, no roles, no workflows. Symbols: C = Context, σ = SenseCell, R = Concept‑Set row, SF = senseFamily, τ = scope threshold, CL = congruence level.

1. senseFamily split need(n) ∧ mixedSF(n) ⊢ split(n) into {n₁…nₖ} by senseFamily You cannot decide for mixed senseFamilies; decide per senseFamily.

2. Cell reuse ∃ C,σ : expresses(n,SF)@σ ⊢ reuseLabel(σ) in C If a single Context’s SenseCell already says it, reuse it locally.

3. Assignment-eligibility reuseLabel(σ) ∧ needAssignable(SF ∈ {Role,Status}) ⊢ mintRoleDescription(σ) When you need assignable behaviour/deontics for a local sense, mint a Role Description anchored to that sense.

4. Row reuse crossContexts(n,SF) ∧ ∃ R: covers(R,SF) ∧ CL(R) ≥ τ(scope) ⊢ reuseRow(R,scope) For Cross‑context readings, reuse a row at a scope whose τ is met.

5. Alias suffices sameIntent(n,label₀) ∧ stylePreference(n,label₁) ⊢ alias(label₀,label₁) If it’s only wording, add an Alias; no semantics move.

6. Row proposal recurrentCross(n,SF) ∧ bridgesCL(cells(n)) ≥ τ(scope) ∧ ¬∃R ⊢ proposeRow(cells,scope) If the need recurs and Bridges support the scope, propose a new row.

7. Kernel minting (rare) kernelCandidate(n) ∧ crossFamily≥3 ∧ irreducible(n) ⊢ proposeUType(n) Only if the notion is cross‑family and cannot be reduced to cells+rows+existing U.Types.

8. Scope downgrade reuseRow(R,scope) ∧ CL(R)↓ < τ(scope) ⊢ downgradeScope(R) If CL falls, lower the row’s licensed scope.

9. Row rejection conflictEvidence(rowCells) ∧ lossUnbounded ⊢ rejectRow If bridges show open‑ended loss, do not publish a row; teach the contrast.

#Extended worked examples

#Execution, observation, and acceptance (engineers)

Need. A reusable label for “what actually happened and how it was checked against the promise”. senseFamilies. Execution (stance: run); Measurement (KD); Status (accept/reject).

Contexts. IEC 61131‑3 (task run), PROV‑O (Activity), SOSA/SSN (Observation), ITIL 4 (SLO/SLA).

Reasoning.

• Execution: IEC SenseCell (task run) and PROV SenseCell (Activity). There exists a row execution-occurrence at Assignment-eligibility with CL = 2 → reuse row at Assignment-eligible scope; do not infer Type-structure.
• Measurement: SOSA Observation cell; no Cross‑context needed → reuse cell.
• Status: ITIL SLO/SLA cell; Role Description “SLO‑Target” anchored to ITIL cell.

Outcome. Prose may say: “This execution-occurrence (row@assignment/enactment-eligibility) was observed (SOSA cell) and evaluated against the SLO (ITIL cell).” No new U.Type; no hidden merges.

#Actor across workflow and provenance (managers)

Need. A single everyday label for “the responsible party” in diagrams. senseFamily. Role (behavioural mask in prose/diagrams).

Contexts. BPMN 2.0 (Participant), PROV‑O (Agent).

Reasoning. A Naming‑only row “actor” exists, CL = 2. Reuse the row at Naming‑only. If assignable behaviour is needed in a model, mint Role Description anchored to BPMN Participant (not to the row).

Outcome. Diagrams show “actor”; formal sections reference Participant or Agent as appropriate.

#Accuracy across metrology and data quality (researchers)

Need. Treat “accuracy” consistently across ISO 80000 (metrology) and ISO/IEC 25024 (data quality). senseFamily. Measurement.

Contexts. ISO 80000‑1 (quantity/units), ISO/IEC 25024 (data quality).

Reasoning. Bridges indicate related but not identical definitions; procedures differ. Existing KD‑metric row “accuracy” has CL = 2 with loss note: population vs instrument focus. Reuse row at KD‑metric scope for dashboards; do not use the row to justify interchange of procedures.

Outcome. One label in reports; method sections still cite the context‑local procedure.

#F.8:12.4 Subtype relation across OWL and a curated taxonomy (formalists)

Need. Present “is‑a” uniformly across OWL 2 classes and a domain taxonomy. senseFamily. Type‑structure.

Contexts. OWL 2 (SubClassOf), Taxonomy_X (curated “is‑a” edges).

Reasoning. F.7 row “subtype‑order” exists at Type‑structure scope with CL = 3 (only after verifying acyclicity & anti‑symmetry in Taxonomy_X). If the curated taxonomy contains cycles, downgrade to Naming‑only or reject the row.

Outcome. When CL≥3, you may reuse row for structural proofs; else teach differences.

#Relations (with other patterns)

• Builds on: E.10.D1 (D.CTX) Context ≡ U.BoundedContext; F.1 Contexts; F.2 Harvest; F.3 SenseCells.

• Constrains:

  • F.4 Role Description: one SenseCell per Role Description; no row anchoring.
  • F.5 Naming: Aliases are style‑only; no semantics movement.
  • F.7 Concept‑Set: rows must declare Scope & Row CL(min) and carry loss notes.
  • F.9 Bridges: any row proposal presupposes Bridges at or above τ(scope).

• Used by. All patterns (Part C) whenever new labels are contemplated.

#Migration notes (conceptual)

1. Old “anchor” language. Replace legacy “anchor” with: SenseCell (local sense) + Role Description (assignable Standard) + (optionally) Concept‑Set row (Cross‑context reading).
2. Over-strong rows. If a row was used for assignment/enactment-eligibility or Type-structure but CL drops, downgrade row scope to Naming-only in prose; adjust examples.
3. Split rows. If one row covers cells whose Bridges diverge, split into two narrower rows with explicit loss notes.
4. Alias proliferation. Collapse redundant Aliases under a single F.5 entry; keep both registers (Tech/Plain).
5. Proto‑types. Suspect kernel inflation? Attempt reduction: SenseCell + row + existing U.Type. Only if irreducible across ≥ 3 families, reopen as a U.Type candidate.

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

#Static conformance (SCR)

• SCR‑F8‑S01 (senseFamily purity). Every decision record names one senseFamily; mixed needs are split.
• SCR‑F8‑S02 (Proper anchoring). Every Role Description cites one SenseCell; no row is used as a assignment/enactment anchor.
• SCR‑F8‑S03 (Row scope). Whenever a row is reused, its Scope is stated and Row CL(min) ≥ τ(scope) holds.
• SCR‑F8‑S04 (Alias modesty). Aliases introduced in F.5 do not claim new semantics or change senseFamily.
• SCR‑F8‑S05 (Kernel restraint). Any new U.Type proposal includes ≥ 3 domain families of evidence and an irreducibility note.

#Regression (RSCR)

• RSCR‑F8‑E01 (CL drift). If any Bridge’s CL changes, re‑evaluate dependent rows; downgrade or split where τ(scope) is no longer met.
• RSCR-F8-E02 (Row overuse). Scan examples: no case uses Naming-only rows to justify Assignment-eligibility or Type-structure claims.
• RSCR‑F8‑E03 (Alias creep). Ensure no Alias has accreted senseFamily‑specific semantics; if it has, migrate to a row or Role Description.
• RSCR‑F8‑E04 (Kernel hygiene). New U.Type proposals are rejected if a SenseCell + row construction suffices.

#Didactic distillation (90‑second teaching script)

“When you feel like coining a new name, pause. Which senseFamily are you in—Role, Status, Measurement, Type‑structure, Method, or Execution? If a single Context’s SenseCell already says it, reuse that label. If you need an assignable Standard, mint a Role Description anchored to that SenseCell. If you must read across Contexts, reuse a Concept‑Set row—but only at a stated scope and only if its CL meets the threshold (τ). If it’s just a nicer wording, add an Alias (style only). Only in the rare case of a cross‑family, irreducible notion do you mint a new U.Type. Never let Naming‑only rows justify Assignment-eligibility or structural inference, and never let identical strings force equivalence. This is not process—it’s discipline of thought: reuse what exists, declare scope when you bridge, and mint new primitives only when the kernel truly needs them.”

#F.8:End

#Alignment & Bridge across Contexts

“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 & StatusModality guard; Bridge-only crossing); F.1 (Contexts fixed); F.2/F.3 (Cells exist); F.7 (rows depend on Bridges); F.8 (thresholds and reuse choice).

Coordinates with: B.3 Trust & Assurance Calculus (uses CL penalties); A.6.1 U.Mechanism (Transport clause for cross-context use; penalties route to R/R_eff only; F/G invariant); Part C patterns (apply Bridges in formal claims); A.6.9 (RPR-XCTX for repairing umbrella “same/equivalent/align/map” prose into explicit Bridge Cards). Aliases (informative). Context-to-Context translator; Sense bridge.

#Intent & applicability

Intent. Provide a conceptual discipline for relating SenseCells from different Contexts (U.BoundedContext). A Bridge states what kind of relationship holds, how far it holds (via CL: Congruence Level), and what is lost during the translation. Bridges permit carefully scoped reuse (e.g., a Concept-Set row) while forbidding silent equivalence.

Applicability. Use whenever an author needs to read across Contexts—to reuse a familiar label, to connect design-time and run-time notions, to compare two standards’ terms, or to justify a row in the Concept-Set table. This pattern is not storage, enactment protocol, or governance; it codifies thinking moves.

Non-goals. No global meaning; no publication-surface semantics; no editor roles. Bridges are semantic relations between local senses, not transport chains, not processes.

#Problem frame

Cross-context work fails in predictable ways:

1. String-equals fallacy. Identical surfaces (“process”, “role”, “accuracy”) taken as identical meaning.
2. Scope creep. A naming convenience is stretched to assignment or structural claims.
3. DesignRunTag jumping. Design artefacts are substituted for run-time occurrences (or vice-versa).
4. Direction amnesia. Narrower/broader relations treated as symmetric.
5. Loss blindness. Differences (units, granularity, preconditions) are left unstated, contaminating downstream reasoning.

Bridges cure these by making relation, direction, loss, and strength explicit.

#Forces

#Core idea (didactic)

A Bridge is a declared translator between two local senses. It always names (a) the two SenseCells, (b) a Bridge kind (what relation), (c) a direction (if non-symmetric), (d) a CL (how strong), and (e) Loss Notes (what fails to carry). Some Bridges permit substitution in limited scopes; others permit only explanation.

#Minimal vocabulary (this pattern only)

• Context — shorthand for U.BoundedContext (per E.10.D1).

• SenseCell - the pair (Context, Local-Sense) from F.3.

• Bridge — a conceptual relation between two SenseCells with kind, direction, CL, and loss notes.

• CL (Congruence Level) — ordinal strength (0…3) of a Bridge (see §7).

• Scope — the licensed use of a Cross-context reading (as in F.7/F.8):

• Naming-only (talk consistently),

• Role Assignment & Enactment-eligibility (assignable constraints/roles/status reuse),

• Type-structure (safe structural inference).

• senseFamily — the semantic category (Role, Status, Measurement, Type-structure, Method, Execution…) per F.0.1 (normative Part F guard).

#Bridge kinds (senseFamily-aware)

Two families of Bridges: Substitution Bridges (senseFamily-preserving; can support Concept-Set rows) and Interpretation Bridges (explanatory; not for substitution).

#Substitution Bridges (sense-preserving)

These relate SenseCells of the same senseFamily and may license limited substitution:

1. Equivalence - near-identity of sense. Symmetric. Rare. Use: May support Type-structure rows when CL=3 and invariants match. Loss Notes: usually “none” or “profiling differences”.

2. Narrower-than / Broader-than - proper inclusion of sense. Directional. Use: Safe to substitute narrower > broader in Naming-only and sometimes Role Assignment & Enactment; broader > narrower is unsafe. Loss Notes: “loses special cases X”.

3. Partial-overlap - non-empty intersection, neither includes the other. Use: Naming-only at best. Never justifies Role Assignment & Enactment / Type-structure. Loss Notes: “A-only senseFamily”, “B-only senseFamily”.

4. Disjoint - explicit contrast. Use: For didactic warnings; not a reuse license. Loss Notes: n/a (it asserts incompatibility).

#Interpretation Bridges (cross-senseFamily, explanatory)

These do not allow substitution but explain connections across senseFamilies:

5. Design-spec -> Run-trace - a design concept relates to its run-time occurrence. Example: BPMN:Process -> PROV:Activity. Use: Explain design-to-execution correspondence. No Concept-Set rows. Loss Notes: “graph vs event”, “control-flow vs temporal extent”.

6. Measure-of / Evidence-for (->) — a measurement SenseCell evidences or quantifies another senseFamily (e.g., a Requirement clause). Example: SOSA:Observation -> ITIL:SLO fulfilment. Use: Explain evaluation. No substitution.

7. Policy-implies / Obliges (->) — a deontic statement constrains another senseFamily. Example: ODRL:Duty -> Service behaviour. Use: Explain constraint propagation.

Rule of thumb. If you want rows or substitution, you need a Substitution Bridge on the same senseFamily. If you want to explain why artefacts relate without claiming sameness, use Interpretation Bridges.

#CL scale and scope thresholds

CL expresses how safely meaning carries over.

• Thresholds (normative):

  • Publishing a Naming-only row requires CL >= 1 across the row-s Cells.
  • Publishing a Role Assignment & Enactment-eligible row requires CL >= 2, the same senseFamily, and compatible stance.
  • Publishing a Type-structure row requires CL = 3 and matched invariants (acyclicity, anti-symmetry, units, etc.).

• Penalty use (informative): B.3 may convert CL into an assurance penalty when a cross-context claim is made.

#The Bridge Card (compact sketch)

A thought-format (not a form). Every bullet can be said in a sentence.

• Cells. A@contextA - B@contextB.
• senseFamily. Role / Status / Measurement / Type-structure / Method / Execution …
• Kind. Equivalence / Narrower-than / Broader-than / Partial-overlap / Disjoint / Design-spec -> Run-trace / Measure-of / Policy-implies.
• Direction. A -> B (if non-symmetric) or A <-> B.
• CL. 0–3 with a short why.
• Loss Notes (bullets). What fails to carry (units, scope, granularity, preconditions, time stance).
• Counter-example. The crispest case where substitution would mislead.
• Allowed use. Naming-only / Role Assignment & Enactment-eligible / Type-structure / Explanation-only.
• Didactic hook. The helpful sentence a careful engineer can remember.

t’t fit on a screen, you’re describing the Contexts, not the Bridge.*

Registry-reference note (normative). BridgeId and any policy/edition identifiers cited by a Bridge Card are registry references (keys into registries), not semantic symbols exported by signatures. Therefore they MUST NOT be demanded via SignatureManifest.provides (or -satisfied- via imports closure); conformance is checked by validating that the referenced registry entries exist and, where required, are edition-pinned (see F.15).

#Invariants (normative)

1. Locality first. A Bridge relates SenseCells, never Contexts or strings.
2. senseFamily discipline. Substitution Bridges must be senseFamily-preserving. Interpretation Bridges may cross senseFamilies but never license substitution.
3. Direction clarity. If the kind is directional, state direction explicitly.
4. CL honesty. Assign CL only if you can state at least one counter-example for CL <= 2 or explain its absence with invariants for CL = 3.
5. Loss visibility. Every Bridge carries Loss Notes (even “none”).
6. Row dependence. A Concept-Set row’s scope is bounded by the weakest CL among its participating Bridges (F.7/F.8).
7. No senseFamily jump by stealth. You must not use an Interpretation Bridge to justify a row or substitution.
8. Time DesignRunTag honesty. If a Context fixes design/run, the Bridge must respect that distinction or explicitly declare a bridge such as Design-spec -> Run-trace.
9. Kernel restraint. Bridges cannot be used to promote ad-hoc sameness into a new U.Type; A.11 applies.
10. Non-inheritance of Contexts. Bridges do not imply -is-a- between Contexts (E.10.D1).

#Micro-examples (illustrative, one-liners)

1. Participant vs Agent (process model vs provenance) Cells: BPMN:Participant - PROV:Agent - senseFamily: Role - Kind: Partial-overlap - CL: 2 - Loss: participation vs attribution scopes differ - Use: Naming-only ("actor").

2. Process (design) vs Activity (run) Cells: BPMN:Process -> PROV:Activity - senseFamily: Method / Execution - Kind: Design-spec -> Run-trace - CL: 2 - Loss: graph vs event; concurrency vs temporalization - Use: Explanation-only.

3. Observation vs SLO check Cells: SOSA:Observation -> ITIL:SLO-fulfilment - senseFamily: Measurement / Status - Kind: Measure-of - CL: 2 - Loss: sampling window; target definition - Use: Explanation-only.

4. Subtype across OWL and curated taxonomy Cells: OWL:SubClassOf - TaxonomyX:is-a - senseFamily: Type-structure - Kind: Equivalence - CL: 3 (only if TaxonomyX is acyclic and anti-symmetric) - Loss: profile differences - Use: Type-structure rows allowed.

5. Accuracy (metrology vs data-quality) Cells: ISO80000:accuracy - ISO25024:accuracy - senseFamily: Measurement - Kind: Partial-overlap - CL: 2 - Loss: instrument vs dataset perspective - Use: Naming-only row -accuracy-; methods stay context-local.

#Anti-patterns & remedies

#Worked examples (didactic)

#Service acceptance (design) vs executions & observations (run)

• Cells & Contexts ITIL4:SLO (Status, design) <- SOSA:Observation(availability) (Measurement, run) BPMN:Process (Method, design) -> IEC61131:Task-Execution (Execution, run)
• Narrative Availability SLOs are evaluated by observations of task executions. No substitution follows: an SLO is not an observation, and a process is not an execution occurrence.
• Bridge Cards (sketch) ITIL:SLO <- SOSA:Observation - CL=2 - Loss: sampling window, clock skew. BPMN:Process -> IEC:Execution - CL=2 - Loss: control-flow vs temporalization, concurrency collapse.
• Permitted use Explanation-only; Concept-Set rows may be Naming-only ("availability") with CL >= 1 label coherence across Contexts.

#Behavioural role vs access role

• Cells & Contexts BPMN:Participant (Role) - NIST-RBAC:Role (Status)
• Narrative Both talk about -who acts-, but one is a behavioural mask in a process model, while the other is a permission grouping.
• Bridge Kind: Partial-overlap, CL=2; Loss: assignment moment, enforcement locus, multiplicity.
• Permitted use
• Naming-only row “actor”; no Role Assignment & Enactment reuse across senseFamilies.

#Equivalence of subtype notions for structural rows

• Cells & Contexts OWL2:SubClassOf (Type-structure) - TaxX:is-a (Type-structure curated)
• Bridge Kind: Equivalence, CL=3 iff the curated taxonomy is acyclic and anti-symmetric and uses class-level reasoning.
• Permitted use Type-structure rows allowed (CL = 3); Loss: OWL profile limitations (RL/EL/QO).

#Accuracy (metrology) vs accuracy (data-quality)

• Cells & Contexts ISO80000:measurement-accuracy (Measurement) - ISO25024:data-accuracy (Measurement)
• Bridge Kind: overlap, CL=2; Loss: “true value” notion differs (instrument vs dataset), scale transformations.
• Permitted use Naming-only row “accuracy” used for reports; no shared methods.

#Setpoint (control) vs target (service)

• Cells & Contexts CTRL:text:setpoint (Status/Control) - ITIL:target (Status/Service)
• Bridge Kind: Disjoint - Rationale: physical reference value vs business objective; different target kinds (control parameters vs requirement clause).
• Permitted use Didactic contrast only; prevents accidental substitution in SLO calculus.

#Role substitution & CL gating (RoleAssignment/enactment scope)

Use. A worked, role-focused restatement of Bridge usage for the recurring question: “May Role_B@B satisfy Role_A@A for requiredRoles / enactment checks-”

Rule. No cross-context substitution by name. If a step in Context A needs Role_A, and the performer only holds Role_B in Context B, an explicit Bridge MUST state how Role_B@B relates to Role_A@A, with direction, CL, and Loss Notes.

#Directional substitution (role-oriented shorthand)

A Bridge may assert, directionally:

• substitutesFor(Role_B@B > Role_A@A) with a CL and a list of kept and lost characteristics (for roles: typical losses are RCS characteristics and/or RSG nuances).
• The reverse direction does not follow unless declared (F.9:13.7).

#CL > gating policy (didactic default)

Notes. The substitution licence is defined in F.9:13.2-13.3 (Role-Assignment/Enactment-eligible substitution requires CL >= 2; Naming-only is CL >= 1). CL penalties route to assurance (R) per B.3; safety-critical policies may require CL >= 2 by default (D.2).

#Typical bridges (worked patterns)

• BPMN Task - PROV Activity.
  substitutesFor(Task@BPMN > Activity@PROV) with CL=2; lost: BPMN control-flow guards; kept: “bounded occurrence consuming/producing entities.”
  Effect. A Work logged as Activity@PROV may satisfy a step requiring a Task@BPMN iff an extra guard enforces the BPMN pre-/post-conditions.

• Essence Alpha-State - RoleStateGraph state.
  substitutesFor(“Alpha.State:Ready”@Essence > “Ready”@RSG) with CL=2; lost: Alpha-specific narrative criteria; kept: checklist-based readiness.
  Effect. A team may reuse Essence states as labels in RSG, but still maintains local checklists as StateAssertions.

• ITIL Service Owner - RBAC Administrator.
  Typically CL=1 and directional (Administrator@RBAC > ServiceOwner@ITIL) rejected unless a policy Bridge enumerates compensating controls.
  Effect. Prevents “ops admin = service owner” conflations without an explicit waiver.

#Bridge invariants (role-relevant reminders)

• Local first. Substitution never overrides in-Context role algebra (its own role relations, guards, and exclusions).
• Loss honesty. If a Bridge’s loss notes indicate that a dropped characteristic is required by a step, substitution is invalid (regardless of CL).
• No silent inversion. Direction is explicit; substitution does not reverse unless declared (F.9:13.7).

#Reasoning primitives (judgement schemas)

All judgements are conceptual. They license or forbid specific thinking moves-not enactment steps and not process enactment surfaces.

#Bridge declaration

Bridge(A@RA, B@RB) : senseFamily, kind, dir, CL, Loss, scope

Reading: There exists a declared Bridge between SenseCells A and B with stated attributes.

#Substitution licence (senseFamily-preserving)

Bridge(A,B): same senseFamily f, kind in {Equivalence, Narrower-than, Broader-than}, dir A->B, CL>=2, Loss L -> A may stand in for B at senseFamily f (Role-Assignment/Enactment-eligible)

Reading: A Substitution Bridge on the same senseFamily with CL >= 2 licenses Role-Assignment/Enactment-level substitution in the stated direction. (Type-structure requires CL = 3.)

#Naming-only licence

Bridge(A,B): kind in {Equivalence, Narrower-than, Broader-than, Partial-overlap}, CL>=1 -> A and B may share a label (Naming-only)

Reading: A Bridge with CL >= 1 supports using a shared label in prose or Concept-Set Naming-only rows, without structural or Role Assignment & Enactment commitments.

#Prohibition by kind

Bridge(A,B): kind=Disjoint -> no substitution and no shared row

Reading: Disjoint forbids substitution and rows; only contrastive teaching is allowed.

#Interpretation embargo

Bridge(A,B): kind in {Design-spec -> Run-trace, Measure-of, Policy-implies} -> Explanation-only

Reading: Interpretation Bridges never license substitution or rows.

#Weakest-link rule for rows

row R uses {Bridge_i} -> scope(R) = min_i(scopeAllowed(Bridge_i)) and CL(R) = min_i(CL_i)

Reading: The row scope and row CL are bounded by the weakest participating Bridge.

#Direction guard

Bridge kind=Narrower-than with dir A->B -> not(B may stand in for A)

Reading: Narrower>Broader does not invert; only A may substitute into B under the stated scope.

#SenseFamily purity

Bridge scope=Role Assignment & Enactment-eligible -> same senseFamily(A,B) and same stance(A,B)

Reading: Role Assignment & Enactment-level substitution requires same senseFamily and same stance (run-time or design time).

#Loss accumulation

A->B with Loss L1 and B->C with Loss L2 -> A->C allowed only if the same senseFamily is preserved, CL=min(CL1,CL2), and Loss accumulates as L1 union L2

Reading: Chained substitution is rarer; if used, accumulate Loss and respect the minimum CL. When in doubt, avoid chaining across Contexts.

#Relations

Builds on: E.10.D1 (Context discipline: Context = U.BoundedContext); F.0.1 (senseFamily guard; Bridge-only crossing); F.1 (Contexts fixed); F.2/F.3 (Cells exist); F.7 (rows depend on Bridges); F.8 (thresholds and reuse choice).

Coordinates with: F.9.1 for stance overlays that remain subordinate to bridge cards; E.17.1 when viewpoint bundles need explicit cross-family correspondence; A.6.Q / C.25 when evaluative endpoints or bundle-shaped quality families cite bridge cards without absorbing bridge semantics.

Constrains:

• F.7 Concept-Set Table: each cross-context row must name supporting Bridges; row scope <= the weakest supporting Bridge.
• F.8 Mint or Reuse: reuse choices reference CL and kind; no reuse without a Bridge.
• Part C patterns: formal claims that span Contexts cite Bridges and respect senseFamily/StatusModality & CL constraints.
• B.3 Trust & Assurance Calculus: may interpret CL as a penalty factor in Cross-context reasoning.

#Migration notes (conceptual)

1. Edition shift in a Context. Re-read affected Cells; if sense moved, split the Bridge or lower CL; keep the older Bridge for historical claims.
2. New evidence of mismatch. Add a counter-example; decrease CL or change bridge kind (for example from Equivalence to Partial-overlap or Disjoint).
3. Convergence over time. When invariants demonstrably match, and counter-examples evaporate, raise CL cautiously; for CL=3, cite invariants.
4. senseFamily refactor. If a Cell’s senseFamily was mis-typed, fix the senseFamily first in F.3, then revisit Bridges; Interpretation is safer than forced substitution.
5. Row under-protected. If a row’s scope exceeds the weakest Bridge, either split the row by Context or downgrade scope to Naming-only.
6. Bridge sprawl. Consolidate near-duplicates into one Bridge with richer Loss Notes; retire the rest.

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

#Static conformance (SCR)

• SCR-F9-S01 (Well-typed). Every Bridge names two SenseCells, each bound to a Context from F.1, and states senseFamily, kind, dir (if needed), CL, Loss, and scope.
• SCR-F9-S02 (senseFamily discipline). Any Bridge that licenses Role/Enactment-eligible substitution is senseFamily-preserving and has kind in {Equivalence, Narrower-than, Broader-than}.
• SCR-F9-S03 (Loss visibility). Every Bridge has non-empty Loss Notes (the word "none" is allowed only with CL=3 and stated invariants).
• SCR-F9-S04 (Counter-example hygiene). Bridges with CL <= 2 carry at least one counter-example; Bridges with CL=3 cite matching invariants.
• SCR-F9-S05 (Row compliance). Every Concept-Set row shows a scope no greater than the minimum CL across its supporting Bridges; no row relies on Interpretation Bridges.

#Regression (RSCR)

• RSCR-F9-E01 (Edition churn). When a Context-s edition changes, re-validate all Bridges touching it; flag CL drift and update rows- scopes if needed.
• RSCR-F9-E02 (Counter-example drift). New counter-examples lower CL; deletions do not automatically raise CL.
• RSCR-F9-E03 (senseFamily drift). If a Cell-s senseFamily is corrected, all Bridges crossing that Cell are re-typed; any substitution that would now cross senseFamilies is invalidated.
• RSCR-F9-E04 (Weakest-link enforcement). Adding a low-CL Bridge to a row reduces the row-s scope; if the row-s published scope would exceed the new minimum, split or downgrade the row.

#Didactic distillation (90-second script)

-A Bridge translates between local senses from different Contexts. It always declares what relation holds (Equivalence, Narrower-than, Broader-than, Partial-overlap, Disjoint, or an interpretation such as Design-spec -> Run-trace), how strong (CL 0-3), which way (when direction matters), and what is lost. Substitution is allowed only on the same senseFamily and only with CL >= 2; Type-structure needs CL = 3. Interpretation Bridges explain, never substitute. Rows in the Concept-Set table obey the weakest-link: their scope cannot exceed the lowest CL among their Bridges. When editions change or counter-examples surface, lower CL or change bridge kind; if two senses truly converge and invariants match, raise to CL = 3-rarely, and with reasons. Translate across Contexts; never collapse them.-