75 lines
3.5 KiB
Markdown
75 lines
3.5 KiB
Markdown
|
|
# 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. |