Feature/product platform foundation v0.62 #1

Merged
robbond merged 683 commits from feature/product-platform-foundation-v0.62 into feature/emergent-unknowns-v0.5 2026-09-09 07:58:20 +01:00
2 changed files with 92 additions and 0 deletions
Showing only changes of commit 870d325d08 - Show all commits
+8
View File
@@ -209,6 +209,14 @@ Experiment 54N tested whether an interpretation disagreement can be judged for m
- Generic non-proposition decision unknowns remain on their existing path when no explicit `Whether...` proposition is present.
- **Still unproven live:** the exact 60B.31 live-shaped customer-signing case through the full end-to-end runtime path on this branch.
### 60B.36 customer-signing follow-up fixture
- Added deterministic reusable fixture `tests/fixtures/pre-anchored-product-launch-customer-signing.json` derived from `tests/fixtures/pre-anchored-product-launch-options.json`.
- Preserved `n_product_launch_decision`, `opt_launch_this_year`, and `opt_wait_twelve_months` unchanged; added one unresolved customer unknown `n_enterprise_customer_signing` only.
- Linked the customer unknown to `opt_launch_this_year` using existing `contained_in` structure; set `graph.activeUnknownNodeId` to the customer node and stored the deterministic selected question text for the next-turn follow-up.
- Deterministic harness validation passed via `npx vitest run tests/reproduce-multi-turn-investigation.harness.test.js` (`64/64`).
- This apparatus now enables the next bounded live experiment: answering the existing customer-signing unknown directly and verifying in-place update plus correct decision-state transition without factor duplication or unrelated uncertainty reopening.
### When This Knowledge-Management Phase Is Complete
Provisional criteria for review (all confirmed met by Experiment 38 cold-start test):
+84
View File
@@ -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.