# 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.