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 11:52:20 UTC · snapshot created 2026-10-03 11:53:41 UTC · last check 2026-10-03 13:55:20 UTC

A.6.3.CSC:4.3 - Ordinary vs exact reuse or reliance account

Ordinary cases should remain light. A short orientation summary, redacted partner note, workshop simplification, or lookup handle needs only the source-to-candidate comparison while the source remains directly available and no stronger use is attempted. The six-row form is optional.

Open the exact branch only when independent reuse, dispute, reliance, citation, cross-scheme interpretation, policy, bridge, work, gate, privacy, engineering justification, or assurance makes identity material. Then:

  1. identify exact source episteme X and exact receiving coarsened episteme Y by claim content, EntityOfConcern, and effective U.ReferenceScheme;
  2. confirm that both concern the same exact EntityOfConcern;
  3. state exact c : X -> Y, including claim construction, endpoint-scheme relation, preservation, controlled loss, prohibited strengthening, applicability, narrower admissible use, and return; and
  4. keep any source set, model, graph, state representation, evidence set, publication occurrence, form, carrier, actual Work, viewpoint, representation, and grounding facts separate and add only those needed by the receiving use.

The exact account below inherits the E.17:5.1e local-field rule. Use its entries as review aids for one exact reuse or reliance case. Apply the defining subject pattern to establish any additional FPF object, relation, or source-reference claim made with those entries.

Keep only entries that change the current use or next action:

  • sourceEpistemeRef, receivingCoarsenedEpistemeRef, and viewingConstructionRefOrStatement first; separately identify any PublicationUnit, publication occurrence, publication face or form, interop publication form, or carrier that exposes either endpoint;
  • coarsenedRenderingPublicationUnitIfAny only when one PublicationUnit is distinct from the publication, disclosure note, dashboard tile, or interop publication form on which it appears;
  • one exact source-relation reference, projectSourceRecordRef, or privileged reopen path, with any cited pattern named for the concrete definition, constraint, test, method, or source relation it supplies, so a coarsened rendering cannot reset its own provenance;
  • optional coarseningBranch only when it selects one additional branch-specific rule in A.6.3.CSC:4.4; ordinary direct semantic compression remains unlabelled;
  • every concrete lost or weakened distinction, with several recorded when several coexist; no single loss tag may substitute for this account;
  • recoverabilityAfterCoarsening only when recovery changes the next action, using exactly one immediate-action value from A.6.3.CSC:4.5 for the proposed use;
  • at least one kept claim or distinction bundle, one coarsened or dropped bundle, and one reopen-only bundle when the case is disputed or later cited;
  • an exact E.17:5.1b literal in a local field permitted by E.17:5.1e only when that source-relation status changes the next bounded use; CSC keeps no local paraphrase catalog;
  • uncertainty or abstention state when branch interpretation, preserved distinctions, source pin, or named narrower use cannot yet be stated stably;
  • the independent-verification question when downstream testing, assurance, gate, or external reliance appears;
  • audienceOverReadRisk, plus a light reader-reliance or user-evidence check when readers may mistake the coarsened rendering for authority it does not carry; and
  • whether local re-expansion is enough or the proposed use still requires return to exact X, an exact source relation, a genuine authoritySourceRef, or the pattern that supplies the needed definition, constraint, test, method, evidence rule, or gate rule.

The concrete named narrower use, non-admissible downstream use, and return trigger are authoritative and are stated once. Do not add a disposition label that repeats or mixes those decisions.