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.
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.
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.1UnifiedTermRow 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.
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.
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.
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.
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.
Constitute a row through the smallest path that reaches the named reuse:
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.
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.
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.
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.
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.
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.
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.
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.
#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.RelationSlotSpecs: 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: basisEpistemeRefDirection: basisEpistemeRef -> localSenseCellRefObtaining: the exact basis episteme supports the cell's exact LocalSenseClaim under its by-value ReferenceScheme for the stated admitted useNonObtaining: shared spelling, accepted name, card, source title, file, carrier, publication availability, or completed fieldsIdentity: <localSenseCellRef, basisEpistemeRef>OccurrenceIdentity: participant-determined; another exact cell or basis-episteme edition identifies another occurrenceLocalSenseBasisRelationDescription <: 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 onlyUnifiedTermRow <: 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.
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.
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.
Position
Presence condition
Meaning
UTSRowId
yes
Stable row designator; an external row reference must resolve the exact C.2.1 episteme rather than trust this string.
Unification thread
yes
Sheet-local navigation designator with no locality or ontology force.
Separate relation from an exact earlier row episteme to this later one.
Currentness condition
yes
Claim stating what reopens review; not a self-proving currentness relation.
Notes
optional
Short lineage, teaching, homonym, use-claim, or reliance note.
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.
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.
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 patternUnified Tech name | Unified Plain name | NameCardRefReference scheme A | Reference scheme B | Reference scheme CBridgeRefs | Row rationale | Admissible use | Not this useRow 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.
Use these checks before citing a row outside its immediate sheet.
Rule
Check
UTS-SCR-01
The row resolves to one C.2.1 row episteme whose EntityOfConcern is one exact governed value; it points separately to that value's kind, the pattern that defines or constrains it, and the exact F.18 naming-settlement episteme.
UTS-SCR-02
One row carries one naming decision and one governed value/use branch; mixed values or independently different uses are split.
UTS-SCR-03
Every local sense resolves to one exact by-value ReferenceScheme, local expression, and local-sense claim; id, description, source publication, card, or basis relation replaces none of them.
UTS-SCR-04
F.14 was applied before the current card, cell, and row; the light dispositions—no durable name, existing designation, alias, local expression, a name already used for the value, and admitted row reuse—were tested first.
UTS-SCR-05
The Tech and Plain designation expressions agree with the exact current F.18 NameCard without becoming the governed value; aliases and rejected candidates remain separate.
UTS-SCR-06
Any cited LocalSenseBasisRelation has only its exact cell and basis episteme as participants; source-unit and publication facts remain qualifiers or neighboring objects.
UTS-SCR-07
Apply all four Bridge probes: same scheme plus same LocalSenseClaim plus another expression is a designation question and adds no Bridge; for the same scheme plus a different claim, use F.9 and, only for a named row use, the separate use-claim/reliance branch; a different scheme opens only the Bridge question and establishes none; no current correspondence use creates no Bridge or use claim regardless of scheme count.
UTS-SCR-08
Any cited F.9 Bridge has exact endpoint cells and editions, an applicable relation-semantic profile, a true kind-defined predicate, and every required dependency. The separate affirmative C.2.1 use claim states direction, correspondence rule, and loss tolerance, with current A.10 or B.3 reliance. A negative use claim rejects that exact row use; non-passing reliance stops or narrows it; neither negates or reidentifies an otherwise obtaining Bridge.
UTS-SCR-09
A system-role-kind row does not identify SystemRoleKindDescription, SystemRoleAssignment, capability, Method, or Work with the governed kind; a status row does not turn a status family, value, or window into a system-role kind.
UTS-SCR-10
Evidence, assurance, source, publication, description, relation, slot, interface, authority, and equivalence claims use the patterns that define, constrain, or test them rather than becoming row truth.
UTS-SCR-11
Row id, block, table position, source title, file, carrier, suffix, and filled-cell count create neither value identity nor row adequacy.
UTS-SCR-12
The row states the exact scheme, receiving use, and reader breadth actually checked; a narrow row claims neither universal nor corpus-wide reuse.
UTS-SCR-13
C.2.1 row succession and E.24.PUB availability are independently recovered; row, edition relation, publication occurrence, form, carrier, rendering Work, and upload Work stay distinct.
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.9 changes a Bridge endpoint or relation-semantic profile, or C.2.1/A.10/B.3 changes the bounded-use claim or reliance basis
Recheck the changed object only: BridgeRefs for endpoint or profile change; row use, rationale, and notes for changed direction, rule, tolerance, polarity, evidence, reliance, or assurance.
UTS-RSCR-05
Row relocation between blocks
Keep the row id stable and state that relocation between blocks has no ontological force.
UTS-RSCR-06
A system-role, status, evidence, source, publication, or description row is reused under another semantic-context projection or by another reader group
Recheck the pattern that defines or constrains the governed value, the exact sense coordinate, and any required Bridge before reuse.
#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.
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.
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.
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.
A sheet has a row labelled Evidence role. F.17 treats that wording as a trigger and recovers the governed object instead of admitting a U-kind. If an episteme is used as evidence for another claim, use A.10, B.3, or A.2.4 for the evidence relation. If an admitted System performs evidence-producing Work, recover the exact actual performer through A.13 and admit the Work independently through A.15.1. Add a local system-role kind with A.2, an obtaining assignment with A.2.1, and Work attribution with F.6 only when the sheet or receiving use expressly represents those separate claims. The UTS may record selected names for those distinct values; a generic evidence-role row that fuses them is not admitted.
#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. Record separate rows unless an obtaining F.9 Bridge states the exact semantic relation and a separate affirmative C.2.1 claim names the proposed comparison direction, correspondence rule, and tolerated loss with current A.10 or B.3 reliance. 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.
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.
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.
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-25ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: R1.2-BoundedModelUse-NamingBlock: Architecture and model useGovernedValueRef: BoundedModelUseStructureGovernedValueKindRef: U.KindSubjectPatternLocator: A.1.1UnifiedTechName: BoundedModelUseStructureUnifiedPlainName: bounded contextNameCardRef: NC-BOUNDED-MODEL-USE-STRUCTURESenseCellRefs: SenseCell.BoundedModelUseStructure.FPFCore.2026-07-25BridgeRefs: none; this row makes no semantic-correspondence or substitution claimRowRationale: 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 itselfAdmissibleUse: Core-facing designation of the A.1.1 dependent structure specialization and retrieval of the DDD plain termBlockedUse: 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 membershipRowEditionId: 2026-07-25CurrentnessCondition: 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 changesSenseCell.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-25LocalSenseBasisRelation.BoundedModelUseStructure.FPFCore.2026-07-25: localSenseCellRef: SenseCell(FPFCoreReferenceScheme, BoundedModelUseStructure-core) basisEpistemeRef: A.1.1LocalSenseBasisRelationDescription.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.
#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-25ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: R1.2-BoundedModelUse-NamingBlock: Architecture and model useGovernedValueRef: ModelApplicabilityRelationGovernedValueKindRef: U.KindSubjectPatternLocator: A.1.1UnifiedTechName: ModelApplicabilityRelationUnifiedPlainName: this model applies to this holon within this claim scopeNameCardRef: NC-MODEL-APPLICABILITY-RELATIONSenseCellRefs: SenseCell.ModelApplicabilityRelation.FPFCore.2026-07-25BridgeRefs: none; this row makes no semantic-correspondence or substitution claimRowRationale: 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 separateAdmissibleUse: 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 testBlockedUse: no applicability occurrence from a name, model mention, shared label, scope row, assertion, interval, publication, or structure membershipRowEditionId: 2026-07-25CurrentnessCondition: reopen when A.1.1 changes the participant kinds, predicate, scope alignment, model-scheme interpretation, temporal identity, NameCard, or named Core useSenseCell.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-25LocalSenseBasisRelation.ModelApplicabilityRelation.FPFCore.2026-07-25: localSenseCellRef: SenseCell(FPFCoreReferenceScheme, ModelApplicabilityRelation-core) basisEpistemeRef: A.1.1LocalSenseBasisRelationDescription.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-25ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: R1.2-BoundedModelUse-NamingBlock: Architecture and model useGovernedValueRef: ModelUseRelationGovernedValueKindRef: U.KindSubjectPatternLocator: A.1.1UnifiedTechName: ModelUseRelationUnifiedPlainName: this assignment's holder uses this model during this work concerning this holonNameCardRef: NC-MODEL-USE-RELATIONSenseCellRefs: SenseCell.ModelUseRelation.FPFCore.2026-07-25BridgeRefs: none; this row makes no semantic-correspondence or substitution claimRowRationale: 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 separateAdmissibleUse: Core-facing designation of the A.1.1 relation kind and its use in the E.24.UK bounded-model-use membership testBlockedUse: no use occurrence from availability, access, mention, assignment alone, Work alone, method application, assertion, publication, or structure membershipRowEditionId: 2026-07-25CurrentnessCondition: 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 useSenseCell.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-25LocalSenseBasisRelation.ModelUseRelation.FPFCore.2026-07-25: localSenseCellRef: SenseCell(FPFCoreReferenceScheme, ModelUseRelation-core) basisEpistemeRef: A.1.1LocalSenseBasisRelationDescription.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-25ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: R1.2-BoundedModelUse-NamingBlock: Architecture and model useGovernedValueRef: ModelExpressionCoherenceRelationGovernedValueKindRef: U.KindSubjectPatternLocator: A.1.1UnifiedTechName: ModelExpressionCoherenceRelationUnifiedPlainName: this model content and this expression content satisfy this declared coherence criterion under this comparison schemeNameCardRef: NC-MODEL-EXPRESSION-COHERENCE-RELATIONSenseCellRefs: SenseCell.ModelExpressionCoherenceRelation.FPFCore.2026-07-25BridgeRefs: 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 declarationRowRationale: 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 separateAdmissibleUse: Core-facing designation of the A.1.1 relation kind and its use in the E.24.UK bounded-model-use membership testBlockedUse: no coherence occurrence from a label, predicate label, equal spelling, maintenance or evaluation Work, changed carrier, result episteme, evidence, assertion, publication, or structure membershipRowEditionId: 2026-07-25CurrentnessCondition: 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 useSenseCell.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-25LocalSenseBasisRelation.ModelExpressionCoherenceRelation.FPFCore.2026-07-25: localSenseCellRef: SenseCell(FPFCoreReferenceScheme, ModelExpressionCoherenceRelation-core) basisEpistemeRef: A.1.1LocalSenseBasisRelationDescription.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.
#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
UTSRowId: UTS.U.Viewpoint.FPFCore.2026-08-02ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: R1.2-MultiView-NamingBlock: Multi-view describingGovernedValueRef: U.ViewpointGovernedValueKindRef: U.KindSubjectPatternLocator: E.17.0UnifiedTechName: U.ViewpointUnifiedPlainName: viewpointNameCardRef: NameCard.U.Viewpoint.FPFPublic.2026-08-02SenseCellRefs: SenseCell.U.Viewpoint.FPFCore.2026-08-02BridgeRefs: none; this row makes no semantic-correspondence or substitution claimRowRationale: 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 projectionAdmissibleUse: Core-facing designation of the dependent kind and exact typing of a reference whose resolution yields an already admitted viewpoint episteme PBlockedUse: 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 carrierRowEditionId: 2026-08-02CurrentnessCondition: 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 useNotes: retain the exact field viewpointRef : U.ViewpointRef; under the effective scheme its resolution yields P, while ViewpointId only designates P and neither operation grants membershipSenseCell.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-02LocalSenseBasisRelation.U.Viewpoint.FPFCore.2026-08-02: localSenseCellRef: SenseCell(FPFCoreReferenceScheme, U.Viewpoint-core) basisEpistemeRef: E.17.0LocalSenseBasisRelationDescription.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
UTSRowId: UTS.U.View.FPFCore.2026-08-02ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: R1.2-MultiView-NamingBlock: Multi-view describingGovernedValueRef: U.ViewGovernedValueKindRef: U.KindSubjectPatternLocator: E.17.0UnifiedTechName: U.ViewUnifiedPlainName: episteme conforming to an exact viewpointNameCardRef: NameCard.U.View.FPFPublic.2026-08-02SenseCellRefs: SenseCell.U.View.FPFCore.2026-08-02BridgeRefs: none; this row makes no semantic-correspondence or substitution claimRowRationale: the governed value is the E.17.0/E.24.UK same-individual dependent-kind token, not candidate episteme E, viewpoint P, conformance occurrence, reference, form, or carrier; an admitted member is the same exact C.2.1 episteme E only when EpistemeViewpointConformanceRelation(E,P) obtains for at least one exact admitted P; one unchanged E may conform to several viewpoint editions through distinct pair-determined occurrences while remaining one episteme; admission result E24UK-AR-UVIEW-RG-01 remains a separate decision projectionAdmissibleUse: Core-facing designation of the dependent kind and exact typing of U.ViewRef values that resolve already conforming epistemesBlockedUse: no View membership, episteme identity, conformance occurrence, adequacy, authority, or publication from the row, name, viewRef, NameCard, direct authoring, A.6.3 construction, query execution, transformation, evaluation, selection, bundling, rendering, audience, form, carrier, or publicationRowEditionId: 2026-08-02CurrentnessCondition: reopen when E.17.0 changes candidate-episteme identity, the exact conformance predicate or pair-determined occurrence rule, same-individual membership, E.24.UK admission, NameCard, FPFCoreReferenceScheme, or typed-reference useNotes: construction history and publication availability remain separately governed; neither creates membership, and no second View individual wraps ESenseCell.U.View.FPFCore.2026-08-02: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: U.View-core LocalExpression: U.View LocalSenseClaim: the same-individual dependent kind of exact C.2.1 epistemes E for which at least one direct EpistemeViewpointConformanceRelation(E,P) occurrence obtains to an exact admitted viewpoint episteme P; E remains the same individual and construction, selection, use, representation, and publication remain non-constitutive senseFamily: MultiViewRecognition NameCardRef: NameCard.U.View.FPFPublic.2026-08-02 LocalSenseBasisRelationRefs: LocalSenseBasisRelation.U.View.FPFCore.2026-08-02LocalSenseBasisRelation.U.View.FPFCore.2026-08-02: localSenseCellRef: SenseCell(FPFCoreReferenceScheme, U.View-core) basisEpistemeRef: E.17.0LocalSenseBasisRelationDescription.U.View.FPFCore.2026-08-02: entityOfConcernRef: LocalSenseBasisRelation.U.View.FPFCore.2026-08-02 entityOfConcernKindRef: LocalSenseBasisRelation basisPublicationUnitRef: E.17.0:4.4-4.5 viewpointRef: FPFCoreReaderViewpoint claimGraph: supportedSenseClaim: U.View names the same E only when exact E/P conformance obtains; it never names a generated or published wrapper admittedUseClaim: Core-facing designation, exact U.ViewRef typing, and retrieval of the direct membership rule nonAdmittedUseClaim: the basis relation, cell, NameCard, row, reference, construction, evaluation, form, carrier, or publication grants no membership referenceScheme: FPFCoreReferenceScheme editionId: 2026-08-02
UTSRowId: UTS.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: R1.2-MultiView-NamingBlock: Multi-view describingGovernedValueRef: EpistemeViewpointConformanceRelationGovernedValueKindRef: U.KindSubjectPatternLocator: E.17.0UnifiedTechName: EpistemeViewpointConformanceRelationUnifiedPlainName: the episteme conforms to this exact viewpointNameCardRef: NameCard.EpistemeViewpointConformanceRelation.FPFPublicSenseCellRefs: SenseCell.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02BridgeRefs: none; this row makes no semantic-correspondence or substitution claimRowRationale: the governed value is E.17.0's direct relation-kind token, not its RelationSignature, either participant, a reference, occurrence, assertion, evaluation result, NameCard, or row; each positive occurrence has exactly candidate episteme E and admitted viewpoint episteme P as participants and is pair-determined by <E,P>; it obtains only when E's C.2.1 EntityOfConcern satisfies P's exact target-kind criterion, E has an independently admitted episteme kind allowed by P without circular U.View use, and E's fixed content under its effective scheme satisfies P's fixed concern-coverage, semantic-form, completeness, consistency, omission, and loss rulesAdmissibleUse: Core-facing designation of the direct relation kind, exact RelationSignature lookup, and readable E/P conformance claims under E.17.0BlockedUse: no conformance occurrence, U.View membership, adequacy, truth, authority, or publication from the row, name, NameCard, signature, SlotSpecs, viewpointRef, ViewpointId, participant fillers, assertion, evidence, evaluation Work, result, construction, query, rendering, form, carrier, or publicationRowEditionId: 2026-08-02CurrentnessCondition: reopen when E.17.0 changes either participant kind, the target/admitted-kind/content predicate, pair-determined positive occurrence identity, RelationSignature, complete NameCard, FPFCoreReferenceScheme, or named Core useNotes: `EpistemeViewpointConformanceRelationSignature` is the E.17.0 declaration episteme whose exact EntityOfConcern is `EpistemeViewpointConformanceRelation`; A.6.0 independently gives that same individual `U.Signature` membership and relation-facing `RelationSignature` use, with `CandidateEpistemeSlot : U.EpistemeRef` and `ViewpointEpistemeSlot : U.ViewpointRef`; retain the exact consumer field `viewpointRef : U.ViewpointRef`, whose resolution yields P but proves no conformanceSenseCell.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: EpistemeViewpointConformanceRelation-core LocalExpression: EpistemeViewpointConformanceRelation LocalSenseClaim: the direct two-participant relation kind whose exact positive occurrence is pair-determined by one independently identified candidate episteme E and one independently admitted viewpoint episteme P and whose E.17.0 predicate tests E's exact EntityOfConcern kind, independently admitted episteme kind, fixed claim content, effective scheme, and satisfaction of P's fixed coverage, semantic-form, completeness, consistency, omission, and loss rules senseFamily: MultiViewConformance NameCardRef: NameCard.EpistemeViewpointConformanceRelation.FPFPublic LocalSenseBasisRelationRefs: LocalSenseBasisRelation.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02LocalSenseBasisRelation.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02: localSenseCellRef: SenseCell(FPFCoreReferenceScheme, EpistemeViewpointConformanceRelation-core) basisEpistemeRef: E.17.0LocalSenseBasisRelationDescription.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02: entityOfConcernRef: LocalSenseBasisRelation.EpistemeViewpointConformanceRelation.FPFCore.2026-08-02 entityOfConcernKindRef: LocalSenseBasisRelation basisPublicationUnitRef: E.17.0:4.4-4.4.1 viewpointRef: FPFCoreReaderViewpoint claimGraph: supportedSenseClaim: EpistemeViewpointConformanceRelation names the exact E.17.0 direct kind rather than its signature, participant references, assertion, evaluation, result, or dependent View membership admittedUseClaim: Core-facing designation, exact signature lookup, and readable reference to the direct relation kind nonAdmittedUseClaim: the basis relation, cell, NameCard, row, signature, references, evaluation, construction, or publication makes no occurrence obtain and grants no U.View membership referenceScheme: FPFCoreReferenceScheme editionId: 2026-08-02
The three row epistemes, their UTSRowId designators, external references, selected designations, governed values, NameCards, cells, basis relations, admission-result refs, conformance RelationSignature, and every obtaining relation occurrence remain independently recoverable. If availability for an audience later becomes current, exact E.24.PUB expression, bearing, and publication occurrences must be added outside these rows; file inclusion or this displayed block is not publication.
#Make a settled row available only through a separate publication operation
Do not perform an E.24.PUB publication operation on a placeholder. First require the governed value, its lexical classification, the reference scheme's selected name and permitted scope, and the intended reader use to pass F.18 and the ordinary F.17 row gate. If any input is unresolved, keep it as naming work rather than representing it as a current row. Only when an exact audience and bounded availability use are current should E.24.PUB make the selected row edition available through a distinct form and carrier.
A NameCard, scheme-sense cell, basis relation, row reference, or E.24.PUB occurrence substitutes for none of those decisions. Keep predicate definition, actual use, basis analysis, naming settlement, row admission, and downstream availability separate.
These eight rows expose the accepted F.18 designation pairs for Core citation. Each row names one value already defined or constrained by its subject pattern and uses one FPFCoreReferenceScheme sense cell. Its currentness follows that value and subject-pattern rule, the stable E.10 token classification and allowed-use rule it consumes, its exact NameCard, sense cell, and cited use. A dated corpus audit or candidate-conformance result is not a row dependency. The rows create no assignment, declaration, judgment, description, relation occurrence, predicate truth, structure, Bridge, or publication occurrence.
UTSRowId: UTS.U.SystemRoleAssignment.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: U.SystemRoleAssignmentGovernedValueKindRef: U.KindSubjectPatternLocator: A.2.1UnifiedTechName: U.SystemRoleAssignmentUnifiedPlainName: assignment to a system roleNameCardRef: NC-U-SYSTEM-ROLE-ASSIGNMENTSenseCellRefs: SenseCell.U.SystemRoleAssignment.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name the direct assignment family whose species relate an independently admitted system to one exact local system-role kindAdmissibleUse: Core-facing citation of the family and exact directly declared speciesBlockedUse: no kind, record, field, occurrence, authority, responsibility, or Work follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when A.2.1, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for U.SystemRoleAssignment, or the cited use changesUTSRowId: UTS.KindUseAdaptationDeclaration.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: KindUseAdaptationDeclarationGovernedValueKindRef: U.KindSubjectPatternLocator: C.3.4UnifiedTechName: KindUseAdaptationDeclarationUnifiedPlainName: declaration of a local use of a kindNameCardRef: NC-KIND-USE-ADAPTATION-DECLARATIONSenseCellRefs: SenseCell.KindUseAdaptationDeclaration.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name the declaration episteme that pins one exact base kind and signature edition, one receiving use, its constraints or vocabulary bindings, definedness, and intended guard useAdmissibleUse: Core-facing citation of the C.3.4 declaration familyBlockedUse: no kind, assignment, scope, profile, system role, guard decision, or judgment follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when C.3.4, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for KindUseAdaptationDeclaration, or the cited use changesUTSRowId: UTS.KindUseAdaptationCorrespondenceDeclaration.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: KindUseAdaptationCorrespondenceDeclarationGovernedValueKindRef: U.KindSubjectPatternLocator: C.3.4UnifiedTechName: KindUseAdaptationCorrespondenceDeclarationUnifiedPlainName: declaration of how two local ways of using kinds correspond and what is lostNameCardRef: NC-KIND-USE-ADAPTATION-CORRESPONDENCE-DECLARATIONSenseCellRefs: SenseCell.KindUseAdaptationCorrespondenceDeclaration.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name one declaration episteme stating deterministic correspondence and loss between two exact adaptation declarationsAdmissibleUse: Core-facing citation of the C.3.4 correspondence-declaration familyBlockedUse: no F.9 Bridge, executable adapter, mapping Method, representation correspondence, assignment, or target truth follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when C.3.4, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for KindUseAdaptationCorrespondenceDeclaration, or the cited use changesUTSRowId: UTS.KindUseAdaptationJudgment.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: KindUseAdaptationJudgmentGovernedValueKindRef: U.KindSubjectPatternLocator: C.3.4UnifiedTechName: KindUseAdaptationJudgmentUnifiedPlainName: judgment of whether a candidate fits a local use of a kindNameCardRef: NC-KIND-USE-ADAPTATION-JUDGMENTSenseCellRefs: SenseCell.KindUseAdaptationJudgment.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name the true, false, or unknown result for one candidate under pinned base-kind, signature, declaration-edition, and slice inputsAdmissibleUse: Core-facing citation of the C.3.4 judgment familyBlockedUse: no declaration, candidate, guard disposition, evidence result, or kind membership follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when C.3.4, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for KindUseAdaptationJudgment, or the cited use changesNotes: J_kindUse remains declaration-local notation and receives no rowUTSRowId: UTS.SystemRoleKindDescription.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: SystemRoleKindDescriptionGovernedValueKindRef: U.KindSubjectPatternLocator: F.4UnifiedTechName: SystemRoleKindDescriptionUnifiedPlainName: description of a system-role kindNameCardRef: NC-SYSTEM-ROLE-KIND-DESCRIPTIONSenseCellRefs: SenseCell.SystemRoleKindDescription.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name one F.4 description episteme whose exact EntityOfConcern is one local system-role kindAdmissibleUse: Core-facing citation of the F.4 description-episteme constructionBlockedUse: no described kind, assignment, NameCard, row, publication form, or carrier follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when F.4, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for SystemRoleKindDescription, or the cited use changesUTSRowId: UTS.SystemRoleAssignmentStateRelation.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: SystemRoleAssignmentStateRelationGovernedValueKindRef: U.KindSubjectPatternLocator: A.2.5UnifiedTechName: SystemRoleAssignmentStateRelationUnifiedPlainName: this assignment to a system role satisfies this state conditionNameCardRef: NC-SYSTEM-ROLE-ASSIGNMENT-STATE-RELATIONSenseCellRefs: SenseCell.SystemRoleAssignmentStateRelation.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name the direct relation between one exact U.SystemRoleAssignment occurrence and one by-value SystemRoleAssignmentStatePredicateAdmissibleUse: Core-facing citation of the A.2.5 direct relation kindBlockedUse: no state assertion, displayed status, predicate value, assignment, or obtaining occurrence follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when A.2.5, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for SystemRoleAssignmentStateRelation, or the cited use changesUTSRowId: UTS.SystemRoleAssignmentStatePredicate.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: SystemRoleAssignmentStatePredicateGovernedValueKindRef: U.KindSubjectPatternLocator: A.2.5UnifiedTechName: SystemRoleAssignmentStatePredicateUnifiedPlainName: state condition for an assignment to a system roleNameCardRef: NC-SYSTEM-ROLE-ASSIGNMENT-STATE-PREDICATESenseCellRefs: SenseCell.SystemRoleAssignmentStatePredicate.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name the predicate-value family whose members state truth conditions over exact system-role assignmentsAdmissibleUse: Core-facing citation of the A.2.5 predicate-value familyBlockedUse: no relation occurrence, assertion, displayed result, state label, or assignment follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when A.2.5, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for SystemRoleAssignmentStatePredicate, or the cited use changesUTSRowId: UTS.SystemRoleKindRelationStructure.FPFCore.2026-08-09ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: RoleOntologyAndWordingPrecision.2026-08-09Block: System-role assignments and kind-use precisionGovernedValueRef: SystemRoleKindRelationStructureGovernedValueKindRef: U.KindSubjectPatternLocator: A.2.7UnifiedTechName: SystemRoleKindRelationStructureUnifiedPlainName: structure of relations among system-role kindsNameCardRef: NC-SYSTEM-ROLE-KIND-RELATION-STRUCTURESenseCellRefs: SenseCell.SystemRoleKindRelationStructure.FPFCore.2026-08-09BridgeRefs: noneRowRationale: both designations name the relation-defined kind specified by A.2.7; each member is a selected U.Structure, not the kind itselfAdmissibleUse: Core-facing designation of that A.2.7 kind; one selected member must instead be identified by its exact kind constituents, selected obtaining relation occurrences, applied constraints, and named selection-use frameBlockedUse: no new root kind, selected structure instance, assignment configuration, taxonomy episteme, graph, table, or system collection follows from this rowRowEditionId: 2026-08-09CurrentnessCondition: reopen when A.2.7, the exact NameCard, FPFCoreReferenceScheme or sense cell, E.10:7.5b classification or allowed-use rule for SystemRoleKindRelationStructure, or the cited use changes
The rows use these exact scheme-based sense cells; the cells name no additional value and require no Bridge merely because both Tech and Plain designations exist.
SenseCell.U.SystemRoleAssignment.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: U.SystemRoleAssignment-core LocalExpression: U.SystemRoleAssignment LocalSenseClaim: the family of assignments in which each occurrence belongs to a declared species, relates an admitted System to one local system-role kind, and includes only the other participants required by that species NameCardRef: NC-U-SYSTEM-ROLE-ASSIGNMENTSenseCell.KindUseAdaptationDeclaration.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: KindUseAdaptationDeclaration-core LocalExpression: KindUseAdaptationDeclaration LocalSenseClaim: a C.2.1 declaration episteme that pins the base kind and signature edition, receiving use, constraints or vocabulary bindings, definedness, and intended guard use NameCardRef: NC-KIND-USE-ADAPTATION-DECLARATIONSenseCell.KindUseAdaptationCorrespondenceDeclaration.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: KindUseAdaptationCorrespondenceDeclaration-core LocalExpression: KindUseAdaptationCorrespondenceDeclaration LocalSenseClaim: a C.2.1 declaration episteme stating deterministic correspondence and loss between two exact KindUseAdaptationDeclaration values; it creates no Bridge, execution, representation correspondence, or target truth NameCardRef: NC-KIND-USE-ADAPTATION-CORRESPONDENCE-DECLARATIONSenseCell.KindUseAdaptationJudgment.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: KindUseAdaptationJudgment-core LocalExpression: KindUseAdaptationJudgment LocalSenseClaim: the true, false, or unknown result for one candidate under a pinned base kind, signature edition, adaptation-declaration edition, and slice; it is not the declaration, guard disposition, or evidence NameCardRef: NC-KIND-USE-ADAPTATION-JUDGMENTSenseCell.SystemRoleKindDescription.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: SystemRoleKindDescription-core LocalExpression: SystemRoleKindDescription LocalSenseClaim: an F.4 description episteme whose exact EntityOfConcern is one local system-role kind NameCardRef: NC-SYSTEM-ROLE-KIND-DESCRIPTIONSenseCell.SystemRoleAssignmentStateRelation.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: SystemRoleAssignmentStateRelation-core LocalExpression: SystemRoleAssignmentStateRelation LocalSenseClaim: an obtaining direct relation between one exact U.SystemRoleAssignment occurrence and one by-value SystemRoleAssignmentStatePredicate NameCardRef: NC-SYSTEM-ROLE-ASSIGNMENT-STATE-RELATIONSenseCell.SystemRoleAssignmentStatePredicate.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: SystemRoleAssignmentStatePredicate-core LocalExpression: SystemRoleAssignmentStatePredicate LocalSenseClaim: the predicate-value family whose members state truth conditions over exact system-role assignments; it is not an assertion, displayed result, or obtaining relation NameCardRef: NC-SYSTEM-ROLE-ASSIGNMENT-STATE-PREDICATESenseCell.SystemRoleKindRelationStructure.FPFCore.2026-08-09: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: SystemRoleKindRelationStructure-core LocalExpression: SystemRoleKindRelationStructure LocalSenseClaim: the A.2.7 relation-defined kind of selected structures; each member is a U.Structure with exact system-role-kind constituents, selected obtaining relation occurrences, applied constraints, and one named selection-use frame; this cell names the kind, not one member, assignment configuration, taxonomy episteme, or system collection NameCardRef: NC-SYSTEM-ROLE-KIND-RELATION-STRUCTURE
This row projects the current F.18 settlement for the product form already governed by E.11.DSG. The governed kind remains the relation-defined product form, not a newly minted root kind. The row makes the name reusable under FPFCoreReferenceScheme; it is neither the Reference product nor the operation that publishes one.
UTSRowId: UTS.DPFSuiteReference.FPFCore.2026-08-28ReferenceScheme: FPFCoreReferenceSchemeUnificationThreadId: DPFSuiteReferenceNaming.2026-08-28Block: DPF Suite public reference product formGovernedValueRef: E.11.DSG DPF Suite Reference product formGovernedValueKindRef: U.KindSubjectPatternLocator: E.11.DSGUnifiedTechName: DPFSuiteReferenceUnifiedPlainName: DPF Suite ReferenceNameCardRef: NC-DPF-SUITE-REFERENCESenseCellRefs: SenseCell.DPFSuiteReference.FPFCore.2026-08-28BridgeRefs: noneRowRationale: both designations name the editioned non-framework product form that starts from a cross-DPF working question, returns a bounded answer or blocker, and points back to the Suite collection, product series, editions, results, states, and sources that change the answer; maintenance is a separate claimAdmissibleUse: Core-facing designation of the E.11.DSG product form and readable title component for one exact continuing DPF Suite Reference series or admitted editionBlockedUse: no Suite, product series, edition, admission, Suite inclusion, currentness, availability, source authority, answer, lookup Work, framework status, instructional Guide, or publication occurrence follows from this rowLineageEntries: DPF Suite Guide is the predecessor Plain designation only; DSG remains stable PatternID lineage residue and is not a current public expansion; no DSR or synonym family is admittedRowEditionId: 2026-08-28CurrentnessCondition: reopen when the E.11.DSG product function, boundary, or identity rule; the exact NameCard; FPFCoreReferenceScheme or sense cell; the selected public use; or repeated reader classification changesSenseCell.DPFSuiteReference.FPFCore.2026-08-28: ReferenceScheme: FPFCoreReferenceScheme LocalSenseId: DPFSuiteReference-core LocalExpression: DPFSuiteReference LocalSenseClaim: the E.11.DSG relation-defined product form for an editioned non-framework publication that answers bounded cross-DPF questions, returns sources and honest gaps, and leaves Suite constitution, product-series and edition identity, lookup Work, publication, availability, authority, currentness, and any maintenance claim to their direct rules NameCardRef: NC-DPF-SUITE-REFERENCE
A product-specific title may qualify the Plain designation, for example Engineering DPF Suite Reference. That use still needs the exact product-series or edition claim; this row supplies only the shared product-form designation.
F.17 blocks table-bias: a row does not make the named object real, global, reusable, equivalent, or authoritative. It also blocks label-bias: the public name is a designation for a governed value, relation, slot, or local concept, not a substitute for the rules that define or constrain it, the scheme-based local-sense coordinate, Bridge, admissible-use statement, or currentness condition.
One exact governed value, its kind, the pattern that defines or constrains it, and the proposed row use were recovered before the row.
CC-F17-2
F.14 was applied at every current card, cell, and row gate, and the lightest sufficient naming disposition was tried first.
CC-F17-3
Row episteme, NameCard, designation expressions, governed value, reference, exact SenseCell, basis relation, and any F.9 Bridge remain distinct.
CC-F17-4
Every cell resolves to an effective by-value ReferenceScheme, exact expression, and local-sense claim; no generic context field or selected structure substitutes for them.
CC-F17-5
Every actual LocalSenseBasisRelation has exactly the cell and basis episteme as participants; descriptions, source units, publication occurrences, forms, and carriers stay separate.
CC-F17-6
Any F.9 Bridge actually obtains between exact cells; the separate use claim and A.10/B.3 reliance are visible only when that row use is current.
CC-F17-7
Admissible use, blocked use, row edition id, currentness condition, and any exact C.2.1 edition relation are recoverable without treating designators as identity.
CC-F17-8
If availability is claimed, exact E.24.PUB expression, bearing, and publication occurrences are recoverable independently from the row and from rendering or upload Work.
CC-F17-9
Multi-view naming uses three separate rows: U.Viewpoint names same-individual P only under E.17.0's fixed-content/selected-S predicate; U.View names same-individual E only after exact E/P conformance obtains; and EpistemeViewpointConformanceRelation names the two-participant pair-determined direct kind. References, designators, NameCards, RelationSignature, occurrences, construction, and publication grant none of those results.
Removes the exact governed value, scheme, and local-sense claim.
Recover the exact value and one scheme-based cell; keep local wording local when that suffices.
One row for system-role kind and status
Fuses a work-facing system-role kind with a state-family value.
Split the rows and use the pattern that defines or constrains each value.
Evidence-role bucket
Turns evidence use, source use, assurance, and Work into one pseudo-kind.
Recover each claim under A.10, B.3, E.10.D2, or the pattern that defines or tests the source or Work claim.
Automatic card-cell-row chain
Treats the presence of one naming object as need for the next.
Apply F.14 separately at each gate and stop at the lightest sufficient object.
Merged viewpoint/view/conformance row
A dependent kind, another dependent kind, and their direct relation are treated as one naming result.
Keep separate U.Viewpoint, U.View, and EpistemeViewpointConformanceRelation rows and use E.17.0 for every membership or obtaining claim.
Spelling or suffix identity
Lets a familiar label, stable id, or ...@Context form create or merge values.
Resolve the value under the pattern that defines or constrains it and treat only tokens fixed there as lineage.
Borrowed locality label as Tech name
Imports one tradition's commitments into the row and hides the effective interpretation basis.
Recover the governed value and scheme-based cell; select the designation under F.18 and cite an actual F.9 Bridge only when its separate predicate and use conditions hold.
Basis by source title
Replaces the exact cell and actual basis relation with a file or citation.
Recover the cell and two-participant basis relation; keep source-unit and publication facts separate.
Row as publication
Treats table presence, rendering, upload, form, or carrier as availability.
Use E.24.PUB for the selected row edition, audience, bounded use, form, and carrier.
Block as ontology or completeness proof
Treats navigation as subtype structure or row count as value evidence.
Keep blocks optional and judge the exact row use through reader recovery and blocked-use avoidance.
One row is ready for its declared citation use only when:
the governed value, exact kind, the pattern that defines or constrains it, and the proposed use are explicit;
F.14 has rejected every lighter sufficient disposition before the current card, cell, and row;
the exact F.18 NameCard and selected Tech/Plain designations are current for this public-row gate;
every SchemeSenseCell resolves to one by-value ReferenceScheme, local expression, and local-sense claim;
every relied-on local-sense basis is an actual two-participant LocalSenseBasisRelation and every description/source/publication object remains separate;
any cross-local use cites an obtaining F.9 Bridge for the exact endpoints, then a separate affirmative use claim and current A.10 or B.3 reliance;
the row has one decision, admitted and blocked citation uses, edition designator, and reopen condition;
any historical continuation is an exact C.2.1EpistemeEditionRelation rather than shared id or title;
any availability is an exact E.24.PUB publication package rather than row, form, carrier, rendering, or upload alone; and
every ontology, obtaining, equivalence, authority, system-role-kind, assignment, relation-position, status, evidence, Work, and other subject-use claim uses the pattern that defines, constrains, or tests it.
No other row needs to be filled before this one can close. A sheet's row count or optional block plan says nothing about whether another naming decision is substantively needed.
Benefits. Readers gain a stable route from one designation pair to the naming decision, governed value, defining or constraining rules, local sense, and admitted use without treating the table as ontology or publication proof.
Costs. A tempting row waits until the independently governed value, F.14 disposition, naming settlement, exact cell, and any actual Bridge are current. Publication availability adds its own E.24.PUB objects only when needed.
Failure avoided.F.17 prevents global glossary drift, card-cell-row cascades, label-based sameness, row-shaped ontology, optional-layout completeness claims, and authority or publication smuggled through a table.
Terms travel farther than the reasoning that produced them. F.17 carries only the reopening hooks needed for that travel. The pattern that defines or constrains the governed value, together with F.18, F.9, C.2.1, A.10/B.3, and E.24.PUB, supplies the separate rules to which those hooks lead.
Question and selected answer. At the effort of settling one reusable term, what must a reader recover beyond a familiar label, and what apparatus can be left out? Applying E.8:11, the selected answer is one readable row that returns separately to the named value, naming decision, exact local sense, permitted and blocked citation uses, and the condition that reopens the row. Create it only when that reader-facing route is needed.
The lightweight serious rival. The OntoLex Community Report, Overview, Purpose, Core, and Semantics, permits the core module alone. A fair one-term comparator is a lexical entry with a form, a sense and a reference to the already defined ontology entity, plus only the usage notes this application needs. It does not require a full lexicon, morphology or syntax graph; it is not intended to define the ontology itself. Adapt its expression/sense/reference separation in 5.1 and 7. Its extensibility also permits notes or a view to expose the same decision content as an F.17 row.
The choice is therefore not between a cheap row and an unnecessarily large graph. Hold the term, target, use conditions, and maintenance obligation fixed. A bare label or bare form/sense/reference chain lets the reader find the expression and target, but leaves the naming choice, blocked use, and reason to revisit it unstated. Adding those statements to the lightweight rival closes that gap; a generated readable view of those same statements is an acceptable way to express the F.17 row. A different vocabulary or file format is not, by itself, an improvement or a second naming result.
For an ordinary reader inspecting one term, select the explicit row because the decision and return are visible together. The deliberate trade-off is maintaining a truthful reader-facing projection instead of asking that reader to reconstruct it from linked lexical statements. When lexical tooling already produces that projection, keep it and avoid a second editable source. Conversely, when morphology, translation, or machine lexicon exchange is the actual use, the core model and only its needed extensions may be the better carrier. No measured speed advantage, blanket cost superiority, or replacement of OntoLex is claimed.
Exact effect and countercases. Steps 1–5 of section 4, together with sections 6 and 14, stop at ordinary wording, a local card, or a cell when no row is needed; steps 7–8 of section 4, together with sections 5.1 and 7, make the row's returns explicit and keep later publication separate. The countercase in 12.2 prevents a state label from becoming a system-role kind, 12.4c leaves ordinary mantra wording without rows, 12.4h distinguishes a reusable structure kind from one selected instance, and 12.4i returns the Reference name to its product-form rule without creating a product or lookup Work. These cases supply the FPF-local reason for the added decision content; the OntoLex report supplies the rival's lexical modeling capability, not validation of FPF ontology. Reject mandatory full-lexicon modeling, raw label familiarity as sufficient reader recovery, and the inference that a row makes its referent or publication real.
Reopen. Recompare when an equally small lexical entry or other presentation exposes the same decision, blocked uses, and exact returns with less reader and maintenance effort; when a generated view drifts from its source; or when the current use needs linguistic distinctions or machine exchange omitted by the row. If the added reader projection no longer changes use, retain the simpler expression of the same content.
Currentness rule: when F.2, F.3, F.5, F.7, F.8, F.9, F.10, F.14, F.15, F.18, C.2.1, E.17.0, E.24.UK, E.24.PUB, A.1.1, A.2, A.2.1, A.2.7, A.6.5, A.10, B.3, E.10.D2, or the pattern that defines or constrains the governed value changes the value, kind, membership or obtaining rule, designation, scheme, cell, basis relation, Bridge, bounded-use claim, reliance, status and system-role boundary, edition relation, reference typing, or publication boundary, recheck only the affected rows and worked examples.
Builds on: F.2 and F.3 for local-sense discovery probes; C.2.1 for row and NameCard epistemes plus exact EpistemeEditionRelation; F.14 for the anti-explosion gate; F.8 and F.18 for naming disposition and settlement; F.9 for actual cell-to-cell Bridges; F.5 for designation form; and F.7/F.15 for neighboring unification and conformance decisions.
Coordinates with: E.10.LRN for the learning anti-row and split boundary; 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.0, E.24.UK, E.24.PUB, F.4, F.6, and F.10, plus every row's SubjectPatternLocator. Row-local review after a changed value, membership or obtaining rule, designation, cell, Bridge, reference typing, edition, or availability rechecks the exact defining predicate and any neighboring subject assertion. Use G.11 only when an actual refresh plan, edition orchestration, telemetry, freshness, or decay claim is current. F.17 does not inherit a generic context-holon identity reading from earlier terminology practice.
Constrains: every public, Core-facing, durable, or cross-local term row that cites FPF values, local senses, relation names, slot names, system-role names, status names, or Bridge occurrences.
A row is a signpost, not the place it points to. Recover the value first, use the lightest sufficient name, and create a row only when a reader-facing durable route is needed. Keep card, cell, basis, Bridge, row, edition, publication, form, and carrier separate. The row may help a reader find the governed value; it cannot make that value, relation, use, authority, Work, or publication true.