fpf.tools
Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading
Source · lines 94981–95031

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 12:30:19 UTC

E.17:5.1a - Episteme-publication relation-position binding (normative)

For functional-description publications, E.17 covers only the publication relation.

Publication relation position. A principle scheme, functional diagram, comparison table, screen, export, scenario, explanation, or code-like method description can help interpretation, source-finding, comparison, selected-method inspection, or work-planning preparation.

Unsupported neighboring claims. The publication does not by itself assert performed U.Work, a work claim, gate passage, evidence, assurance, engineering justification, supervisory relation or control relation, authority, release permission, or a new transformation-flow kind.

Interface and protocol proximity. When interface, protocol, schema, boundary, or API wording appears beside a functional-flow description, keep that operational claim with its project claim set and exact reference. Apply the boundary, interface, protocol, or transformation rules in A.6.B, A.6.C, or E.18 as the concrete claim requires; do not absorb it into the publication by layout proximity.

Retargeting. If the publication changes the EntityOfConcern or retargeting target from an already described component, recovered transformation, method, work occurrence, transformation-flow structure, material U.Entity, or source claim into a functional, control, or flow architecture claim, this is not a same-entity publication-use change. Use A.6.4, OntologicalReframing, or E.18 as applicable.

Source recovery. When a requested use requires a project-side object or relation beyond the publication face, first recover the existing reference that actually carries that claim. The bullets below are different concrete checks, not one grouped route or generic pattern relation:

  • source wording, publication construction, carrier-relation construction, source relation, project-side reference, or explicit non-use disposition under C.2.P;
  • appearance-based reliance repair under A.15.4;
  • project U.Method, U.WorkPlan, or work-result record under A.15;
  • evidence and provenance path under A.10;
  • engineering-justification record under B.3;
  • constraint or gate decision under A.20 or A.21;
  • supervisor-subholon feedback record under B.2.5, control-structure-view record under C.30.LCA, or a record of the exact architecture claim under C.30 or selected-structure claim under A.22, as applicable;
  • carrier, export, OCR, or front-end distinction under A.7, followed by the applicable carrier, front-end, or Work pattern;
  • same-entity textual relation under A.6.3.CR;
  • representation relation under A.6.3.RT;
  • reduced-use-rendering relation under A.6.3.CSC.

No backdating. If no existing typed project-side FPF kind and reference named by value carries a claim that was supposed to already have a source relation, do not create a backdated source. Create only a prospective repair request, prospective decision request, prospective work-plan entry, or explicit missing-source-relation note, and treat the earlier claim or effect as unsupported until the required source exists.

Ordinary orientation and source-finding can stay as an inline note.

Functional-description guard (CC-MVPK-FD). A functional-description publication separates the source U.Episteme or episteme-side U.View, the exact publication form (the MVPK face), any present carrier or rendering work, the separate bounded-use declaration, and unsupported neighboring use. The guard applies only when a functional-description face is present; it is not the first universal MVPK conformance gate.

MVPK inherits the distinction among U.Episteme, contingent published-episteme use, publication occurrence, publication form, U.View, U.PresentationCarrier, and authority-reference relation. It introduces no durable published-episteme kind or other generic semio kind. A publication face does not define another relation’s claim, supply authority, or become the source claim merely by being published; use the exact source or authority relation when one is current.

When a morphism publication is encountered or reused, name only the relation positions needed by the current use:

  • the selected source U.Episteme, D episteme, or S episteme edition and the claims actually exposed; identify its exact ClaimGraph only when claim identity must travel;
  • the exact PublicationFormExpressionRelation occurrence among that selected edition, exact form, and exact bounded-use declaration;
  • the exact PublicationFormBearingRelation occurrence between the presentation carrier and form;
  • the exact five-participant EpistemePublicationRelation occurrence when that selected edition is available to the declared audience for the bounded use;
  • the selected episteme’s independent E.17.0 U.View membership when the publication use calls it a view, plus any separate A.6.3 construction history when current;
  • the exact system-performed carrier or rendering Work; any A.10 evidence/provenance path or G.6 path citation needed to replay it; and any G.11 currentness result, only when those neighboring facts are current; and
  • the exact project-side object, reference, or authority relation when the next work or reliance claim depends on it.

Changed claim content, EntityOfConcern, or effective reference scheme identifies another episteme edition under C.2.1. Re-evaluate PublicationFormExpressionRelation only when its selected edition, form, bounded-use declaration, or obtaining predicate changes; re-evaluate PublicationFormBearingRelation only when its carrier, form, or obtaining predicate changes. Independently, changing any of the five EpistemePublicationRelation participants identifies another publication occurrence without reidentifying an otherwise unchanged episteme. Publication availability lost and later restored creates a later occurrence; a file rename or layout change alone proves none of those changes. The practical payoff is that a reader can recover which object or relation is available for reliance: the episteme claim, the published form, the view, the carrier, the typed project-side FPF kind and reference named by value, or the authority-reference relation. A dashboard tile, generated explanation, card face, credential view, or carrier can guide source-finding, but it does not by itself establish the source claim or effect, gate decision, evidence relation, assurance claim, local system-role kind, separate System-classification judgment, assignment occurrence or state, direct status predicate, responsibility or authority predicate, Work occurrence, or permission. If its source uses role or status without making one of those claims clear, treat that phrase as unresolved recognition wording and route it through E.10.ROLE; then use the recovered direct pattern or return the exact missing governor.

Source-exposure rule. A face, carrier, rendering, dashboard tile, credential view, status view, comparison unit, explanation, signed memo, release record, approval publication, or gate dashboard exposes another project-side object only when that exact object and its direct relation are recoverable. Readability, layout, title, color, fluency, proximity, copying, generation, or reuse establishes none of them. If a real SpeechAct, GateDecision, evidence path, credential or status source, U.Work occurrence, U.Episteme, or publication occurrence is recoverable, rely on that object and relation; otherwise use the face only for orientation or source-finding.

No retroactive source creation. When the required source relation is missing, a new entry can be only a prospective repair request, prospective decision request, prospective work-plan entry, or explicit missing-source-relation note. It is not used as earlier evidence, approval, gate passage, instituting speech act, U.Work occurrence, release permission, engineering justification, or assurance for the unsupported past claim or effect.