Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 07:42:37 UTC · snapshot created 2026-10-03 07:43:27 UTC · last check 2026-10-03 07:55:10 UTC

A.6.2:5.4 - Worked endpoint-value and relation-read profile (engineering SystemDescription episteme kind)

(informative)

To make the C.2.1 value and EFEM law discipline concrete, consider an engineering episteme of a dependent system-description kind whose exact EntityOfConcern is one U.System:

Value named by the EFEM speciesKind or reference formUse
exact EntityOfConcernU.Entity constrained to U.System; designated by U.EntityRefidentifies the system that the claims concern
claim contentU.ClaimGraphcarries the description or specification claims
effective ReferenceSchemeU.ReferenceSchememakes the claims and their designations interpretable

This table names the three values that identify an episteme; it is not a RelationSignature or SlotSpec table. EntityOfConcernSlot, ClaimGraphSlot, and ReferenceSchemeSlot are declaration-local SlotKinds only when the reusable C.2.1 EpistemeConstitutionRelationSignature is being inspected. An EFEM species states how the endpoint values compare. If its rule uses a selected viewpoint, empirical-grounding relation, or representation relation, it names the exact occurrence or use qualification separately and reads or compares the endpoint facts without changing the occurrence.

Two typical EFEM species over this kind are:

  • Specify_DescEp_SpecDesc_Sys : SystemDescription → SystemSpec — an EntityOfConcernChangeMode = preserve species that:

    • relates independently identified source and receiving epistemes with the same exact EntityOfConcern, makes their effective ReferenceSchemes explicit, and cites any separately obtaining empirical-grounding relation or viewpoint selection only when the formal relation depends on it;
    • satisfies P2 only when every claim in the receiving specification is recoverable from exact source ClaimGraphs or independently current facts under named relations and schemes; the unchanged EntityOfConcern is an endpoint identity condition, not a proposition or additional premise;
    • satisfies C.2.1:7.1 by declaring its endpoint-value comparison, named relation-read profile, and change mode.
  • Normalize_EngView — a family of view-normalisation EFEM arrows n_X : X -> Y between exact U.View epistemes (again with EntityOfConcernChangeMode = preserve) that:

    • states how the formal relation uses the three C.2.1 identity values and makes the exact source-to-receiving ClaimGraph difference explicit; any difference between separately obtaining endpoint facts that it compares is named by the exact predicate and participants, and any normalization application remains separate;
    • is effect-free. A repeat claim identifies the next arrow n_Y : Y -> Z under the same rules, establishes Z = Y under C.2.1, and witnesses compose(n_Y, n_X) ≃ n_X under the declared arrow equivalence, as in §5.2;
    • is conservative (P2) by construction: it never introduces new atoms about the selected system.

Concrete A.6.3/A.6.4/E.17.* patterns for engineering description and specification-use idioms state explicitly, under C.2.1:7.1 and CC-EFEM.*, which of the three C.2.1 endpoint values remain the same or differ and which exact separately obtaining relation occurrences their arrow rules read or compare.