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

experiment: define decision factor relationship family

Browse Source
This commit is contained in:
robbond
2026-08-14 12:21:28 +01:00
parent 014c6b72dc
commit 3d7f2cc3dd
2 changed files with 310 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/current-handoff.md
+2
View File
@@ -2992,6 +2992,8 @@ Experiment 60B.37 ran the customer-signing followup fixture through a single bou
---
Experiment 60B.59 was a read-only design-diagnosis of which existing graph relationships are strong enough to make an unresolved unknown count as a material factor attached to a decision — the core gap from 60B.58. **Classification: E — RELATION-FAMILY-AWARE NARROW SET REQUIRED.** Analysis of all eight relationship types (parentId/childIds, depends_on, affects, may_cause, causes, contained_in, supports, measures) confirmed that exactly three families carry genuine structural force for sufficiency: (1) decomposition hierarchy via parentId/childIds — only created by production decomposition logic; (2) prerequisite dependency via depends_on edge from unknown to decision — explicitly structural in `findDirectChildUnknowns`; (3) consequence linkage through option-attachment via affects/may_cause/causes edges pointing to options contained_in the decision — same set used for Route B embedding. Two key design decisions: (a) contained_in alone does NOT qualify because it expresses "is a candidate for" not "depends on"; (b) supports/measures do NOT qualify because they express evidential weight, not prerequisite/consequence. The customer-signing factor (attached via contained_in-only to opt_launch_this_year) would NOT block closure under the winning family — this is intentional. A separate helper is required (not extending propagateResolvedChildEvidence) to avoid mixing decomposition progress with sufficiency checking. One unresolved question: whether containment chains beyond one hop should count. Implementation readiness: A — ready for bounded implementation. No production code changed. 0 Ollama calls. Pure code inspection + fixture analysis. Full trace in docs/experiment-60b59.md.
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.
---