confidence-engine/docs/archive/experiments/decision-closure-integration/experiment-60b78.md

Experiment 60B.78 — Decision Closure Ownership Policy (Design Only)

Date: 2026-08-15
Branch: feature/sufficiency-decision-detection-v0.46
Preceded by: Experiment 60B.77 (model-led closure proven by elimination)
Type: Design analysis — no implementation

Objective

Choose the correct ownership policy for parent-decision closure when:

hasRemainingMaterialFactors(decision) === false
AND
isUserConfirmationOfNoRemainingUncertainty(answer) === false

The question is not how to implement a fix. The question is whether model-led parent closure should be allowed in that state, or whether the deterministic sufficiency policy owns whether a decision may close.

Key Findings

Prompt Ownership (Prompt-Builder Rule 143)

Rule 143 states: "If the currently supported evidence is sufficient to distinguish the options and no such material unresolved factor remains, resolve the existing decision context and do not ask a generic continuation question."

This permits evidence sufficiency alone to justify parent closure. It does NOT explicitly require user confirmation. It conflates "model judges represented factors exhausted" with "user confirms nothing else material remains."

Deterministic Gate (decision-sufficiency.js + apply-proposal.js)

shouldCloseDecision requires both:

1. countRemainingMaterialFactors === 0
2. isUserConfirmationOfNoRemainingUncertainty(answer) returns true (bounded CONFIRMATION_PHRASES/PATTERNS matching)

This is the authoritative closure policy — it unconditionally sets status=resolved when both conditions are met, with no override mechanism.

Model-Led Closure Risk

60B.77 proved the model independently proposes terminal closure when resolving its last material factor. When this happens without explicit user confirmation:

• Premature-closure risk: HIGH — contradicts false-open-over-false-closed philosophy
• Unrepresented uncertainty possible: YES — model cannot capture what user knows but hasn't graphed
• Bypasses conservative policy: YES — removes the explicit confirmation step entirely

Status Semantics

• known: directional value determined (TERMINAL_STATUSES)
• resolved: investigation complete, nothing to investigate further (TERMINAL_STATUSES)
• Both appear in TERMINAL_STATUSES — no existing distinction supports separating "model direction" from "user-confirmed closure" without broader changes.

Decision

Choice: B — EXPLICIT CONFIRMATION SHOULD AUTHORITATIVELY GATE CLOSURE

Rationale:

1. Conservative false-open philosophy encoded in confirmation phrases must not be overridable by model judgment
2. Model-led closure was proven (60B.77) to occur without confirmation
3. Unrepresented material uncertainty is possible
4. State B exists specifically for this gap — removing it via model-led closure defeats its purpose
5. False closure cost >> unnecessary questioning cost

Minimum Corrective Boundary

Choice: E — PROMPT CLARIFICATION + DETERMINISTIC ENFORCEMENT

1. Reword rule 143 to require explicit user confirmation matching deterministic gate criteria
2. Add validation in apply-proposal.js that strips model-proposed terminal closure without explicit confirmation

No schema change required. State B remains reachable when confirmation absent. Model reasoning/direction preservable (can express preferred option without setting resolved status).

Files Modified

• docs/experiment-60b78.md — this file
• docs/current-handoff.md — appended experiment entry

No production code, tests, prompts, schema, or harness changes.