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 17:24:51 UTC · snapshot created 2026-10-03 17:30:20 UTC · last check 2026-10-03 18:55:10 UTC

A.19.SelectorMechanism:2 - Problem

Engineering teams regularly need to make “a selection decision” under conditions that are normal in real projects:

  • comparisons are partial, multi‑criteria, or set‑valued,
  • evidence is incomplete or policy‑gated, and
  • different stakeholders ask for different “best” notions.

If selection is not a first‑class mechanism boundary with stable semantics, the same high‑risk drift happens repeatedly:

  • Silent winner forcing: partial orders get collapsed to a single winner by ad‑hoc tie‑breakers or hidden weights.
  • Hidden thresholds and constants: thresholds, weights, dominance regimes, and default PortfolioMode fields get smuggled into implementations and become invisible in discussion and audit.
  • Scalarization by convenience: set‑valued comparison outcomes get replaced by a scalar “score summary” that is treated as decision‑relevant without being declared as such.
  • Evidence coercion: missing or unknown evidence gets treated as “good enough” (implicit pass) rather than yielding explicit degrade or abstain.
  • Boundary erosion: selection quietly performs comparison, scoring, aggregation, or publishing.
  • Selection-boundary drift: a selected-set label is reused after candidate universe, finite upstream comparison-application basis or its required coverage, selection conditions, A.19 predicate, claim scope, selected context slices, reference plane, or evaluation window changed.
  • Guard-output collapse: degrade or abstain is treated as a selected-set member or as a generic selection result.