confidence-engine/docs/experiment-57j74.md

Experiment 57J.74 — Pre-Anchored Update-Only Fixtures and Harness

Branch: feature/semantic-action-contract-v0.23 Starting HEAD: beef434 (tooling: capture structural action declaration in live harness) Experiment commit: pending (docs: record pre-anchored update apparatus)

Objective

Answer exactly:

Does a deterministic pre-existing graph fixture + update-only harness mode exist that allows direct testing of the false + no meaningful mutation → accepted branch without requiring Update 1 to establish an anchor?

This resolves the self-defeating constraint from 57J.73 (Classification G), where Answer 2 was unreachable because Update 1 failed to produce mutation and triggered contract rejection — making it impossible to test whether the model produces false + no-op on a graph that already contains the savings-realism anchor.

Problem Statement

The v0.23 harness only supports start → update(n) chains. There is no mechanism to inject an arbitrary pre-anchored situationGraph directly into the Update API without first running Start. This means:

1. Update 2 can never receive a graph where the savings-realism anchor already exists from Answer 1's perspective, because Answer 1 fails at proposal_compatibility when it declares structuralActionRequired=true but produces zero mutation.
2. Even if Update 1 were to succeed (e.g., with Start producing a pre-populated anchor), there is no harness mechanism to inject that graph for the next update's input without actually sending an answer.
3. Testing the false + no-op branch requires starting from a known anchored state — but only start → update chains are supported.

Hypothesis

If a deterministic pre-existing graph fixture (with a dedicated savings-realism unknown) can be injected directly into the Update request as an arbitrary situationGraph, and the harness can report structuralActionRequired=false + zero meaningful mutation when updating with Answer 2's input on that anchored graph, then:

false + no meaningful mutation → accepted

can be tested without relying on Update 1's success.

Tooling Changes

Fixture: tests/fixtures/pre-anchored-update-savings-realism.json

A deterministic situationGraph representing the state after Answer 1 has been processed:

{
  "centralStatement": "We are considering relocating the engineering team to reduce operating costs.",
  "nodes": [
    {
      "id": "n_relocation_state",
      "kind": "state",
      "status": "provisional",
      "label": "Engineering team relocation consideration"
    },
    {
      "id": "n_savings_realism",
      "kind": "unknown",
      "status": "unknown",
      "label": "Are the projected office savings from relocation realistic?"
    }
  ],
  "edges": [
    { "fromNodeId": "n_savings_realism", "toNodeId": "n_relocation_state", "relationship": "depends_on" }
  ],
  "activeUnknownNodeId": "n_savings_realism",
  "resolvedNodeIds": []
}

Contains exactly one unresolved savings-realism anchor (kind=unknown, status=unknown).

Harness: runPreAnchoredSimulation() in test file

A new synchronous simulator that mirrors what the harness does when supplied an arbitrary pre-anchored graph:

• No Start call — graph is supplied directly via initialGraph or defaults to the fixture
• Verifies fixture integrity before proceeding (exactly one savings-realism unknown)
• Sends the exact fixture graph into the Update request body
• Reports: node count, edge count, structuralActionRequired, answerMeaning fields, proposal mutations, selectedQuestion
• Call accounting reflects 0 start + 1 update

Inlined fixture constant: PRE_ANCHORED_FIXTURE

The JSON fixture is also inlined as a JS constant in the test file so all tests can access it without filesystem reads.

Harness Tests Added (10)

#	Test	Asserts
1	pre-anchored fixture contains exactly one savings-realism anchor	savingsNodes.length === 1, id === "n_savings_realism"
2	fixture uses valid existing graph shape	All node/edge fields present with valid enum values
3	fixture contains a valid relationship into the graph	Edge exists, from/to nodes exist, relationship === "depends_on"
4	pre-anchored update-only mode sends exact fixture graph into real update request shape	node count = 2, edge count = 1, ids match fixture
5	pre-anchored update-only mode does not call Start	startCalls === 0, updateCalls === 1
6	pre-anchored update-only mode makes exactly one Update call	type === "all_success", exitCode = 0
7	normal Start→Update harness mode remains unchanged	startCalls === 1, updateCalls === 1 via existing patterns
8	57J.62 accepted/rejected capture hardening remains unchanged	addedNodes/updatedNodes/resolvedUnknownNodeIds captured on acceptance; rejection snapshot intact
9	57J.72 structuralActionRequired direct capture remains unchanged	true/false/null reports work correctly via existing patterns
10	no retries/additional calls introduced in pre-anchored mode	totalCalls === 1, zero retry entries

Results

All 39 tests pass. The pre-anchored fixture is valid, the update-only apparatus makes exactly one Update call with no Start, the exact fixture graph is sent, and all existing harness behaviour (57J.62 capture hardening, 57J.72 structuralActionRequired capture, normal start→update mode) remains unchanged.

Classification: A — HARNESS-ONLY FIX VALIDATED

The pre-anchored update-only apparatus successfully decouples Update testing from the Start pipeline for anchor establishment. The fixture is deterministic and valid per the existing graph schema. The harness helper reports all necessary fields with zero Ollama calls, zero production code changes, and zero API calls beyond the single Update request.

What this enables (but does not prove)

This enables testing false + no meaningful mutation → accepted by injecting a pre-anchored graph as the Update input. It does not itself prove that the live model will produce that outcome — only that the harness can now reach that test scenario without requiring Update 1's success. The next step is a live update-only experiment: inject the fixture, send Answer 2, observe whether the model produces structuralActionRequired = false with zero mutation.

What remains unproven

1. Whether the live model, given this pre-anchored graph and Answer 2 input, declares false + no meaningful mutation
2. Whether the live update accepts that as an intentional no-op (vs. rejecting it)
3. Whether a different pre-anchored graph with additional anchors would produce different results

Production code changed: NO

Harness restored: YES

Scenario, answers, and maxUpdates in scripts/reproduce-multi-turn-investigation.mjs are at canonical defaults.

Ollama calls beyond harness count: 0

Dev server disturbed: NO