#Unified Term Sheet (UTS)

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

“One table that a careful mind can hold.” Status. Architectural pattern. Builds on: F.1–F.3 (Contexts → seeds → local senses), F.4 (Role Characterisation), F.5 (Naming), F.7 (Concept‑Set table), F.8 (Mint/Reuse decision), F.9 (Bridges), F.10–F.12 (Status & method/service bindings), F.15 (SCR/RSCR). Coordinates with: A.1.1 U.BoundedContext, A.7 Strict Distinction, A.8 Heterogeneity, A.11 Ontological Parsimony, A.15 Role–Method–Work Alignment. Non‑goals. No registries, workflows, editors, or storage formats. No by‑name Cross‑context equivalence. No “data pipeline.” This pattern prescribes what a UTS is and how to judge it, not how to generate files.

Intent. Provide a single, normative table—the Unified Term Sheet (UTS)—that distils the output of F.1–F.12 into human‑readable rows. Each row expresses one Concept‑Set unified into one FPF U.Type with its Tech/Plain names and cross‑context senses. The UTS is the front‑door view that authors, engineers, and managers use; it replaces scattered notes and eliminates guesswork.

#Keywords

• Unified Term Sheet
• UTS
• summary table
• glossary
• publication
• human-readable output.

#Relations

#Content

#Intent & Applicability

Intent. Provide a single, normative table—the Unified Term Sheet (UTS)—that distils the output of F.1–F.12 into human‑readable rows. Each row expresses one Concept‑Set unified into one FPF U.Type with its Tech/Plain names and cross‑context senses. The UTS is the front‑door view that authors, engineers, and managers use; it replaces scattered notes and eliminates guesswork.

Applicability. Produce a UTS per FPF pattern thread (e.g., Role Assignment & Enactment, Method quartet, Trust & Evidence). Use it:

• to name U.Types and their Tech/Plain labels (F.5),
• to teach the mapping from familiar canons to unified concepts,
• to audit coverage and heterogeneity (A.8), and
• to feed examples in Parts A/C without re‑explaining terminology.

Why now. Earlier F‑patterns define how to think. F.17 defines what you publish so others can think with you.

#Problem Frame

Without a single sheet:

1. Locality is lost. Mappings hide in prose; readers re‑globalise words.
2. Naming drifts. Teams adopt ad‑hoc labels that collide later.
3. Coverage is opaque. No quick check that coverage spans ≥ 3 domain families across the sheet (A.8).
4. Didactic load spikes. Each section re‑teaches the same terms.

UTS fixes this by putting the unification decision and the cross‑context evidence on one line per concept.

#Forces

#Core Idea

A UTS is a Concept‑Set table with names. Each row = one Concept‑Set unified into one FPF U.Type (the “what we mean”). Each column family shows how this concept appears in the chosen contexts of meaning (F.1).

Two canonical layouts are allowed (pick one or publish both):

• Layout A — Kernel‑first: rows keyed by FPF U.Type; Bounded‑Context Columns (BCC).
• Layout B — Base‑concept: rows keyed by Base concept (EN/RU) of a discipline, then unified to U.Type; Discipline Columns (DC).

Both layouts are normative; choose based on audience. In Layout A, comparability is by BCC (Bounded‑Context Column); in Layout B, comparability is by DC (Discipline Column); never conflate the two.

#Minimal Vocabulary (for this pattern)

• UTS (Unified Term Sheet). The published, human‑readable table per thread.
• Context. Alias in Tech register for U.BoundedContext (E.10.D1). Normative unit of meaning; every SenseCell is scoped to a Context (name + edition).
• Bounded‑Context Column (BCC). A didactic column used only in Layout A; one column per Context (U.BoundedContext) from the F.1 cut; not a model element; the header includes the Context name + edition.
• Discipline Column (DC). A discipline vantage used only in Layout B (e.g., Operational Management, IT/Software, Physics). A DC is not a Bounded‑Context Column and does not carry editions.
• Concept‑Set (CSR). One unified concept with pointers to its SenseCells.
• SenseCell. (Context × Local‑Sense) address—how a Context “says that thing”.
• Bridge / CL. Explicit cross‑context mapping (F.9) with Congruence Level and Loss note.
• Plain Twin (LEX). The LEX record pairing the Unified Tech name with its Unified Plain name for a U.Type; governed by PTG and referenced by Twin‑Map Id (LEX) (E.10 LEX‑BUNDLE).
• Block Plan. Didactic grouping of rows to keep the sheet memorizable.
• Unified Tech name / Unified Plain name. Dual‑register names chosen per F.5; the Tech name is the neutral, unified term for the U.Type, not a borrowed Context name.

Discipline. “Context” always means U.BoundedContext (E.10.D1). No global words.

#Row Schema (normative)

Every UTS row MUST carry the following fields (verbatim headings recommended):

Constraint. “SenseCells (by Context)” MUST cite at least three distinct Contexts overall across the sheet for the thread (A.8). A single row may show fewer if the concept truly appears in fewer contexts; coverage is a property of the whole UTS.

