#Unified Term Sheet (UTS)

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

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Status: Stable

Status: stable pattern.

Use this when a term decision must become reader-facing, durable, public, Core-facing, or cross-context. Use it when a role name, status name, relation name, slot name, FPF kind name, local concept name, or bridgeable term set has outgrown one local repair and must be shown as one reviewed term row.

First useful move: identify the governed term decision, not the wording alone. Name the bounded context, the governed FPF kind or governed object kind, the local senses, the bridge claim if cross-context use is present, and the current direct pattern that owns the underlying object. Then publish only the term-row facts that are already governed there.

Do not use this pattern for one sentence repair, one private glossary note, one local synonym choice, or one attempt to make an object real by putting it into a table. Use E.10, A.6.P, C.2.P, F.18, or the direct domain pattern first when the kind, relation, slot position, admissible use, or name-card decision is still unsettled.

UnifiedTermSheet is a reader-facing term publication for one bounded unification thread. It gives a careful reader one compact table of reviewed term rows: the chosen Tech and Plain names, the specified governed kind or governed value, the local senses, the bridge relation when cross-context use is claimed, and the small rationale that makes the naming decision reviewable.

#Keywords

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

#Relations

#Content

#Intent and applicability

UnifiedTermSheet is a reader-facing term publication for one bounded unification thread. It gives a careful reader one compact table of reviewed term rows: the chosen Tech and Plain names, the specified governed kind or governed value, the local senses, the bridge relation when cross-context use is claimed, and the small rationale that makes the naming decision reviewable.

The pattern is useful when a team has already done enough local sense work that a name can be reused without redoing the whole unification argument each time. It is especially useful for:

• public or cross-context role names;
• status-family names and status-window labels;
• durable relation, slot, interface, or signature names;
• FPF kind names and local concept names that appear in more than one bounded context;
• term rows cited by examples, training material, project standards, or tool interfaces;
• Part G, architecture, transformation, and evaluation vocabulary where row ids must stay stable across editions.

F.17 does not create U.Role, U.Status, U.Evidence, U.Method, U.Work, U.Episteme, U.Relation, U.SlotKind, or any other underlying object. It publishes a term row for an already governed object, relation, slot, or local concept. The direct pattern remains responsible for the object and its admissible use.

#Problem frame

Unification work often succeeds locally and then fails in reuse. A term looks stable in one section, but another reader cannot see which bounded context, local sense, bridge, name-card decision, or direct governing pattern was used. Teams then invent new labels, import a local tradition as if it were universal, or treat a teaching block as if it were an ontology.

The damage is practical:

• local meanings become global slogans;
• one row silently mixes a role, a role description, a status value, a capability claim, and a work assignment;
• public names drift because no row id, edition, or name-card reference stays stable;
• cross-context sameness is asserted by spelling rather than by an F.9 bridge;
• examples in other patterns cite a term but not the term decision that makes the example portable.

F.17 fixes this by making the term row itself reviewable. Each row says what kind of thing is being named, where the local senses came from, what bridge is claimed, which name was selected, and which direct pattern owns the underlying object.

#Forces

#Core idea

A Unified Term Sheet is a table of term rows for one bounded unification thread.

Each row has one primary term decision:

UnifiedTermRow:
  UTSRowId
  ThreadContextRef
  GovernedObjectKindOrValueRef
  DirectGoverningPatternRef
  UnifiedTechName
  UnifiedPlainName
  NameCardRef?
  SenseCells[]
  BridgeRefs[]
  RowRationale
  RowEdition
  CurrentnessCondition
  Notes?

The row may cite several local senses and several bridges, but it does not fuse their underlying objects. If a source phrase points toward multiple typed FPF values, split the row or cite the direct pattern that keeps the values distinct.

#Minimal vocabulary

UnifiedTermSheet is the whole reader-facing term table for one bounded unification thread.

UnifiedTermRow is one row in that sheet. It publishes one reviewed term decision.

ThreadContextRef names the bounded context and edition in which the sheet is current.

GovernedObjectKindOrValueRef names the specified kind, local concept, relation, slot kind, status family, role, or other governed value being named. Use U.Type only when the row really names a U-kind. Do not force local concepts, slot kinds, relation kinds, status values, or role assignments into U.Type.

DirectGoverningPatternRef names the pattern that owns the underlying object or claim. F.17 owns the term-row publication, not the object.

SenseCell is a bounded-context local sense reference. It names the context, edition, local expression, local sense, and source reference when source use is current.

BridgeRef cites an F.9 bridge when one row uses senses from more than one bounded context or when sameness, near-identity, retargeting, or loss matters.

UnifiedTechName and UnifiedPlainName are the selected names governed by F.5 and F.18. Extra aliases belong in the name-card or local lexicon material, not as rival unified names in the row.

BlockPlan is the didactic grouping of rows. A block is a memory and teaching device, not an ontological parent.

#When to create or update a UTS row

Create or update a UTS row when at least one condition is present:

• the name will be public, Core-facing, or reused across bounded contexts;
• a row id is needed for later examples, checks, dashboards, training material, or tool interface labels;
• a role name, status-family name, slot name, relation name, or local concept name is being reused outside the immediate local repair;
• a bridge claim is being used for cross-context term reuse;
• a name-card decision from F.18 needs a compact reader-facing term row;
• a direct pattern changes the governed object in a way that changes the name, local sense, bridge, or admissible use.

