Concept‑Set Table Construction

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

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

Keywords

  • concept-set
  • table
  • row
  • columns
  • differences
  • comparisons.

Relations

Content

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

ForceTension to resolve
Locality vs comparisonMeaning lives in Contexts; yet we must compare Contexts to reason across disciplines.
Didactics vs fidelityA compact row is easy to grasp; it must still show scope and loss honestly.
Simplicity vs completenessA minimal grid aids memory; temptation to overload it with proofs and procedures must be resisted.
Sameness vs differenceSome families cannot be unified; the table must support contrast rows without pretending equivalence.

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).
  • senseFamilyreferenced 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 CLRow 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)

FPF LabelRow ScopeRow CL(min)OWL 2Kind-CALRationaleCounter‑examples
is‑a (Tech) / type hierarchy (Plain)Type‑structureCL = 3rdfs:subClassOfU.SubtypeRelationBoth are partial‑order class subsumption used for inheritance.FCA concept order is not a class subsumption; keep it out or CL drops.

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

FPF LabelRow ScopeRow CL(min)SOSA/SSNISO 80000‑1ITIL 4RationaleCounter‑examples
result‑value / measured valueKD‑metricCL = 2sosa:Result (literal)QuantityValue (unit‑bearing)metric value (service KPI)Values can be read as numbers tied to a Characteristic; ITIL metric uses same notion when unitised.ITIL “metric” may be composite indices (loss of unit fidelity).

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

FPF LabelRow ScopeRow CL(min)BPMN 2.0PROV‑OThermodynamicsRationaleCounter‑examples
process (contrast)graph of flow nodestime‑bounded activitystate‑space trajectorySame surface, different senses; no licensed sameness.Any attempt to equate design‑graph with run‑occurrence fails stance compatibility.

Anti‑patterns & remedies

#Anti‑patternSymptom in a rowWhy it breaks thinkingRemedy (conceptual move)
AP‑1Bridge‑free samenessCells listed as “same” because their labels look alike; no cited Bridges.Violates locality; imports meaning across Contexts by name.A row exists only if backed by F.9 Bridges. Otherwise produce a contrast row.
AP-2Scope creepRow labelled “Type-structure” but used to justify assignment/enactment-eligibility or KD metrics.Scope licences are not transferable; inference leaks.Keep a small controlled set of Row Scopes. If use widens, mint a new row or re-bridge with higher CL.
AP‑3senseFamily mixingOne row mixes Role, Status, Measurement, and Type‑structure cells.Conflates senseFamily (F.0.1); readers cannot tell “what kind of sameness”.Type each row. If two senseFamilys are needed, split into two rows.
AP‑4Temporal blurCells with incompatible DesignRunTag declared “same”.Design artefacts ≠ run occurrences; claims invert.Either harmonise stance (choose only compatible cells) or publish a contrast row.
AP‑5Loss denialBridges carry loss notes, but the row omits counter‑examples.Readers over‑trust; misuse outside safe scope.Add a one‑line counter‑example that illustrates the loss.
AP‑6CL averagingRow CL(min) computed as an average of heterogeneous Bridges.The weakest link governs; averages overstate safety.Row CL(min) is the bottleneck (minimum along connecting paths).
AP‑7Overwide rows6–8 Contexts in one row; hard to read; subtle mismatches hide.Violates didactic primacy; invites hidden losses.Parsimony: 2–4 Contexts per row unless each extra cell has a distinct necessity you can state in one line.
AP‑8Minted paraphrasesCells reword a Context’s label instead of citing the SenseCell.Hides locality; future drift becomes invisible.Cells are Context‑loyal. Use the Context’s own SenseCell label.
AP‑9Duplicate rows by styleTwo rows with the same cell set but different FPF labels.Name inflation; readers assume two distinct concepts.Keep one row per Concept‑Set per scope. Alternative labels appear as aliases in F.5, not new rows.
AP‑10Implied transitivityA↔B and B↔C Bridges exist; row silently assumes A↔C at the same CL.Paths can reduce CL; semantics might not compose.Compute CL for A↔C via bottleneck; if too low, either reduce Row Scope or omit the cell.

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)

FPF Label (Tech / Plain)Row ScopeRow CL(min)BPMN 2.0PROV‑ORationaleCounter‑examples
actor / party that participatesNaming‑onlyCL = 2ParticipantAgentBoth denote a bearer that can be named as the party to which activities are attributed.PROV Agent includes software agents; BPMN Participant is typically an organisation lane/pool.

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)

FPF LabelRow ScopeRow CL(min)PROV‑OIEC 61131‑3RationaleCounter‑examples
execution-occurrence / a run that happensassignment/enactment-eligibilityCL = 2Activity (time-bounded occurrence using/generating entities)Task execution (cyclic/event-driven program run)Both are run-time occurrences that can be referenced by U.RoleEnactment to ground Work performed under an assignment.BPMN Process is a design graph; not an occurrence—exclude.

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)

FPF LabelRow ScopeRow CL(min)SOSA/SSNISO 80000‑1ITIL 4RationaleCounter‑examples
result‑value / measured valueKD‑metricCL = 2Result (literal)QuantityValue (unit‑bearing)metric valueA number representing a Characteristic at observation time; can be unitised and compared to targets.ITIL “metric” may be a composite index; units may be implicit.

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

Subtype relation (type‑structure)

FPF LabelRow ScopeRow CL(min)OWL 2Kind-CALRationaleCounter‑examples
is‑a / type hierarchyType‑structureCL = 3rdfs:subClassOfU.SubtypeRelationBoth are partial orders used for inheritance.FCA concept order is not a class subsumption—exclude or publish another row.

Contrast: “role” (access vs behaviour)

FPF LabelRow ScopeRow CL(min)NIST RBACBPMN 2.0RationaleCounter‑examples
role (contrast)Role (permission set)Participant/Actor (behavioural mask)Same surface; different senseFamilys (Status vs Role/behaviour).Any attempt to unify collapses deontics into behaviour; stance and effects differ.

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