robbond/confidence-engine
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

experiment: validate clean decision closure live

Browse Source
This commit is contained in:
robbond
2026-08-14 09:21:36 +01:00
parent 6b13e67c05
commit 50ae28b325
2 changed files with 137 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current-handoff.md
+2
View File
@@ -2984,3 +2984,5 @@ Experiment 60B.40 performed read-only post-mutation guard location diagnosis for
---
Experiment 60B.41 was a read-only diagnosis of whether `selectActiveUnknownCandidate` must independently exclude terminal-status nodes (known/resolved/contradicted) for the 60B.37 closure path to be correct and fallback selection to remain semantically sound. **Classification: A — SELECTOR ITSELF MUST FILTER TERMINAL STATUS.** The selector at utils.js:593 filters only `kind === "unknown"` and `!resolvedNodeIds.includes(n.id)`. Zero status filtering exists. Key findings: (1) Scoring (`scoreUnknownCandidate`) is completely blind to node.status — it uses text classification, downstream count, and upstream unresolved dependency count, none of which inspect status. A known-status unknown-kind node scores identically to an unknown-status one. (2) In 60B.37's exact scenario: if no other genuine unresolved unknown remains, the selector would return the known decision node as the sole candidate, recreating the stale-target bug post-guard. (3) Adding terminal-status filtering does NOT affect genuine fallback candidates or prerequisite-first ordering because filtering happens before scoring and all genuine unknown-status nodes pass unchanged. (4) Five independent locations share the same gap pattern (`["resolved", "contradicted"]` exclusion without "known"): isSelectableUnresolvedUnknown, listUnresolvedUnknownCandidates, carriedActiveUnknownStillUnresolved, remainingUnknownExists inline check, and selectPatternCompatibleUnknownCandidate. This is PARTIAL overlap — different contracts serving different operational contexts but sharing the same systematic gap. **Critical distinction: D — SHARED ELIGIBILITY CONTRACT IS REQUIRED.** **Minimum implementation model: A — add terminal-status filter to selectActiveUnknownCandidate.** The selector must independently guard because it has zero caller-enforced input protection and known-status nodes bypass resolvedNodeIds entirely (they transition via updatedNodes.newStatus). Implementation boundary: one line change at utils.js:596 — add `!["known", "resolved", "contradicted"].includes(n.status)` to the existing filter. Ready for bounded implementation. No production code changed. 0 Ollama calls. Pure code inspection. Full trace in docs/experiment-60b41.md.
Experiment 60B.44 was a live regression of 60B.43's terminal post-mutation eligibility fix on the customer-signing closure case through the full production update path. **Classification: A — LIVE CLEAN CLOSURE CONFIRMED.** One bounded update call resolved `n_enterprise_customer_signing` in place (unknown → resolved) and closed `n_product_launch_decision` (unknown → resolved). Both option identities preserved. No new nodes or edges created. `activeUnknownNodeId = null` (cleared). Final `selectedQuestion = null`. Zero stale artifacts. This proves that 60B.43's terminal-status filtering across all six post-mutation eligibility paths eliminates the exact 60B.37-shaped stale-target persistence through live LLM-driven production code. One live Ollama call at qwen-claude:latest on http://192.168.1.111:11434. No production code changed. Status pending Rob's review.