Discipline: Every SenseCell must cite the Context name + edition (e.g., “BPMN 2.0 (2011): Activity instance”).

#NQD Fields (normative; when applicable)

If a UTS row describes a Generator/Selector/Portfolio (design‑time or run‑time artefact), it MUST add the following fields. These are publication fields, not tooling‑specific formats.

Note. These fields extend the Row Schema; they do not change SenseCells/Bridges/Names. Rows that are purely definitional (no generator/selector/portfolio semantics) do not carry §6.1.

#Autonomy fields (when applicable)

Add the following columns (nullable; required when autonomy is claimed by the row’s subject):

• AutonomyBudgetDeclRef (id, version)
• Aut-Guard policy-id (PolicyIdRef)
• OverrideProtocolRef
• Scope (G) (autonomy scope)
• Γ_time (admission window selector)
• (optional) ScaleLensPolicyRef
• (optional) ScaleLensOptIn ∈ {OptedIn, Neutral, OptedOut} Note. These fields are required for UTS rows that describe a Role, Method, Service, or Selector with autonomy claims; optional fields make Bitter‑Lesson/Scale‑Lens an explicit opt‑in with published criteria.

#Block Plan (didactic grouping)

A UTS MUST declare a Block Plan—the sequence of blocks that group rows. Blocks are thread‑specific. Example Block Plan for Role Assignment & Enactment (matches your earlier tables):

• Block A - Context & Roles — U.BoundedContext, U.Role, U.RoleAssignment, U.Capability.
• Block B - Method & Description — U.Method, U.MethodDescription, Access/Acceptance descriptions (fields of U.PromiseContent).
• Block C - Execution & Schedule — U.Work, U.WorkDescription, U.Observation.
• Block D - Service & Deontics — U.PromiseContent, U.SpeechAct, U.Commitment, U.PromiseContent, U.PromiseFulfillmentEvaluation.
• Block E - Carriers & Bridges — U.Carrier, Alignment (Bridge entry).
• Block R - Knowledge Units & Statuses — U.Episteme, U.EvidenceRole, U.StandardStatus, U.RequirementStatus, U.DefinitionRole, U.AxiomaticCoreRole.

Rule. Block names are didactic, not ontological. Do not infer mereology or subtyping from blocks.

#Column Families (two canonical layouts)

#Layout A — Kernel‑first (U.Type as rows)

Columns:

• FPF U.Type - Unified Tech name - Unified Plain name - Plain‑Twin Governance (PTG) - Twin‑Map Id (LEX) - FPF Description (left rail; PTG/LEX are optional)
• Bounded‑Context Columns (BCC) — one column per Context (U.BoundedContext) from the F.1 cut; each header shows name + edition: e.g., OMG BPMN 2.0, W3C PROV‑O, ITIL 4, NIST RBAC, W3C SOSA/SSN, OMG Essence (Language), DEMO/DEMO‑EO, PMBOK 7, CM/BPM (CMMN/BPMN), IEC 61131‑3, ODRL 2.2, ISO 80000‑1 / Metrology … (your chosen 12 Contexts)
• Bridges (CL/Loss)
• Unification Rationale
• Notes

Do not mix Discipline Columns (DC) in Layout A. Columns here are only Bounded‑Context Columns (BCC).

#Layout B — Base‑concept pivot (discipline columns)

Columns: Base concept - Scale‑map - Unified Tech name - Unified Plain name - Plain‑Twin Governance (PTG) - Twin‑Map Id (LEX) - Formal U.Type - Discipline Columns (DC) (e.g., Operational Management / IT/Software / Physics / …) - Rationale - Notes.

• Base concept (EN / RU)

• Scale‑map (Σ / Π / μ) (optional; see §9.4)

• Unified Tech name

• Unified Plain name

• Plain‑Twin Governance (PTG) (optional)

• Twin‑Map Id (LEX) (optional)

• Formal U.Type

• Discipline Columns (DC) (choose 3–5): e.g., Operational Management, IT/Software, Physics, Science/Theory, Math/Proof, Literature, Religion (or other discipline columns suited to the thread)

• Unification Rationale

• Notes

Guidance. Publish Layout A for kernel users and spec authors; publish Layout B for cross‑disciplinary onboarding and teaching. Clarification — Plain vs Base concept. In Layout B the Base concept (EN/RU) is a discipline vantage aid and does not substitute for the single Unified Plain name in the left rail. Do not mint alternative unified‑plain synonyms inside DC cells; flag homonym risks with ⚡ in Notes.

#Invariants (normative constraints)

1. Locality. Every SenseCell is Context‑scoped (E.10.D1). No global synonyms.
2. Bridges only via F.9. Cross‑context equivalence appears only as an explicit Bridge with CL. Any row citing > 1 Context must state at least one Bridge.
3. Heterogeneity. Across the UTS, coverage must involve ≥ 3 domain families (F.1 Step 2; A.8).
4. Scale‑map tags (optional but disciplined). If used in Layout B:
   • Σ (Summative): concept’s quantitative properties aggregate across a population of executions/holders.
   • Π (Conjunctive/Compositional): concept composes by required conjunction (all‑of), not by averaging.
   • μ (Micro/Atomic): concept is inherently micro‑level (per single execution/holder). (Tags aid teaching; they do not change semantics.)
