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

Experiment 57J.86 — Smallest Recovery Contract for Null Semantic/Action with Good Mutation (Read-Only Design)

Branch: feature/semantic-action-contract-v0.23 Starting HEAD: a40a3e3 (experiment: diagnose null semantic mutation path)

Objective

Answer exactly:

What is the smallest recovery contract that lets the engine preserve a good mutation while recovering missing semantic/action declarations, without regenerating or discarding the mutation?

Read-only architecture design. No code changes. No Ollama calls. No live API calls.

Context Files Read

1. docs/current-handoff.md (handoff state through 57J.85)
2. docs/experiment-57j85.md (transition compatibility diagnosis)
3. lib/graph/schema.js (schema truth for answerMeaning, structuralActionRequired, graphUpdateSchema)
4. lib/graph/utils.js (validator logic at line 868+)
5. lib/graph/apply-proposal.js (validation/parsing section: lines 2937–3146; applyValidatedProposal entry at 3182)
6. lib/graph/orchestrator.js (proposal rejection path and diagnostics snapshot construction)
7. app/api/cases/update/route.js (production API boundary — no retry/repair logic)

---

1 — Separate the Two Missing Declarations

A. structuralActionRequired

Can deterministic code recover it from proposal structure alone?

PARTIAL — YES for the true direction only.

Test: hasMeaningfulChange=true → structuralActionRequired=true

From lib/graph/utils.js lines 878–883:

const hasMeaningfulChange =
  update.addedNodes.length > 0 ||
  statusChanged ||
  valueChanged ||
  update.addedEdges.length > 0 ||
  update.removedEdgeIds.length > 0;

If hasMeaningfulChange=true, then at least one of these conditions holds:

