F.17 - Make a Settled Naming Decision Recoverable for Reuse (Unified Term Sheet)

Type: Lexical row pattern (F) Status: Stable

Use this when. Use F.17 only when one already-governed value already has a selected durable naming settlement and public, Core-facing, durable, or cross-local reuse now needs one reader-facing term row.

First useful move. Point to the exact governed value, its kind, the pattern that defines or constrains it, one proposed row use, and the selected Tech and Plain designations. Then apply F.14 at the row gate. If no durable row is needed, reuse the designation, alias, local expression, or name already supplied for that value and stop.

Primary working object. One C.2.1 UnifiedTermRow episteme whose exact EntityOfConcern is the independently governed value. Its claim graph cites the separate F.18 naming-settlement episteme and selected designation expressions. The value, its kind, the pattern that defines or constrains it, the designations, effective U.ReferenceScheme, SchemeSenseCell, NameCard, basis relation, F.9 Bridge, row episteme, edition relation, publication occurrence, publication form, and carrier remain different objects.

What goes wrong if missed. A table entry becomes an ontology claim; a stable identifier looks like identity evidence; one source title or file stands in for a local sense; a NameCard automatically creates a cell and row; or a row is mistaken for the publication occurrence that makes it available.

What this buys. A compact, durable navigation row through which readers can recover the naming decision and the rules that define or constrain the governed value without letting the row create, merge, prove, or publish that value.

Not this pattern when. Keep private wording, local synonyms or aliases, and names already supplied where the value is defined or constrained in their local use. Use F.14 before every naming object, F.8 for one unresolved mint-or-reuse choice, F.18 for the durable naming settlement, F.9 only for an actual relation between exact cells, and E.24.PUB only when a selected row edition must be made available. For any stronger ontology, obtaining, equivalence, authority, system-role-kind, assignment, relation-position, status, evidence, Work, or subject-use claim, use the pattern that defines or constrains it.

F.17:1 - Intent and applicability

UnifiedTermSheet is a reader-facing collection of independently identified term-row epistemes for one useful naming thread. Each row makes one selected naming decision easy to find: it names the governed value, its kind, where that value is defined or constrained, selected designations, exact local senses, any actual Bridge needed by the declared use, admitted and blocked citation uses, and reopen condition.

Use it especially for:

• public system-role-kind and status names whose underlying values are already governed;
• durable relation, slot, interface, signature, or FPF kind names;
• Core-facing names used by examples, training material, project standards, dashboards, checks, tool interfaces, Part G search packs, architecture, transformation, or evaluation work;
• one exact naming use between independently recovered local senses;
• row identifiers that must remain usable across row-episteme editions.

F.17 introduces no system-role kind, assignment, relation position, status, evidence, method, Work, relation occurrence, slot kind, local concept, NameCard, Bridge, publication occurrence, form, or carrier. It constitutes the row episteme only. Its visible table form can be useful, but table position, filled cells, suffix, source prestige, or row count has no ontological force.

F.17:2 - Problem frame

Naming work often succeeds locally and then fails in reuse. A term looks stable, but the receiving reader cannot recover which value was named, which pattern defines or constrains it, which naming decision selected the expressions, which effective scheme and local-sense claim are current, or whether a cited Bridge actually obtains.

Five shortcuts follow:

• shared spelling is treated as shared value;
• a row combines unlike system-role-kind, assignment, status, relation, Work, evidence, or publication concerns;
• a card, cell, row, id, and publication are minted as one automatic chain;
• a source title, document, or table layout substitutes for the exact sense and basis relation;
• the row itself is said to make the term public, current, authoritative, or obtaining.

F.17 repairs those shortcuts by making every row a separately identified claim-bearing episteme whose references lead back to the exact naming settlement and governed value.

F.17:2.1 - Problem

The practical problem is to make one durable naming decision recoverable without turning its row, representation, or availability into the named object. One row therefore carries one decision or splits; any stronger claim leaves the row and uses its own defining or constraining rule.

F.17:3 - Forces

F.17:4 - Solution

Constitute a row through the smallest path that reaches the named reuse:

1. Recover the value. Identify one exact already-governed value or relation, its kind, the pattern that defines or constrains it, its identity or obtaining semantics, and one proposed use. Split a mixed candidate before naming.
2. Run the anti-explosion gate. Apply F.14 before minting a card, cell, row, or family. Try no durable name, an existing designation, an alias, a local expression, a name already used for the value, and an admitted existing-row name. Stop at the first sufficient disposition.
3. Settle only the durable name that is needed. If one expression remains unresolved, use F.8. If a durable naming settlement is justified, F.18 constitutes one C.2.1 NameCard and selects Tech and Plain designations. The card creates neither the value nor its kind and does not require a cell or row.
4. Address a local sense only when useful. Create one SchemeSenseCell only when the exact local expression and sense claim need a stable address under an effective by-value U.ReferenceScheme. Cite a selected bounded-model-use Structure only when its organization changes this exact naming use. The cell does not require a NameCard or row.
5. Open the public-row gate independently. Apply F.14 again when public, Core-facing, durable, or cross-local reuse needs a row. The current F.18 public-row interface supplies the exact NameCard, selected designations, governed value and kind, the locator for its defining or constraining pattern, effective scheme, and exact cell. None of those inputs alone requires the row.
6. Add a Bridge only for an actual cross-local relation. Compare the exact <ReferenceScheme, LocalSenseClaim> projections. When the proposed row use relates different projections, cite an obtaining F.9 Bridge between the exact cells and separately cite the affirmative C.2.1 use claim plus its current A.10 or B.3 reliance. Same spelling, scheme difference, or cell presence proves no Bridge.
7. Constitute one row episteme. Its C.2.1 EntityOfConcern is the exact independently governed value; its claim graph cites the separate naming-settlement episteme, selected designations, admitted and blocked citation uses, rationale, and reopen condition. Split unlike governed values or independently different uses into separate rows.
8. Keep succession and availability downstream. Use EpistemeEditionRelation only when a later row episteme historically continues an earlier one under C.2.1. When availability is current, use the exact E.24.PUB expression, bearing, and publication relations. A row, row id, form, carrier, upload, or rendering establishes neither succession nor publication by itself.

