A.19.CHR:6 - Bias-Annotation
The following trade-offs matter when using the suite:
- Gov. Bias toward fail-closed admissibility and explicit auditability (applicable relation/crossing references, pinned spec refs, guard–gate separation). Mitigation: the tri-state
GuardDecisionallows uncertainty to degrade or abstain without forcing gate-level blocking; exploration can still proceed via explicit SoS‑LOG policy branches. - Arch. Bias toward explicit node-level composition (E.18) and explicit planned baselines and conditional typed fillings. Mitigation: the suite fixes only the universal core; discipline-specific generators and extensions remain separate mechanisms connected by
Uses, keeping the suite compact. - Onto/Epist. Bias toward a strict separation of CN‑Spec and CG‑Spec spec refs, mechanisms (A.6.1), and planning epistemes (A.15.2; A.15.3 for typed fillings). Mitigation: specialization is explicitly supported (
⊑/⊑⁺) and does not require inventing new kernel constructs; method diversity is expressed via MethodDescription refs and ComparatorSpec refs. - Prag. Bias toward conservative uncertainty handling (unknown does not coerce to pass) may reduce decisiveness. Mitigation: “probe-only” and “sandbox” behaviors are permitted as explicit, audited degrade modes (policy-id + branch-id), not as silent coercions.
- Did. Bias toward explicit terminology and pins increases authoring surface area. Mitigation: this pattern provides a canonical protocol and ordinary baseline content with reusable references so authors can reuse a stable template rather than re-inventing local prose conventions.