84 lines
3.4 KiB
Markdown
84 lines
3.4 KiB
Markdown
# 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. |