Apply the static and regression checks to the affected row, then stop. The result grants no ontology, obtaining, equivalence, authority, system-role classification or assignment, relation position, status, evidence, Work, publication truth, or receiving action.

F.17:5 - Minimal vocabulary

F.17:5.1 - Scheme-based local-sense coordinate, basis relation, and row episteme

A selected expression, an exact local sense, the episteme supporting that sense, the naming decision, and the reader-facing row answer different questions. Keep them independently recoverable.

SchemeSenseCell:
  ValueKind: F.17-local composite coordinate; not a root U-kind
  ReferenceScheme: effective U.ReferenceScheme carried by value
  LocalSenseId: address designator only
  LocalExpression: selected expression in this local use
  LocalSenseClaim: exact local meaning under the scheme
  Identity: <ReferenceScheme by value, LocalExpression, LocalSenseClaim>

LocalSenseBasisRelation <: U.Relation
SlotSpecs:
  LocalSenseCellSlot:
    ValueKind: F.17 SchemeSenseCell coordinate
    RefKind: SenseCellAddressRef resolving the exact scheme, expression, and sense claim
    Field: localSenseCellRef
  BasisEpistemeSlot:
    ValueKind: U.Episteme
    RefKind: U.EpistemeRef resolving one exact basis-episteme edition
    Field: basisEpistemeRef
Direction: basisEpistemeRef -> localSenseCellRef
Obtaining: the exact basis episteme supports the cell's exact LocalSenseClaim under its by-value ReferenceScheme for the stated admitted use
NonObtaining: shared spelling, accepted name, card, source title, file, carrier, publication availability, or completed fields
Identity: <localSenseCellRef, basisEpistemeRef>
OccurrenceIdentity: participant-determined; another exact cell or basis-episteme edition identifies another occurrence

LocalSenseBasisRelationDescription <: U.Episteme:
  entityOfConcernRef: U.EntityRef resolving one exact LocalSenseBasisRelation occurrence
  entityOfConcernKindRef: U.KindRef resolving LocalSenseBasisRelation
  viewpointRef?: U.ViewpointRef
  subjectRef?: U.SubjectRef, only when independently governed
  basisPublicationUnitRef?: U.EntityRef resolving one exact source unit as description/provenance content, never as relation participant or identity discriminator
  claimGraph: U.ClaimGraph carrying supported-sense, admitted-use, blocked-use, and any exact source-unit qualifier claims
  referenceScheme: U.ReferenceScheme by value; exactly the scheme in localSenseCellRef
  editionId: designator only

UnifiedTermRow <: U.Episteme:
  UTSRowId: stable designator only
  UnificationThreadId: sheet-local navigation designator
  Block?: optional didactic navigation label
  GovernedValueRef: U.EntityRef; the same exact referent fills the C.2.1 EntityOfConcern position
  ClaimContent: complete U.ClaimGraph constituted by the identity-bearing row claims designated below
  ReferenceScheme: effective U.ReferenceScheme carried by value
  GovernedValueKindRef: U.KindRef
  SubjectPatternLocator: U.EntityRef resolving the pattern that defines or constrains the governed value
  UnifiedTechName: selected Tech designation expression
  UnifiedPlainName: selected Plain designation expression
  NameCardRef: U.EpistemeRef resolving the separate exact F.18 naming-settlement episteme
  SenseCellRefs[]: exact SenseCellAddressRefs
  BridgeRefs[]?: actual F.9 Bridge occurrences only
  RowRationale
  AdmissibleUse
  BlockedUse
  RowEditionId: designator only
  EpistemeEditionRelationRef?: exact C.2.1 occurrence only when historical continuation obtains
  CurrentnessCondition
  Notes?

SenseCellAddressRef designates one SchemeSenseCell; it does not create that cell or a universal context object. A legacy address is usable only through an explicit lossless adapter to the exact effective scheme, expression, and local-sense claim. Otherwise stop the row.

The basis relation has exactly two participants. basisEpistemeRef resolves the exact current basis-episteme edition; its exact kind is derived from that referent and is not copied as another participant. A relation reference resolves the exact LocalSenseBasisRelation occurrence rather than its description or designator. basisPublicationUnitRef, when present, is a provenance qualifier that narrows the supporting episteme; it neither participates in nor identifies the relation. A source publication occurrence, its form, and its carrier remain separate E.24.PUB objects.

The relation says only that this basis episteme supports this cell’s exact sense claim for the admitted use. Its description states the supported and blocked uses and any exact source-unit qualifier. A changed NameCard reopens the selected expression. A changed scheme, expression, sense claim, or basis-episteme edition identifies another cell or basis-relation participant pair. A changed source-unit or supported-use claim creates another relation-description episteme without silently changing the basis relation.

Any description of a SchemeSenseCell is a separate C.2.1 episteme whose EntityOfConcern is that exact cell. The cell’s identifier, description, source publication, NameCard, and basis relation neither replace nor identify the cell.

UnifiedTermRow is another C.2.1 episteme, not a root U-kind, value container, or publication occurrence. Its EntityOfConcern is the exact governed value. Its displayed identity-bearing row claims jointly constitute the complete ClaimContent; a scalar graph-ref line need not be repeated in the readable fixture when that graph is recoverable from them. The claim graph cites the separate NameCard and the governed value’s kind, locates the rules that define or constrain that value, and projects the selected designation expressions. The row, card, designations, governed value, external row reference, and UTSRowId designator remain distinct; UnificationThreadId, Block, and RowEditionId are navigation or edition designators rather than additional identity discriminators.

