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:

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.

3.4 KiB Raw Blame History