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

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 17:24:51 UTC · snapshot created 2026-10-03 17:30:20 UTC · last check 2026-10-03 18:45:20 UTC

A.3.1:2 - Problem

Without a current U.Method distinction, FPF cannot repair method-like wording cleanly. Texts then slide among several different claims:

  1. Description as method. A SOP, code repository, proof script, BPMN diagram, SQL query, solver model, or protocol is treated as the method itself.
  2. Plan or run as method. A calendar plan, access plan, run log, telemetry trace, or work-result record is called the method.
  3. Mechanism or formal substrate as method. A mathematical object, formal substrate, mechanism declaration, causal model, or control structure is used as if it already selected the way of doing work.
  4. System-role or capability leakage. Named people, organizations, teams, permissions, system-role assignments, or a particular holder’s capability assessment are baked into the Method instead of remaining with their direct classification, assignment, authority, capability, or gate patterns.
  5. Programming-paradigm overread. Imperative, functional, logical, constraint, object-centric event, or effect-handler wording is taken as a direct ontology of work rather than one possible description or representation of a way of doing.

The practical harm is fragile reliance. Changing a publication looks like changing the method; a run error looks like method invalidation; a mechanism declaration starts authorizing work; and a dashboard cue starts acting like evidence or permission.