If a later row episteme revises, refines, or supersedes an earlier one, an independently obtaining C.2.1 EpistemeEditionRelation(earlierRowEpisteme, laterRowEpisteme) carries historical continuation. Stable row spelling, id, table position, shared carrier, or later publication establishes no such relation. A CurrentnessCondition is row claim content; it is not the edition relation and does not make itself true.

When a selected row edition must be made available, E.24.PUB supplies three separate relations: PublicationFormExpressionRelation(selectedRowEdition, publicationForm, boundedUseDeclaration), PublicationFormBearingRelation(carrier, publicationForm), and EpistemePublicationRelation(selectedRowEdition, audience, boundedUse, publicationForm, carrier). The row does not publish itself; the form is not the row; the carrier bears the form rather than the episteme; rendering or uploading is dated Work when current and is not the publication occurrence.

GovernedValueRef and GovernedValueKindRef are separate. A kind token has kind U.Kind. An exact local system-role kind, obtaining system-role-assignment or other relation occurrence, status value, slot kind, representation position, or local concept retains its own kind; the row points to the pattern that defines or constrains that value. A row or card cannot admit a U-kind or make a direct relation obtain.

NameCardRef resolves the F.18 C.2.1 naming-decision episteme consumed by the current public-row gate. UnifiedTechName and UnifiedPlainName are designation expressions selected by that decision, not values or references. Aliases and rejected candidates stay in the NameCard or local lexicon rather than becoming rival selected names in the row.

BridgeRefs cites only actual F.9 occurrences between exact cells. Direction, use-specific rule, loss tolerance, polarity, evidence, reliance, permission, and receiving action remain in their own claims and relations. Local senses do not globalize; same spelling or a different scheme provides neither governed-value identity nor Bridge obtaining.

A.22.CGUS:4.4 permits a separately constituted demonstrative-slice episteme after CGUS qualification. The token DemonstrativeUnfoldingSlice@Context is neither a U.Kind nor an exact slice by itself. F.17 records a row only after one exact C.2.1 slice episteme and its current F.18 naming settlement are recoverable; a local phrase or seminar expression alone creates neither.

UnifiedTermSheet is the reader-facing collection or layout through which rows are found. A selected table layout, optional block plan, or carrier is not the row episteme and does not prove that every needed decision is present.

F.17:6 - When to create or update a UTS row

Create or revise one row only when all entry objects are exact and at least one receiving need is current:

• public or Core-facing citation of the selected naming decision;
• durable reuse outside the immediate local repair;
• cross-local reuse whose exact cells, any actual Bridge, separate use claim, and reliance are recoverable;
• stable citation from examples, checks, dashboards, training material, a project standard, or a tool interface;
• a change to the rules that define or constrain this value, or an F.18 change, that alters this exact row’s value, name, sense, admitted use, or blocked use.

Before the row, apply F.14 again. A noticed word, accepted designation, stable local sense, NameCard, Bridge description, source publication, or desire for a tidy table does not by itself meet the gate. A durable local NameCard can remain local; a cell can remain a cell; an existing row can be reused only within its admitted use.

F.17:7 - Row schema

Use these positions when they are current. Presence means that the exact referenced object or claim is independently recoverable; it is not a form-completion target.

For SenseCellRefs, recover the exact by-value scheme, expression, and local-sense claim. Cite LocalSenseBasisRelation only when an actual basis relation obtains. A NameCard selects designations; it does not fill the cell or basis positions. A source title, file, carrier, locality label, selected structure, row id, or description substitutes for none of them.

Publication availability is not a row column. When current, maintain the exact E.24.PUB relation occurrences, form, carrier, audience, and bounded use beside the selected row edition. Publication change does not silently change the row episteme or its C.2.1 edition relation.

F.17:8 - Optional block plan

A block plan is an optional navigation aid for a sheet with enough rows that grouping helps a reader. Use few memorable blocks and omit the plan when direct row search is clearer. Neither a declared plan, the number of blocks, nor filled row count proves coverage, completeness, usefulness, or semantic adequacy.

Example navigation plan for a system-role, Method, Work, and status thread:

• governed values and naming decisions;
• system-role kinds and their descriptions;
• system-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 list defines no ontology. A sheet may use another small navigation plan for architecture, transformation flows, evaluation characteristics, Part G search packs, or another receiving use.

F.17:9 - Layouts

F.17 admits two common layouts.

Layout A, scheme-first: keep the left rail fixed and add one exact reference-scheme column per selected interpretation basis. Use this when the reader’s comparison concerns local senses under named schemes.

UTSRowId | Unification thread | Block | Governed value | Governed value kind | Defining or constraining pattern
Unified Tech name | Unified Plain name | NameCardRef
Reference scheme A | Reference scheme B | Reference scheme C
BridgeRefs | Row rationale | Admissible use | Not this use
Row edition | Currentness condition | Notes

Layout B, comparison-column: keep the scheme, local expression, and sense claim inside SenseCellRefs and use a smaller set of presentation columns such as tradition, discipline, language, publication family, or project family. These columns are teaching aids; they have interpretation authority only when each cell still resolves to its exact by-value scheme and local-sense claim.

Never mix a scheme column and a discipline or project-family column as if they had the same kind. A U.ReferenceScheme is an interpretation basis carried by value; a comparison column is a didactic view.

F.17:10 - Static conformance rules for a UTS

Use these checks before citing a row outside its immediate sheet.

Passing the schema is not the value criterion. A row succeeds only when intended readers can recover the correct naming decision, governed value, and applicable defining or constraining rule for the declared use while avoiding the blocked use. Row count, filled-cell count, label uniformity, block neatness, and stable identifiers are maintenance aids only.

F.17:11 - Regression and stability rules

Recheck only the rows affected by the changed object, name, scheme, sense, Bridge, basis, or source.

F.17:12 - Archetypal Grounding - worked cases

F.17:12.1 - System-role-kind name becomes public across two project contexts

One project has an exact local DesignReviewerSystemRole kind and another has an independently governed ExternalAuditReviewerSystemRole kind. Both local expressions say reviewer, but one classifies an admitted System that may perform design-review Work and the other classifies an admitted assurance System that may produce an audit report. Any actual assignment and Work are separately identified.

