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
PortfolioModefields 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
degradeorabstain. - 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:
degradeorabstainis treated as a selected-set member or as a generic selection result.