5. Strict Distinction. Use U.Method vs U.MethodDescription, U.Work vs U.WorkDescription, U.Role vs U.RoleCharacterisation correctly; do not collapse intensional objects with their descriptions.
6. Dual register. Every row has Tech and Plain labels per F.5.
7. One‑breath rationale. The Unification Rationale is a single sentence explaining the conceptual sameness despite local wording.
8. Unified naming neutrality. The Unified Tech name is the neutral FPF choice per F.5; it is not lifted wholesale from any single Context unless the Concept‑Set justification (F.7) shows identity.
9. Column discipline. Layout A uses Bounded‑Context Columns (BCC) only; Layout B uses Discipline Columns (DC) only. Mixing is non‑conformant.
10. Plain‑twin discipline. The single Unified Plain name lives in the left rail; BCC/DC cells carry senses only. Any additional Plain aliases are managed in LEX (tv:*) and never minted per column.

#How to Compile (conceptual moves, not a workflow)

M1 - Fix contexts (F.1). Declare the 12 (±) contexts for this thread. M2 - Harvest & cluster (F.2–F.3). Identify candidate senses per Context; cluster within Contexts; mint SenseCells. M3 - Form Concept‑Sets (F.7). For each “the‑same‑thing” across Contexts, create one CSR; attach SenseCells. M4 - Name (F.5). Choose Tech/Plain labels; assert the FPF U.Type (or propose a new one via F.8). M5 - Bridge (F.9). Where Cross‑context relations are not exact, assert Bridges with CL and a short Loss note. M6 - Place rows into blocks (§7). Keep the sheet memorisable. M7 - Write one‑line FPF Description and the Rationale. M8 - Run acceptance harness (F.15). Apply the UTS checks in §11.

Note. These are thought moves. No tooling is implied or required.

#Acceptance Harness (SCR/RSCR) for a UTS

#Static Conformance Rules (SCR‑UTS)

• SCR‑UTS‑01 (Row completeness). Each row contains: U.Type, Tech, Plain, FPF Description, SenseCells (≥ 1), Rationale.
• SCR‑UTS‑02 (Dual register). Each row has both Tech and Plain labels; Tech is used in spec prose, Plain in didactics.
• SCR‑UTS‑03 (Locality discipline). Every SenseCell is cited with its Context name & edition.
• SCR‑UTS‑04 (Heterogeneity). Across the sheet, the set of referenced Context spans ≥ 3 domain families.
• SCR‑UTS‑05 (Bridge honesty). All cross‑context sameness claims are expressed via an F.9 Bridge with a CL score; if identity, mark CL=3 and note “identity/no loss” rather than omitting the bridge.
• SCR‑UTS‑06 (One‑breath rationale). The rationale is ≤ 35 words and states the conceptual invariant that unifies the row.
• SCR‑UTS‑07 (Block parsimony). Block Plan uses ≤ 7 blocks; each block’s rows can be recited from memory by a careful reader.
• SCR‑UTS‑08 (Strict Distinction). No row description conflates Method↔MethodDescription, Work↔WorkDescription, Role↔RoleCharacterisation.
• SCR‑UTS‑09 (Unified naming). Each row’s Unified Tech name complies with F.5 rules (dual register, minimal generality, morphology); it is not a mere alias of one Context unless justified by an F.9 Bridge with CL=3.
• SCR‑UTS‑10 (Column discipline). Layout A: all non‑left‑rail columns are Contexts with editions. Layout B: all non‑left‑rail columns are discipline columns. No cross‑use.
• SCR‑UTS‑11 (Plain‑twin hygiene). The Unified Plain name appears once in the left rail (tv:primary). Neither BCC (Layout A) nor DC (Layout B) cells may introduce alternative unified Plain synonyms; use the ⚡ marker in Notes to flag homonym risk where needed.

#Regression Rules (RSCR‑UTS)

• RSCR‑UTS‑A (Edition churn). When a Context’s edition changes, old SenseCells remain addressable; new cells are added; no silent rewrites.
• RSCR‑UTS‑B (Name stability). Tech labels change only with a documented F.5 decision; Plain labels may evolve didactically if the Tech name stays.
• RSCR‑UTS‑C (Coverage drift). Adding/removing rows must not reduce family heterogeneity below §9.3.
• RSCR‑UTS‑D (Loss drift). If new evidence changes a Bridge’s CL/Loss, the row updates both the CL and the 2–6 word loss note.
• RSCR‑UTS‑E (Plain discipline). No per‑column Plain text appears in BCC/DC columns; any additional Plain aliases are tracked in Annex with tv: entries and counted against the alias budget (F.13).

#Canonical Heading Templates (fill with your Contexts/Discipline columns)

Layout A — Kernel‑first