docs: record customer signing followup fixture

2026-08-14 08:02:45 +01:00
parent 89551c5e8c
commit 870d325d08
2 changed files with 92 additions and 0 deletions
@@ -0,0 +1,84 @@
+# Experiment 60B.36 — Customer-signing follow-up fixture
+
+**Date:** 2026-08-14
+
+## Purpose
+
+Create a deterministic reusable pre-anchored fixture representing the confirmed product-launch graph state immediately before the user answers the material customer-signing follow-up question. This avoids recreating the state stochastically in the next live experiment.
+
+## Why the fixture was needed
+
+60B.35 closed the runtime question-formulation discrepancy. The next bounded behavioural check is no longer about wording. It is whether a direct user answer to the existing customer-signing unknown updates that unknown in place, transitions decision state correctly, and does so without duplicating the factor or reopening unrelated uncertainty.
+
+To test that deterministically, the next experiment needs a reusable starting state that already contains:
+
+- the existing product-launch decision
+- both existing options
+- the unresolved customer-signing factor already present in the graph
+- that customer factor marked as the active follow-up target
+
+## Source / base fixture
+
+- Base fixture: `tests/fixtures/pre-anchored-product-launch-options.json`
+- New fixture: `tests/fixtures/pre-anchored-product-launch-customer-signing.json`
+
+The new fixture preserves the existing decision and both existing option node IDs exactly as they appear in the base fixture.
+
+## Exact added customer unknown
+
+- **ID:** `n_enterprise_customer_signing`
+- **Label:** `Prospective enterprise customer signing status`
+- **Description:** `Unknown whether one prospective enterprise customer will sign if we launch this year, because they account for approximately £700,000 of the £1.2 million expected annual revenue.`
+- **Kind:** `unknown`
+- **Status:** `unknown`
+
+No other new unknowns were introduced.
+
+## Structural linkage
+
+The fixture uses an existing repository relationship type only:
+
+- `n_enterprise_customer_signing -> opt_launch_this_year`
+- relationship: `contained_in`
+
+This keeps the customer-signing uncertainty structurally attached to the existing product-launch decision context through the launch-this-year option without inventing a new edge type or duplicating any decision/option nodes.
+
+## Active target / selected question
+
+The fixture records the customer-signing node as the next unresolved target via:
+
+- `graph.activeUnknownNodeId = "n_enterprise_customer_signing"`
+
+The fixture also stores the deterministic selected question text:
+
+- `What evidence would clarify whether one prospective enterprise customer will sign if we launch this year?`
+
+## Validation
+
+Validation used the existing deterministic harness route only. No Ollama calls and no live API calls were made.
+
+Command run:
+
+```bash
+npx vitest run tests/reproduce-multi-turn-investigation.harness.test.js
+```
+
+Result:
+
+- PASS — `64/64` tests
+
+The added fixture-specific assertions confirm:
+
+- fixture parses
+- graph validates
+- decision identity preserved
+- both option identities preserved
+- customer unknown present exactly once
+- customer unknown unresolved
+- decision unresolved
+- no duplicate nodes
+- customer unknown is represented as the active target
+
+## Next live question now enabled
+
+The next bounded live experiment can now start directly from the confirmed pre-answer graph state and test whether answering the customer-signing question updates the existing unknown in place, drives the correct decision-state transition, and avoids duplicating or broadening uncertainty.