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

experiment: define active selector terminal guard

Browse Source
This commit is contained in:
robbond
2026-08-14 08:51:19 +01:00
parent 5c6b3421dd
commit 865565b7af
2 changed files with 178 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current-handoff.md
+4
View File
@@ -2964,3 +2964,7 @@ Experiment 60B.38 was a read-only diagnosis of why `n_product_launch_decision` b
---
Experiment 60B.40 performed read-only post-mutation guard location diagnosis for same-turn terminal-target survival (known status). **Classification: B — PREFERRED TARGET NEEDS EXPLICIT POST-MUTATION REVALIDATION.** Traced all five post-mutation sources that can supply the final selectedQuestion node after applyGraphUpdate (line 3671): Source A (selectActiveUnknownCandidate, line 3722) has zero status filtering; Source B (isSelectableUnresolvedUnknown preservation at line 3764) excludes ["resolved", "contradicted"] but not "known"; Source C (model-selection honour at line 3984) has same gap; Source D (remainingUnknownExists inline check at line 3710) checks only kind + resolvedNodeIds, no status; Source E/F (selectPatternCompatibleUnknownCandidate and listUnresolvedUnknownCandidates) share the same ["resolved", "contradicted"] exclusion gap. Earliest safe guard point: line 3704 — updatedSituationGraph exists, proposal accepted, selected target can still be discarded, question not yet finalized. Fallback behaviour confirmed as C (both A+B): selectAnotherUnresolvedCandidate when one exists, return null when none remain. Minimum corrective boundary: E (minimum combination) — add "known" to isSelectableUnresolvedUnknown exclusion list AND add known exclusion to remainingUnknownExists inline check at line 3710-3711. Leaves residual gap in selectActiveUnknownCandidate if all candidates cascade to known status. One unresolved question requires clarification before readiness. Full analysis in docs/experiment-60b40.md. No production code changed. 0 Ollama calls. Pure code inspection.
---
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.