experiment: confirm live confirmation-gated state b path

This commit is contained in:
2026-08-15 12:27:08 +01:00
parent 357be25de5
commit abc01b181f
2 changed files with 71 additions and 0 deletions
+23
View File
@@ -4349,3 +4349,26 @@ Why:
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.
---
### Experiment 60B.81 — Live Confirmation-Gated State B Path Confirmed (2026-08-15)
**Type:** Bounded live observation (1 update call, production route)
**Input:** No-confirmation answer: *"The enterprise customer has now confirmed in writing that they will not sign if we launch this year, so the £700,000 of expected annual revenue from them will not be received."*
**Classification: A — LIVE CONFIRMATION-GATED STATE B PATH CONFIRMED**
Observed:
- Customer resolved ("Will not sign")
- Decision remains non-terminal (status=unknown, value=null)
- Decision remains active target (finalActiveUnknownNodeId = n_product_launch_decision)
- Focused sufficiency question fires: *"Is there anything else material that could change which option is better?"*
- decision_threshold_sufficiency_confirmation template selected
- No spurious uncertainty introduced
- Enforces the confirmation-gated closure boundary from 60B.80 in live production code
What this proves: The deterministic stripping gate from 60B.80 prevents premature model-led terminal closure of parent decisions when no explicit sufficiency confirmation is present, and allows State B to fire naturally through the existing questioning path.
**Doc:** docs/experiment-60b81.md
+48
View File
@@ -0,0 +1,48 @@
# Experiment 60B.81 — Live Confirmation-Gated State B Path Confirmed
**Date:** 2026-08-15
**Branch:** `feature/decision-closure-ownership-v0.47`
**Preceded by:** Experiment 60B.80 (deterministic confirmation-gated closure enforcement implemented)
**Type:** Bounded live observation — single update call
## Objective
Answer: Does the exact no-confirmation live case now stay open and ask the sufficiency question?
This is the remaining proof after 60B.80 committed deterministic stripping. The model-led terminal closure bug from 60B.74/60B.76 should be fully eliminated.
## Method
- **Fixture:** `tests/fixtures/pre-anchored-product-launch-customer-signing.json`
- **Input:** `"The enterprise customer has now confirmed in writing that they will not sign if we launch this year, so the £700,000 of expected annual revenue from them will not be received."`
- **Crucially absent:** any phrase equivalent to "no other material uncertainty" / "nothing else remains uncertain"
- **Mode:** updateOnly (1 update call via production HTTP route)
## Result
**Classification: A — LIVE CONFIRMATION-GATED STATE B PATH CONFIRMED**
### Observed
| Field | Value |
|-------|-------|
| Customer status | resolved |
| Customer value | "Will not sign" |
| Decision status | unknown (non-terminal) |
| Decision value | null |
| resolvedUnknownNodeIds | ["n_enterprise_customer_signing"] (decision NOT present) |
| finalActiveUnknownNodeId | n_product_launch_decision |
| selectedQuestionTemplate | decision_threshold_sufficiency_confirmation |
| Question text | "Is there anything else material that could change which option is better?" |
### What This Proves
1. The 60B.80 stripping gate prevents premature model-led terminal closure of the parent decision when no explicit sufficiency confirmation is present in the user's answer.
2. State B fires naturally: focused sufficiency confirmation/discovery question targeting n_product_launch_decision.
3. Customer resolution with negative "will not sign" meaning is preserved independently — non-parent work survives the strip.
4. No spurious structural uncertainty was introduced.
### What Remains Unproven by This Run
- Raw model closure intent (whether the model itself proposed terminal status or whether the strip caught it). The harness exposes post-reconciliation/applied proposal only. Classification is "ENFORCEMENT EFFECT OBSERVED" rather than raw compliance.
- Explicit confirmation path still works through the gate (covered in 60B.80 unit tests but not live-tested here).