experiment: define decision sufficiency evidence

2026-08-14 12:10:25 +01:00
parent 2394ad4c0c
commit 014c6b72dc
2 changed files with 380 additions and 0 deletions
@@ -3018,3 +3018,5 @@ Experiment 60B.48 was a read-only code-path and contract diagnosis of why 60B.47
 ---

 Experiment 60B.56 was a live regression of negative customer-signing closure after the proposal-compatibility fix (54e2e21). **Classification: D — GRAPH CLOSES BUT CONVERSATION DOES NOT.** The enterprise-customer unknown resolved in place (unknown → resolved), negative meaning preserved ("customer will not sign" confirmed in resolution reason), zero addedNodes/edges, zero validation errors. However, `finalActiveUnknownNodeId = "n_product_launch_decision"` (non-null) and `finalSelectedQuestion` was non-null — the engine formulated a decision_threshold follow-up question ("What outcome would demonstrate enough value to justify launching?") targeting the parent decision node instead of closing it. The proposal-compatibility bug from 60B.47 is fixed (proposal accepted, HTTP 200), but the clean-closure contract (null → null when all dependencies resolve) remains unmet. `n_product_launch_decision` stays unknown despite having no remaining dependent unknowns — both options are known. One live Ollama call at qwen-claude:latest on http://192.168.1.111:11434. No production code changed. Full trace in docs/experiment-60b56.md.
+
+Experiment 60B.58 was a read-only decision-sufficiency evidence map. **Classification: E — DUAL-SIGNAL CLOSURE REQUIRED.** Analysis of the existing topology confirmed that no single signal suffices for correct closure detection. The winning model is Candidate E: relationship-aware graph traversal PLUS user declaration, both required independently. Key findings: (1) Existing architecture captures factor→option edges but does not traverse them during closure propagation — only parentId/depends_on children are counted; (2) Self-counting of the decision node as its own unresolved child is inherent in `selectActiveUnknownCandidate` because it filters only kind+resolvedNodeIds, never status alone beyond terminal exclusion; (3) Extending the predicate to include `affects → option contained_in decision` traversal fixes both premature-closure and missed-closure without schema changes. Implementation readiness: B — one unresolved question remains: which exact relationship types (affects, may_cause, causes) qualify as "decision-relevant" for generic factors beyond those already defined by 60B.15. No production code changed. 0 Ollama calls. Pure code inspection + fixture analysis. Full trace in docs/experiment-60b58.md.