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

experiment: locate post-mutation question guard

Browse Source
This commit is contained in:
robbond
2026-08-14 08:38:23 +01:00
parent 88a80180b7
commit 5c6b3421dd
2 changed files with 368 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current-handoff.md
+3
View File
@@ -2961,3 +2961,6 @@ Experiment 60B.37 ran the customer-signing followup fixture through a single bou
---
Experiment 60B.38 was a read-only diagnosis of why `n_product_launch_decision` becomes known in the same update yet still survives as the final selectedQuestion target. **Classification: B — QUESTION TARGET VALIDATION IS WRONG.** Two independent gaps discovered in the selectable-node predicate chain: (1) `validateSelectedQuestion` at lib/graph/apply-proposal.js:246 checks `effectiveStatus === "resolved"` only, NOT `"known"`; (2) `isSelectableUnresolvedUnknown` at lib/graph/apply-proposal.js:1663 excludes ["resolved", "contradicted"] but NOT "known". These gaps propagate through the entire pipeline: `selectActiveUnknownCandidate` in utils.js has no status filter at all. The decision node transitioned via `updatedNodes.newStatus="known"` rather than `resolvedUnknownNodeIds`, and no predicate catches this gap. **Minimum corrective boundary:** C — unify all final targets through one canonical post-mutation unresolved/selectable check. Add "known" to the exclusion list in `isSelectableUnresolvedUnknown` and add `effectiveStatus === "known"` check in `validateSelectedQuestion`. No production code changed. 0 Ollama calls. Pure code inspection. Full trace in docs/experiment-60b38.md.
---
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.