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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 14:36:52 UTC · snapshot created 2026-10-03 14:38:14 UTC · last check 2026-10-03 14:40:20 UTC

A.6.7:3 - Forces

  1. Strict distinction (level hygiene). “many mechanisms” must not be encoded as “many realizations of one mechanism”. Violating this blurs specialization laws, mechanism-declaration invariants, and audit/crossing responsibilities.

  2. Minimal specificity + kind suffix discipline (E.10). The token name should encode only what is essential: it is a description, it is about mechanisms, it is a suite. It must not capture a particular domain (e.g., CHR) in the Kernel name.

  3. Governing spec ref centrality (CN‑Spec and CG‑Spec). Suites must cite governing spec refs as pins, not duplicate their internals, otherwise multiple competing admissibility centers arise.

  4. Transport and crossing visibility discipline. An asserted semantic correspondence needs its F.9 Bridge; a kind correspondence needs its C.3.3 basis; a plane relation retains its own defining rule. Expose the anchors required by each actual relation and receiving use. An independently governed E.18 crossing or A.21 gate retains its required bundle or gate evidence. Any applicable penalty routes to R/R_eff only; suites do not embed CL/Φ/Ψ/Φ_plane tables.

  5. Guard vs gate separation. Mechanisms can output tri-state guard outcomes and explanations; gate decisions (including block) and DecisionLog remain gate-level (OperationalGate(profile)). A suite must not collapse these layers.

  6. FPF is conceptual. The suite is a conceptual descriptor: no implementation fields, no “lint rules”, no machine governance. The suite expresses obligations as conceptual constraints and required pins/anchors.