• addedNodes.length > 0 (new nodes were added)
• statusChanged (at least one node's status was changed)
• valueChanged (at least one node's value was changed)
• addedEdges.length > 0 (new edges were added)
• removedEdgeIds.length > 0 (edges were removed)

Each of these is by definition a structural action. The model declared that it intended to act (via the mutation itself). Setting structuralActionRequired=true when hasMeaningfulChange=true is a deterministic mapping from "mutation present" → "action was required."

No semantic inference is needed. This is purely structural: if nodes/edges were added or changed, structural action occurred.

Would doing so preserve the original meaning of structuralActionRequired as a model declaration, or would it change the field into an engine-derived fact?

CHANGES FIELD SEMANTICS.

structuralActionRequired was designed as a model declaration — the model telling the engine "I know I must act structurally." Deriving it from mutation presence converts it to an engine-inferred fact. The semantic shift is:

• Before (declaration): "The model consciously chose to declare action is required"
• After (inference): "There was structural change, therefore action must have been needed"

The practical effect for this experiment's scope is identical (action flows forward either way). But the contract semantics shift from declaration → inference. The field no longer reflects model intent; it reflects engine observation.

This matters for future contract work because:

• A model declaring structuralActionRequired=false with mutation would still be a contradiction (rule 3 checks structuralActionRequired===false)
• An engine-derived structuralActionRequired=true from mutation cannot be "wrong" — it is tautologically true by definition of the mutation

B. answerMeaning

Can existing structured mutation fields recover userSupportedMeaning, supportCategory, resolutionGuidance?

NOT RECOVERABLE.

Reasoning:

• userSupportedMeaning is the model's semantic interpretation of the raw user answer — a natural language summary of what the user established. No graph field captures this.
• supportCategory classifies the reasoning pattern (relative_priority_only, conditional_tradeoff, uncertain, explicit_hard_constraint, other). This requires understanding the raw answer text, not just the structural result.
• resolutionGuidance (must_remain_unresolved, may_resolve, must_resolve) is a judgment about what downstream processing should do — a control signal, not derivable from mutation shape.

The mutation arrays (addedNodes, updatedNodes, addedEdges) capture WHAT was done to the graph but not WHY or WHAT THE USER ESTABLISHED. The same mutation shape (new reported_claim node) could result from radically different answer meanings (explicit fact vs. estimate vs. uncertainty). There is no deterministic mapping from mutation structure back to semantic intent.

---

2 — Existing Recovery Capabilities

Can validator mutate/repair proposal: NO

validateGraphUpdate (utils.js line 868) returns { valid, errors } only. It has no side effects on the input proposal and no repair logic.

Can validator preserve rejected proposal and continue: PARTIAL

The orchestrator captures a rejectedProposalSnapshot (orchestrator.js lines 693–725) for diagnostics when rejection occurs at proposal_compatibility. This is write-only diagnostic evidence — it does not feed back into any repair mechanism.

Can orchestrator issue a bounded repair call: NO

The orchestrator flow (orchestrator.js lines 620–800) is strictly linear:

1. Build prompt → model call
2. Parse proposal (Zod + normalisation)
3. Apply validated proposal → direct graph mutation
4. Return success or error

There is no retry, repair, or secondary call path. On rejection at proposal_compatibility, the orchestrator returns an error with diagnostic snapshot and terminates.

Can existing code call the model again with the original proposal attached: NO

No mechanism exists to re-invoke the model with any proposal content. The raw response is parsed once and never retained after parsing. No prompt-building path accepts a previous proposal as context.

Can a repaired proposal reuse the exact original mutation arrays: REQUIRES NEW PATH

Currently, rejected proposals are discarded. Only a diagnostic snapshot (subset of fields) survives. To preserve and reuse the exact mutation arrays through repair would require new plumbing: retention of parsed proposal past rejection, plus a repair call path that accepts mutation-arrays-as-immutable-context.

---

3 — Compare Four Recovery Designs

Option A — deterministic action-field fill only

When hasMeaningfulChange=true and structuralActionRequired=null, engine sets structuralActionRequired=true. Leaves answerMeaning unchanged (null).

Criterion	Answer
preserves useful original mutation	YES
requires new LLM call	NO
can change graph mutation	NO — only fills one boolean field on the proposal; mutation arrays untouched
requires English keyword inference	NO
retains semantic accountability	PARTIAL — recovers structural accountability (action = required, inferred from mutation); leaves answerMeaning unaccountable (null)
new failure surface	LOW — deterministic fill cannot produce incorrect values. If hasMeaningfulChange=true, structuralActionRequired MUST be true by definition. No hallucination risk.

Option B — one bounded declaration-only repair call

Preserve original mutation arrays exactly. Ask model to populate only:

• answerMeaning (userSupportedMeaning, supportCategory, resolutionGuidance)
• structuralActionRequired

Forbidden from changing addedNodes, updatedNodes, resolvedUnknownNodeIds, addedEdges, removedEdgeIds.

Criterion	Answer
preserves useful original mutation	YES — mutation arrays are passed as immutable context to the repair call
requires new LLM call	YES — one additional bounded call
can change graph mutation	NO — forbidden by contract boundary of the repair call
requires English keyword inference	NO — repair receives raw answer text + original proposal; must produce structured semantics, not derive from keywords
retains semantic accountability	FULL — all three missing fields (answerMeaning + structuralActionRequired) are recovered through model declaration, not engine inference
new failure surface	MEDIUM — second LLM call introduces latency/cost variance; repair prompt must be carefully constrained to prevent mutation drift

Option C — full proposal regeneration

Reject original proposal. Ask model to regenerate everything from raw answer + graph state.

Criterion	Answer
preserves useful original mutation	NO — entirely discarded; new mutation may differ materially
requires new LLM call	YES
can change graph mutation	YES — full regeneration allows different nodes, edges, values
requires English keyword inference	NO — but introduces cold-start variance across two generations from same input
retains semantic accountability	FULL — regenerated proposal is fully accountable (model produces fresh declarations for everything)
new failure surface	HIGH — double the cost; double the variance; original good data is lost

Option D — keep transition compatibility unchanged

No repair architecture. Accept null/null + mutation as-is.

Criterion	Answer
preserves useful original mutation	YES — current path accepts it
requires new LLM call	NO
can change graph mutation	NO
requires English keyword inference	NO
retains semantic accountability	NONE — no semantic declarations, no action declaration. The graph records what happened but not why or what the user meant.
new failure surface	LOW — no new code; existing path already exercised

---

4 — 57J.84 Walkthrough

Apply each option to the exact 57J.84 shape:

answerMeaning = null
structuralActionRequired = null
addedNodes = [n_lease_savings_claim (reported_claim, £2M/year)]
addedEdges = [supports edge → n_savings_realism]
existing uncertainty preserved (n_savings_realism)

Option A: PRESERVED

Engine sees hasMeaningfulChange=true (new node + new edge). Sets structuralActionRequired=true deterministically. Mutation arrays pass through unchanged. answerMeaning remains null but mutation is preserved.

Option B: PRESERVED

Repair call receives original mutation arrays as immutable context. Produces answerMeaning with userSupportedMeaning ("User claims £2M/year savings from lease elimination, remaining uncertain about realism"), supportCategory="other", resolutionGuidance="may_resolve". structuralActionRequired=true. Mutation preserved exactly.

Option C: REGENERATED

Original mutation discarded. New proposal generated — might produce different node IDs, slightly different label/description for the claim, potentially different edge relationships. £2m information survives only if model regenerates it faithfully.

Option D: ACCEPTED UNCHANGED

Proposal accepted as-is through transition compatibility path. Mutation applied. answerMeaning=null and structuralActionRequired=null persist on the graph with no recovery.

---

5 — Repair-Call Ownership

If option B is chosen, the narrowest possible contract:

Should repair be allowed to reconsider semantic meaning? YES

The entire purpose of the repair call is to recover meaning declarations. It must produce userSupportedMeaning, supportCategory, and resolutionGuidance.

Should repair be allowed to alter mutation arrays? NO

Mutation integrity is the core invariant. The repair call must treat addedNodes/updatedNodes/addedEdges as frozen input context. Only semantic/action fields may be populated or changed.

Should repair be allowed to alter selectedQuestion? NO

selectedQuestion is derived from the mutation (nodeId references an unresolved unknown created or preserved by the mutation). Altering it would create a mismatch with the frozen mutation. Keep as-is.

Should repair receive raw user answer? YES

answerMeaning fields require understanding of the raw answer text. The repair call cannot produce userSupportedMeaning without the source material.

Should repair receive original proposal? YES

The repair call needs to see the original mutation arrays (as frozen context) and any existing non-null fields (to avoid overwriting). It must know what was already produced.

---

6 — Call-Budget Consequence

Repair classification: SECOND-STAGE REPAIR

This is not a RETRY (retry implies failure + repetition of the same operation). This is not a NORMAL SECOND MODEL CALL (implies independent decision-making). This is a repair: it operates on an accepted-but-incomplete primary proposal, adding missing declarations without regenerating.

Can existing call accounting distinguish primary vs repair calls? NO

Current call accounting tracks startCalls and updateCalls. There is no distinction between primary proposals and repair sub-calls within those counts. A bounded repair would be invisible to current accounting unless classified as either start or update.

Requires tooling change: YES — for complete distinction, but minimal.

Existing accounting can approximate the distinction by noting that repairs only occur on proposal_compatibility rejections (as opposed to proposal_validation, provider, or application failures). No new counters needed if using stage-diagnosis as proxy. But clean separation would require a call type field.

---

7 — Chose the Smallest Next Boundary

Choice: B — DECLARATION-ONLY REPAIR CALL

Why: Option A (deterministic action fill) solves only half the problem (structuralActionRequired) and changes field semantics from declaration to inference. Option C (full regeneration) discards the entire point of this experiment (preserving good mutation). Option D (keep transition path) accepts the gap indefinitely without resolving it.

Option B is the smallest design that:

1. Preserves the exact original mutation (no regeneration, no discard)
2. Recovers ALL missing fields (not just structuralActionRequired)
3. Retains declaration semantics (model still produces the declarations)
4. Is bounded (one call, forbidden from changing mutations)
5. Solves the 57J.84 case fully (both meaning and action recovered)

The trade-off: one additional LLM call per affected proposal vs. semantic accountability gap. This trade-off is justified by the volume of proposals flowing through the null/null/mutation path (confirmed in 57J.84 as the dominant pattern for "implicit meaning through structure" cases).

---

8 — Non-Negotiable Invariants

For option B (declaration-only repair call):

original useful mutation preserved: YES
no keyword/synonym logic: YES
no mutation regeneration: YES
bounded additional model calls: 1
provider-agnostic: YES
57J.84 information would survive: YES

---

Chosen Boundary Summary

The smallest recovery contract that preserves good mutation while recovering missing declarations is a bounded second-stage repair call that receives the raw answer and original proposal as context, produces only answerMeaning and structuralActionRequired fields, and is forbidden from touching any mutation arrays. This converts a null/null/mutation acceptance (57J.84) into a fully declared proposal with zero mutation change.