Do not create a row only because a word was noticed. First recover the kind, relation, slot position, and admissible use under the direct governing pattern.

#Row schema

Use these columns unless the sheet has a justified specialization.

For SenseCells, cite the bounded context and edition. If the source is a publication or source text, cite the source through the source-governing pattern; do not let the source title substitute for the local sense.

#Block plan

A UTS must declare its block plan. Blocks should be few enough for a careful reader to remember and specific enough to make row search easy.

Example block plan for a role, method, work, and status thread:

• Context and governed values.
• Roles and role descriptions.
• Role assignments and performed work.
• Methods, method descriptions, and work plans.
• Status families and status windows.
• Relation, slot, interface, and bridge terms.
• Evidence, assurance, source, and publication terms when those are the governed values.

This example is not a required ontology. It is a didactic grouping. The sheet may use different blocks when the unification thread is about architecture, transformation flows, evaluation characteristics, Part G search packs, or another area.

#Layouts

F.17 admits two common layouts.

Layout A, context-first: keep the left rail fixed and add one bounded-context column per selected context. Use this when the reader must compare local senses across named contexts.

UTSRowId | Block | Governed kind or value | Direct pattern
Unified Tech name | Unified Plain name | NameCardRef
Context A, edition | Context B, edition | Context C, edition
BridgeRefs | Row rationale | Admissible use | Not this use
Row edition | Currentness condition | Notes

Layout B, comparison-column: keep context and edition inside SenseCells and use a smaller set of comparison columns such as tradition, discipline, language, or project family. Use this for teaching when the direct bounded-context cells would be too wide. The comparison columns are presentation aids; they have context authority only when each cell still cites the bounded context and edition.

Never mix a context column and a discipline column as if they had the same kind. A bounded context is a meaning scope; a discipline column is a didactic comparison view.

#Static conformance rules for a UTS

Use these checks before citing a UTS row outside its local sheet.

#Regression and stability rules

Recheck only the rows affected by the changed object, name, bridge, or source.

#Worked cases

#Role name becomes public across two project contexts

A project has ReviewerRole@DesignReview and ReviewerRole@ExternalAudit. The local expressions both say "reviewer", but one concerns a system-in-role performing design review work and the other concerns an assurance actor producing an audit report.

The UTS row does not declare one universal reviewer. It either creates two rows or one row with an explicit F.9 bridge and loss note. Each row cites the direct role pattern, the RoleDescription when current, and the F.18 NameCardRef. If evidence or assurance is current, A.10 or B.3 governs that separate row or note.

#Status label looks like a role name

A team proposes BlockedReviewer as a public label. F.17 does not accept it as a row until the direct patterns are separated. Reviewer is a role value; blocked is a status-family value or status-window value. The sheet may publish Reviewer as a role row and Blocked as a status row, with a note that a local UI may render them together. The table does not create a role called "blocked reviewer".

#Relation and slot names become reusable

An architecture pattern needs public names for interfaceSlot, providedPort, and requiredPort. The UTS row cites A.6.5 for slot discipline, A.6.RSIR when the relation-signature-interface boundary is current, and F.18 for durable names. The row does not treat a slot name as a component, role, or capability. If a project context uses port differently, the UTS row keeps the local sense and bridge explicit.

#Misleading evidence-role row

A sheet has a row labelled Evidence role. F.17 repairs the row by recovering the governed object instead of treating that label as a U-kind. If the claim is that an episteme is being used as evidence for another claim, A.10, B.3, or A.2.4 governs the evidence relation. If the claim is that a system performs evidence-producing work, A.2.1, F.6, and A.15.1 govern role assignment and performed work. The UTS may publish names for these values, but it must not keep a generic evidence-role row that fuses them.

#Anti-patterns and repairs

#Closure conditions

A UTS row is ready for ordinary reuse only when:

• the governed kind or value is explicit;
• the direct pattern is named;
• Tech and Plain names are selected under F.5 and F.18;
• local senses are bounded-context and edition scoped;
• cross-context claims cite F.9;
• the row names admissible use and blocked use;
• currentness conditions are stated;
• any role, status, evidence, source, publication, description, method, work, relation, slot, interface, or characteristic claim remains under its direct pattern.

#Relations

Builds on: F.1, F.2, F.3, F.5, F.7, F.8, F.9, F.15, and F.18.

Coordinates with: A.2, A.2.1, A.2.7, A.6.5, A.6.P, A.10, A.15.1, A.19.SPR, B.3, C.2.P, E.10, E.10.D2, E.17, F.4, F.6, F.10, and F.14.

Constrains: any public, Core-facing, durable, or cross-context term sheet row that cites FPF vocabulary, local concepts, relation names, slot names, role names, status names, or bridgeable sense clusters.

#SoTA-Echoing

Currentness rule: when F.5, F.8, F.9, F.10, F.15, F.18, A.2, A.2.1, A.2.7, A.6.5, A.10, B.3, E.17, or E.10.D2 changes the governed value, admissible use, bridge, source-use boundary, status-family boundary, role boundary, or naming decision, recheck only the affected UTS rows and examples.

#Didactic distillation

A Unified Term Sheet is not the ontology and not the object. It is the table that lets people reuse the naming decision without guessing. Each row says: what kind of thing is named, which direct pattern governs it, which local senses were used, which bridge is claimed, which Tech and Plain names were selected, and what use the row permits.

#F.17:End

Last Updated: 2026-06-17 — this section last modified in upstream FPF commit 205de763 (github.com/ailev/FPF)