The UTS row does not declare one universal reviewer kind. It creates two rows. Only when a named use really needs correspondence between their two exact sense cells may it cite an obtaining F.9 Bridge plus an affirmative C.2.1 claim that names direction, label rule, and tolerated loss. Each row cites the pattern that defines or constrains its local system-role kind, its SystemRoleKindDescription when current, and the F.18 NameCardRef. Use A.10 or B.3 to state reliance on the use claim; no row or card creates an assignment or review Work.

F.17:12.2 - Status label looks like a system-role-kind name

A team proposes BlockedReviewer as a public label. F.17 does not accept it as a row until the two governed values are separated. ReviewerSystemRole is a local system-role kind; blocked is a status-family or status-window value. The sheet may record one system-role-kind row and one status row, with a note that a local UI may render their labels together. The table creates neither a BlockedReviewerSystemRole kind nor an assignment. If either exact row edition must later be made available, use a separate E.24.PUB publication package.

F.17:12.2a - Learning is an anti-row and split prompt

A DPF or dashboard proposes one public Learning row, perhaps with LearningProgress as its value. Apply E.10.LRN first. Teaching or practice Work, a holder’s capability, a fitted model edition, an inference result, acquired information, a representation relation, cultural change, and a course or other product are independently governed values and claims. Performance, capability evidence, information gain, model fit, prediction error, compression, and representation change are likewise different progress coordinates; shared spelling does not make them one governed value, one SchemeSenseCell, or an F.9 Bridge.

F.17 therefore creates no umbrella Learning or LearningProgress row. If one recovered value later needs a durable public designation, apply F.14 and F.18 to that exact value and create at most one row for its admitted use; another recovered value receives another row only under its own gate. When the direct claim is already readable or durable reuse is absent, stop with no UTS row.

F.17:12.3 - 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, system-role kind, assignment, or capability. If a project context uses port differently, keep the two local senses explicit. Cite an F.9 Bridge only when its direct predicate between the exact F.17 cells obtains; keep the proposed naming use and any reliance separate.

F.17:12.4 - Misleading evidence-role row

A sheet has a row labelled Evidence role. Recover the governed object before choosing a name. For an episteme’s evidence use, establish the direct relation under A.2.4 or its other subject rule; A.10 describes the evidence-provenance path and classifies the bounded reliance, and B.3 enters only for an actual named assurance claim. For dated evidence-producing Work, recover each precise performer’s A.13 core, including the same obtaining assignment, and independently admit the Work under A.15.1. Add F.6 only when the row or receiving use needs precise assignment-bound attribution. A separately needed local-kind claim uses A.2 with C.3. The UTS may expose selected names for these distinct values; it does not admit a generic evidence-role row that fuses them.

F.17:12.4a - Manufacturing batch across material and planning contexts

A furnace team uses batch for one physically handled set of shafts that shares a heat-treatment run and traceability basis. A planning dashboard uses batch for a grouping of intended PlanItems. Spelling does not make these one governed value. Recover the physical batch under the material or production DPF pattern that supplies its identity and part-whole rules when the proposed comparison relies on either; recover the planning grouping and its relation to intended PlanItems under A.15.2. When the row gate is met, record separate rows for the distinct governed values. A needed semantic comparison may cite an obtaining F.9 Bridge and a separate affirmative C.2.1 claim stating direction, correspondence rule and tolerated loss with current reliance; those facts do not combine the values into one row. If either selected row edition must be made available, apply E.24.PUB separately. A batch row cannot turn a PlanItem grouping into a physical holon or make the physical batch a WorkPlan.

F.17:12.4b - Clinical discharge wording

A clinical publication proposes one row for discharge and discharge-ready. First separate the governed values. A patient-state classification uses A.19.SPR plus the clinical DPF pattern for its bearer, state frame, evidence, qualification window, and use. An accountable discharge decision remains a decision relation under the pattern that defines or tests that decision. A completed discharge is dated Work under A.15.1. Record distinct rows and connect them only through relations that actually obtain in the clinical use. A later publication operation uses E.24.PUB for each row edition that must be made available. One familiar label does not make state, decision, and Work interchangeable.

F.17:12.4c - Demonstrative walkthrough and bounded mantra

A.22.CGUS:4.4 permits a separate C.2.1 episteme that shows one traversal through an already qualified CGUS for a declared teaching or comparison use. It does not define a demonstrative-slice U.Kind, and the token DemonstrativeUnfoldingSlice@Context does not identify one exact slice. The current sources also do not constitute FPFSeminarTeachingReferenceScheme-2026-07-11 as a second by-value reference scheme. F.17 therefore records no demonstrative-slice row, seminar SenseCell, Bridge, bounded-use claim, or current public-row result from those tokens.

Use demonstrative walkthrough as ordinary readable wording for a shown traversal when the sentence makes the exact slice clear. Keep mantra as bounded seminar or pattern-local recall wording when repetition and attention are the point. Neither expression creates a kind, episteme, scheme, cell, Bridge, row, or publication occurrence. mantra move remains E.10.MOVE Plain wording for an E.11.PUA practice-continuation description when such a description is actually shown; ordinary long and local mantras receive no F.17 row.

If a later use needs a durable public name, first recover one exact slice episteme under C.2.1 from its claim content, the qualified CGUS it concerns, and its effective scheme. F.18 may then record one naming settlement and F.17 may record one row after the ordinary gate. A second cell and F.9 Bridge are justified only when another exact scheme-and-sense projection and a named current correspondence use both exist. Availability of any selected row edition still requires a separate exact E.24.PUB publication package.

F.17:12.4d - Bounded model-use structure public row

This row records and exposes the already selected A.1.1/F.18 naming decision for the dependent U.Structure specialization. It does not make A.1.1 Stable, create a structure individual, make any relation obtain, or make the row edition available.

