When a derisking spike’s predefined kill-condition has multiple OR clauses, score the strict-vs-spirit reading separately and use the maturity vocabulary outcome-MITIGATED to handle the gap.
Why: Kill-conditions are typically authored as multi-clause ORs (“X fails OR Y fails OR Z fails OR W happens”) to be defensive. But strict OR-reading flags as KILL the moment any clause triggers — even when the functional purpose of the spike is still achieved via an architectural alternative. The spike-runner needs a way to honestly signal both: (a) yes, a clause strictly met; (b) no, the functional path still works. Without the distinction, the maturity tag forces a binary KILL/VALIDATED choice that misrepresents the actual signal.
The S3 case (T-spike-eps-iota-S3-ontouml-linkml-2026-05-02.md): kill-condition was “gen-pydantic doesn’t transfer annotations OR ontouml:phase annotation lost in any codegen step OR Catala scope-binding cannot reference annotation metadata under any plumbing approach”. Strict reading: clause 2 (“annotation lost in any codegen step”) MET because gen-typescript + gen-json-schema drop annotations. Spirit reading: clause 3 (“Catala scope-binding cannot reference annotation metadata under any plumbing approach”) NOT MET because the YAML-direct shim approach fully works. Without outcome-MITIGATED, this would have to be either KILL (forcing fallback to boolean slot_usage: { active: false } that loses standards-track narrative) or VALIDATED (dishonestly hiding the strict-clause failure). MITIGATED carries both honestly.
How to apply:
- At spike-authoring time (when writing a plan): if the kill-condition has multiple OR clauses, also document a “spirit clause” — the single criterion that captures the functional purpose. Phrase as “the spike should KILL only if functional purpose X is unachievable under ANY plumbing approach”. This gives the spike-runner a clean signal at outcome time.
- At spike-execution time: score both strict-OR clauses AND the spirit clause. If strict says KILL but spirit says no, mark
maturity: outcome-MITIGATEDin the T-file frontmatter + document the strict-vs-spirit reasoning in §4 (kill-condition outcome). Don’t be tempted to read the kill-condition leniently — be honest that strict-clause met, then explain why architectural alternative validates. - Maturity vocabulary for ε.ι spikes:
outcome-VALIDATED— no kill clauses met (strict OR spirit). e.g. S1 v6.6 SEED audit, S2.5 owlready2 rescue.outcome-MITIGATED— strict clause(s) met BUT architectural alternative validates functional path. e.g. S2 LinkML imports (manual fallback works), S3 OntoUML annotations (YAML-direct works).outcome-KILL-CONDITION-MET— strict AND spirit BOTH unachievable; fallback to plan’s predefined fallback. e.g. (no spike has hit this in the ε.ι suite as of 2026-05-02).
- Per post-S2.5 alternatives-first discipline: before declaring
outcome-KILL-CONDITION-MET, surface 2-3 alternatives (perfeedback_surface_alternatives_before_collapsing_synthesis_to_baseline); often one alternative will validate the functional path → outcome shifts to MITIGATED. S2 → S2.5 demonstrated this; S3 demonstrated it again (5 alternatives surfaced before settling on YAML-as-canonical). - Plan-time kill-condition authoring discipline: when authoring a future spike’s kill-condition, prefer ONE clause that captures the spirit (“the spike kills only if functional purpose X is unachievable under any plumbing approach”) OVER many strict OR clauses. The strict OR style invites strict-vs-spirit confusion + ambiguous outcome scoring.
- Forward action: refined-prompt v3.6 candidate to require kill-conditions to specify
clause_priority:field + spirit-test alongside strict-clauses. This formalises the discipline at authoring time so spike-runners don’t have to reverse-engineer the spirit-test.
Source: T-spike-eps-iota-S3-ontouml-linkml-2026-05-02.md §4 (kill-condition outcome — strict vs spirit reading); arch-state v3.19 §11 S3 row + Changelog v3.19 row “Methodological observation #2”; plan v1.4 §1.7 codification candidate. Pattern first surfaced at S2 → S2.5 (alternatives-first); S3 named the underlying concept explicitly.
Related memories:
feedback_surface_alternatives_before_collapsing_synthesis_to_baseline— operational discipline that USUALLY converts a strict-clause-met spike into MITIGATED rather than KILL-CONDITION-METfeedback_linkml_annotation_surface_separation— example of why a strict kill-condition clause can over-trigger when the underlying tool surface is by-design rather than brokenfeedback_yaml_as_canonical_metadata_carrier— the architectural alternative that validated S3’s spirit clause