experiment: define closure enforcement boundary
This commit is contained in:
@@ -4079,3 +4079,273 @@ Watchman used: NO
|
||||
Documentation updated: docs/experiment-60b78.md created; docs/current-handoff.md appended
|
||||
|
||||
Git status: will be clean after commit
|
||||
|
||||
---
|
||||
|
||||
#### Experiment 60B.79 — Closure Enforcement Boundary Analysis (READ-ONLY DESIGN)
|
||||
|
||||
**Date:** 2026-08-15
|
||||
**Branch:** `feature/sufficiency-decision-detection-v0.46`
|
||||
**Preceded by:** Experiment 60B.78 (explicit confirmation authoritatively gates closure)
|
||||
**Type:** Design analysis — no implementation
|
||||
|
||||
## Objective
|
||||
|
||||
Determine the smallest deterministic enforcement boundary that prevents model-led terminal closure without explicit confirmation, while preserving legitimate model reasoning/direction and keeping State B reachable.
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 1 — Direction representation
|
||||
|
||||
Existing fields carrying directional meaning WITHOUT parent terminal status:
|
||||
|
||||
| Field | Directional? | Requires terminal? | Survives removal? | Used downstream? |
|
||||
|-------|-------------|-------------------|-------------------|-----------------|
|
||||
| `answerMeaning.userSupportedMeaning` | YES | NO | YES | PARTIAL |
|
||||
| `answerMeaning.possibleInference` | YES | NO | YES | PARTIAL |
|
||||
| `answerMeaning.supportCategory` | PARTIAL | NO | YES | PARTIAL |
|
||||
| `answerMeaning.resolutionGuidance` | PARTIAL | NO | YES | YES |
|
||||
| `updatedNodes[].newValue` (child nodes) | YES | NO | YES | YES |
|
||||
| `updatedNodes[].newStatus` (non-parent) | PARTIAL | NO | YES | YES |
|
||||
| `updatedNodes[].reason` | YES (text) | NO | YES | PARTIAL |
|
||||
|
||||
Direction survives removal of parent terminal update via `userSupportedMeaning`, `possibleInference`, and child node updates. These are the legitimate channels for "launch is better" without closing the decision.
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 2 — What must be blocked
|
||||
|
||||
### Case A — Model proposes: decision → resolved, value = null
|
||||
- Block terminal status: **YES**
|
||||
- Direction preservable separately: **YES** (via `userSupportedMeaning` + `possibleInference`)
|
||||
- State B reachable: **YES**
|
||||
|
||||
### Case B — Model proposes: decision → known, value = "launch this year"
|
||||
- Block terminal status: **YES**
|
||||
- Direction preservable separately: **YES** (`userSupportedMeaning` can state same direction; child node values also survive). Critical note: `newValue` on unknown-status decision is semantically contradictory (see Checkpoint 6).
|
||||
- State B reachable: **YES**
|
||||
|
||||
### Case C — Model proposes: decision → resolved, value = "launch this year"
|
||||
- Block terminal status: **YES**
|
||||
- Direction preservable separately: **YES** (`userSupportedMeaning` + `possibleInference` carry direction; child updates survive)
|
||||
- State B reachable: **YES**
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 3 — Normalisation candidate
|
||||
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Deterministic guarantee | HIGH |
|
||||
| Proposal remains usable | YES |
|
||||
| Customer resolution preserved | YES |
|
||||
| Option updates preserved | YES |
|
||||
| Direction preservable | CONDITIONAL — survives in `answerMeaning` but NOT as newValue on unknown decision |
|
||||
| Retry required | NO |
|
||||
| State B reachable | YES |
|
||||
| Silent-intent-change risk | MEDIUM |
|
||||
| Principal weakness | Model's directional conclusion on parent is lost to downstream consumers that check parent newValue/status rather than answerMeaning. Direction only survives in text fields, not structural form. |
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 4 — Rejection candidate
|
||||
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Deterministic guarantee | HIGH |
|
||||
| Customer resolution lost | YES (entire proposal discarded) |
|
||||
| Retry required | YES |
|
||||
| Repeat-proposal risk | HIGH (60B.77 proved pattern is deterministic) |
|
||||
| State B reachable without retry | NO |
|
||||
| Semantic cleanliness | HIGH |
|
||||
| Principal weakness | Total loss of proposal work + high retry loop probability |
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 5 — Partial normalisation shape
|
||||
|
||||
Can reconciliation safely produce stripped shape (parent terminal removed, other updates preserved)?
|
||||
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Safe shape possible | CONDITIONAL — reconcileResolutionSemantics line 356 forces newStatus="resolved" for nodes in resolvedUnknownNodeIds. A dedicated pre-validation step needed before reconciliation. |
|
||||
| Validators accept | NO (current reconciler forces terminal) / UNPROVEN with modification |
|
||||
| selectedQuestion interference | UNPROVEN (depends on which question was selected) |
|
||||
| Bookkeeping consistent | UNPROVEN — depends on ordering: normalisation must fire BEFORE deterministic closure gate (line 3787) |
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 6 — Parent value semantics on unknown decision
|
||||
|
||||
**Choice: C — TECHNICALLY ACCEPTED BUT SEMANTICALLY UNSAFE**
|
||||
|
||||
The schema accepts any newValue regardless of status. `applyGraphUpdate` applies it unconditionally. But:
|
||||
- An unknown-status node with a non-null value conflates determination with incompleteness
|
||||
- No downstream code path was designed for this hybrid state
|
||||
- Propagation (line 777) ignores them for resolution counting
|
||||
- **Do NOT preserve direction on parent node.** Use `answerMeaning.userSupportedMeaning` and `possibleInference` instead.
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 7 — Enforcement location
|
||||
|
||||
### Boundary A — reconcileResolutionSemantics()
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Raw answer available | NO |
|
||||
| Graph available | YES |
|
||||
| Proposal mutable | YES |
|
||||
| Retry risk | LOW |
|
||||
| Separation | LOW (confounds policy with semantic cleanup) |
|
||||
| Semantic risk | MEDIUM (requires adding answer parameter — changes function signature) |
|
||||
| Principal weakness | No raw answer. Cannot detect confirmation absence without modifying function interface. |
|
||||
|
||||
### Boundary B — Post-reconciliation, pre-validation
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Raw answer available | YES |
|
||||
| Graph available | YES |
|
||||
| Proposal mutable | CONDITIONAL (after line 3549, before line 3552) |
|
||||
| Retry risk | LOW |
|
||||
| Separation | HIGH (dedicated boundary layer owns closure policy) |
|
||||
| Semantic risk | LOW |
|
||||
| Principal weakness | Adds pipeline step but gap exists naturally at line 3549-3552. **RECOMMENDED LOCATION.** |
|
||||
|
||||
### Boundary C — Compatibility validation
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Raw answer available | CONDITIONAL (not all validators receive it) |
|
||||
| Graph available | YES |
|
||||
| Proposal mutable | NO (rejection returns immediately) |
|
||||
| Retry risk | HIGH |
|
||||
| Separation | MEDIUM (blurs validation/policy boundary) |
|
||||
| Semantic risk | LOW |
|
||||
| Principal weakness | Rejects ALL work. Retry loop risk HIGH. |
|
||||
|
||||
### Boundary D — Post-validation, pre-mutation (inside applyValidatedProposal)
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Raw answer available | CONDITIONAL (available as local variable at line 3493) |
|
||||
| Graph available | YES |
|
||||
| Proposal mutable | YES (proposalSnapshot at line 3659) |
|
||||
| Retry risk | MEDIUM |
|
||||
| Separation | LOW (merges with existing gate at lines 3787-3851) |
|
||||
| Semantic risk | MEDIUM |
|
||||
| Principal weakness | Existing gate only ADDS closures; doesn't STRIP model-proposed ones. Adding strip logic here is consistent but conflates two responsibilities in one function. |
|
||||
|
||||
---
|
||||
|
||||
## Checkpoint 8 — Prompt alignment
|
||||
|
||||
**Prompt clarification required:** YES
|
||||
|
||||
**Conflicting rule:** Rule 143 (prompt-builder.js line 143):
|
||||
> "If the currently supported evidence is sufficient to distinguish the options and no such material unresolved factor remains, resolve the existing decision context."
|
||||
|
||||
This permits closure based on model judgment alone. Does NOT require user confirmation.
|
||||
|
||||
**Minimum semantic change:** Add explicit requirement that closure requires user confirmation matching deterministic gate criteria. Example:
|
||||
> "You may not resolve the decision context unless the user explicitly confirms (using their own words) that no other material uncertainty remains. If you judge evidence sufficient but user has not confirmed, state directional conclusion in possibleInference and recommend continuation question."
|
||||
|
||||
**Would prompt clarification alone be sufficient:** NO — 60B.78 confirmed stochastic compliance is insufficient when model closure pattern was proven deterministic (60B.77).
|
||||
|
||||
---
|
||||
|
||||
## Candidate enforcement models assessment
|
||||
|
||||
### Model A — PROMPT ONLY
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Prevents premature closure | NO |
|
||||
| Preserves proposal work | HIGH/LOW (stochastic) |
|
||||
| Preserves direction safely | PARTIAL |
|
||||
| Retry risk | MEDIUM |
|
||||
| State B reachable | STOCHASTIC |
|
||||
| Schema change | NO |
|
||||
| Principal weakness | Same fundamental problem as current state |
|
||||
|
||||
### Model B — REJECT WHOLE PROPOSAL
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Prevents premature closure | YES |
|
||||
| Preserves proposal work | LOW (total loss) |
|
||||
| Preserves direction safely | NO |
|
||||
| Retry risk | HIGH |
|
||||
| State B reachable | CONDITIONAL |
|
||||
| Schema change | NO |
|
||||
| Principal weakness | Total loss + high retry loop probability |
|
||||
|
||||
### Model C — NORMALISE TERMINAL PARENT UPDATE AWAY
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Prevents premature closure | YES |
|
||||
| Preserves proposal work | HIGH |
|
||||
| Preserves direction safely | PARTIAL (answerMeaning only) |
|
||||
| Retry risk | LOW |
|
||||
| State B reachable | YES |
|
||||
| Schema change | NO |
|
||||
| Principal weakness | Direction lost from parent node; survives only in text fields |
|
||||
|
||||
### Model D — NORMALISE STATUS BUT KEEP PARENT VALUE
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Prevents premature closure | YES |
|
||||
| Preserves proposal work | HIGH |
|
||||
| Preserves direction safely | NO (semantically contradictory, unhandled edge case) |
|
||||
| Retry risk | LOW |
|
||||
| State B reachable | YES |
|
||||
| Schema change | NO (creates unhandled edge case) |
|
||||
| Principal weakness | Hybrid unknown+value state no downstream code handles correctly |
|
||||
|
||||
### Model E — NORMALISE TERMINAL UPDATE AWAY, PRESERVE OTHER EVIDENCE
|
||||
| Criterion | Assessment |
|
||||
|-----------|-----------|
|
||||
| Prevents premature closure | YES |
|
||||
| Preserves proposal work | HIGH |
|
||||
| Preserves direction safely | PARTIAL (answerMeaning survives; parent node direction does not) |
|
||||
| Retry risk | LOW |
|
||||
| State B reachable | YES |
|
||||
| Schema change | NO |
|
||||
| Principal weakness | Direction only in text fields, not structural form on parent. Acceptable trade-off vs Model D's unhandled edge case or Model B's total loss. |
|
||||
|
||||
---
|
||||
|
||||
## Critical distinction
|
||||
|
||||
**Choice: E — CURRENT REPRESENTATION CANNOT PRESERVE DIRECTION SAFELY**
|
||||
|
||||
Why: On an unknown-status decision node, a non-null newValue is semantically contradictory (Checkpoint 6, Choice C). Schema accepts it technically but no downstream code path handles it correctly. Direction CAN survive in answerMeaning.userSupportedMeaning and possibleInference — these fields exist for carrying user intent independent of status. But this is PARTIAL preservation (textual, not structural on the parent).
|
||||
|
||||
**Practical consequence:** Model E is best available because it deterministically prevents premature closure while preserving direction in the canonical channel (answerMeaning) where current semantics safely permit it. State B remains reachable and no schema change needed.
|
||||
|
||||
---
|
||||
|
||||
## Minimum corrective boundary
|
||||
|
||||
**Choice: C — prompt clarification + dedicated pre-validation closure-ownership normalisation**
|
||||
|
||||
Why:
|
||||
1. Explicit confirmation remains authoritative (deterministic enforcement)
|
||||
2. Customer-factor resolution survives in preserved non-parent updates
|
||||
3. Unrelated proposal work preserved (Model E approach)
|
||||
4. No retry loop (application proceeds, State B fires naturally)
|
||||
5. State B reachable deterministically
|
||||
6. Parent lifecycle internally consistent (no hybrid states)
|
||||
7. Direction preserved only where current semantics safely permit it (answerMeaning)
|
||||
8. No schema change
|
||||
|
||||
**Would explicit confirmation remain authoritative:** YES
|
||||
**Would customer-factor resolution survive:** YES
|
||||
**Would State B remain reachable:** YES
|
||||
**Would retry loops be avoided:** YES
|
||||
**Would schema remain unchanged:** YES
|
||||
|
||||
---
|
||||
|
||||
## Implementation readiness
|
||||
|
||||
**Choice: A — READY FOR BOUNDED IMPLEMENTATION**
|
||||
|
||||
One unresolved question: Boundary B (dedicated pre-validation function) vs Boundary D (extend existing gate). Boundary D is more tightly coupled but less architecturally clean. **Recommendation: Boundary B** — `reconcileDecisionClosureOwnership(graph, proposal, answer)` between reconciliation (line 3549) and validation (line 3552).
|
||||
|
||||
Smallest implementation boundary: One new function + one prompt rule change. No schema changes.
|
||||
|
||||
Reference in New Issue
Block a user