UTSRowId: UTS.BoundedModelUseStructure.FPFCore.2026-07-25
ReferenceScheme: FPFCoreReferenceScheme
UnificationThreadId: R1.2-BoundedModelUse-Naming
Block: Architecture and model use
GovernedValueRef: BoundedModelUseStructure
GovernedValueKindRef: U.Kind
SubjectPatternLocator: A.1.1
UnifiedTechName: BoundedModelUseStructure
UnifiedPlainName: bounded context
NameCardRef: NC-BOUNDED-MODEL-USE-STRUCTURE
SenseCellRefs: SenseCell.BoundedModelUseStructure.FPFCore.2026-07-25
BridgeRefs: none; this row makes no semantic-correspondence or substitution claim
RowRationale: the governed value is the A.1.1 kind token; its admitted members are exactly the U.Structure individuals that satisfy the A.1.1/A.22 membership condition, and the selected names designate that organization of one model edition's governed applicability, actual use, and fixed-content expression coherence over exact admitted model-use holons, exact applied constraint claims, and the named frame; a claim scope or membership outcome is not an applied constraint by itself
AdmissibleUse: Core-facing designation of the A.1.1 dependent structure specialization and retrieval of the DDD plain term
BlockedUse: no generic context holon, no identity for a subsystem, team, claim scope, model episteme, description, or view, no relation occurrence, and no positive crossing-structure membership
RowEditionId: 2026-07-25
CurrentnessCondition: reopen when the A.1.1/A.22 membership or continuity rule, one of the three direct relation kinds, FPFCoreReferenceScheme, the NameCard, an exact applied constraint proposition or its use in selection, or the named bounded-model-use frame changes

SenseCell.BoundedModelUseStructure.FPFCore.2026-07-25:
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseId: BoundedModelUseStructure-core
  LocalExpression: BoundedModelUseStructure
  LocalSenseClaim: the dependent U.Structure specialization selected over one exact model episteme, exact admitted model-use holons, obtaining applicability, actual-use, and fixed-content expression-coherence relations, exact applied constraint claims used by the selection judgment, and the named bounded-model-use frame; a claim scope participates only in its applicability relation unless a distinct constraint proposition refers to that scope or its membership predicate, and crossings belong only to a distinct A.22 structure over already identified bounded model-use structures
  senseFamily: BoundedModelUse
  NameCardRef: NC-BOUNDED-MODEL-USE-STRUCTURE
  LocalSenseBasisRelationRefs: LocalSenseBasisRelation.BoundedModelUseStructure.FPFCore.2026-07-25

LocalSenseBasisRelation.BoundedModelUseStructure.FPFCore.2026-07-25:
  localSenseCellRef: SenseCell(FPFCoreReferenceScheme, BoundedModelUseStructure-core)
  basisEpistemeRef: A.1.1

LocalSenseBasisRelationDescription.BoundedModelUseStructure.FPFCore.2026-07-25:
  entityOfConcernRef: LocalSenseBasisRelation.BoundedModelUseStructure.FPFCore.2026-07-25
  entityOfConcernKindRef: LocalSenseBasisRelation
  viewpointRef: FPFCoreReaderViewpoint
  claimGraph:
    supportedSenseClaim: BoundedModelUseStructure names the exact A.1.1/A.22 dependent structure specialization, with bounded context retained only as its Plain retrieval name
    admittedUseClaim: Core-facing designation and citation of that governed specialization
    nonAdmittedUseClaim: the name or row creates no structure, holon, context bearer, direct relation occurrence, crossing occurrence, view, representation, or publication event
  referenceScheme: FPFCoreReferenceScheme
  editionId: 2026-07-25

This row makes only BoundedModelUseStructure current for public reuse; that currentness does not make its row edition available without an exact E.24.PUB publication package. A.22’s separate cross-structure NameCard remains local and pending: without an independently governed obtaining crossing and an exact positive membership basis, no public row is admitted or current for that label.

F.17:12.4e - Three bounded-model-use direct relation-kind rows

These rows record the three already governed A.1.1 relation-kind names used by E.24.UK. Each row makes one naming decision recoverable; it does not make that row edition available. A.1.1 defines the obtaining and reidentification tests for each such relation occurrence. The naming objects and the separately governed local-sense basis occurrences make none of the three A.1.1 relations obtain, and they create no assertion, temporal extent, Work, or structure.

UTSRowId: UTS.ModelApplicabilityRelation.FPFCore.2026-07-25
ReferenceScheme: FPFCoreReferenceScheme
UnificationThreadId: R1.2-BoundedModelUse-Naming
Block: Architecture and model use
GovernedValueRef: ModelApplicabilityRelation
GovernedValueKindRef: U.Kind
SubjectPatternLocator: A.1.1
UnifiedTechName: ModelApplicabilityRelation
UnifiedPlainName: this model applies to this holon within this claim scope
NameCardRef: NC-MODEL-APPLICABILITY-RELATION
SenseCellRefs: SenseCell.ModelApplicabilityRelation.FPFCore.2026-07-25
BridgeRefs: none; this row makes no semantic-correspondence or substitution claim
RowRationale: the governed value is the A.1.1 relation-kind token; its admitted instances are exactly the obtaining U.Relation occurrences that satisfy the A.1.1 applicability predicate and identity rule, and the selected names expose that relation while keeping A.2.6 scope membership, the derived interval, assertions, and the selected structure separate
AdmissibleUse: Core-facing designation of the A.1.1 relation kind, including A.2.6 claim-scope coordination and the E.24.UK bounded-model-use membership test
BlockedUse: no applicability occurrence from a name, model mention, shared label, scope row, assertion, interval, publication, or structure membership
RowEditionId: 2026-07-25
CurrentnessCondition: reopen when A.1.1 changes the participant kinds, predicate, scope alignment, model-scheme interpretation, temporal identity, NameCard, or named Core use

