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 02:22:15 UTC · snapshot created 2026-10-03 03:38:22 UTC · last check 2026-10-03 04:40:20 UTC

FPF.Preface:2 - FPF As A Project, Not Only A Pattern List

FPF is a project for improving how difficult reasoning is written, checked, taught, used by humans, and used by AI agents. The Core Specification is the normative center of that project, but it is not the whole project.

The Core Specification gives the pattern language: the named concepts, distinctions, pattern bodies, conformance checks, and relations that make FPF usable across domains. It says what the reasoning objects are and how exact claims are constituted and checked. When a project needs to know whether a diagram is architecture, whether a dashboard is evidence, whether a model output may be used for a decision, or whether a term is hiding several kinds, the Core pattern bodies provide the relevant action- or judgement-guiding content and the definitions or constraints the claim actually needs. A separate U.MethodDescription, admitted Method, or exact ClaimGraph locator is recovered only when that distinction is current. Evidence use depends on the relation between an exact episteme and a target claim (A.2.4), with reliance checked under A.10; publication alone does not establish that relation. Actor, ownership, and external-authority claims need their own direct basis.

Domain principle frameworks explain the methods and evidence practices of their fields and identify the FPF content and editions on which they rely. A local practice framework supplies guidance for a bounded local setting and may also rely on a domain framework. A local guide that simply applies existing guidance needs no new framework boundary. E.4 explains when a separate framework or adjacent product is useful and how its dependencies differ from its publication.

Other publications can teach, demonstrate or support this content: companion explanations, worked cases, tooling guides and research notes have different purposes. A companion may teach a method more slowly, and a tool may implement a publication form; the method, its explanation and the implementation retain their own identities. A useful explanation can be brought back into the supplying pattern when ordinary framework use needs it.

The Preface belongs to the framework edition it explains. A DPF Suite instead brings together separately constituted DPF product series. An optional, separately constituted DPF Suite Reference can explain how to use their contributions together and return readers to the supplying editions. It is a non-framework publication, not a required stage before using a known sufficient DPF result. E.4:4.2 and E.11.DSG give the full Suite and Reference rules.

One file or website can expose several such publications. Their shared carrier provides access; each framework, Reference or companion keeps the content, edition and change conditions established for it. Core meanings remain defined in Core. Authors can revise domain and local methods while preserving those dependencies. The Core can therefore remain tool-agnostic while companions, tools and domain explanations change for their intended uses.