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

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:45:10 UTC

A.19.UINDM:3 - Forces

  1. Policy primacy vs method freedom. Indicatorization must be governed by explicit IndicatorChoicePolicy, while still allowing multiple method families (e.g., theory‑first, invariance‑driven, evidence‑gated) to be wired later without mutating the mechanism’s signature.

  2. Selection‑only vs “semantic alchemy.” UINDM must not smuggle normalization, scaling, polarity flips, aggregation, or scoring inside “indicator choice.” It is a selection mechanism over the declared characteristic-space basis, not a transformation mechanism.

  3. Declared-use locality vs reuse. An indicator set is valid for its characteristic-space and CN-Spec editions, bearer, scope and window, evidence basis, policy, and intended use; a later use must recheck those premises and cite any source-local, kind, or plane relation it actually relies on.

  4. Auditability vs authoring overhead. Engineer‑managers need to see why an indicator set was chosen and which editions/policies were in effect, but FPF stays conceptual (no data governance, no tool‑enforced metadata). Audit obligations must therefore be minimal yet decisive.

  5. Evolvability vs didactic usability. CHR mechanisms must remain evolvable (stable slot lexicon; method specifics in SoTA packs / wiring), while the spec must remain teachable: a reader should find UINDM’s purpose, boundary, laws, guard behavior, and audit obligations in one place.

  6. Fail‑closed discipline. Unknown/insufficient evidence must never be coerced into “pass”; tri‑state guards (pass|degrade|abstain) are required to preserve correctness under uncertainty.

  7. P2W separation and gate/guard separation. UINDM must expose eligibility and audit pins without turning into (i) a WorkPlanning baseline binder or (ii) an admissibility gate: planned slot fillings belong to WorkPlanning plan items, while GateDecision/GateLog live in gate patterns / WorkEnactment (suite protocols remain mechanism‑steps only).