SenseCell.ModelApplicabilityRelation.FPFCore.2026-07-25:
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseId: ModelApplicabilityRelation-core
  LocalExpression: ModelApplicabilityRelation
  LocalSenseClaim: the direct relation kind over one model episteme, one exact holon, and one participating claim scope; one exact relation occurrence obtains only when the A.1.1 applicability predicate is true and all other governing conditions hold
  senseFamily: ModelApplicability
  NameCardRef: NC-MODEL-APPLICABILITY-RELATION
  LocalSenseBasisRelationRefs: LocalSenseBasisRelation.ModelApplicabilityRelation.FPFCore.2026-07-25

LocalSenseBasisRelation.ModelApplicabilityRelation.FPFCore.2026-07-25:
  localSenseCellRef: SenseCell(FPFCoreReferenceScheme, ModelApplicabilityRelation-core)
  basisEpistemeRef: A.1.1

LocalSenseBasisRelationDescription.ModelApplicabilityRelation.FPFCore.2026-07-25:
  entityOfConcernRef: LocalSenseBasisRelation.ModelApplicabilityRelation.FPFCore.2026-07-25
  entityOfConcernKindRef: LocalSenseBasisRelation
  basisPublicationUnitRef: A.1.1:4.2 ModelApplicabilityRelation
  viewpointRef: FPFCoreReaderViewpoint
  claimGraph:
    supportedSenseClaim: ModelApplicabilityRelation names the exact A.1.1 relation kind rather than a scope-membership predicate, claim, record, or interval
    admittedUseClaim: Core-facing designation and citation of that governed relation kind
    nonAdmittedUseClaim: the name or row makes no applicability occurrence obtain and grants no selected-structure membership
  referenceScheme: FPFCoreReferenceScheme
  editionId: 2026-07-25

UTSRowId: UTS.ModelUseRelation.FPFCore.2026-07-25
ReferenceScheme: FPFCoreReferenceScheme
UnificationThreadId: R1.2-BoundedModelUse-Naming
Block: Architecture and model use
GovernedValueRef: ModelUseRelation
GovernedValueKindRef: U.Kind
SubjectPatternLocator: A.1.1
UnifiedTechName: ModelUseRelation
UnifiedPlainName: this assignment's holder uses this model during this work concerning this holon
NameCardRef: NC-MODEL-USE-RELATION
SenseCellRefs: SenseCell.ModelUseRelation.FPFCore.2026-07-25
BridgeRefs: none; this row makes no semantic-correspondence or substitution claim
RowRationale: the governed value is the A.1.1 relation-kind token; its admitted instances are exactly the obtaining U.Relation occurrences that satisfy the A.1.1 actual-use predicate and identity rule, and the selected names expose that relation while keeping applicability, system-role assignment, performed Work, Method application, claims, and records separate
AdmissibleUse: Core-facing designation of the A.1.1 relation kind and its use in the E.24.UK bounded-model-use membership test
BlockedUse: no use occurrence from availability, access, mention, assignment alone, Work alone, method application, assertion, publication, or structure membership
RowEditionId: 2026-07-25
CurrentnessCondition: reopen when A.1.1 changes the participant kinds, the F.6 attribution condition for a row that expressly consumes it, actual-use predicate, actor derivation, maximal-continuous-use identity, NameCard, or named Core use

SenseCell.ModelUseRelation.FPFCore.2026-07-25:
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseId: ModelUseRelation-core
  LocalExpression: ModelUseRelation
  LocalSenseClaim: the direct relation kind over one exact system-role-assignment occurrence, model episteme, performed Work occurrence, and use-locus holon; one exact relation occurrence obtains only when the A.1.1 actual-use predicate is true and all other governing conditions hold
  senseFamily: ModelUse
  NameCardRef: NC-MODEL-USE-RELATION
  LocalSenseBasisRelationRefs: LocalSenseBasisRelation.ModelUseRelation.FPFCore.2026-07-25

LocalSenseBasisRelation.ModelUseRelation.FPFCore.2026-07-25:
  localSenseCellRef: SenseCell(FPFCoreReferenceScheme, ModelUseRelation-core)
  basisEpistemeRef: A.1.1

LocalSenseBasisRelationDescription.ModelUseRelation.FPFCore.2026-07-25:
  entityOfConcernRef: LocalSenseBasisRelation.ModelUseRelation.FPFCore.2026-07-25
  entityOfConcernKindRef: LocalSenseBasisRelation
  basisPublicationUnitRef: A.1.1:4.2 ModelUseRelation
  viewpointRef: FPFCoreReaderViewpoint
  claimGraph:
    supportedSenseClaim: ModelUseRelation names the exact A.1.1 actual-use relation kind rather than applicability, availability, Work, assignment, method application, claim, or record
    admittedUseClaim: Core-facing designation and citation of that governed relation kind
    nonAdmittedUseClaim: the name or row makes no model-use occurrence obtain and grants no selected-structure membership
  referenceScheme: FPFCoreReferenceScheme
  editionId: 2026-07-25

UTSRowId: UTS.ModelExpressionCoherenceRelation.FPFCore.2026-07-25
ReferenceScheme: FPFCoreReferenceScheme
UnificationThreadId: R1.2-BoundedModelUse-Naming
Block: Architecture and model use
GovernedValueRef: ModelExpressionCoherenceRelation
GovernedValueKindRef: U.Kind
SubjectPatternLocator: A.1.1
UnifiedTechName: ModelExpressionCoherenceRelation
UnifiedPlainName: this model content and this expression content satisfy this declared coherence criterion under this comparison scheme
NameCardRef: NC-MODEL-EXPRESSION-COHERENCE-RELATION
SenseCellRefs: SenseCell.ModelExpressionCoherenceRelation.FPFCore.2026-07-25
BridgeRefs: none; this designation makes no semantic-correspondence claim, and any Bridge needed for a particular coherence occurrence is a separately obtaining prerequisite named by that occurrence's predicate declaration
RowRationale: the governed value is the A.1.1 relation-kind token; its admitted instances are exactly the obtaining U.Relation occurrences that satisfy the A.1.1 coherence predicate and participant-determined identity rule, and the selected names expose fixed-content semantic coherence while keeping the local predicate value, maintenance, transformation, evaluation, result, evidence, and assertion separate
AdmissibleUse: Core-facing designation of the A.1.1 relation kind and its use in the E.24.UK bounded-model-use membership test
BlockedUse: no coherence occurrence from a label, predicate label, equal spelling, maintenance or evaluation Work, changed carrier, result episteme, evidence, assertion, publication, or structure membership
RowEditionId: 2026-07-25
CurrentnessCondition: reopen when A.1.1 changes the participant kinds, five-part predicate-value rule, interpretation branch, permitted loss, participant-determined identity, NameCard, or named Core use

