FPF Reference

Mint or Reuse? (U.Type vs Concept-Set vs Role Description vs Alias)

Pattern F.8 · Stable Part F - The Unification Suite (U-Suite): Concept-Sets, SenseCells & Contextual Role Assignment

“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. Provide a minimal, conceptual decision lattice that answers, for any modelling need:

Keywords

  • decision lattice
  • type explosion
  • reuse
  • minting new types
  • parsimony.

Relations

F.8builds onRole Description (RCS + RoleStateGraph + Checklists)
F.8builds onConcept‑Set Table Construction
F.8builds onLexical Discipline for “Context” (D.CTX)
F.8builds onDomain‑Family Landscape Survey
F.8builds onTerm Harvesting & Normalisation
F.8builds onIntra‑Context Sense Clustering
F.8constrainsRole Description (RCS + RoleStateGraph + Checklists)
F.8constrainsNaming Discipline for U.Types & Roles
F.8constrainsConcept‑Set Table Construction
F.8constrainsAlignment & Bridge across Contexts
F.8explicit referenceLexical Discipline for “Context” (D.CTX)
F.8explicit referenceStrict Distinction (Clarity Lattice)
F.8explicit referenceOntological Parsimony (C-5)
F.8explicit referenceUniversal Core (C-1)
F.8explicit referenceDomain‑Family Landscape Survey
F.8explicit referenceTerm Harvesting & Normalisation
F.8explicit referenceIntra‑Context Sense Clustering
F.8explicit referenceRole Description (RCS + RoleStateGraph + Checklists)
F.8explicit referenceNaming Discipline for U.Types & Roles
F.8explicit referenceConcept‑Set Table Construction
F.8explicit referenceAlignment & Bridge across Contexts
F.8explicit referenceTransduction Graph Architecture (E.TGA)
F.8explicit referenceGateProfilization: OperationalGate(profile) (GateFit core)

Content

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

ForceTension to resolve
Parsimony vs coverageAvoid new names unless necessary, yet cover recurring Cross‑context readings.
Locality vs unificationKeep senses in‑Context; when reading across, do it explicitly and only as far as needed.
Didactics vs fidelityGive readers one label to hold, but never over‑state sameness (respect CL and scope).

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

Row / Use ScopeWhat it licensesDefault τ (minimum CL)Typical consumers
Naming‑onlyShared label in prose, diagrams, and primers; no inference.1Pedagogy, glossary, didactic figures.
Assignment-eligibilitySafe to reference the row’s target as the thing a U.RoleAssignment may point to (e.g., a run, a value).2F.4 Role Description, acceptance narratives.
KD‑metricTreat cells as the same measured outcome (unit‑compatible, procedure‑compatible).2Measurement summaries, SLO tables.
Type‑structureTreat cells as the same structural relation (e.g., subtyping) with inheritance semantics.3Kind-CAL pages, structural proofs.

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)

You feel you need…Likely actionWhy
A convenient everyday word across two ContextsReuse a Naming‑only rowKeeps prose simple without smuggling inference.
An assignable mask with invariantsRole Description (single Context)Roles/Statuses attach to local senses.
The same measured outcome across ContextsReuse a KD‑metric rowUnits/procedures aligned at CL ≥ 2.
A unifying schema relation (e.g., is‑a)Reuse a Type‑structure rowStructural inference preserved at CL ≥ 3.
A nicer label for the same FPF conceptAlias in F.5Style only; zero semantics.
A brand‑new primitive conceptNew U.Type (rare)Only if cross‑family, irreducible, kernel‑level.

Anti‑patterns & remedies

#Anti‑patternSymptomWhy it harms thinkingRemedy (conceptual move)
AP‑1Row‑less samenessDeclaring “these mean the same” across Contexts without citing a Concept‑Set row.Imports meaning implicitly; no CL guard.If Cross‑context reuse is desired, reuse an existing row at a declared scope (F.7), else publish the contrast and defer to F.9 Bridges.
AP-2Scope creepUsing a Naming-only row to justify Assignment-eligibility or structural inferences.Over-claims sameness; breaks τ(scope).Respect scope thresholds (τ). Upgrade only when Row CL(min) ≥ τ(new scope); otherwise stay Naming-only.
AP‑3Alias with payloadIntroducing an Alias that subtly changes intent or senseFamily.Hides semantics behind wording; confuses senseFamilies.Aliases (F.5) are style only. If semantics change, choose row reuse or Role Description instead.
AP-4Role-Description-to-row anchoringRole Description points to a row rather than a single SenseCell.Masks locality; assignments become cross-context by stealth.Role Descriptions must anchor to one SenseCell (F.4). Use rows only in prose or aggregated views.
AP‑5Kernel inflationProposing a new U.Type because a convenient label is missing.Duplicates the kernel; violates parsimony.Apply A.8: require ≥ 3 domain families and irreducibility; otherwise Alias or row.
AP‑6senseFamily mixingOne name that conflates Role, Status, Measurement, or Type‑structure.Collapses A.7 Strict Distinction.Split by senseFamily first (Q0). Decide per senseFamily.
AP‑7Bridge‑by‑stringTreating identical surface forms as equivalent senses across Contexts.Homonym trap; ignores local sense.Equivalence only via F.9 Bridge + row; never by string.
AP‑8Row without loss notesPublishing a row where Bridges indicate mismatches, but row text is silent.Readers assume full equivalence.Include counter‑example and loss sketch in the row’s narrative (F.7).
AP‑9CL launderingCiting a high‑scope row based on old high CL while Bridges have since weakened.Invalidates downstream claims.When CL falls below τ(scope), downgrade row scope (e.g., to Naming‑only) or split row.
AP‑10Global normal formSeeking one canonical wording across all Contexts as if meaning were global.Erases locality; fuels hidden merges.Keep normalisation per Context (F.2/F.3). Cross‑context sameness lives in rows with scope.

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