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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 08:25:59 UTC · snapshot created 2026-10-03 10:17:34 UTC · last check 2026-10-03 10:20:08 UTC

E.4.FPF:2 - Problem

After DPF and local-framework publication forms become explicit, FPF itself can fall into the opposite omission: DPF packages get careful publication-unit, form, carrier, relation, naming, quality, and refresh rules, while FPF is treated as if its form were self-evident because it is “the main spec”.

That creates several failures:

  • an all-in-one file or site, one of its Readme, Preface, ToC, pattern-body, card, or first-entry units, a skill-pack bundle, or an MCP route is mistaken for the FPF edition itself;
  • FPF is described as one more DPF, losing the first-principles and transdisciplinary burden that makes DPFs possible;
  • whole-FPF quality is checked by local pattern scores, landing status, or DPF package scales instead of E.2.DA;
  • adoption units, forms, or access surfaces grow user-facing explanations that quietly become shadow authority beside subject patterns;
  • skill or MCP access makes FPF look like a callable service, tool permission layer, or runtime dependency rather than a framework edition reached through an access route or borne by an exact access-facing presentation carrier.

Use an FPF-specific form rule. FPF must keep first-principles distinctions usable across domains while allowing domain and local frameworks to grow from it; E.4.DPF governs those dependent frameworks.