SenseCell.ModelExpressionCoherenceRelation.FPFCore.2026-07-25:
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseId: ModelExpressionCoherenceRelation-core
  LocalExpression: ModelExpressionCoherenceRelation
  LocalSenseClaim: the participant-determined direct relation kind over one model episteme, expression episteme, admitted five-part predicate value, and comparison scheme when an admissible interpretation branch exists and that predicate is true
  senseFamily: ModelExpressionCoherence
  NameCardRef: NC-MODEL-EXPRESSION-COHERENCE-RELATION
  LocalSenseBasisRelationRefs: LocalSenseBasisRelation.ModelExpressionCoherenceRelation.FPFCore.2026-07-25

LocalSenseBasisRelation.ModelExpressionCoherenceRelation.FPFCore.2026-07-25:
  localSenseCellRef: SenseCell(FPFCoreReferenceScheme, ModelExpressionCoherenceRelation-core)
  basisEpistemeRef: A.1.1

LocalSenseBasisRelationDescription.ModelExpressionCoherenceRelation.FPFCore.2026-07-25:
  entityOfConcernRef: LocalSenseBasisRelation.ModelExpressionCoherenceRelation.FPFCore.2026-07-25
  entityOfConcernKindRef: LocalSenseBasisRelation
  basisPublicationUnitRef: A.1.1:4.2 ModelExpressionCoherenceRelation
  viewpointRef: FPFCoreReaderViewpoint
  claimGraph:
    supportedSenseClaim: ModelExpressionCoherenceRelation names the exact A.1.1 relation kind rather than its predicate value, maintenance, transformation, evaluation, result, evidence, or assertion
    admittedUseClaim: Core-facing designation and citation of that governed relation kind
    nonAdmittedUseClaim: the name or row makes no coherence occurrence obtain, makes no predicate-value name available, and grants no selected-structure membership
  referenceScheme: FPFCoreReferenceScheme
  editionId: 2026-07-25

Do not create a public F.17 row for ModelExpressionCoherencePredicate: that label remains local to A.1.1 and names the five-part criterion ValueKind rather than any of the three relation kinds.

F.17:12.4f - Viewpoint, view, and conformance-relation public rows

These three rows satisfy different receiver needs and therefore cannot be merged. E.24.UK has already admitted U.Viewpoint and U.View as same-individual dependent kinds under U.Episteme; E.17.0 defines both positive membership predicates and the direct EpistemeViewpointConformanceRelation. F.14 has been applied again: the existing Tech designations are retained, no synonym family is opened, and the public rows are justified by stable Core citation and exact typed-reference use. The rows admit no kind, make no relation obtain, and assert no E.24.PUB publication occurrence, form, carrier, or authority.

The two existing dependent-kind designations use these progressive-minimum F.18 naming-settlement epistemes. They remain distinct from the E.24.UK admission results, the governed kinds, their members, every reference or designator, and the F.17 rows that cite them.

NameCard:
  NameCardId: NameCard.U.Viewpoint.FPFPublic.2026-08-02
  GovernedValueRef: U.Viewpoint
  GovernedValueKindRef: U.Kind
  SubjectPatternLocator: E.17.0
  ReferenceScheme: FPFCoreReferenceScheme
  ClaimContent: NameCard.U.Viewpoint.FPFPublic.2026-08-02.ClaimGraph — complete naming-settlement graph constituted by the claims designated below
  LocalSenseCellRef: SenseCell.U.Viewpoint.FPFCore.2026-08-02
  LocalSenseBasisRelationRef: LocalSenseBasisRelation.U.Viewpoint.FPFCore.2026-08-02
  TechLabel: U.Viewpoint
  PlainLabel: viewpoint
  CandidateSet: U.Viewpoint; ViewpointEpisteme; ViewpointConvention; ViewpointRecord; ViewpointStructure
  CandidateCoverage: dependent-kind, episteme, convention, record, and structure readings tested
  RejectedCandidates: ViewpointEpisteme hides the stable public kind name; ViewpointConvention can denote fixed claim content rather than P; ViewpointRecord adds a wrapper; ViewpointStructure names S rather than P; none is an alias
  SelectionRationale: retain the admitted Core Tech name and ordinary Plain retrieval word while the exact local-sense claim keeps P, S, references, and designators distinct
  DeclaredUse: Core-facing designation of the E.17.0 same-individual dependent kind and typed reference resolution to exact P
  NonAdmissibleUse: no P, S, kind membership, selection, Work, conformance, view membership, or publication follows from the card or labels
  BridgeRefs: none; this settlement makes no cross-local correspondence claim
  PublicRowStatus: current
  UnifiedTermRowRef: UTS.U.Viewpoint.FPFCore.2026-08-02
  LineageEntries: ViewpointId remains only a designator of exact P; viewpointRef remains U.ViewpointRef and resolution grants no membership
  RefreshCondition: reopen when E.17.0 changes P's same-individual membership predicate, E.24.UK admission, exact reference typing, FPFCoreReferenceScheme, reader meaning, or public use

