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

Experiment 57J.69 — structuralActionRequired Live Population and Contract Enforcement

Branch: feature/semantic-action-contract-v0.23 Starting HEAD: 1b3bbd5 (experiment: record structural action contract implementation) Parent design experiment: 57J.68 (bounded implementation complete — schema, validator, prompt, tests)

Objective

Answer exactly:

For the fixed savings-realism uncertainty case, does the live model populate structuralActionRequired, and does the resulting proposal satisfy the new strict declaration-to-mutation contract?

Fixed scenario

We are considering relocating the engineering team to reduce operating costs.

Fixed answer

I am unsure whether the projected office savings from the relocation are realistic.

Hypothesis

For this answer, the model should explicitly declare structuralActionRequired = true if the savings-realism uncertainty is not already fully represented in the graph. If true, the proposal must contain meaningful graph mutation.

Call accounting

Metric	Value
startCalls	1
updateCalls	1
totalCalls	2

Retries: 0 Supplementary scripts: NO

START

• HTTP: 200
• Stage: unknown
• Nodes: 5
• Edges: 3
• Selected question: "What evidence would confirm or rule out current location, target location, team size, collaboration dependencies, and productivity impact?"
• Relevant unresolved unknowns: (graph contains state/uncertainty nodes only from fresh start — no pre-existing savings-realism node)

UPDATE 1

• HTTP: 422
• Stage: proposal_compatibility
• First error: "structuralActionRequired is true but proposal contains no graph mutation" + "answerMeaning.userSupportedMeaning is populated, but the proposal contains no graph mutation. answerMeaning alone does not constitute graph progress."

Answer meaning fields

Field	Value
userSupportedMeaning	"User is unsure whether the projected office savings from the relocation are realistic."
possibleInference	"If the savings projections are overestimated, the net financial benefit of relocating the engineering team may be negligible or negative."
supportCategory	"uncertain"
resolutionGuidance	null

structuralActionRequired

true (declared by model)

Proposal content (rejected snapshot)

{
  "updatedNodes": [{ "nodeId": "nqx00rq", "newValue": null }],
  "resolvedUnknownNodeIds": [],
  "addedNodes": [],
  "addedEdges": []
}

• selectedQuestion: null (rejected before question selection)

Meaningful mutation check

updatedNodes contains only [{nodeId: "nqx00rq", newValue: null}] — a null assignment to an existing node. addedNodes and addedEdges are empty. resolvedUnknownNodeIds is empty.

Using production hasMeaningfulChange semantics, this evaluates to NO MEANINGFUL MUTATION (the only structural change is a null set on an existing node, which does not create or alter graph topology).

Contract state

structuralActionRequired	meaningful mutation	Contract classification
true	absent	CONTRACT TRUE + NO MUTATION

Structural identity

UNAVAILABLE — no mutation occurred.

Classification: C — TRUE/NO-MUTATION CONTRADICTION

The model declared structuralActionRequired = true but produced a proposal with no meaningful graph mutation. The validator correctly rejected this at proposal_compatibility stage (HTTP 422).

Why

The configured model (qwen-claude:latest) recognized that the savings-realism uncertainty warranted structural action and set structuralActionRequired = true. However, instead of creating a dedicated unknown node for the savings-realism concern, it produced only a null-set on an existing node — structurally inert. This is the same class of proposal failure observed in Experiment 57J.61 (meaning extracted but zero mutation proposed) and Experiment 57J.63 (same rejection pattern).

The validator's new structuralActionRequired contract check fired first (it appears before the legacy userSupportedMeaning guard in evaluation order), producing the dual rejection message:

1. "structuralActionRequired is true but proposal contains no graph mutation" — new v0.23 contract rule
2. "answerMeaning.userSupportedMeaning is populated, but the proposal contains no graph mutation" — legacy guard

Both errors express the same fundamental violation: model declared action needed but didn't deliver structural change.

Did model populate structuralActionRequired: YES

The field was present and set to true.

Did declaration match proposal shape: NO

structuralActionRequired = true contradicts the zero-mutation proposal content.

Did validator enforce the strict contract: YES

The validator rejected at proposal_compatibility with specific dual error messages covering both the new contract rule and the legacy guard, preventing any graph mutation from being applied.

What this establishes:

1. The structuralActionRequired field IS populated by the live model for savings-realism uncertainty.
2. The v0.23 validator ENFORCES the strict declaration-to-mutation contract — a true declaration with zero mutation is rejected.
3. The new contract rejection fires at the correct stage (proposal_compatibility) before any graph mutation occurs.
4. The dual-error output (new + legacy) works correctly: both guards agree on the violation.

What this does NOT prove:

1. Whether structuralActionRequired = true is semantically correct for this answer — the validator tests contract consistency, not semantic truth of the boolean choice.
2. Whether the model could produce a correct true+mutation proposal in a subsequent retry (retries are forbidden).
3. Stability across repeated runs with this scenario/answer pair.
4. That Update 2 would proceed differently if Update 1 had succeeded.
5. Whether cold-start node count variance (5 nodes) affects the model's ability to commit to structural action.

What this reveals about the remaining gap:

The model knows it should act structurally (structuralActionRequired = true) but fails to produce the actual graph mutation in a single attempt. This is the same prompt-enforcement gap identified in 57J.64 — the model owns the structural action decision, and when it chooses true, code rejects the no-op without providing a bounded repair path. The production-only path (no regeneration/retry) means this remains an unresolved capability gap.

---

Ollama calls beyond harness count: 0 Dev server disturbed: NO Production code changed: NO Prompt changed during experiment: NO Canonical harness restored: YES 57J.62 capture hardening preserved: YES (rejectedProposalSnapshot captured correctly) Hardened no-retry behaviour preserved: YES