# 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:

```text
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.