NameCard:
  NameCardId: NameCard.U.View.FPFPublic.2026-08-02
  GovernedValueRef: U.View
  GovernedValueKindRef: U.Kind
  SubjectPatternLocator: E.17.0
  ReferenceScheme: FPFCoreReferenceScheme
  ClaimContent: NameCard.U.View.FPFPublic.2026-08-02.ClaimGraph — complete naming-settlement graph constituted by the claims designated below
  LocalSenseCellRef: SenseCell.U.View.FPFCore.2026-08-02
  LocalSenseBasisRelationRef: LocalSenseBasisRelation.U.View.FPFCore.2026-08-02
  TechLabel: U.View
  PlainLabel: episteme conforming to an exact viewpoint
  CandidateSet: U.View; ViewEpisteme; ConformingEpisteme; ViewArtifact; PublishedView
  CandidateCoverage: dependent-kind, episteme, conformance, artifact, and publication readings tested
  RejectedCandidates: ViewEpisteme can look like a second individual; ConformingEpisteme drops the exact viewpoint relation; ViewArtifact collapses episteme with form or carrier; PublishedView makes availability look constitutive; none is an alias
  SelectionRationale: retain the admitted Core Tech name while the Plain label exposes that the same E gains membership only through exact E/P conformance
  DeclaredUse: Core-facing designation of the E.17.0 same-individual dependent kind and typed reference to an already conforming episteme
  NonAdmissibleUse: no membership from direct authoring, construction, query execution, transformation, selection, rendering, bundle, form, carrier, or publication
  BridgeRefs: none; this settlement makes no cross-local correspondence claim
  PublicRowStatus: current
  UnifiedTermRowRef: UTS.U.View.FPFCore.2026-08-02
  LineageEntries: viewRef resolves exact E only after membership is independently current; view, diagram, face, form, and carrier readings remain separated
  RefreshCondition: reopen when E.17.0 changes E/P conformance, same-individual membership, E.24.UK admission, FPFCoreReferenceScheme, reader meaning, or public use

F.17:12.4f.1 - U.Viewpoint

UTSRowId: UTS.U.Viewpoint.FPFCore.2026-08-02
ReferenceScheme: FPFCoreReferenceScheme
UnificationThreadId: R1.2-MultiView-Naming
Block: Multi-view describing
GovernedValueRef: U.Viewpoint
GovernedValueKindRef: U.Kind
SubjectPatternLocator: E.17.0
UnifiedTechName: U.Viewpoint
UnifiedPlainName: viewpoint
NameCardRef: NameCard.U.Viewpoint.FPFPublic.2026-08-02
SenseCellRefs: SenseCell.U.Viewpoint.FPFCore.2026-08-02
BridgeRefs: none; this row makes no semantic-correspondence or substitution claim
RowRationale: the governed value is the E.17.0/E.24.UK same-individual dependent-kind token, not P, S, a reference, or a designator; an admitted member is the same exact C.2.1 episteme P whose EntityOfConcern is independently selected viewpoint-convention Structure S_viewpoint and whose fixed ClaimGraph under its effective ReferenceScheme satisfies E.17.0's complete positive membership predicate; admission result E24UK-AR-UVIEWPOINT-RG-01 remains a separate decision projection
AdmissibleUse: Core-facing designation of the dependent kind and exact typing of a reference whose resolution yields an already admitted viewpoint episteme P
BlockedUse: no viewpoint membership, episteme identity, Structure selection, method, Work, conformance, View membership, authority, or publication from the row, name, ViewpointId, viewpointRef, NameCard, bundle position, selected S, form, or carrier
RowEditionId: 2026-08-02
CurrentnessCondition: reopen when E.17.0 changes P's C.2.1 discriminators, exact S EntityOfConcern, fixed target/concern/admitted-kind/conformance claims, effective ReferenceScheme, same-individual predicate, E.24.UK admission, NameCard, or typed-reference use
Notes: retain the exact field viewpointRef : U.ViewpointRef; under the effective scheme its resolution yields P, while ViewpointId only designates P and neither operation grants membership

SenseCell.U.Viewpoint.FPFCore.2026-08-02:
  ReferenceScheme: FPFCoreReferenceScheme
  LocalSenseId: U.Viewpoint-core
  LocalExpression: U.Viewpoint
  LocalSenseClaim: the same-individual dependent kind of exact C.2.1 epistemes P whose exact EntityOfConcern is independently selected viewpoint-convention Structure S_viewpoint and whose fixed claims identify S, state the exact target-kind criterion, stakeholder or audience referents when current, concerns, admitted episteme kinds, coverage, semantic-form, completeness, consistency, omission and conformance rules without circular View premises, and the describing-use frame and fixed applicability qualifiers
  senseFamily: MultiViewRecognition
  NameCardRef: NameCard.U.Viewpoint.FPFPublic.2026-08-02
  LocalSenseBasisRelationRefs: LocalSenseBasisRelation.U.Viewpoint.FPFCore.2026-08-02

LocalSenseBasisRelation.U.Viewpoint.FPFCore.2026-08-02:
  localSenseCellRef: SenseCell(FPFCoreReferenceScheme, U.Viewpoint-core)
  basisEpistemeRef: E.17.0

LocalSenseBasisRelationDescription.U.Viewpoint.FPFCore.2026-08-02:
  entityOfConcernRef: LocalSenseBasisRelation.U.Viewpoint.FPFCore.2026-08-02
  entityOfConcernKindRef: LocalSenseBasisRelation
  basisPublicationUnitRef: E.17.0:4.2,4.6.1-4.6.4
  viewpointRef: FPFCoreReaderViewpoint
  claimGraph:
    supportedSenseClaim: U.Viewpoint names the same P identified under C.2.1 only when P's exact S EntityOfConcern and fixed convention claims satisfy E.17.0
    admittedUseClaim: Core-facing designation, exact U.ViewpointRef typing, and retrieval of the direct membership rule
    nonAdmittedUseClaim: the basis relation, cell, NameCard, row, identifier, reference, Structure, bundle, or publication grants no membership
  referenceScheme: FPFCoreReferenceScheme
  editionId: 2026-08-02

F.17:12.4f.2 - U.View