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 08:25:59 UTC · snapshot created 2026-10-03 08:26:43 UTC · last check 2026-10-03 08:50:20 UTC

E.24:5.2a - One Workflow Expression Across the Boundary

Use one fixture to see what changes the answer. The exact expression Line 7 pump-service workflow comes from source episteme Line7MaintenanceManual_v4; when availability matters, Line7ManualRelease_2026-04 is its source publication occurrence. Keep its source-use status quote-only in every case below. The fixed EntityOfConcern of each decision card is Line7WorkflowInquiry_v1, an independently identified source-construct entity for this exact inquiry; it asserts neither a workflow ontic nor any branch payload. The recovered objects are already governed: Pump37ServiceMethodDescription_v2 under A.3.2, Pump37WeeklyMaintenancePlan_2026Q3 under A.15.2, dated Work occurrence Pump37ServiceWork_2026-07-18 under A.15.1, and selected Pump37MaintenanceFlowStructure under E.18. The expression and provenance do not choose the ontology disposition; the receiving use and recovered evidence do.

  1. Direct-use result. A manual editor needs to check the one claim that Pump37ServiceMethodDescription_v2 describes the service method used in the manual. A.3.2 closes that readable claim. The decision’s EntityOfConcern remains Line7WorkflowInquiry_v1; its DirectUseResult points to the exact assertion, the identified method-description episteme, and A.3.2. Do not add a coordination episteme or a workflow ontic.
  2. Bounded-episteme result. A weekly scheduling review needs the method description, current work plan, dated Work occurrence, and selected flow structure read together because each claim explains how exact Pump #37 will be serviced that week. The decision’s EntityOfConcern remains Line7WorkflowInquiry_v1; its BoundedEpistemeResult points to Pump37WorkflowScheduling_v1, whose own EntityOfConcern is exact Pump #37 under C.2.1. No current dependent use requires that claim package as ontology. Leave every designated object under its exact predicate, subject assertion, and defining or constraining ClaimGraph.
  3. Durable-ontic threshold—not met by the current fixture. The decision’s EntityOfConcern remains Line7WorkflowInquiry_v1. A positive DurableOnticResult would have to point to an independently identified ontology-unit individual such as MaintenanceWorkflowOntic_v1, its stable identity or constitution rule, and the exact reliance of multiple A.3.2, A.15.2, A.15.1, and E.18 consumers on that one unit. Those facts are absent, so this fixture has no durable result; when this stronger use is the active question, its UnresolvedResult names the missing identity and reliance evidence. The source expression and recurring four-object list do not identify a durable ontic.
  4. Unresolved stop. The same manual may ask only to “align the workflow” while leaving open whether the concern is the method description, plan, dated Work, flow structure, Pump #37, or an admitted whole or selected structure. The decision’s EntityOfConcern remains Line7WorkflowInquiry_v1; its UnresolvedResult records that no exact governed payload has been recovered and names the missing identity evidence. Keep the quote and provenance, and split any direct claims that are already valid; do not turn the phrase or list into a subject.

The fact that changes the result is one closing claim, several claims for one use, shared cross-pattern ontology reliance with stable identity, or no exact governed subject.

The E.24 move is:

  1. name the working expression and identify the pre-judgment candidate entity, proposal episteme, or source-construct entity under its direct rule; keep that fixed object as the decision episteme’s EntityOfConcern. If none is identifiable, retain inquiry material; a missing governed payload instead permits an unresolved result about the identified decision subject;
  2. list the direct entities and relations that currently carry the subject; for every reused declaration, separately list its RelationSignature and SlotSpecs;
  3. run the existing-rule-content, exact-identity, typed-connectivity-or-constitution, dependent-use, and non-duplication tests, then select one ontology disposition for the recovered payload—direct subject-assertion use, bounded local episteme under C.2.1, durable ontic, or unresolved stop—and record source-use status separately;
  4. if a durable ontic is selected, write or cite its exact defining or constraining ClaimGraph before dependent uses rely on it.

Do not repeat the surrounding method/work/change inventory here. The current claim selects one object class in E.24:4.3a; the workflow fixture names method description, plan, Work, and structure only because each changes that case. Their co-occurrence is an applicability signal, not a durable-ontic result.

For another broad head such as system, relation, or architecture, recover its exact subject assertion and defining or constraining ClaimGraph first and apply the same thresholds; the head alone admits no ontic.

Dependent pattern descriptions may keep a thin cue: when one recognizable concern spans several direct entities and relations, name the exact relation assertion and cite the pattern locator for its defining or constraining ClaimGraph. That cue does not license treating a local set of references as a durable ontic before the E.24 decision, assigning one entity to two kinds without direct admission, or treating a SlotKind label as alternate ontology.