docs: checkpoint return to Confidence Engine origin

test(harness): preserve null-question start captures
experiment: compare model and deterministic investigation selection
2026-08-18 08:33:05 +01:00 · 2026-08-18 07:11:27 +01:00 · 2026-08-18 07:00:39 +01:00 · 2026-08-18 06:48:40 +01:00 · 2026-08-18 06:32:40 +01:00 · 2026-08-17 18:25:40 +01:00
386 changed files with 119069 additions and 217 deletions
@@ -0,0 +1,77 @@
+# Architecture Guardrails
+
+## Hard boundary for UX tasks
+
+When a task is described as UI, UX, layout, styling, loading feedback or
+presentation work, do not modify:
+
+- reasoning algorithms;
+- unknown selection;
+- reasoning-pattern selection;
+- question formulation;
+- atomicity or answerability assessment;
+- graph mutation;
+- graph schemas;
+- API request or response contracts;
+- reconstruction prompts;
+- provider configuration;
+- confidence propagation;
+- compatibility validation.
+
+If a UX request appears to require one of those changes, stop and report the
+dependency rather than changing it silently.
+
+## Reasoning invariants
+
+Preserve these invariants:
+
+- The LLM proposes information; deterministic code owns graph mutation.
+- Every user-facing question comes from an explicit unresolved graph node.
+- Questions contain one primary concept and seek one coherent answer.
+- Unknowns must be atomic or decomposed.
+- Atomic wording alone is insufficient; a selected unknown must be independently
+  answerable.
+- Question family must match the active reasoning pattern.
+- Active investigation nodes must be compatible with the reasoning pattern.
+- Relationship classification cannot outrun comparability assessment.
+- Ambiguity remains explicit rather than being resolved alphabetically.
+- Parent unknowns do not resolve before their completion rule is satisfied.
+- Confidence must not outrun evidence or completeness.
+- Duplicate evidence must not increase confidence.
+- Conflicting evidence caps conclusion confidence.
+- A successful update must rerun deterministic next-question selection when
+  eligible unknowns remain.
+- No question is preferable to an unjustified question.
+
+## Current architecture, simplified
+
+Scenario
+→ reconstruction
+→ situation graph
+→ unknown selection
+→ atomicity
+→ answerability
+→ reasoning pattern
+→ investigation strategy
+→ question family
+→ question formulation
+→ complexity validation
+→ user answer
+→ proposed graph update
+→ deterministic validation/application
+→ propagation
+→ confidence/completeness update
+→ next unknown
+
+## Compatibility discipline
+
+Do not expand schemas merely because a model emits a synonym.
+
+Prefer:
+
+1. identify the source;
+2. determine whether it is a synonym;
+3. normalise deterministically when justified;
+4. retain strict validation.
+
+Do not weaken validation globally to fix a single malformed response.
@@ -0,0 +1,110 @@
+# Project Context
+
+> **Start every resumed session with `docs/current-handoff.md`, then read `docs/current-project-state.md` and choose the relevant pack from `docs/task-context-packs.md`.** Use `docs/project-knowledge-inventory.md` to locate task-specific or historical context. Do not read the full design-evolution log unless a named experiment is required. Do not load `docs/archive/` by default; use `docs/archive/README.md` to locate historical evidence when specifically required.
+
+## What the Confidence Engine is
+
+The Confidence Engine is a structured reasoning tool intended to help people
+decide whether they have enough justified confidence to act.
+
+It does not simply answer the user's original question.
+
+It:
+
+1. reconstructs the situation;
+2. separates observations, assumptions, relationships and unknowns;
+3. creates a structured reasoning graph;
+4. selects the most useful unresolved uncertainty;
+5. asks one simple question;
+6. updates the graph from the answer;
+7. repeats until action is justified or the remaining uncertainty is clear.
+
+A chatbot remembers the conversation.
+
+The Confidence Engine preserves the state of the reasoning.
+
+## Product direction
+
+The eventual product should feel like a calm, capable investigator helping the
+user think one step at a time.
+
+The user should not need to understand:
+
+- graph theory;
+- node IDs;
+- internal enums;
+- schemas;
+- prompt versions;
+- proposal validation;
+- model-provider details.
+
+Those remain available through developer/debug views.
+
+## Core product promise
+
+The engine should help a user reach one of these states:
+
+- I have enough justified confidence to act.
+- I do not yet have enough confidence, but I know what to investigate next.
+- I have discovered that my original question needs reframing.
+
+## Current development stage
+
+The deterministic reasoning architecture reached a stable alpha checkpoint.
+
+Current work is primarily improving:
+
+- usability;
+- presentation;
+- loading feedback;
+- plain-language explanations;
+- separation of user and developer views.
+
+Do not resume broad reasoning architecture work unless a repeated observed
+failure clearly requires it.
+
+## Important philosophy
+
+Complicated situations are made from smaller parts.
+
+Each part may influence the whole, but parts do not necessarily carry equal
+weight.
+
+Previous cases may suggest where to investigate, but they must never determine
+the outcome of a new case.
+
+Every case begins with no accepted evidence from previous cases.
+
+## Product Principle: TL;DR First
+
+The Confidence Workspace is not a document viewer or chat transcript. It is an active investigation workspace.
+
+At any point, the interface should allow a user returning after seconds, minutes or hours to understand where they are within a few seconds.
+
+The workspace should always answer:
+
+1. What is the situation?
+2. What have we established?
+3. What is the single most important thing to determine next?
+4. Why does that matter?
+5. How close are we to having sufficient confidence?
+
+The interface should minimise cognitive load by presenting the current state first and allowing progressively deeper exploration only when requested.
+
+The engine may contain hundreds of reasoning nodes; the user should only see the information required to take the next meaningful action.
+
+## Why workspace layout matters (v0.7)
+
+This phase optimises for simultaneous visibility instead of sequential scrolling.
+Related panels — Understanding alongside Investigation Map, Situation alongside History — can appear side-by-side on wide screens while mobile continues to stack everything vertically. The reasoning engine is completely unaware of these changes; only the presentation layer is affected.
+
+## Routing Notes
+
+Read `docs/current-working-principles.md` for current guidance. Treat `docs/architectural-principles.md` as a broader task-specific reference, not a statement of current implementation.
+
+For UI mock work, read `docs/ui-mock-reference.md`. Do not load
+`docs/archive/deferred-ux-backlog.md` unless a named past UX idea is being reviewed.
+Engine and UI experiments are paused. First file to inspect when resuming:
+`docs/current-project-state.md`, then `docs/project-knowledge-inventory.md`.
+
+> After reading `docs/current-project-state.md`, choose the relevant minimal pack from `docs/task-context-packs.md`. Do not combine packs unless a specific task genuinely crosses boundaries.
@@ -0,0 +1,601 @@
+# UX Guidelines
+
+## Main principle
+
+The user should see the next useful step clearly.
+
+The system may retain considerable complexity underneath, but the primary
+workspace should remain calm and understandable.
+
+## Main user view
+
+Prioritise:
+
+1. Your situation
+2. Current understanding
+3. What we are working out
+4. Why it matters
+5. Next question
+6. Answer field
+7. Reasoning progress
+
+## Developer view
+
+Keep technical details behind a collapsed `Developer details` disclosure.
+
+This may contain:
+
+- complete situation graph;
+- graph counts;
+- nodes and edges;
+- affected and resolved nodes;
+- diagnostics;
+- proposal details;
+- raw JSON;
+- prompt and model details;
+- technical confidence data.
+
+Do not remove the developer view. It remains important while the product is
+being tested.
+
+## Language
+
+Use plain language.
+
+Prefer:
+
+- `areas that still need investigation`
+- `what we are working out`
+- `why this matters`
+- `what we understand so far`
+- `next question`
+
+Avoid in the main view:
+
+- unknown nodes;
+- unresolved candidates;
+- activeUnknownNodeId;
+- graph references;
+- proposal compatibility;
+- candidate count;
+- internal enum values;
+- raw IDs.
+
+Never display an unexplained count such as:
+
+`3 remaining`
+
+Explain what the count represents, or omit it.
+
+Do not imply that one unresolved graph node always equals one remaining user
+question.
+
+## Loading experience
+
+Analysis and update requests can take around a minute with the current local
+model.
+
+A disabled button is not sufficient feedback.
+
+Show a visible processing card immediately.
+
+Recommended initial-analysis messages:
+
+- 0–10 seconds: `Reading your situation`
+- 10–25 seconds: `Building a structured understanding`
+- 25–45 seconds: `Identifying what is known and still unclear`
+- 45+ seconds: `Selecting the next useful question`
+
+Recommended update messages:
+
+- 0–10 seconds: `Considering your answer`
+- 10–25 seconds: `Updating the situation`
+- 25–45 seconds: `Checking what changed`
+- 45+ seconds: `Choosing the next question`
+
+These messages are time-based reassurance only.
+
+Do not claim that a backend stage has completed unless the backend explicitly
+reports it.
+
+Show elapsed time.
+
+Do not show fake progress percentages.
+
+Disable duplicate submission while a request is active.
+
+## Visual character
+
+Aim for:
+
+- calm;
+- professional;
+- spacious;
+- accessible;
+- suitable for business, consultancy and government users.
+
+Prefer:
+
+- clear hierarchy;
+- restrained colour;
+- generous whitespace;
+- readable line lengths;
+- consistent cards;
+- accessible contrast;
+- responsive layouts.
+
+Avoid:
+
+- visual clutter;
+- excessive badges;
+- neon colour;
+- unnecessary gradients;
+- glassmorphism;
+- distracting animation;
+- dashboard-style density.
+
+The next question should be the strongest visual element.
+
+## Workspace Layout Philosophy
+
+The Confidence Engine is a workspace, not a document.
+
+Documents optimise for reading from top to bottom.
+
+Workspaces optimise for allowing related information to be visible simultaneously.
+
+As investigations become larger, users should not be forced into unnecessary
+vertical scrolling simply because horizontal space is available.
+
+Layout decisions should always ask:
+
+> "How much useful investigation context can be seen at one time?"
+
+rather than:
+
+> "How narrow can the content column be?"
+
+### Principles
+
+- **Active investigation remains the primary focus.** The current question and response form are always fully visible first.
+- **Frequently referenced information should remain visible.** Understanding and Investigation Map should be scannable without scrolling away from the active question.
+- **Reference material may share horizontal space on larger displays.** Situation and History can sit side-by-side when there is room.
+- **Layout should adapt to available space without changing the investigation flow.** The same information is always present; only its arrangement changes.
+- **Mobile and tablet continue to use a stacked single-column layout.** No progressive disclosure at small sizes — every section remains accessible by scrolling, just as it always has been.
+- **Desktop progressively exposes more simultaneous context.** Instead of simply adding whitespace, wider screens reveal horizontal relationships between related panels.
+
+### Desktop layout model (wide screens)
+
+```
+┌───────────────────── full-width ─────────────────────┐
+│  Investigation Summary                                │
+├───────────────────────────────────────────────────────┤
+│  Active Workspace   │  Working Memory                │
+│  (full width)       │  Understanding     Map        │
+│  Current Investigation                      │         │
+│  Response           └─────────────────────────────────┘
+├───────────────────────────────────────────────────────┤
+│  Reference: Situation    │    History                 │
+├───────────────────────────────────────────────────────┤
+│  Developer Details (always below)                     │
+└───────────────────────────────────────────────────────┘
+```
+
+### Visual goal
+
+The page should feel less like a long report and more like an investigator's
+workspace. The eye should be able to compare Understanding alongside Investigation Map without scrolling, and Situation alongside History in the same way.
+
+### What this phase does NOT include
+
+- No card redesigns.
+- No new navigation.
+- No account management or top bar.
+- No tabs, collapsing layouts, resizable panes, floating panels, or masonry.
+- No typography or colour changes.
+
+This is a layout-only phase. The reasoning engine should remain completely unaware of presentation decisions.
+
+## TL;DR Workspace Rules
+
+The newest state is the most important state.
+
+The primary focus of every screen should be the user's next action, not the history of how they arrived there.
+
+### Information hierarchy
+
+1. Current investigation
+2. Why this matters
+3. Response
+4. Current understanding
+5. Investigation history
+6. Original situation
+7. Developer details
+
+### Progressive disclosure
+
+Show only the information needed for the current decision.
+
+Everything else should be collapsible or secondary.
+
+### Cognitive load
+
+The user should never need to scan an entire page to discover:
+
+- what is happening
+- what they need to do next
+- why they are being asked
+
+These should always be immediately visible.
+
+### Investigation history
+
+History exists to provide confidence and traceability, not to compete with the current investigation.
+
+History should remain collapsed unless the user chooses to inspect previous reasoning.
+
+### Original situation
+
+Once an investigation has started, the original scenario becomes reference material rather than the primary focus.
+
+## Interaction Modes
+
+The Confidence Engine operates in two distinct modes.
+
+### Workspace Mode
+
+The user is reading, thinking, and providing information.
+
+The interface should:
+
+- present the current investigation
+- allow the user to answer
+- show the current understanding
+- provide investigation history
+
+The workspace is interactive.
+
+---
+
+### Reasoning Mode (initial analysis)
+
+The engine is constructing the first investigation from nothing.
+
+A full primary loading state appears:
+
+- prominent overlay with spinner, rotating status messages, elapsed timer;
+- the entire workspace is replaced until reasoning completes;
+- no partial or changing content is visible during processing.
+
+---
+
+### Reasoning Mode (subsequent answers — localised)
+
+The investigation already exists.
+
+Only the active response panel is replaced by the loading card:
+
+- Current investigation question remains visible for context;
+- Current understanding, Original situation, and Investigation history persist;
+- Terminal state cards are suppressed during loading;
+- The workspace layout remains stable and recognisable;
+- Recovery states appear in place of the loading card if reasoning fails.
+
+The interface should:
+
+- clearly indicate that reasoning is in progress via the response-panel overlay;
+- reassure the user that their answer has been accepted;
+- avoid displaying partial or changing reasoning outside the response panel.
+
+---
+
+### Transition
+
+Every submission follows the same lifecycle:
+
+User submits information
+↓
+Loading card appears (full-page for initial analysis, localised for updates)
+↓
+Updated workspace returns
+
+The interaction is consistent in intent — both modes confirm input acceptance and pause the active response area — but the page-level behaviour differs because one constructs from nothing while the other refines existing context.
+
+Users should never wonder whether their input has been accepted or whether the engine is still reasoning.
+
+## Workspace Polish (v0.7)
+
+The workspace should feel calm. Every visible element must justify its presence.
+
+Unknown values should usually be hidden rather than represented with placeholders.
+
+Whitespace is preferred over decorative UI.
+
+Prefer removing over adding. Prefer consistency over cleverness.
+
+Every section group should feel visually connected — spacing within a group is tighter than between groups.
+
+Labels should be brief. "Investigation History" → "History". "Your response" → "Response". The context already makes the meaning clear.
+
+Headings should be clean. Remove unnecessary subheadings that duplicate context. Remove uppercase labels from headings where they add visual noise without adding information.
+
+Cards should have consistent border radius, padding, and heading treatment across the workspace.
+
+An Investigation Map Preview should look provisional — lighter borders, muted text, subtle background — so the user knows it is a preview rather than completed content.
+
+## Entry Experience
+
+The landing page is not the investigation workspace.
+
+The landing page welcomes the user.
+
+The landing page explains what will happen.
+
+Complexity appears progressively.
+
+Users begin with observations rather than conclusions.
+
+The Confidence Engine behaves like a facilitator introducing a workshop — calm, patient, and focused on understanding before acting.
+
+## Facilitator Behaviour
+
+Orientation should support work, not interrupt it.
+
+The facilitator is present by invitation, not obligation.
+
+Returning users should control repeated guidance.
+
+The workspace should remain the primary visual focus.
+
+Information should naturally flow from left to right.
+
+## Attention Hierarchy
+
+The current task always owns the user's attention.
+
+Supporting information should remain available without competing.
+
+Visual emphasis should come primarily from hierarchy rather than colour.
+
+Reduce distraction before adding decoration.
+
+Calm interfaces improve reasoning.
+
+Hierarchy flows from strongest to quietest:
+
+1. The current investigation question (strongest visual element)
+2. The response area (interactive, clear action)
+3. Supporting context (visible but restrained)
+4. Reference material (available, low priority)
+
+The workspace should feel like an active desk — the work in progress is prominent, supporting tools are within reach but not shouting for attention.
+
+## Input Expectations
+
+Input size communicates expected effort.
+
+Do not visually ask for more information than the engine currently needs.
+
+The initial situation is a starting observation, not a completed report.
+
+The engine should gather detail progressively through justified questions.
+
+Short inputs should feel valid.
+
+Users may still paste longer content when necessary.
+
+Meaning and state must never depend on colour alone.
+
+Similar interactions should look similar.
+
+Every investigation answer is a single observation.
+
+Response controls should communicate concise input unless the engine explicitly requests otherwise.
+
+Consistency reduces cognitive load.
+
+## Investigation Rhythm
+
+Principles:
+
+Every interaction should feel like the next natural step.
+
+The interface should never appear to stop thinking.
+
+Users should always know what just happened.
+
+Users should always know what happens next.
+
+The investigation should feel continuous rather than page-based.
+
+The conversation should flow naturally.
+
+## Conversation and Reference Lanes
+
+On desktop, the workspace splits into two persistent lanes:
+
+- The left lane (approximately two-thirds) is the active conversation area.
+- The right lane (approximately one-third) holds supporting reference artefacts.
+
+The active conversation has a stable spatial home. Question, Response, and History form one continuous interaction lane. History grows downward beneath the active response. Each turn stays part of the same notebook within that lane.
+
+Supporting artefacts should remain spatially stable while the conversation grows. Desktop width should be used to preserve context, not merely enlarge cards. Text should not be truncated when sufficient readable space exists.
+
+Mobile remains a natural stacked flow with no horizontal split.
+
+## Facilitator Translation Layer (Experiment 11 — Emerging)
+
+The reasoning engine produces a rich graph with structured concepts (observations, unknowns, assumptions, relationships, metrics, states). The UI should increasingly become a translation layer over this graph rather than maintaining separate duplicated summaries.
+
+For end users, present the same data as:
+
+- **Known** — resolved nodes and established observations
+- **Still investigating** — unresolved unknowns and assumptions to validate
+- **Quiet reasoning summary** — raw counts (nodes, edges, etc.) visually secondary
+
+Internal graph concepts should remain available for developers (Developer Details) but should not dominate the primary view. The panel should feel like a facilitator's notebook: someone looking at it should immediately understand where the investigation stands, what has been learned, and what remains uncertain — without needing to understand graph theory.
+
+## Graph Projection
+
+The reasoning engine produces a rich graph with structured concepts (observations, unknowns, assumptions, relationships, metrics, states). The UI increasingly becomes a translation layer over this graph rather than maintaining separate duplicated summaries.
+
+This section records principles for projecting graph data into human-meaningful views.
+
+### Translation over exposure
+
+- The graph is internal structure; the UI communicates human meaning.
+- User-facing panels should translate graph state rather than expose graph terminology.
+- Display only the amount of graph information useful for the current task.
+
+### Epistemic clarity
+
+- Known information, uncertainty and assumptions must remain visibly distinct.
+- Assumptions must never look like facts.
+- Use explicit structural labels (e.g., "Possible explanation", "Not yet established") rather than relying on colour or implicit cues.
+
+### Curation as explanation
+
+- Prioritisation and omission are part of good explanation.
+- Repeated scenario text should not dominate derived summaries.
+- Complete technical detail remains available through Developer Details.
+
+### Robustness constraints
+
+- Meaning must remain understandable without relying on colour.
+- Displayed content must be grounded in existing graph fields — never invent facts absent from the graph.
+- When nothing useful is established, show calm fallback language rather than an empty panel or a fabricated summary.
+
+### Label hygiene
+
+- Prefer labels over descriptions when labels are clearer.
+- Normalise text for deduplication (lowercase, trim, collapse whitespace).
+- Omit items that are too verbose to scan; do not synthesise rewritten claims that change meaning.
+- Avoid displaying graph identifiers, confidence values without context, or raw enum categories in user-facing views.
+
+### State-aware framing
+
+- The same panel must remain useful during early, active and terminal investigation states.
+- Terminal state content should change its framing (e.g., "What the evidence supports" rather than "Still investigating") but not invent certainty.
+
+## Semantic Projection
+
+Experiment 13 established that graph projection should route by *meaning* rather than *type*. These are the resulting principles.
+
+### Meaning over type
+
+- Classify nodes by what they *say*, not by their kind enum. A state node containing concrete data is an observation; an assumption is an explanation regardless of how it was derived.
+- Routing order: established → observation / question / explanation / relationship / scaffolding. Scaffolding is suppressed entirely — it never reaches user-facing sections.
+
+### Suppression hierarchy
+
+Three tiers, applied top to bottom:
+
+1. **Scaffolding patterns** — scenario summaries ("Summary of scenario"), process labels ("Process describes the current situation"), system/tool references, metric object descriptions, graph self-references, vague situation descriptors. These are structural glue; the user does not need to see them.
+2. **Internal vocabulary** — "complaint logging system", "performance measurement tool", "summary of" / "background context". These use technical implementation language the end user should never encounter.
+3. **Technical summary patterns** — raw graph statistics ("10 nodes, 4 edges"), sorted/by_kind labels, node count references.
+
+### Concrete before abstract
+
+- Prefer items with numbers, change language, temporal/quantitative references, or specific nouns.
+- Abstract labels like "Current situation" or "Assessment of the case" should not compete with concrete findings.
+
+### Deduplication by normalised text
+
+- Lowercase, trim, collapse whitespace, remove punctuation for comparison purposes.
+- Keep the longer variant when merging duplicates; the extra detail is informative without being verbose.
+
+### Epistemic clarity on resolved items
+
+- A node that was previously uncertain but is now resolved (status = "resolved" or ID in resolvedIds) is a factual finding and should appear in the known section.
+- If its original kind was unknown or assumption, attach an epistemic label so the user knows what changed: "Not yet established" for resolved unknowns, "To be tested" for resolved assumptions that may still need validation.
+
+### Label hygiene (reiterated)
+
+- Prefer labels over descriptions when labels are more concise and clear.
+- Omit items too verbose to scan; do not synthesise rewritten claims.
+- Never invent facts absent from the graph.
+
+## Investigation Narrative
+
+The reasoning graph is the machine representation of the investigation.
+
+The investigation narrative is the human representation.
+
+The UI renders projections from the narrative, not directly from the graph.
+
+Principles:
+
+- Users understand investigations, not graphs.
+- The graph is an internal reasoning structure.
+- The narrative is the explanation of current understanding.
+- Every user-facing panel should consume narrative state where possible.
+- Multiple UI layouts may share the same narrative.
+- Narrative should evolve as evidence changes.
+- Narrative must never invent facts absent from the graph.
+- Narrative explains uncertainty rather than exposing graph mechanics.
+
+## Facilitator Behaviour
+
+The facilitator is defined by patterns of action, not by its words.
+The same investigation state can produce different behaviours depending on context and history.
+
+### Core behavioural principles
+
+Every turn should reflect a behaviour selected from the following set — not a mechanically determined response:
+
+**Orient.** Establish shared understanding before asking anything.
+
+**Acknowledge.** Integrate what was learned before introducing new uncertainty.
+
+**Observe pattern.** Surface connections between established facts without resolving them for the user.
+
+**Clarify.** Target ambiguous or partially useful information with narrow, precise questions.
+
+**Validate.** Mark resolutions explicitly and show their consequence on the investigation.
+
+**Connect.** Propose exploring relationships between established findings as natural next steps.
+
+**Challenge assumption.** Expose premises that lack sufficient evidence without dismissing them.
+
+**Refine understanding.** Restate the current state more coherently when sufficient information exists — not as repetition but as evolution.
+
+**Expose uncertainty.** Make the disparity between known and unknown visible rather than hiding gaps behind generic language.
+
+**Decide direction.** Recommend a specific next step with reasoning — not enumerate all options equally.
+
+**Know when to pause.** Hold space after significant insight instead of immediately asking another question.
+
+**Avoid premature closure.** Validate partial understanding; offer deeper pathways without implying urgency to conclude.
+
+**Communicate confidence honestly.** Express certainty through epistemic language that matches the actual resolution state.
+
+**Progressively narrow focus.** Shift from breadth to synthesis to depth as the investigation matures.
+
+### What the facilitator does NOT do
+
+- Ask questions to fill graph nodes.
+- Treat all unknowns equally.
+- Present every available explanation as equally valid.
+- Move on before integrating what was just learned.
+- Summarise too often or too rarely.
+- Claim certainty where none exists.
+- Forget what was established earlier.
+
+### State-aware behaviour selection
+
+The facilitator selects its behavioural response from investigation state assessment, not from a fixed sequence:
+
+> What was resolved this turn?
+> How many turns since last synthesis?
+> What is the proportion of known vs unknown?
+> Did recent turns explore or synthesise?
+> Do newly established facts form a pattern?
+> Did user information introduce clarity or ambiguity?
+> What phase is the investigation in (early / active / terminal)?
+
+### Relationship to architecture
+
+The narrative layer describes *state* (what do we know?).
+The behavioural model describes *action* (what should we do about it?).
+
+They are complementary. The engine assesses state through the narrative, then selects a behaviour, then executes through the conversation infrastructure.
@@ -0,0 +1,125 @@
+# Claude Code Working Rules
+
+## Mandatory command constraints
+
+These rules exist because previous long shell commands and streamed responses
+caused tool failures.
+
+- Do not use heredocs.
+- Do not use long `node -e` commands.
+- Do not use long `python -c` commands.
+- If helper code is needed, create a small script file and run it.
+- Keep shell commands short and readable.
+- Break complex work into several commands.
+- Write large outputs to files instead of printing them.
+- Do not print full JSON responses or graph objects.
+- Do not paste complete large files into chat.
+- Prefer: tool → file → concise summary.
+- Keep final reports concise.
+- Do not narrate every implementation step.
+
+## Change discipline
+
+Before editing:
+
+1. state the current branch;
+2. inspect `git status`;
+3. identify the relevant files;
+4. explain the smallest intended change.
+
+Work on one component or concern at a time.
+
+Do not combine unrelated cleanup with the requested task.
+
+Do not reformat unrelated files.
+
+Do not modify production reasoning code during UX tasks.
+
+## Testing discipline
+
+Use focused tests.
+
+Do not run the full test suite unless requested or genuinely necessary.
+
+Do not call Ollama in unit tests.
+
+Do not run live multi-scenario evaluations for ordinary UI changes.
+
+Do not run Playwright unless the task specifically requires it.
+
+Do not weaken existing reasoning tests to make UI changes pass.
+
+## Git discipline
+
+Before committing:
+
+- inspect the diff;
+- confirm no secrets;
+- confirm no internal IP addresses;
+- confirm no raw provider responses;
+- confirm no screenshots;
+- confirm no temporary scripts;
+- confirm no generated test outputs;
+- confirm only intended files changed.
+
+Use a focused commit message.
+
+Do not merge or tag unless explicitly requested.
+
+## Non-narration rule
+
+Claude Code must act as an implementation agent, not narrate its internal
+debugging process.
+
+When tests fail:
+
+1. inspect the focused failure;
+2. make the smallest justified edit;
+3. rerun the focused test;
+4. repeat until passing or genuinely blocked.
+
+Do not print or explain intermediate reasoning.
+
+Never print:
+
+- rendered HTML;
+- full JSON;
+- full graph objects;
+- large diffs;
+- long stack traces;
+- repeated interpretations of the same failure.
+
+Prefer:
+
+tool → edit → focused test → concise report
+
+The final chat response must be under 1,000 words and normally contain only:
+
+- branch;
+- commit hash;
+- files changed;
+- behaviour changed;
+- tests;
+- lint/build;
+- remaining limitation;
+- git status.
+
+## Response discipline
+
+At the end of a task, normally report only:
+
+- branch;
+- commit hash, when committed;
+- files changed;
+- behaviour changed;
+- tests;
+- lint/build;
+- manual result, if performed;
+- remaining limitation;
+- git status.
+
+Stop after reporting. Do not begin the next task automatically.
+
+When a task is interrupted by output limits, resume with a narrowly scoped repair prompt rather than restating the entire original brief.
+
+User interfaces communicate reasoning, not implementation. If a piece of information exists only because the engine tracks it internally (graph nodes, unresolved counts, edge totals, confidence scores), it should remain in Developer Details unless it directly helps the user make their next decision.
@@ -3,3 +3,13 @@ OLLAMA_BASE_URL=http://192.168.x.x:11434

 # Model name (e.g., llama3, mistral, codellama, etc.)
 OLLAMA_MODEL=replace-with-model-name
+
+# ── Mock / Demo Mode (UI development only) ──────────────────
+# Set to "true" to use pre-recorded scenario fixtures instead of Ollama.
+NEXT_PUBLIC_CONFIDENCE_ENGINE_MOCKS=true
+
+# Mock delay mode: "instant" | "normal" (default, 700ms) | "slow" (2500ms)
+NEXT_PUBLIC_CONFIDENCE_MOCK_DELAY=normal
+
+# Scenario to replay: "complete" (jump to end after start) | "error" | "" (default sequential turns)
+NEXT_PUBLIC_CONFIDENCE_ENGINE_MOCK_SCENARIO=complete
@@ -34,3 +34,8 @@ Thumbs.db
 npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
+
+# Generated evaluation artifacts (regenerated each run)
+evaluation-results/
+provider-debug-results/
+tests-results/
@@ -0,0 +1,51 @@
+# Confidence Engine
+
+Read these project instructions before making changes:
+
+- @.claude/project-context.md
+- @.claude/architecture-guardrails.md
+- @.claude/ux-guidelines.md
+- @.claude/working-rules.md
+
+## Current working principle
+
+The Confidence Engine helps a person move from uncertainty towards justified
+confidence by asking one simple, useful question at a time.
+
+The graph preserves the state of the reasoning. The conversation is the primary
+user experience.
+
+## Before changing anything
+
+1. Inspect the current branch and working tree.
+2. Read the relevant implementation and tests.
+3. Identify whether the request concerns:
+   - reasoning behaviour;
+   - API/data contracts;
+   - or presentation only.
+4. Respect the boundaries in the imported instructions.
+5. Make the smallest change that satisfies the task.
+
+Do not assume an architectural redesign is wanted.
+
+## Live experiment harness rule
+
+When running reasoning experiments, use the canonical harness at
+`tests/graph/live-update-experiment-helper.cjs`. Never create a new harness,
+enumerate `/api/tags`, probe localhost, or discover/substitute models during
+normal reasoning experiments.
+
+## Standard validation
+
+For UI-only work, normally run:
+
+```bash
+npm test -- --run tests/ui/scenario-form.test.jsx
+npm run lint
+npm run build
+```
+
+Run additional focused tests only when relevant files are affected.
+
+Do not run Ollama, Playwright, the full test suite, or evaluator suites unless the
+task explicitly requires them.
@@ -1,101 +1,49 @@
-import { getConfig } from "@/lib/config";
-import { getProvider } from "@/lib/llm/provider";
-import { reconstructionSchema } from "@/lib/reconstruction/schema";
-
-const MAX_SCENARIO_LENGTH = 10000;
+import {
+  analyseScenario,
+  PROMPT_VERSIONS,
+  DEFAULT_PROMPT_VERSION,
+} from "@/lib/analysis";

 export async function POST(request) {
-  const startTime = Date.now();
-  let rawResponse = null;
-  
  try {
    const body = await request.json();
-    
+
    if (!body.scenario || typeof body.scenario !== "string") {
      return Response.json(
        { error: "Request must include a 'scenario' string field" },
-        { status: 400 }
+        { status: 400 },
      );
    }

-    const trimmed = body.scenario.trim();
-    
-    if (trimmed.length === 0) {
+    // Optional prompt version override
+    let promptVersion = DEFAULT_PROMPT_VERSION;
+    if (body.promptVersion && PROMPT_VERSIONS.includes(body.promptVersion)) {
+      promptVersion = body.promptVersion;
+    }
+
+    const result = await analyseScenario(body.scenario, { promptVersion });
+
+    if (!result.success) {
      return Response.json(
-        { error: "Scenario cannot be empty" },
-        { status: 400 }
+        { ...result, reconstruction: result.reconstruction || null },
+        { status: Number(result.statusCode) || 500 },
      );
    }

-    if (trimmed.length > MAX_SCENARIO_LENGTH) {
-      return Response.json(
-        { error: `Scenario must be under ${MAX_SCENARIO_LENGTH} characters` },
-        { status: 400 }
-      );
-    }
-
-    const configResult = getConfig();
-    if (!configResult.ok) {
-      return Response.json(
-        { error: "Invalid server configuration" },
-        { status: 500 }
-      );
-    }
-
-    const { OLLAMA_BASE_URL, OLLAMA_MODEL } = configResult.config;
-    const provider = getProvider();
-
-    // Attempt parse to capture raw for debugging
-    let reconstruction;
-    try {
-      reconstruction = await provider.generateReconstruction(trimmed, OLLAMA_MODEL);
-    } catch (e) {
-      return Response.json(
-        { 
-          error: e.message || "Unknown server error", 
-          responseDurationMs: Date.now() - startTime,
-          modelName: OLLAMA_MODEL,
-          validationStatus: "invalid",
-        },
-        { status: 500 }
-      );
-    }
-    
-    // Try to stringify for rawResponse display (safe even if it's already an object)
-    try {
-      rawResponse = JSON.stringify(reconstruction);
-    } catch {
-      rawResponse = String(reconstruction).slice(0, 2000);
-    }
-
-    const duration = Date.now() - startTime;
-
-    // Validate with Zod schema
-    const validationResult = reconstructionSchema.safeParse(reconstruction);
-
-    if (!validationResult.success) {
-      return Response.json({
-        reconstruction: null,
-        modelName: OLLAMA_MODEL,
-        responseDurationMs: duration,
-        validationStatus: "invalid",
-        rawResponse: rawResponse?.slice(0, 2000),
-        errors: validationResult.error.issues.map((i) => `${i.path.join(".")}: ${i.message}`),
-      });
-    }
-
    return Response.json({
-      reconstruction: validationResult.data,
-      modelName: OLLAMA_MODEL,
-      responseDurationMs: duration,
-      validationStatus: "valid",
-      rawResponse: rawResponse?.slice(0, 2000),
+      inputClassification: result.inputClassification,
+      reconstruction: result.reconstruction,
+      evidence: result.evidence,
+      nextQuestion: result.nextQuestion,
+      modelName: result.modelName,
+      responseDurationMs: result.responseDurationMs,
+      validationStatus: result.validationStatus,
+      promptVersion: result.promptVersion,
    });
  } catch (e) {
-    const duration = Date.now() - startTime;
    return Response.json(
-      { error: e.message || "Unknown server error", responseDurationMs: duration },
-      { status: 500 }
+      { error: e.message || "Unknown server error", responseDurationMs: 0 },
+      { status: 500 },
    );
  }
 }
@@ -0,0 +1,38 @@
+import { startCase } from "@/lib/graph/orchestrator.js";
+
+export async function POST(request) {
+  try {
+    const body = await request.json();
+    const result = await startCase(body);
+
+    if (result.success) {
+      return Response.json(result, { status: 200 });
+    }
+
+    const status =
+      result.statusCode === 400
+        ? 400
+        : result.statusCode >= 500
+          ? result.statusCode
+          : 500;
+
+    return Response.json(
+      {
+        success: false,
+        error: result.error ?? "Start case failed",
+        validationErrors: result.validationErrors,
+        diagnostics: result.diagnostics,
+        analysisErrors: result.analysisErrors,
+      },
+      { status },
+    );
+  } catch {
+    return Response.json(
+      {
+        success: false,
+        error: "Internal server error",
+      },
+      { status: 500 },
+    );
+  }
+}
@@ -0,0 +1,68 @@
+import { updateCase } from "@/lib/graph/orchestrator.js";
+
+function mapFailureStatus(result) {
+  switch (result?.stage) {
+    case "request_validation":
+    case "graph_validation":
+      return 400;
+    case "provider":
+      return 502;
+    case "proposal_validation":
+    case "proposal_compatibility":
+    case "application":
+      return 422;
+    case "result_validation":
+      return 500;
+    default:
+      return 500;
+  }
+}
+
+function buildFailureResponse(result) {
+  return {
+    success: false,
+    stage: result?.stage ?? "internal",
+    error: result?.error ?? "Update case failed",
+    validationErrors: result?.validationErrors,
+    graphValidationErrors: result?.graphValidationErrors,
+    proposalErrors: result?.proposalErrors,
+    providerErrors: result?.providerErrors,
+    errors: result?.errors,
+    diagnostics: result?.diagnostics,
+  };
+}
+
+export async function POST(request) {
+  try {
+    const body = await request.json();
+    const result = await updateCase(body, { applyProposal: true });
+
+    if (result.success) {
+      return Response.json(result, { status: 200 });
+    }
+
+    return Response.json(buildFailureResponse(result), {
+      status: mapFailureStatus(result),
+    });
+  } catch (error) {
+    if (error instanceof SyntaxError) {
+      return Response.json(
+        {
+          success: false,
+          stage: "request_validation",
+          error: "Invalid JSON request body",
+        },
+        { status: 400 },
+      );
+    }
+
+    return Response.json(
+      {
+        success: false,
+        stage: "internal",
+        error: "Internal server error",
+      },
+      { status: 500 },
+    );
+  }
+}
@@ -1,3 +1,35 @@
@tailwind base;
@tailwind components;
@tailwind utilities;
+
+@keyframes spin {
+  from { transform: rotate(0deg); }
+  to { transform: rotate(360deg); }
+}
+
+@keyframes fadeIn {
+  from { opacity: 0; transform: translateY(4px); }
+  to { opacity: 1; transform: translateY(0); }
+}
+
+.investigation-card {
+  animation: fadeIn 0.4s ease-out both;
+}
+
+.investigation-card:nth-child(2) {
+  animation-delay: 0.08s;
+}
+
+.investigation-card:nth-child(3) {
+  animation-delay: 0.16s;
+}
+
+@media (prefers-reduced-motion: reduce) {
+  [style*="animation:spin"] {
+    animation: none !important;
+  }
+
+  .investigation-card {
+    animation: none;
+  }
+}
@@ -2,7 +2,7 @@ import ScenarioForm from "@/components/scenario-form";

 export default function Home() {
  return (
-    <main className="mx-auto max-w-2xl px-6 py-12">
+    <main className="mx-auto max-w-[1600px] px-6 py-12">
      <h1 className="mb-2 text-3xl font-bold tracking-tight">Confidence Engine</h1>
      <p className="mb-8 text-sm text-gray-500">
        Experimental prototype: enter a scenario and send it to a local LLM for
@@ -1,3 +1,5 @@
+import React from "react";
+
 const ValidationIndicator = ({ status }) => {
  const styles = {
    valid: "text-green-600",
@@ -10,17 +12,91 @@ const ValidationIndicator = ({ status }) => {
    invalid: "❌ Validation failed",
  };
  return (
-    <div className={`flex items-center gap-2 ${styles[status] || "text-gray-500"}`}>
+    <div
+      className={`flex items-center gap-2 ${styles[status] || "text-gray-500"}`}
+    >
      <span className="font-medium">{labels[status] || status}</span>
    </div>
  );
 };

+const validationIcons = {
+  valid: "✅",
+  partial: "⚠️",
+  invalid: "❌",
+};
+
 export default function DiagnosticsView({ result }) {
+  if (!result) return null;
+
+  const diagnostics = result.diagnostics || result;
+
  const metrics = [
-    { label: "Model", value: result.modelName || "?" },
-    { label: "Duration", value: result.responseDurationMs != null ? `${result.responseDurationMs}ms` : "?" },
-    { label: "Validation", value: <ValidationIndicator status={result.validationStatus || "invalid"} /> },
+    { label: "Model", value: diagnostics.modelName || result.modelName || "?" },
+    { label: "Provider", value: "Ollama" },
+    {
+      label: "Prompt version",
+      value: diagnostics.promptVersion || result.promptVersion || "?",
+    },
+    {
+      label: "Duration",
+      value:
+        diagnostics.responseDurationMs != null
+          ? `${diagnostics.responseDurationMs}ms`
+          : "?",
+    },
+    {
+      label: "Validation",
+      value: (
+        <ValidationIndicator
+          status={diagnostics.validationStatus || result.validationStatus || "invalid"}
+        />
+      ),
+    },
+    {
+      label: "Node count",
+      value:
+        diagnostics.nodeCount != null
+          ? diagnostics.nodeCount
+          : diagnostics.graphNodeCount != null
+            ? diagnostics.graphNodeCount
+            : "?",
+    },
+    {
+      label: "Edge count",
+      value:
+        diagnostics.edgeCount != null
+          ? diagnostics.edgeCount
+          : diagnostics.graphEdgeCount != null
+            ? diagnostics.graphEdgeCount
+            : "?",
+    },
+    {
+      label: "Graph references",
+      value:
+        diagnostics.graphReferenceValidation == null
+          ? "?"
+          : diagnostics.graphReferenceValidation.valid
+            ? `${validationIcons.valid} valid`
+            : `${validationIcons.invalid} invalid`,
+    },
+    {
+      label: "Investigation strategy",
+      value:
+        diagnostics.investigationStrategy?.key ||
+        diagnostics.investigationStrategy ||
+        result.selectedQuestion?.strategy ||
+        "?",
+    },
+  ];
+
+  const errors = [
+    ...(result.errors || []),
+    ...(result.validationErrors || []),
+    ...(result.graphValidationErrors || []),
+    ...(result.proposalErrors || []),
+    ...(result.providerErrors || []),
+    ...(result.analysisErrors || []),
  ];

  return (
@@ -35,16 +111,32 @@ export default function DiagnosticsView({ result }) {
        ))}
      </dl>

+      {/* Collapsed raw output for debugging */}
      {result.rawResponse && (
        <details className="mt-4">
          <summary className="cursor-pointer text-xs text-gray-500 underline hover:text-gray-700">
-            View raw model response
+            View raw model response (
+            {(result.rawResponse?.length || 0).toLocaleString()} chars)
          </summary>
          <pre className="mt-2 max-h-60 overflow-auto rounded bg-gray-900 px-3 py-2 text-xs leading-relaxed text-green-400">
            {result.rawResponse}
          </pre>
        </details>
      )}
+
+      {/* Errors if present */}
+      {errors.length > 0 && (
+        <details className="mt-3">
+          <summary className="cursor-pointer text-xs text-red-500 underline hover:text-red-700">
+            Validation errors ({errors.length})
+          </summary>
+          <ul className="mt-1 space-y-0.5 text-xs text-red-600">
+            {errors.map((err, i) => (
+              <li key={i}>{typeof err === "string" ? err : err?.message || JSON.stringify(err)}</li>
+            ))}
+          </ul>
+        </details>
+      )}
    </div>
  );
 }
@@ -0,0 +1,228 @@
+import React from "react";
+
+function ListSection({ title, items, renderItem = (item) => item }) {
+  if (!items?.length) return null;
+
+  return (
+    <section className="rounded-lg border border-gray-200 bg-white p-4">
+      <h3 className="mb-2 text-sm font-semibold text-gray-800">{title}</h3>
+      <ul className="space-y-1 text-sm text-gray-700">
+        {items.map((item, index) => (
+          <li key={`${title}-${index}`}>{renderItem(item)}</li>
+        ))}
+      </ul>
+    </section>
+  );
+}
+
+export default function GraphUpdateView({ updateResult }) {
+  if (!updateResult?.proposal) return null;
+
+  const {
+    resolvedUnknownNodeIds,
+    affectedNodeIds,
+    previousActiveUnknownNodeId,
+    newActiveUnknownNodeId,
+    selectedQuestion,
+    changesApplied,
+    proposal,
+    previousSituationGraph,
+    updatedSituationGraph,
+    reasoningState,
+    previousReasoningState,
+  } = updateResult;
+
+  const newlySurfacedUnknownNodeIds = (proposal.addedNodes || [])
+    .filter((node) => node.kind === "unknown")
+    .map((node) => node.id);
+
+  const previousNodesById = new Map(
+    (previousSituationGraph?.nodes || []).map((node) => [node.id, node]),
+  );
+  const updatedNodesById = new Map(
+    (updatedSituationGraph?.nodes || []).map((node) => [node.id, node]),
+  );
+  const proposalUpdatesByNodeId = new Map(
+    (proposal.updatedNodes || []).map((update) => [update.nodeId, update]),
+  );
+
+  function resolveNodePresentation(nodeId) {
+    const previousNode = previousNodesById.get(nodeId) || null;
+    const updatedNode = updatedNodesById.get(nodeId) || null;
+    const node = updatedNode || previousNode;
+    const update = proposalUpdatesByNodeId.get(nodeId) || null;
+
+    if (!node) {
+      return (
+        <div className="space-y-1">
+          <div className="font-medium text-gray-900">Unknown node (ID: {nodeId})</div>
+        </div>
+      );
+    }
+
+    return (
+      <div className="space-y-1">
+        <div className="font-medium text-gray-900">{node.label}</div>
+        <div className="text-xs text-gray-600">
+          {node.kind} · {node.confidence}
+        </div>
+        {node.confidenceAssessment && (
+          <div className="text-xs text-gray-600">
+            evidence {node.confidenceAssessment.evidenceConfidence} · completeness {node.confidenceAssessment.completenessStatus} · conclusion {node.confidenceAssessment.conclusionConfidence}
+          </div>
+        )}
+        {(update?.previousStatus || update?.newStatus || node.status) && (
+          <div className="text-xs text-gray-700">
+            {update?.previousStatus ? `Previous status: ${update.previousStatus}` : null}
+            {update?.previousStatus && update?.newStatus ? " → " : null}
+            {update?.newStatus
+              ? `New status: ${update.newStatus}`
+              : !update?.previousStatus
+                ? `Status: ${node.status}`
+                : null}
+          </div>
+        )}
+        {update?.reason && <div className="text-xs text-gray-700">{update.reason}</div>}
+      </div>
+    );
+  }
+
+  function resolveActiveUnknown(nodeId) {
+    if (!nodeId) return null;
+
+    const node = updatedNodesById.get(nodeId) || previousNodesById.get(nodeId);
+    if (!node) {
+      return `Unknown node (ID: ${nodeId})`;
+    }
+
+    return `${node.label} · ${node.status} · ${node.confidence}`;
+  }
+
+  const changeItems = [
+    changesApplied?.addedNodeCount
+      ? `${changesApplied.addedNodeCount} node(s) added`
+      : null,
+    changesApplied?.updatedNodeCount
+      ? `${changesApplied.updatedNodeCount} node(s) updated`
+      : null,
+    changesApplied?.addedEdgeCount
+      ? `${changesApplied.addedEdgeCount} edge(s) added`
+      : null,
+    changesApplied?.removedEdgeCount
+      ? `${changesApplied.removedEdgeCount} edge(s) removed`
+      : null,
+    changesApplied?.resolvedUnknownCount
+      ? `${changesApplied.resolvedUnknownCount} unknown(s) resolved`
+      : null,
+  ].filter(Boolean);
+
+  const previousComparabilityStatus =
+    previousReasoningState?.comparabilityStatus ||
+    previousSituationGraph?.reasoningState?.comparabilityStatus ||
+    null;
+  const newComparabilityStatus =
+    reasoningState?.comparabilityStatus ||
+    updatedSituationGraph?.reasoningState?.comparabilityStatus ||
+    null;
+  const relationshipStatus =
+    reasoningState?.relationshipStatus ||
+    updatedSituationGraph?.reasoningState?.relationshipStatus ||
+    null;
+  const reasoningStagesAfter =
+    reasoningState?.reasoningStages ||
+    updatedSituationGraph?.reasoningState?.reasoningStages ||
+    [];
+
+  return (
+    <div className="space-y-4">
+      <section className="rounded-lg border border-blue-200 bg-blue-50 p-4">
+        <h2 className="mb-2 text-base font-semibold text-blue-900">
+          Graph update applied
+        </h2>
+        <div className="grid gap-2 text-sm text-blue-950 sm:grid-cols-2">
+          {previousActiveUnknownNodeId && (
+            <div>
+              <span className="font-medium">Previous active unknown:</span>{" "}
+              {resolveActiveUnknown(previousActiveUnknownNodeId)}
+            </div>
+          )}
+          {newActiveUnknownNodeId && (
+            <div>
+              <span className="font-medium">New active unknown:</span>{" "}
+              {resolveActiveUnknown(newActiveUnknownNodeId)}
+            </div>
+          )}
+          {selectedQuestion?.question && (
+            <div>
+              <span className="font-medium">Next question:</span>{" "}
+              {selectedQuestion.question}
+            </div>
+          )}
+          {previousComparabilityStatus && newComparabilityStatus && (
+            <div>
+              <span className="font-medium">Comparability:</span>{" "}
+              {previousComparabilityStatus} → {newComparabilityStatus}
+            </div>
+          )}
+          {relationshipStatus && (
+            <div>
+              <span className="font-medium">Relationship status:</span>{" "}
+              {relationshipStatus}
+            </div>
+          )}
+          {!selectedQuestion?.question && !newActiveUnknownNodeId && previousActiveUnknownNodeId && (
+            <div>
+              <span className="font-medium">Next question status:</span> No next question selected yet.
+            </div>
+          )}
+        </div>
+        {reasoningStagesAfter.length > 0 && (
+          <div className="mt-3 text-sm text-blue-950">
+            <span className="font-medium">Reasoning stages:</span>{" "}
+            {reasoningStagesAfter
+              .map((stage) => `${stage.stage}: ${stage.status}`)
+              .join(" → ")}
+          </div>
+        )}
+      </section>
+
+      <ListSection
+        title="Resolved unknowns"
+        items={resolvedUnknownNodeIds}
+        renderItem={resolveNodePresentation}
+      />
+      <ListSection
+        title="Newly surfaced unknowns"
+        items={newlySurfacedUnknownNodeIds}
+        renderItem={resolveNodePresentation}
+      />
+      <ListSection
+        title="Affected nodes"
+        items={affectedNodeIds}
+        renderItem={resolveNodePresentation}
+      />
+      <ListSection title="Applied changes" items={changeItems} />
+
+      <details className="rounded-lg border border-gray-200 bg-gray-50 p-4">
+        <summary className="cursor-pointer text-sm font-medium text-gray-700 underline">
+          Proposal details
+        </summary>
+        <pre className="mt-3 overflow-auto rounded bg-gray-900 p-3 text-xs text-green-400">
+          {JSON.stringify(proposal, null, 2)}
+        </pre>
+        <pre className="mt-3 overflow-auto rounded bg-gray-900 p-3 text-xs text-green-400">
+          {JSON.stringify(
+            {
+              previousActiveUnknownNodeId,
+              newActiveUnknownNodeId,
+              resolvedUnknownNodeIds,
+              affectedNodeIds,
+            },
+            null,
+            2,
+          )}
+        </pre>
+      </details>
+    </div>
+  );
+}
@@ -0,0 +1,101 @@
+/**
+ * Investigation Map — user-facing workspace card.
+ *
+ * Shows the progress of reasoning as a set of investigation topics with
+ * simple status indicators. Does NOT expose graph internals.
+ *
+ * Design principles:
+ *   - Calm, spacious, accessible
+ *   - No percentages, no progress bars, no confidence scores
+ *   - Topics evolve naturally across turns
+ */
+
+import getInvestigationMapTopics from "@/lib/map/investigation-map-adapter";
+import React from "react";
+
+/* ── Status icons (unicode — no icon library dependency) ─── */
+
+const STATUS_ICONS = {
+  established: "✓",
+  current: "●",
+  unknown: "○",
+};
+
+function topicRowColor(status) {
+  switch (status) {
+    case "established":
+      return "text-gray-900";
+    case "current":
+      return "text-blue-800";
+    default:
+      return "text-gray-400";
+  }
+}
+
+function topicIconColor(status) {
+  switch (status) {
+    case "established":
+      return "text-green-600";
+    case "current":
+      return "text-blue-500";
+    default:
+      return "text-gray-300";
+  }
+}
+
+/* ── Single topic row ───────────────────────────────────── */
+
+function TopicRow({ title, status }) {
+  const icon = STATUS_ICONS[status];
+  const colorClass = topicRowColor(status);
+  const iconColor = topicIconColor(status);
+  const ariaLabel = `${status === "established" ? "Established" : status === "current" ? "Currently investigating" : "Still to explore"}: ${title}`;
+
+  return (
+    <div
+      className={`flex items-center gap-3 py-2.5 text-sm transition-opacity duration-300 ease-in-out ${colorClass}`}
+      aria-label={ariaLabel}
+      role="listitem"
+      data-testid={`map-topic-${status === "established" ? "established" : status === "current" ? "current" : "unknown"}`}
+    >
+      <span className={`flex-none text-base ${iconColor} leading-none`} aria-hidden="true">
+        {icon}
+      </span>
+      <span className="flex-1">{title}</span>
+    </div>
+  );
+}
+
+/* ── Card wrapper ────────────────────────────────────────── */
+
+export default function InvestigationMap({ turnCount = 0 }) {
+  const topics = getInvestigationMapTopics(turnCount);
+
+  // Group topics by status for cleaner rendering
+  const groups = {
+    established: topics.filter((t) => t.status === "established"),
+    current: topics.filter((t) => t.status === "current"),
+    unknown: topics.filter((t) => t.status === "unknown"),
+  };
+
+  // Only render the card if there are non-established topics (during active investigation)
+  const hasActiveTopics = groups.current.length > 0 || groups.unknown.length > 0;
+  if (!hasActiveTopics && groups.established.length === 0) return null;
+
+  return (
+    <div className="rounded-lg border border-gray-200/60 bg-gray-50/30 p-4" role="region" aria-label="Investigation map preview">
+      <h2 className="mb-1 text-[11px] font-medium tracking-widest uppercase text-gray-300">
+        Investigation Map
+      </h2>
+      <p className="mb-3 text-xs text-gray-400/70">
+        Active investigation topics and their status.
+      </p>
+
+      <div className="space-y-px border-t border-gray-200/60 pt-3" role="list" aria-label="Investigation topics">
+        {topics.map((topic, i) => (
+          <TopicRow key={`${topic.title}-${i}`} title={topic.title} status={topic.status} />
+        ))}
+      </div>
+    </div>
+  );
+}
@@ -0,0 +1,259 @@
+/**
+ * InvestigationSummaryPanelV2 — Phase 4, Experiment 11
+ * A facilitator-style progress panel that translates the reasoning graph
+ * into a human-friendly "what is known / what remains" view.
+ *
+ * Design principle:
+ *   The UI should progressively become a translation layer over the
+ *   reasoning graph rather than maintaining separate duplicated summaries.
+ *   Internal graph concepts remain available for developers, while end
+ *   users see a facilitator-style explanation of what is currently understood
+ *   and what remains uncertain.
+ *
+ * This component uses exactly the same graph data as InvestigationSummaryPanel
+ * (Version A). No new backend fields or API contracts are required.
+ */
+
+import React from "react";
+
+/* ── Helpers ──────────────────────────────────────────────── */
+
+function formatTimestamp(iso) {
+  if (!iso) return "—";
+  try {
+    const d = new Date(iso);
+    if (isNaN(d)) return iso;
+    const pad = (n) => String(n).padStart(2, "0");
+    return `${d.getFullYear()}-${pad(d.getMonth()+1)}-${pad(d.getDate())} ${pad(d.getHours())}:${pad(d.getMinutes())}`;
+  } catch {
+    return iso;
+  }
+}
+
+function humaniseDuration(seconds) {
+  if (!seconds || seconds < 0) return "—";
+  const mins = Math.floor(seconds / 60);
+  const secs = seconds % 60;
+  if (mins === 0) return `${secs}s`;
+  return `${mins}m ${secs}s`;
+}
+
+/* ── Data extraction helpers ─────────────────────────────── */
+
+/**
+ * Classify nodes into "known" (resolved / observations with values) and
+ * "still investigating" (unresolved unknowns and assumptions needing validation).
+ */
+function classifyNodes(graph, resolvedIds) {
+  if (!graph?.nodes) return { known: [], stillInvestigating: [] };
+
+  const resolved = new Set(resolvedIds || []);
+
+  const known = [];
+  const stillInvestigating = [];
+
+  for (const node of graph.nodes) {
+    const isResolved = resolved.has(node.id) || node.status === "resolved";
+
+    // Resolved nodes become known facts
+    if (isResolved) {
+      known.push({
+        label: node.label,
+        description: node.description,
+        kind: node.kind,
+        confidence: node.confidence,
+      });
+    } else {
+      // Unresolved unknowns and assumptions go into "still investigating"
+      stillInvestigating.push({
+        label: node.label,
+        description: node.description,
+        kind: node.kind,
+        confidence: node.confidence,
+      });
+    }
+  }
+
+  return { known, stillInvestigating };
+}
+
+/**
+ * Map graph node kinds to end-user-friendly group labels.
+ */
+function groupLabelForKind(kind) {
+  const map = {
+    unknown: "Still investigating",
+    assumption: "Assumptions to validate",
+    observation: "Observations",
+    state: "Current states",
+    metric: "Metrics",
+    conclusion: "Conclusions",
+  };
+  return map[kind] || kind.replace(/_/g, " ").replace(/\b\w/g, (c) => c.toUpperCase());
+}
+
+/* ── Rendering helpers ───────────────────────────────────── */
+
+/**
+ * Render a single item from the known or still-investigating lists.
+ * Show only meaningful content — hide labels that duplicate description.
+ */
+function renderListItem(item) {
+  // Prefer description if it adds something beyond the label
+  const text = (item.description && item.description !== item.label)
+    ? item.description
+    : item.label;
+
+  return text;
+}
+
+/* ── Component ────────────────────────────────────────────── */
+
+function InvestigationSummaryPanelV2({ graph, selectedQuestion, result, updateStatus }) {
+  // ── Status (same derivation logic as Version A) ──────────
+  const isInvestigating = Boolean(selectedQuestion);
+  const hasGraph = Boolean(graph);
+
+  let currentStatus;
+  if (updateStatus === "loading") {
+    currentStatus = { label: "Reasoning", level: "investigating" };
+  } else if (!hasGraph) {
+    currentStatus = { label: "Not started", level: "idle" };
+  } else if (isInvestigating) {
+    currentStatus = { label: "Investigation in progress", level: "investigating" };
+  } else if (graph.resolvedNodeIds?.length > 0 && graph.nodes) {
+    const unresolvedUnknowns = graph.nodes.filter(
+      (n) => n.kind === "unknown" && !graph.resolvedNodeIds.includes(n.id)
+    );
+    if (unresolvedUnknowns.length === 0) {
+      currentStatus = { label: "Investigation complete", level: "complete" };
+    } else {
+      currentStatus = { label: "Current evidence limit reached", level: "limit" };
+    }
+  } else {
+    currentStatus = { label: "Analysis complete", level: "complete" };
+  }
+
+  const statusColors = {
+    idle:        { border: "border-gray-200/60",   bg: "bg-gray-50/40",    text: "text-gray-400" },
+    investigating: { border: "border-blue-200/60",  bg: "bg-blue-50/30",   text: "text-blue-600" },
+    complete:    { border: "border-green-200/60",   bg: "bg-green-50/30",  text: "text-green-600" },
+    limit:       { border: "border-gray-200",    bg: "bg-gray-50/40",  text: "text-gray-400" },
+  };
+
+  const colors = statusColors[currentStatus.level] || statusColors.idle;
+
+  // ── Current understanding (same source as Version A) ────
+  const currentUnderstanding =
+    result?.summary ||
+    result?.updatedSituationGraph?.currentSummary ||
+    graph?.currentSummary ||
+    null;
+
+  // ── Classify graph data ─────────────────────────────────
+  const resolvedIds = new Set(graph?.resolvedNodeIds || []);
+  const { known, stillInvestigating } = classifyNodes(graph, resolvedIds);
+
+  // Group still-investigating items by kind for a cleaner view
+  const investigatingByGroup = {};
+  for (const item of stillInvestigating) {
+    const key = groupLabelForKind(item.kind);
+    if (!investigatingByGroup[key]) investigatingByGroup[key] = [];
+    investigatingByGroup[key].push(item);
+  }
+
+  // ── Reasoning summary counts (quiet, at bottom) ─────────
+  const reasonCounts = {
+    observations: graph?.nodes?.filter((n) => n.kind === "observation").length || 0,
+    unknowns: stillInvestigating.filter((n) => n.kind === "unknown").length || 0,
+    assumptions: graph?.nodes?.filter((n) => n.kind === "assumption" && !resolvedIds.has(n.id)).length || 0,
+    relationships: graph?.edges?.length || 0,
+    metrics: graph?.nodes?.filter((n) => n.kind === "metric").length || 0,
+    states: graph?.nodes?.filter((n) => n.kind === "state").length || 0,
+    conclusions: graph?.nodes?.filter((n) => n.kind === "conclusion").length || 0,
+  };
+
+  // Only show non-zero counts in the reasoning summary
+  const reasonEntries = Object.entries(reasonCounts).filter(([_, v]) => v > 0);
+
+  return (
+    <div className={`rounded-lg border ${colors.border} ${colors.bg} p-5 space-y-4`}>
+      {/* Status — minimal indicator */}
+      <div className="flex items-center gap-2">
+        <span className={`inline-block h-2.5 w-2.5 rounded-full bg-current ${colors.text}`} />
+        <span className={`text-sm font-medium ${colors.text}`}>{currentStatus.label}</span>
+      </div>
+
+      {/* ── Current understanding (if any) ──────────────── */}
+      {currentUnderstanding && (
+        <div>
+          <p className="text-sm leading-relaxed text-gray-600">{currentUnderstanding}</p>
+        </div>
+      )}
+
+      {/* ── Still investigating — primary focus ─────────── */}
+      {(stillInvestigating.length > 0 || known.length === 0) && (
+        <div>
+          {stillInvestigating.length > 1 ? (
+            <>
+              <h3 className="mb-2 text-xs font-medium text-gray-400">Still investigating</h3>
+              <ul className="space-y-1.5">
+                {Object.entries(investigatingByGroup).map(([group, items]) => (
+                  <li key={group}>
+                    <span className="text-xs font-medium text-gray-500">{group}</span>
+                    <ul className="mt-1 space-y-1">
+                      {items.map((item, i) => (
+                        <li key={i} className="flex items-start gap-2">
+                          <span className="mt-1.5 h-1.5 w-1.5 shrink-0 rounded-full bg-blue-400/60" />
+                          <span className="text-sm text-gray-700">
+                            {renderListItem(item)}
+                          </span>
+                        </li>
+                      ))}
+                    </ul>
+                  </li>
+                ))}
+              </ul>
+            </>
+          ) : stillInvestigating.length === 1 ? (
+            <div className="flex items-start gap-2">
+              <span className="mt-1.5 h-1.5 w-1.5 shrink-0 rounded-full bg-blue-400/60" />
+              <p className="text-sm text-gray-700">{renderListItem(stillInvestigating[0])}</p>
+            </div>
+          ) : null}
+        </div>
+      )}
+
+      {/* ── What we have learned ────────────────────────── */}
+      {known.length > 0 && (
+        <div>
+          <h3 className="mb-2 text-xs font-medium text-gray-400">What we know</h3>
+          <ul className="space-y-1.5">
+            {known.map((item, i) => (
+              <li key={i} className="flex items-start gap-2">
+                <span className="mt-1 h-4 w-4 shrink-0 rounded-full bg-green-400/30" style={{ fontSize: "8px", lineHeight: "1" }}>✓</span>
+                <span className="text-sm text-gray-700">
+                  {renderListItem(item)}
+                </span>
+              </li>
+            ))}
+          </ul>
+        </div>
+      )}
+
+      {/* ── Quiet reasoning summary — secondary ─────────── */}
+      <div className="pt-2 border-t border-gray-200/40">
+        <p className="text-[10px] font-medium tracking-widest uppercase text-gray-300 mb-1.5">Reasoning</p>
+        <div className="flex flex-wrap gap-x-4 gap-y-1 text-xs text-gray-400">
+          {reasonEntries.map(([label, count]) => (
+            <span key={label}>
+              {count} {label}
+            </span>
+          ))}
+        </div>
+      </div>
+    </div>
+  );
+}
+
+export default InvestigationSummaryPanelV2;
@@ -0,0 +1,173 @@
+/**
+ * InvestigationSummaryPanelV3 — Phase 4, Experiment 12
+ * A user-facing facilitator view that translates the reasoning graph into
+ * a concise, human-meaningful presentation.
+ *
+ * Design principles:
+ *   - The panel shows up to four sections: what we know, still investigating,
+ *     possible explanations, and a quiet summary.
+ *   - All content is grounded in existing graph fields. No invented facts.
+ *   - Epistemic labels are explicit (structural), not colour-dependent.
+ *   - The same panel remains useful during early, active and terminal states.
+ */
+
+import { buildFacilitatorViewModel } from "@/lib/presentation/facilitator-view-adapter";
+import React from "react";
+
+/* ── Item rendering ─────────────────────────────────────────────── */
+
+/**
+ * Render a single item with its structural label where applicable.
+ */
+function renderItem(item, isExplanation) {
+  if (isExplanation && typeof item === "object") {
+    return (
+      <li key={item.text} className="flex items-start gap-2">
+        <span className="mt-[3px] h-1.5 w-1.5 shrink-0 rounded-full bg-gray-400/50" />
+        <span className="text-sm text-gray-700">{item.text}</span>
+        <span className="ml-auto mt-[-2px] shrink-0 whitespace-nowrap text-[10px] font-medium tracking-wide text-gray-400">
+          {item.label}
+        </span>
+      </li>
+    );
+  }
+
+  return (
+    <li key={item} className="flex items-start gap-2">
+      <span className="mt-[3px] h-1.5 w-1.5 shrink-0 rounded-full bg-gray-400/50" />
+      <span className="text-sm text-gray-700">{item}</span>
+    </li>
+  );
+}
+
+/* ── Section components ──────────────────────────────────────────── */
+
+function KnownSection({ title, items }) {
+  if (!items || items.length === 0) return null;
+
+  return (
+    <div>
+      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-400">
+        {title}
+      </h3>
+      <ul className="space-y-1.5">
+        {items.map((item, i) => (
+          <li key={i} className="flex items-start gap-2">
+            <span className="mt-[3px] h-1.5 w-1.5 shrink-0 rounded-full bg-gray-500" />
+            <span className="text-sm text-gray-700">{item}</span>
+          </li>
+        ))}
+      </ul>
+    </div>
+  );
+}
+
+function InvestigatingSection({ title, items }) {
+  if (!items || items.length === 0) return null;
+
+  return (
+    <div>
+      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-400">
+        {title}
+      </h3>
+      <ul className="space-y-1.5">
+        {items.map((item, i) => (
+          <li key={i} className="flex items-start gap-2">
+            <span className="mt-[3px] h-1.5 w-1.5 shrink-0 rounded-full bg-gray-400/60" />
+            <span className="text-sm text-gray-700">{item}</span>
+          </li>
+        ))}
+      </ul>
+    </div>
+  );
+}
+
+function ExplanationSection({ items }) {
+  if (!items || items.length === 0) return null;
+
+  return (
+    <div>
+      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-400">
+        Possible explanations
+      </h3>
+      <ul className="space-y-1.5">
+        {items.map((item, i) => renderItem(item, true))}
+      </ul>
+    </div>
+  );
+}
+
+function QuietSummary({ text }) {
+  if (!text) return null;
+
+  return (
+    <div className="pt-2 border-t border-gray-200/40">
+      <p className="text-[10px] font-medium tracking-widest uppercase text-gray-300 mb-1.5">
+        Investigation state
+      </p>
+      <p className="text-xs text-gray-400">{text}</p>
+    </div>
+  );
+}
+
+/* ── Empty-state fallback ──────────────────────────────────────── */
+
+function EmptyState() {
+  return (
+    <div className="space-y-3">
+      <KnownSection title="What we know" items={[]} />
+      <InvestigatingSection title="Still investigating" items={[]} />
+      {/* Intentionally no Possible explanations section when empty */}
+      <QuietSummary text={null} />
+      <div className="flex items-start gap-2">
+        <span className="mt-[3px] h-1.5 w-1.5 shrink-0 rounded-full bg-gray-400/50" />
+        <p className="text-sm text-gray-500 italic">We are still establishing the basic facts.</p>
+      </div>
+    </div>
+  );
+}
+
+/* ── Main component ────────────────────────────────────────────── */
+
+function InvestigationSummaryPanelV3({ graph, selectedQuestion, result }) {
+  // Build the view model from the adapter
+  const resolvedIds = new Set(graph?.resolvedNodeIds || []);
+
+  const viewModel = buildFacilitatorViewModel({
+    nodes: graph?.nodes || [],
+    resolvedIds,
+    activeUnknownNodeId: graph?.activeUnknownNodeId || null,
+    edges: graph?.edges || [],
+    selectedQuestion,
+  });
+
+  // Early state fallback
+  if (!viewModel.known.hasItems && !viewModel.investigating.hasItems) {
+    return <EmptyState />;
+  }
+
+  return (
+    <div className="rounded-lg border border-gray-200/60 bg-gray-50/40 p-5 space-y-4">
+      {/* What we know */}
+      <KnownSection title={viewModel.known.title} items={viewModel.known.items} />
+
+      {/* Still investigating — or "Remaining cautions" in terminal state */}
+      {!viewModel.investigating.shouldOmit && (
+        <InvestigatingSection
+          title={viewModel.investigating.title}
+          items={viewModel.investigating.items}
+        />
+      )}
+
+      {/* Possible explanations */}
+      {viewModel.explanations.hasItems && (
+        <ExplanationSection items={viewModel.explanations.items} />
+      )}
+
+      {/* Quiet reasoning summary */}
+      <QuietSummary text={viewModel.summary.text} />
+    </div>
+  );
+}
+
+export default InvestigationSummaryPanelV3;
@@ -0,0 +1,154 @@
+/**
+ * InvestigationSummaryPanel — Phase 4
+ * Displays key investigation metrics in a compact card.
+ * Some fields are currently mocked; TODO comments identify what the
+ * reasoning engine must eventually provide.
+ */
+
+/* ── Helpers ──────────────────────────────────────────────── */
+
+import React from "react";
+
+function formatTimestamp(iso) {
+  if (!iso) return "—";
+  try {
+    const d = new Date(iso);
+    if (isNaN(d)) return iso;
+    const pad = (n) => String(n).padStart(2, "0");
+    return `${d.getFullYear()}-${pad(d.getMonth()+1)}-${pad(d.getDate())} ${pad(d.getHours())}:${pad(d.getMinutes())}`;
+  } catch {
+    return iso;
+  }
+}
+
+function humaniseDuration(seconds) {
+  if (!seconds || seconds < 0) return "—";
+  const mins = Math.floor(seconds / 60);
+  const secs = seconds % 60;
+  if (mins === 0) return `${secs}s`;
+  return `${mins}m ${secs}s`;
+}
+
+/* ── Component ────────────────────────────────────────────── */
+
+function InvestigationSummaryPanel({ graph, selectedQuestion, result, updateStatus }) {
+  // ── Current status ────────────────────────────────────────────
+  // TODO: reasoning should emit an explicit status field such as
+  //   "investigating", "evidence_limit_reached", "resolution_achieved".
+  // Currently derived heuristically from graph state.
+  const isInvestigating = Boolean(selectedQuestion);
+  const hasGraph = Boolean(graph);
+
+  let currentStatus;
+  if (updateStatus === "loading") {
+    currentStatus = { label: "Reasoning", level: "investigating" };
+  } else if (!hasGraph) {
+    currentStatus = { label: "Not started", level: "idle" };
+  } else if (isInvestigating) {
+    currentStatus = { label: "Investigation in progress", level: "investigating" };
+  } else if (graph.resolvedNodeIds?.length > 0 && graph.nodes) {
+    const unresolvedUnknowns = graph.nodes.filter(
+      (n) => n.kind === "unknown" && !graph.resolvedNodeIds.includes(n.id)
+    );
+    if (unresolvedUnknowns.length === 0) {
+      currentStatus = { label: "Investigation complete", level: "complete" };
+    } else {
+      // TODO: reasoning should emit a terminal "evidence_limit_reached"
+      // status when it stops selecting questions because no unknown has
+      // sufficient upstream evidence. Currently we infer this from the
+      // absence of an active question combined with unresolved unknowns.
+      currentStatus = { label: "Current evidence limit reached", level: "limit" };
+    }
+  } else {
+    currentStatus = { label: "Analysis complete", level: "complete" };
+  }
+
+  const statusColors = {
+    idle:        { border: "border-gray-200/60",   bg: "bg-gray-50/40",    text: "text-gray-400" },
+    investigating: { border: "border-blue-200/60",  bg: "bg-blue-50/30",   text: "text-blue-600" },
+    complete:    { border: "border-green-200/60",   bg: "bg-green-50/30",  text: "text-green-600" },
+    limit:       { border: "border-gray-200",    bg: "bg-gray-50/40",  text: "text-gray-400" },
+  };
+
+  const colors = statusColors[currentStatus.level] || statusColors.idle;
+
+  // ── Current understanding ────────────────────────────────
+  // TODO: reasoning should provide a durable summary field that is
+  // guaranteed to be the latest plain-language synthesis.
+  // Currently falls back to graph.currentSummary which may not exist
+  // in all mock scenarios.
+  const currentUnderstanding =
+    result?.summary ||
+    result?.updatedSituationGraph?.currentSummary ||
+    graph?.currentSummary ||
+    null;
+
+  // ── Questions answered / remaining ───────────────────────
+  // TODO: reasoning should emit a list of resolved unknown node IDs
+  // and the total set of unknown nodes it identified at start.
+  // Currently we count from the graph snapshot: every unknown whose
+  // status is "resolved" (or whose ID appears in resolvedNodeIds).
+  let questionsAnswered = 0;
+  let questionsRemaining = 0;
+
+  if (graph?.nodes) {
+    const allUnknowns = graph.nodes.filter((n) => n.kind === "unknown");
+    const resolvedCount = allUnknowns.filter(
+      (n) => n.status === "resolved" || (graph.resolvedNodeIds && graph.resolvedNodeIds.includes(n.id))
+    ).length;
+    questionsAnswered = resolvedCount;
+    // TODO: this is a rough heuristic — the reasoning engine should
+    // explicitly track which unknowns were proposed for questioning.
+    questionsRemaining = allUnknowns.length - resolvedCount;
+  }
+
+  // ── Timestamps ───────────────────────────────────────────
+  // TODO: reasoning should provide investigationStartedAt and
+  // lastUpdatedAt as part of the start/update contract.
+  // Currently we use the session updatedAt timestamp (persisted by
+  // the UI layer) as a best-effort approximation.
+  const investigationStartTime = result?.updatedAt || null;
+  const lastUpdatedAt = result?.updatedAt || null;
+
+  // Derive elapsed time since last update
+  let elapsedSeconds = 0;
+  if (lastUpdatedAt) {
+    elapsedSeconds = Math.floor((Date.now() - new Date(lastUpdatedAt).getTime()) / 1000);
+  }
+
+  return (
+    <div className={`rounded-lg border ${colors.border} ${colors.bg} p-5 space-y-4`}>
+      {/* Status */}
+      <div className="flex items-center gap-2">
+        <span className={`inline-block h-2.5 w-2.5 rounded-full bg-current ${colors.text}`} />
+        <span className={`text-sm font-medium ${colors.text}`}>{currentStatus.label}</span>
+      </div>
+
+      {/* Current understanding */}
+      {currentUnderstanding && (
+        <div>
+          <h3 className="mb-1 text-[11px] font-medium tracking-widest uppercase text-gray-400/70">
+            What we understand so far
+          </h3>
+          <p className="text-sm leading-relaxed text-gray-600">{currentUnderstanding}</p>
+        </div>
+      )}
+
+      {/* Questions — hidden when no meaningful value to show */}
+      {isInvestigating && questionsRemaining > 0 && (
+        <div className="grid grid-cols-2 gap-4">
+          <div>
+            <span className="block text-xs text-gray-400">Questions answered</span>
+            <span className={`text-lg font-semibold ${colors.text}`}>{questionsAnswered}</span>
+          </div>
+          <div>
+            <span className="block text-xs text-gray-400">Still working on</span>
+            <span className={`text-lg font-semibold ${colors.text}`}>{questionsRemaining + " items"}</span>
+          </div>
+        </div>
+      )}
+    </div>
+  );
+}
+
+export default InvestigationSummaryPanel;
@@ -0,0 +1,829 @@
+"use client";
+
+import React, { useState, useRef, useEffect, useMemo } from "react";
+import DiagnosticsView from "@/components/diagnostics-view";
+import GraphUpdateView from "@/components/graph-update-view";
+import SituationGraphView from "@/components/situation-graph-view";
+import InvestigationSummaryPanel from "@/components/investigation-summary-panel";
+import InvestigationSummaryPanelV2 from "@/components/investigation-summary-panel-v2";
+import InvestigationSummaryPanelV3 from "@/components/investigation-summary-panel-v3";
+import InvestigationMap from "@/components/investigation-map";
+
+// ── Technical summary detector (main view filters these) ───
+const TECHNICAL_PATTERNS = [
+  /nodes?\s*[:\d]/i,
+  /edges?\s*[:\d]/i,
+  /\b(?:unknown|observation|conclusion)\b\s/i,
+  /\bsorted\b/i,
+  /by_kind/i,
+  /\b(?:node|edge|unknown|state)\s+count/i,
+];
+
+function isTechnicalSummary(summary) {
+  if (!summary || typeof summary !== "string") return false;
+  const trimmed = summary.trim();
+  if (!trimmed) return false;
+  for (const p of TECHNICAL_PATTERNS) {
+    if (p.test(trimmed)) return true;
+  }
+  return false;
+}
+
+// ── Recovery state components (Phase 2) ───────────────────────
+
+function ProviderUnavailableCard({ onRestart }) {
+  return (
+    <div className="rounded-lg border border-amber-300 bg-amber-50 px-5 py-6 text-center">
+      <h2 className="mb-1 text-sm font-bold uppercase tracking-wide text-amber-700">Provider unavailable</h2>
+      <p className="text-sm text-amber-800 mb-4">
+        The reasoning service could not be reached. This is usually temporary — check that the local model is running and try again.
+      </p>
+      {onRestart && (
+        <button
+          onClick={onRestart}
+          className="rounded-lg border border-amber-300 bg-white px-4 py-2 text-sm font-medium text-amber-800 hover:bg-amber-100"
+        >
+          Restart investigation
+        </button>
+      )}
+    </div>
+  );
+}
+
+function MalformedResponseCard({ onRestart }) {
+  return (
+    <div className="rounded-lg border border-orange-300 bg-orange-50 px-5 py-6 text-center">
+      <h2 className="mb-1 text-sm font-bold uppercase tracking-wide text-orange-700">Unexpected response</h2>
+      <p className="text-sm text-orange-800 mb-4">
+        The reasoning service returned a response we could not interpret. This may indicate a temporary issue with the model output format.
+      </p>
+      {onRestart && (
+        <button
+          onClick={onRestart}
+          className="rounded-lg border border-orange-300 bg-white px-4 py-2 text-sm font-medium text-orange-800 hover:bg-orange-100"
+        >
+          Try again
+        </button>
+      )}
+    </div>
+  );
+}
+
+function UnexpectedStateCard({ stateName, onRetry, onRestart }) {
+  return (
+    <div className="rounded-lg border border-red-300 bg-red-50 px-5 py-6 text-center">
+      <h2 className="mb-1 text-sm font-bold uppercase tracking-wide text-red-700">Unexpected state</h2>
+      <p className="text-sm text-red-800 mb-4">
+        {stateName ? `The system is in an unexpected state (${stateName}).` : "An unexpected internal error occurred."}
+        Please restart the investigation to continue.
+      </p>
+      <div className="flex items-center justify-center gap-3">
+        {onRetry && (
+          <button
+            onClick={onRetry}
+            className="rounded-lg border border-red-300 bg-white px-4 py-2 text-sm font-medium text-red-800 hover:bg-red-100"
+          >
+            Retry update
+          </button>
+        )}
+        {onRestart && (
+          <button
+            onClick={onRestart}
+            className="rounded-lg bg-red-700 px-4 py-2 text-sm font-medium text-white hover:bg-red-600"
+          >
+            Restart investigation
+          </button>
+        )}
+      </div>
+    </div>
+  );
+}
+
+function ContinueLaterBanner({ onRestart }) {
+  return (
+    <div className="rounded-lg border border-blue-200/60 bg-blue-50/40 px-5 py-4 text-center">
+      <p className="text-sm text-blue-700/70">
+        Your previous investigation state is still saved. You can continue where you left off or start fresh.
+      </p>
+      {onRestart && (
+        <button
+          onClick={onRestart}
+          className="mt-2 text-sm font-medium text-blue-700 underline hover:text-blue-900"
+        >
+          Restart investigation
+        </button>
+      )}
+    </div>
+  );
+}
+
+// ── Session persistence hook (Phase 3) ────────────────────────
+
+function useSessionPersistence() {
+  const [sessionReady, setSessionReady] = useState(false);
+  const sessionKey = "confidence-engine-session";
+
+  function saveSession(state) {
+    if (typeof sessionStorage === "undefined") return;
+    try {
+      sessionStorage.setItem(sessionKey, JSON.stringify(state));
+    } catch (_) { /* quota or disabled — ignore silently */ }
+  }
+
+  function loadSession() {
+    if (typeof sessionStorage === "undefined") return null;
+    try {
+      const raw = sessionStorage.getItem(sessionKey);
+      return raw ? JSON.parse(raw) : null;
+    } catch (_) {
+      return null;
+    }
+  }
+
+  function clearSession() {
+    if (typeof sessionStorage === "undefined") return;
+    try { sessionStorage.removeItem(sessionKey); } catch (_) {}
+  }
+
+  return { saveSession, loadSession, clearSession, sessionReady: true };
+}
+
+// ── Current understanding card ────────────────────────────────
+
+// Evidence-limit text that must not appear inside Current understanding
+// when the terminal outcome already communicates that state.
+const EVIDENCE_LIMIT_PHRASES = [
+  "The available evidence has reached its current limit",
+  "evidence has reached its current limit",
+  "evidence limit reached",
+  "has reached its current limit",
+];
+
+function resolveCurrentSummary(currentSummary) {
+  if (!currentSummary || typeof currentSummary !== "string") return null;
+  const trimmed = currentSummary.trim();
+  if (!trimmed) return null;
+
+  // Filter out technical graph summaries
+  for (const p of TECHNICAL_PATTERNS) {
+    if (p.test(trimmed)) return null;
+  }
+
+  // Don't show evidence-limit text in Current understanding when
+  // the terminal outcome card already communicates that state.
+  const lower = trimmed.toLowerCase();
+  for (const phrase of EVIDENCE_LIMIT_PHRASES) {
+    if (lower.includes(phrase)) return null;
+  }
+
+  return trimmed;
+}
+
+// ── Status message pools for loading feedback ────────────────
+const INITIAL_MESSAGES = [
+  { min: 0, text: "Reading your situation" },
+  { min: 10, text: "Building a structured understanding" },
+  { min: 25, text: "Identifying what is known and still unclear" },
+  { min: 45, text: "Selecting the next useful question" },
+];
+
+const UPDATE_MESSAGES = [
+  { min: 0, text: "Considering your answer" },
+  { min: 10, text: "Updating the situation" },
+  { min: 25, text: "Checking what changed" },
+  { min: 45, text: "Choosing the next question" },
+];
+
+function useLoadingStatus(messages, isLoading) {
+  const [elapsed, setElapsed] = useState(0);
+  const startRef = useRef(null);
+
+  useEffect(() => {
+    if (isLoading) {
+      startRef.current = Date.now();
+      const iv = setInterval(() => {
+        setElapsed(Math.floor((Date.now() - startRef.current) / 1000));
+      }, 1000);
+      return () => clearInterval(iv);
+    } else {
+      setElapsed(0);
+      startRef.current = null;
+    }
+  }, [isLoading]);
+
+  const currentMessage = useMemo(() => {
+    if (!messages || messages.length === 0) return "";
+    let msg = messages[0].text;
+    for (const m of messages) {
+      if (elapsed >= m.min) msg = m.text;
+    }
+    return msg;
+  }, [messages, elapsed]);
+
+  return { elapsed, currentMessage };
+}
+
+// ── Spinner component ───────────────────────────────────────
+function ActivitySpinner() {
+  return (
+    <span
+      className="inline-block h-4 w-4 border-[2px] border-gray-300 border-t-gray-600 rounded-full"
+      style={{ animation: "spin 1s linear infinite" }}
+    />
+  );
+}
+
+// ── Current investigation card (prominent hero section) ──────
+function CurrentInvestigationCard({ selectedQuestion, graph }) {
+  if (!selectedQuestion) return null;
+
+  const q = typeof selectedQuestion === "string" ? selectedQuestion : selectedQuestion.question;
+  if (!q) return null;
+
+  // Derive meaningful context from the active node only when it adds value
+  let whyMattersText = null;
+  if (graph?.activeUnknownNodeId && graph.nodes) {
+    const activeNode = graph.nodes.find((n) => n.id === graph.activeUnknownNodeId);
+    if (activeNode?.description && activeNode.description !== activeNode.label) {
+      whyMattersText = activeNode.description;
+    }
+  }
+
+  return (
+    <div className="investigation-card rounded-lg border-[2.5px] border-green-400 bg-gradient-to-b from-green-50 to-white p-8 shadow-sm">
+      <h2 className="mb-3 text-xs font-bold tracking-widest uppercase text-green-600/70">
+        Investigation
+      </h2>
+      <p className="text-2xl font-semibold leading-tight text-gray-900">{q}</p>
+      {whyMattersText && (
+        <p className="mt-5 text-sm leading-relaxed text-green-800/80">
+          {whyMattersText}
+        </p>
+      )}
+    </div>
+  );
+}
+
+// ── Outcome helpers ───────────────────────────────────────────
+
+function hasGenuineCompletion(graph) {
+  if (!graph || !graph.nodes?.length) return false;
+  const resolvedIds = new Set(graph.resolvedNodeIds || []);
+  const unresolvedCount = graph.nodes.filter(
+    (n) => n.kind === "unknown" && n.status !== "resolved" && !resolvedIds.has(n.id),
+  ).length;
+  if (unresolvedCount > 0) return false;
+  if (graph.activeUnknownNodeId) {
+    const active = graph.nodes.find((n) => n.id === graph.activeUnknownNodeId);
+    if (active && active.status !== "resolved" && !resolvedIds.has(active.id)) return false;
+  }
+  return true;
+}
+
+// ── Completion card (terminal state when all unknowns resolved) ─
+function CompletionCard({ summary }) {
+  return (
+    <div className="rounded-lg border border-green-300 bg-green-50 px-5 py-6 text-center">
+      <h2 className="mb-1 text-sm font-bold uppercase tracking-wide text-green-700">Investigation complete</h2>
+      <p className="text-base text-gray-800 mb-3">The available evidence supports the following understanding.</p>
+      {summary && (
+        <div className="mt-4 text-left rounded-md bg-white/60 px-4 py-3 border border-green-100">
+          <p className="text-sm leading-relaxed text-gray-700">{summary}</p>
+        </div>
+      )}
+    </div>
+  );
+}
+
+// ── Evidence-limit card (terminal state: no next question) ───────
+function EvidenceLimitCard({ summary }) {
+  return (
+    <div className="rounded-lg border border-gray-200 bg-gray-50 px-5 py-6 text-center">
+      <h2 className="mb-1 text-sm font-bold uppercase tracking-wide text-gray-500">Current evidence limit reached</h2>
+      {summary && (
+        <div className="mt-4 text-left rounded-md bg-white/60 px-4 py-3 border border-gray-100">
+          <p className="text-sm leading-relaxed text-gray-700">{summary}</p>
+        </div>
+      )}
+      <p className="mt-3 text-base text-gray-700">Further progress requires additional evidence.</p>
+    </div>
+  );
+}
+
+// ── Current understanding card ────────────────────────────────
+function CurrentUnderstandingCard({ currentSummary, plainLanguage }) {
+  if (plainLanguage) return <PlainLanguageCard summary={plainLanguage} />;
+
+  const summary = resolveCurrentSummary(currentSummary);
+
+  if (!summary) return null;
+
+  return (
+    <div className="rounded-lg border border-gray-100/80 bg-transparent px-6 pt-5 pb-6">
+      <h2 className="mb-3 text-[11px] font-medium tracking-widest uppercase text-gray-300">
+        Understanding
+      </h2>
+      <p className="text-sm leading-relaxed text-gray-600">{summary}</p>
+    </div>
+  );
+}
+
+// ── Plain-language understanding card (from pipeline summary) ──
+function PlainLanguageCard({ summary }) {
+  if (!summary) return null;
+
+  return (
+    <div className="rounded-lg border border-gray-100/80 bg-transparent px-6 pt-5 pb-6">
+      <h2 className="mb-3 text-[11px] font-medium tracking-widest uppercase text-gray-300">
+        Understanding
+      </h2>
+      <p className="text-sm leading-relaxed text-gray-600">{summary}</p>
+    </div>
+  );
+}
+
+// ── Investigation history card (readable notebook style) ──────
+function InvestigationHistoryCard({ turn }) {
+  const isCollapsed = turn._collapsed;
+  const isAnswered = Boolean(turn.answer?.trim());
+
+  const displayedQuestion = turn.question;
+
+  return (
+    <details
+      className="rounded-lg border border-gray-200/60 bg-gray-50/30"
+      key={turn.id}
+      open={!isCollapsed}
+      data-testid="investigation-turn"
+    >
+      <summary className="cursor-pointer px-4 py-2 text-sm font-medium text-gray-700 hover:text-gray-900">
+        {isAnswered && <span aria-hidden="true">✓ </span>}
+        {displayedQuestion}
+      </summary>
+
+      <div className="space-y-2 px-4 pb-4 pt-2">
+        <p className="text-gray-700">{turn.answer}</p>
+
+        {turn.acknowledgement && (
+          <p className="italic text-gray-500">
+            {turn.acknowledgement}
+          </p>
+        )}
+      </div>
+    </details>
+  );
+}
+
+// ── Investigation history section ─────────────────────────────
+function InvestigationHistory({ turns }) {
+  if (!turns || turns.length === 0) return null;
+
+  const latestId = turns[turns.length - 1].id;
+
+  return (
+    <div className="space-y-3" data-testid="investigation-history">
+      <h2 className="text-[11px] font-medium tracking-widest uppercase text-gray-300">
+        History
+      </h2>
+      <div className="space-y-2">
+        {turns.map((turn) => (
+          <InvestigationHistoryCard key={turn.id} data-testid="investigation-turn" turn={{ ...turn, _collapsed: turn.id !== latestId }} />
+        ))}
+      </div>
+    </div>
+  );
+}
+
+// ── Original situation (always-visible reference card) ────────
+function OriginalSituation({ scenario, centralStatement }) {
+  const text = scenario || centralStatement;
+
+  if (!text) return null;
+
+  return (
+    <div className="rounded-lg border border-gray-200/60 bg-gray-50/40 px-5 py-4">
+      <h2 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-300">
+        Situation
+      </h2>
+
+      <p className="whitespace-pre-wrap text-sm leading-relaxed text-gray-600">
+        {text}
+      </p>
+    </div>
+  );
+}
+
+// ── Transient acknowledgement (auto-dismisses after 3s) ─────────
+
+function useAutoDismiss(duration = 3000) {
+  const [visible, setVisible] = useState(true);
+
+  useEffect(() => {
+    if (!visible) return;
+    const timer = setTimeout(() => setVisible(false), duration);
+    return () => clearTimeout(timer);
+  }, [visible, duration]);
+
+  return visible;
+}
+
+function UpdateAcknowledgement({ updateResult }) {
+  const visible = useAutoDismiss(3000);
+
+  if (!updateResult || !visible) return null;
+
+  const summary = updateResult.summary;
+
+  return (
+    <div
+      className="transition-all duration-1500 ease-in"
+      style={{ opacity: visible ? 0.7 : 0, maxHeight: visible ? "4rem" : "0", marginBottom: visible ? "1rem" : "0" }}
+    >
+      <div className="rounded-md border border-blue-200/60 bg-blue-50/30 px-4 py-2 text-xs text-blue-700/60">
+        {summary}
+      </div>
+    </div>
+  );
+}
+
+// ── Developer details disclosure ──────────────────────────────
+function DeveloperDetails({ graph, selectedQuestion, diagnostics, newlySurfacedNodeIds, updateResult }) {
+  return (
+    <details className="rounded-lg border border-gray-200/60 bg-gray-50/30">
+      <summary className="cursor-pointer px-5 py-3 text-sm font-medium text-gray-400 hover:text-gray-600">
+        Developer details
+      </summary>
+      <div className="border-t border-gray-200/60 px-5 pb-4 pt-3 space-y-4">
+        {graph && (
+          <SituationGraphView
+            situationGraph={graph}
+            selectedQuestion={selectedQuestion}
+            newlySurfacedNodeIds={newlySurfacedNodeIds}
+          />
+        )}
+        {updateResult && (
+          <GraphUpdateView updateResult={{ ...updateResult, previousSituationGraph: graph }} />
+        )}
+        {diagnostics && <DiagnosticsView result={{ diagnostics }} />}
+      </div>
+    </details>
+  );
+}
+
+// ── Loading overlay (for both start and update) ───────────────
+function LoadingOverlay({ isLoading, elapsed, currentMessage, variant }) {
+  if (!isLoading) return null;
+
+  const messages = variant === "update" ? UPDATE_MESSAGES : INITIAL_MESSAGES;
+  let statusText = messages[0].text;
+  for (const m of messages) {
+    if (elapsed >= m.min) statusText = m.text;
+  }
+
+  return (
+    <div className="rounded-lg border border-blue-200/60 bg-blue-50/40 px-6 py-7" role="status" aria-busy="true" data-testid="loading-overlay">
+      <div className="flex items-center gap-3">
+        <ActivitySpinner />
+        <span className="text-base font-medium text-blue-800/70">Working through your situation</span>
+      </div>
+      <p className="mt-3 text-sm text-blue-600/60">{statusText}</p>
+      <p className="mt-2 text-xs text-blue-400/50" aria-live="polite">
+        This has been running for {elapsed}s.
+        {variant === "initial" && elapsed >= 45 && (
+          <span className="block mt-1">This can take around a minute with the current local model.</span>
+        )}
+      </p>
+    </div>
+  );
+}
+
+// ── Main workspace component ──────────────────────────────────
+
+function getErrorType(errorStr, stage, hasGraph) {
+  if (!errorStr && !stage) return null;
+  const lower = (errorStr || "").toLowerCase();
+  if (/provider|unavailable|network|timeout/.test(lower)) return "provider-unavailable";
+  if (/malformed|invalid.*format|parse|structured/.test(lower)) return "malformed-response";
+  if (stage === "provider") return "provider-error";
+  if (stage === "unexpected") return "unexpected-state";
+  if (/validation/.test(lower) && !hasGraph) return "no-graph";
+  return null;
+}
+
+export default function ReasoningWorkspace({
+  scenario,
+  status,
+  updateStatus,
+  currentUnderstanding: propUnderstanding,
+  result,
+  answer,
+  setAnswer,
+  onAnswerSubmit,
+  lastSubmittedAnswer,
+  onRestart,
+}) {
+  const [investigationHistory, setInvestigationHistory] = useState([]);
+  const turnCounter = useRef(0);
+  const pendingTurnRef = useRef(null);
+  // ── Experiment 12: toggle between progress panel versions (temporary experimental UI) ──
+  const [panelVariant, setPanelVariant] = useState("c");
+  const { saveSession, loadSession } = useSessionPersistence();
+
+  // Persist workspace state on every successful update (Phase 3)
+  useEffect(() => {
+    if (updateStatus === "success" && result?.situationGraph) {
+      saveSession({
+        scenario,
+        situationGraph: result.situationGraph,
+        selectedQuestion: result.selectedQuestion,
+        summary: result.summary || propUnderstanding,
+        updatedAt: new Date().toISOString(),
+      });
+    }
+  }, [updateStatus, result]);
+
+  // Capture the current selected question at submit time (not from a stale ref)
+  const capturePendingTurn = (selectedQuestion, answerText) => {
+    if (!selectedQuestion || !answerText?.trim()) return null;
+    const q = typeof selectedQuestion === "string" ? selectedQuestion : selectedQuestion.question;
+    if (!q) return null;
+    turnCounter.current += 1;
+    return {
+      id: `turn-${turnCounter.current}`,
+      question: q,
+      answer: answerText.trim(),
+      acknowledgement: null,
+    };
+  };
+
+  // Append the captured pending turn to history after a successful update only
+  useEffect(() => {
+    const pending = pendingTurnRef.current;
+    if (!pending || updateStatus !== "success") return;
+
+    setInvestigationHistory((prev) => [
+      ...prev,
+      { ...pending, acknowledgement: result?.summary || null },
+    ]);
+    pendingTurnRef.current = null;
+  }, [updateStatus, result]);
+
+  const handleUpdateCaptureAndSubmit = async (e) => {
+    e.preventDefault();
+    if (!answer?.trim() || !result?.selectedQuestion) return;
+    pendingTurnRef.current = capturePendingTurn(result.selectedQuestion, answer);
+    await onAnswerSubmit(e);
+  };
+
+  const graph = result?.situationGraph ?? null;
+  const hasGraph = Boolean(graph);
+  const diagnostics = result?.diagnostics ?? null;
+  const newlySurfacedNodeIds = result?.newlySurfacedNodeIds || [];
+  const genuineCompletion = hasGenuineCompletion(graph);
+
+  const errorType = getErrorType(
+    result?.error || (result?.updateError ? result.updateError.error : null),
+    result?.stage,
+    Boolean(graph)
+  );
+
+  const isProviderUnavailable =
+    errorType === "provider-unavailable" || errorType === "provider-error";
+  const isMalformedResponse = errorType === "malformed-response";
+
+  const { elapsed: startElapsed, currentMessage: startMsg } = useLoadingStatus(
+    INITIAL_MESSAGES,
+    status === "loading"
+  );
+
+  const { elapsed: updateElapsed, currentMessage: updateMsg } = useLoadingStatus(
+    UPDATE_MESSAGES,
+    updateStatus === "loading"
+  );
+
+  const isUpdating = updateStatus === "loading";
+  const hasSelectedQuestion = Boolean(result?.selectedQuestion);
+
+  const canAnswer =
+    status === "success" &&
+    !isUpdating &&
+    Boolean(result?.situationGraph) &&
+    hasSelectedQuestion;
+
+  const selectedQ = result?.selectedQuestion ?? null;
+
+  // Determine whether the Current Understanding card should render:
+  // — when there is a durable plain-language understanding, or
+  // — when there is an actual summary from any graph snapshot, or
+  // — when the investigation has reached a terminal state with no active question.
+  const hasCurrentSummaryCondition =
+    Boolean(propUnderstanding || graph?.currentSummary || result?.updatedSituationGraph?.currentSummary) || !hasSelectedQuestion;
+
+  return (
+    <div className="space-y-6" data-testid="reasoning-workspace">
+      {/* ── Loading overlays ─────────────────────────────── */}
+      {status === "loading" && (
+        <LoadingOverlay
+          elapsed={startElapsed}
+          currentMessage={startMsg}
+          variant="initial"
+        />
+      )}
+
+      {/* ── Provider unavailable recovery (always visible) ───────────── */}
+      {isProviderUnavailable && (
+        <ProviderUnavailableCard onRestart={onRestart} />
+      )}
+
+      {/* ── Malformed response recovery (always visible) ──────────────── */}
+      {isMalformedResponse && (
+        <MalformedResponseCard onRestart={onRestart} />
+      )}
+
+      {/* ── Unexpected state recovery ──────────────────── */}
+      {(errorType === "unexpected-state") && result && (
+        <UnexpectedStateCard
+          stateName={result.stage || null}
+          onRetry={updateStatus === "error" ? onRestart : null}
+          onRestart={onRestart}
+        />
+      )}
+
+      {/* ── No graph produced after initial analysis ───────── */}
+      {(status === "success" || status === "error") && !graph ? (
+        <div className="rounded-lg border border-yellow-300 bg-yellow-50 px-4 py-3 text-sm text-yellow-800">
+          {diagnostics?.noQuestionReason
+            ? "Validation failed — no structured graph output was produced."
+            : "The analysis completed but did not produce a structured result."}
+        </div>
+      ) : (
+        <>
+          {/* ── Workspace grid: persistent whenever a graph exists ─── */}
+          {hasGraph && (
+            <div className="grid grid-cols-1 gap-6 lg:grid-cols-3">
+              {/* ── Left lane: active conversation & notebook ───────── */}
+              <div className="space-y-6 lg:col-span-2">
+                {/* Active question — only when there is one */}
+                {hasSelectedQuestion && (
+                  <>
+                    <CurrentInvestigationCard selectedQuestion={selectedQ} graph={graph} />
+
+                    {updateStatus === "success" && !isUpdating && (
+                      <UpdateAcknowledgement updateResult={result} />
+                    )}
+                  </>
+                )}
+
+                {/* Answer form — only when a question is active and not loading */}
+                {!isUpdating && canAnswer && (
+                  <form onSubmit={handleUpdateCaptureAndSubmit} className="space-y-4 rounded-lg border border-gray-200 bg-white p-5">
+                    <div>
+                      <label htmlFor="rw-answer" className="mb-2 block text-sm font-medium text-gray-700">
+                        Response
+                      </label>
+                      <textarea
+                        id="rw-answer"
+                        value={answer}
+                        onChange={(e) => setAnswer(e.target.value)}
+                        rows={4}
+                        disabled={updateStatus === "loading"}
+                        data-testid="response-textarea"
+                        className="w-full rounded-lg border border-gray-300 px-4 py-3 text-sm focus:border-gray-500 focus:outline-none focus:ring-2 focus:ring-gray-400 disabled:cursor-not-allowed disabled:opacity-60"
+                        placeholder="What do you know about this?"
+                      />
+                    </div>
+                    <div className="flex items-center justify-between">
+                      <p className="text-xs text-gray-400">
+                        One update turn only in this prototype.
+                      </p>
+                      <button
+                        type="submit"
+                        disabled={!answer.trim()}
+                        className="rounded-lg bg-blue-700 px-5 py-2.5 text-sm font-medium text-white transition hover:bg-blue-600 disabled:cursor-not-allowed disabled:opacity-40"
+                      >
+                        Update
+                      </button>
+                    </div>
+                  </form>
+                )}
+
+                {/* Terminal state */}
+                {status === "success" && !hasSelectedQuestion && (
+                  <>
+                    {genuineCompletion && (
+                      <CompletionCard summary={resolveCurrentSummary(propUnderstanding || graph?.currentSummary || result?.updatedSituationGraph?.currentSummary)} />
+                    )}
+                    {!genuineCompletion && (
+                      <EvidenceLimitCard summary={resolveCurrentSummary(propUnderstanding || graph?.currentSummary || result?.updatedSituationGraph?.currentSummary)} />
+                    )}
+                  </>
+                )}
+
+                {investigationHistory.length > 0 && (
+                  <InvestigationHistory turns={investigationHistory} />
+                )}
+
+                {/* Supporting context within conversation lane */}
+                {hasCurrentSummaryCondition && (
+                  <>
+                    <CurrentUnderstandingCard currentSummary={graph?.currentSummary || result?.updatedSituationGraph?.currentSummary} plainLanguage={propUnderstanding || null} />
+                    {/* ── Experiment 12: progress panel A / B / C toggle (temporary experimental UI) ── */}
+                    {hasGraph && (
+                      <div className="space-y-2">
+                        <div className="flex items-center gap-2" role="radiogroup" aria-label="Progress panel variant">
+                          <button
+                            role="radio"
+                            aria-checked={panelVariant === "a"}
+                            onClick={() => setPanelVariant("a")}
+                            onKeyDown={(e) => {
+                              if (e.key === "ArrowRight") setPanelVariant("b");
+                              if (e.key === "ArrowLeft") setPanelVariant("c");
+                            }}
+                            className={`text-xs transition ${panelVariant === "a" ? "font-medium text-gray-700 underline" : "text-gray-400 hover:text-gray-500"}`}
+                          >
+                            Panel A
+                          </button>
+                          <span className="text-gray-300">/</span>
+                          <button
+                            role="radio"
+                            aria-checked={panelVariant === "b"}
+                            onClick={() => setPanelVariant("b")}
+                            onKeyDown={(e) => {
+                              if (e.key === "ArrowRight") setPanelVariant("c");
+                              if (e.key === "ArrowLeft") setPanelVariant("a");
+                            }}
+                            className={`text-xs transition ${panelVariant === "b" ? "font-medium text-gray-700 underline" : "text-gray-400 hover:text-gray-500"}`}
+                          >
+                            Panel B
+                          </button>
+                          <span className="text-gray-300">/</span>
+                          <button
+                            role="radio"
+                            aria-checked={panelVariant === "c"}
+                            onClick={() => setPanelVariant("c")}
+                            onKeyDown={(e) => {
+                              if (e.key === "ArrowRight") setPanelVariant("a");
+                              if (e.key === "ArrowLeft") setPanelVariant("b");
+                            }}
+                            className={`text-xs transition ${panelVariant === "c" ? "font-medium text-gray-700 underline" : "text-gray-400 hover:text-gray-500"}`}
+                          >
+                            Panel C
+                          </button>
+                        </div>
+                        <div className="opacity-75">
+                          {panelVariant === "a"
+                            ? <InvestigationSummaryPanel graph={graph} selectedQuestion={selectedQ} result={result} updateStatus={updateStatus} />
+                            : panelVariant === "b"
+                              ? <InvestigationSummaryPanelV2 graph={graph} selectedQuestion={selectedQ} result={result} updateStatus={updateStatus} />
+                              : <InvestigationSummaryPanelV3 graph={graph} selectedQuestion={selectedQ} result={result} />
+                          }
+                        </div>
+                      </div>
+                    )}
+                  </>
+                )}
+              </div>
+
+              {/* ── Right lane: stable supporting reference ───────── */}
+              {hasCurrentSummaryCondition && (
+                <div className="space-y-6 lg:col-span-1">
+                  <OriginalSituation scenario={scenario} centralStatement={graph?.centralStatement} />
+                  <InvestigationMap turnCount={investigationHistory.length} />
+                </div>
+              )}
+            </div>
+          )}
+
+          {/* Developer details — full-width beneath workspace */}
+          {(status === "success" || status === "error") && graph && (
+            <DeveloperDetails
+              graph={graph}
+              selectedQuestion={selectedQ}
+              diagnostics={diagnostics}
+              newlySurfacedNodeIds={newlySurfacedNodeIds}
+              updateResult={updateStatus === "success" ? result : null}
+            />
+          )}
+        </>
+      )}
+
+      {/* ── Errors (always visible above debug) ─────────── */}
+      {(status === "error" || updateStatus === "error") && (
+        <div className="space-y-3">
+          {status === "error" && result?.error && (
+            <div className="rounded-lg border border-red-300 bg-red-50 px-4 py-3 text-sm text-red-700 whitespace-pre-wrap">
+              Error: {result.error}
+            </div>
+          )}
+          {updateStatus === "error" && !isProviderUnavailable && !isMalformedResponse && result?.updateError && (
+            <div className="rounded-lg border border-red-300 bg-red-50 px-4 py-3 text-sm text-red-700">
+              Update error: {result.updateError.error || JSON.stringify(result.updateError)}
+            </div>
+          )}
+        </div>
+      )}
+    </div>
+  );
+}
+
+export { useLoadingStatus, INITIAL_MESSAGES, UPDATE_MESSAGES, LoadingOverlay, resolveCurrentSummary, isTechnicalSummary, ContinueLaterBanner };
@@ -1,15 +1,8 @@
-const categoryLabels = {
-  observations: "Direct Observations",
-  reportedClaims: "Reported Claims",
-  assumptions: "Unsupported Assumptions",
-  entities: "Entities",
-  transitions: "Transitions",
-  expectedButMissing: "Expected But Missing",
-  presentButUnexpected: "Present But Unexpected",
-  contradictions: "Contradictions",
-  openUncertainties: "Open Uncertainties",
-};
+"use client";

+import { useMemo } from "react";
+
+// ── Confidence badge (shared) ────────────────────────
 const confidenceColor = {
  low: "text-red-600 bg-red-50 border-red-200",
  medium: "text-yellow-700 bg-yellow-50 border-yellow-200",
@@ -17,54 +10,401 @@ const confidenceColor = {
 };

 const ConfidenceBadge = ({ level }) => (
-  <span className={`inline-block rounded-full border px-2 py-0.5 text-xs font-medium ${confidenceColor[level] || "text-gray-600 bg-gray-100"}`}>
+  <span
+    className={`inline-block rounded-full border px-2 py-0.5 text-xs font-medium ${confidenceColor[level] || "text-gray-600 bg-gray-100"}`}
+  >
    {level}
  </span>
 );

-function ItemList({ items, renderExtra }) {
-  if (!items?.length) return <p className="text-sm italic text-gray-400">None identified</p>;
-  
+// ── Evidence type labels (shared) ───────────────────
+const evidenceTypeLabels = {
+  direct_observation: "Direct Observation",
+  reported_statement: "Reported Statement",
+  interpretation: "Interpretation",
+  assumption: "Assumption",
+  inferred_relationship: "Inferred Relationship",
+};
+
+const importanceColors = {
+  incidental: "text-gray-500 bg-gray-50 border-gray-200",
+  supporting: "text-blue-700 bg-blue-50 border-blue-200",
+  important: "text-orange-700 bg-orange-50 border-orange-200",
+  critical: "text-red-800 bg-red-50 border-red-300 font-semibold",
+};
+
+const importanceLabels = {
+  incidental: "Incidental",
+  supporting: "Supporting",
+  important: "Important",
+  critical: "Critical",
+};
+
+// ── Input classification display ────────────────────
+function ClassificationDisplay({ classification }) {
+  if (!classification) return null;
+  const p = classification.primaryType || classification.primary_type;
+  const sec =
+    classification.secondaryTypes || classification.secondary_types || [];
+  const modes =
+    classification.reasoningModes || classification.reasoning_modes || [];
+
+  // Normalize camelCase to snake_case for display if needed
+  const primaryLabel = String(p)
+    .replace(/_/g, " ")
+    .replace(/\b\w/g, (c) => c.toUpperCase());
+  const secLabels = sec.map((s) =>
+    s.replace(/_/g, " ").replace(/\b\w/g, (c) => c.toUpperCase()),
+  );
+  const modeLabels = modes.map((m) =>
+    m.replace(/_/g, " ").replace(/\b\w/g, (c) => c.toUpperCase()),
+  );
+
  return (
-    <ul className="space-y-2">
-      {items.map((item) => (
-        <li key={item.id} className="rounded border border-gray-200 bg-white px-3 py-2 text-sm">
-          <div className="flex items-center gap-2">
-            <span className="font-mono text-xs text-gray-400">#{item.id}</span>
-            <ConfidenceBadge level={item.confidence} />
-          </div>
-          <p className="mt-1">{item.description}</p>
-          {renderExtra && renderExtra(item)}
-        </li>
-      ))}
-    </ul>
+    <div className="rounded-lg border border-blue-200 bg-blue-50 p-4">
+      <h3 className="mb-2 text-sm font-semibold text-blue-700">
+        Input Classification
+      </h3>
+      <dl className="grid grid-cols-[auto_1fr] gap-x-4 gap-y-1.5 text-sm">
+        <dt className="text-blue-500">Primary type</dt>
+        <dd className="font-medium">{primaryLabel}</dd>
+        {secLabels.length > 0 && (
+          <>
+            <dt className="text-blue-500 pt-1">Secondary types</dt>
+            <dd>{secLabels.join(" · ")}</dd>
+          </>
+        )}
+        {modeLabels.length > 0 && (
+          <>
+            <dt className="text-blue-500 pt-1">Reasoning modes</dt>
+            <dd>{modeLabels.join(" · ")}</dd>
+          </>
+        )}
+        <dt className="text-blue-500 pt-1">Classification reason</dt>
+        <dd className="italic">
+          {classification.classificationReason ||
+            classification.classification_reason}
+        </dd>
+        <dt className="text-blue-500 pt-1">Confidence</dt>
+        <dd>
+          <ConfidenceBadge level={classification.confidence} />
+        </dd>
+      </dl>
+    </div>
  );
 }

+// ── Reconstruction summary ──────────────────────────
+function SummaryDisplay({ reconstruction }) {
+  if (!reconstruction?.summary) return null;
+  const summary = reconstruction.summary || reconstruction.Summary;
+  return (
+    <div className="rounded-lg border border-gray-200 bg-white p-4">
+      <h3 className="mb-2 text-sm font-semibold text-gray-600">
+        Reconstruction Summary
+      </h3>
+      <p className="text-sm leading-relaxed">{summary}</p>
+    </div>
+  );
+}
+
+// ── Generic item list (used for multiple sections) ──
+function ItemList({ title, items, renderExtra }) {
+  const count = items?.length;
+  if (!count) return null; // hide empty sections entirely
+
+  const itemsArr = Array.isArray(items) ? items : [items];
+
+  return (
+    <div className="mb-4 rounded-lg border border-gray-200 bg-white p-4">
+      <h3 className="mb-2 text-sm font-semibold text-gray-600">
+        {title} ({count})
+      </h3>
+      <ul className="space-y-2">
+        {itemsArr.map((item, idx) => (
+          <li
+            key={item.id || `${title}-${idx}`}
+            className="rounded border border-gray-200 bg-white px-3 py-2 text-sm"
+          >
+            <div className="flex items-center gap-2">
+              {item.id && (
+                <span className="font-mono text-xs text-gray-400">
+                  #{item.id}
+                </span>
+              )}
+              {item.confidence && <ConfidenceBadge level={item.confidence} />}
+              {item.importance && (
+                <span
+                  className={`inline-block rounded-full border px-2 py-0.5 text-xs font-medium ${importanceColors[item.importance] || "text-gray-600 bg-gray-100"}`}
+                >
+                  {importanceLabels[item.importance]}
+                </span>
+              )}
+            </div>
+            <p className="mt-1">{item.description}</p>
+            {renderExtra && renderExtra(item)}
+          </li>
+        ))}
+      </ul>
+    </div>
+  );
+}
+
+// ── Plausible interpretations ───────────────────────
+function InterpretationsDisplay({ interpretations }) {
+  if (!interpretations?.length) return null;
+  const arr = Array.isArray(interpretations)
+    ? interpretations
+    : [interpretations];
+
+  return (
+    <div className="mb-4 rounded-lg border border-indigo-200 bg-indigo-50 p-4">
+      <h3 className="mb-2 text-sm font-semibold text-indigo-700">
+        Plausible Interpretations ({arr.length})
+      </h3>
+      <ul className="space-y-3">
+        {arr.map((interp, idx) => (
+          <li
+            key={interp.id || `${idx}`}
+            className="rounded border border-indigo-200 bg-white px-3 py-2.5 text-sm leading-relaxed"
+          >
+            <div className="flex items-center gap-2 mb-1">
+              <span className="font-medium text-indigo-600">
+                {interp.description}
+              </span>
+              {interp.confidence && (
+                <ConfidenceBadge level={interp.confidence} />
+              )}
+            </div>
+            {interp.supportingEvidenceIds?.length > 0 && (
+              <p className="text-xs text-gray-500">
+                Supporting evidence: {interp.supportingEvidenceIds.join(", ")}
+              </p>
+            )}
+            {interp.assumptionsRequired?.length > 0 && (
+              <p className="text-xs italic text-gray-500">
+                Requires assumptions: {interp.assumptionsRequired.join("; ")}
+              </p>
+            )}
+          </li>
+        ))}
+      </ul>
+    </div>
+  );
+}
+
+// ── Next question (prominent) ───────────────────────
+function NextQuestionDisplay({ question }) {
+  if (!question?.question) return null;
+  const q = question.question || question.Question;
+  const targets = question.targets || question.Targets || [];
+  const reason = question.reason || question.Reason || "";
+  const value =
+    question.expectedInformationValue ||
+    question.expected_information_value ||
+    "medium";
+
+  const valueLabel =
+    { low: "Low", medium: "Medium", high: "High" }[value] || "Medium";
+  const valueColor =
+    {
+      low: "bg-yellow-100 text-yellow-800",
+      medium: "bg-blue-100 text-blue-800",
+      high: "bg-green-100 text-green-800",
+    }[value] || "";
+
+  return (
+    <div className="rounded-lg border-2 border-green-300 bg-green-50 p-5">
+      <div className="flex items-center gap-2 mb-2">
+        <h3 className="text-sm font-bold text-green-800">Next Question</h3>
+        <span
+          className={`rounded-full px-2 py-0.5 text-xs font-medium ${valueColor}`}
+        >
+          {valueLabel} value
+        </span>
+      </div>
+      <p className="mb-2 text-base font-medium text-gray-900">{q}</p>
+      {targets.length > 0 && (
+        <p className="text-sm text-gray-600">Targets: {targets.join(", ")}</p>
+      )}
+      {reason && (
+        <p className="text-sm italic text-gray-500">Because: {reason}</p>
+      )}
+    </div>
+  );
+}
+
+// ── Evidence list ───────────────────────────────────
+function EvidenceDisplay({ evidence }) {
+  if (!evidence?.length) return null;
+  const arr = Array.isArray(evidence) ? evidence : [evidence];
+
+  const evidenceLabels = {
+    direct_observation: "👁 Direct Observation",
+    reported_statement: "🗣 Reported Statement",
+    interpretation: "💡 Interpretation",
+    assumption: "❓ Assumption",
+    inferred_relationship: "🔗 Inferred Relationship",
+  };
+
+  return (
+    <div className="mb-4 rounded-lg border border-gray-200 bg-white p-4">
+      <h3 className="mb-2 text-sm font-semibold text-gray-600">
+        Supporting Evidence ({arr.length})
+      </h3>
+      <ul className="space-y-2">
+        {arr.map((item, idx) => (
+          <li
+            key={item.id || `${idx}`}
+            className="rounded border border-gray-200 bg-white px-3 py-2 text-sm leading-relaxed"
+          >
+            <div className="flex items-center gap-2 mb-0.5 flex-wrap">
+              {item.id && (
+                <span className="font-mono text-xs text-gray-400">
+                  #{item.id}
+                </span>
+              )}
+              <span
+                className={`inline-block rounded px-1.5 py-0.5 text-[10px] font-medium ${importanceColors[item.importance] || "text-gray-600 bg-gray-100"}`}
+              >
+                {importanceLabels[item.importance]}
+              </span>
+              <span className="inline-block rounded px-1.5 py-0.5 text-[10px] font-medium bg-gray-100 text-gray-700">
+                {evidenceLabels[item.evidenceType] || item.evidenceType}
+              </span>
+              {item.confidence && <ConfidenceBadge level={item.confidence} />}
+            </div>
+            <p className="text-sm">{item.description}</p>
+            {(item.source || item.attribution) && (
+              <p className="mt-0.5 text-xs text-gray-400">
+                Source: {item.source || item.attribution}
+              </p>
+            )}
+          </li>
+        ))}
+      </ul>
+    </div>
+  );
+}
+
+// ── Main component ──────────────────────────────────
 export default function ReconstructionView({ reconstruction, partial }) {
+  // Handle both v0.2 direct object and wrapped result formats
+  const data = reconstruction;
+
  if (partial) {
    return (
      <div className="rounded-lg border border-yellow-300 bg-yellow-50 px-4 py-3 text-sm text-yellow-800">
-        ⚠ Partial result — some fields failed validation. Showing what was accepted.
+        ⚠ Partial result — some fields failed validation. Showing what was
+        accepted.
      </div>
    );
  }

-  const categories = Object.entries(categoryLabels).map(([key, label]) => ({
-    key,
-    label,
-    items: reconstruction[key],
-  }));
-
  return (
-    <div className="space-y-1">
-      <h2 className="mb-3 text-lg font-semibold">Reconstruction</h2>
-      {categories.map(({ key, label, items }) => (
-        <div key={key} className="mb-4 rounded border border-gray-200 bg-white p-4">
-          <h3 className="mb-2 text-sm font-medium text-gray-600">{label}</h3>
-          <ItemList items={items} />
-        </div>
-      ))}
+    <div className="space-y-4">
+      {/* Classification first */}
+      {data.inputClassification && (
+        <ClassificationDisplay classification={data.inputClassification} />
+      )}
+
+      {/* Summary */}
+      {data.reconstruction?.summary && (
+        <SummaryDisplay reconstruction={data.reconstruction} />
+      )}
+
+      {/* Key differences */}
+      {data.reconstruction?.differences && (
+        <ItemList
+          title="Key Differences"
+          items={data.reconstruction.differences}
+        />
+      )}
+
+      {/* Unexplained transitions */}
+      {data.reconstruction?.unexplainedTransitions &&
+        data.reconstruction.unexplainedTransitions.length > 0 && (
+          <ItemList
+            title="Unexplained Transitions"
+            items={data.reconstruction.unexplainedTransitions}
+            renderExtra={(i) =>
+              i.entity && (
+                <p className="mt-1 text-xs text-gray-500">Entity: {i.entity}</p>
+              )
+            }
+          />
+        )}
+
+      {/* Contradictions */}
+      {data.reconstruction?.contradictions &&
+        data.reconstruction.contradictions.length > 0 && (
+          <ItemList
+            title="Contradictions"
+            items={data.reconstruction.contradictions}
+          />
+        )}
+
+      {/* Important unknowns */}
+      {data.reconstruction?.importantUnknowns &&
+        data.reconstruction.importantUnknowns.length > 0 && (
+          <ItemList
+            title="Important Unknowns"
+            items={data.reconstruction.importantUnknowns}
+          />
+        )}
+
+      {/* Plausible interpretations */}
+      {data.reconstruction?.plausibleInterpretations &&
+        data.reconstruction.plausibleInterpretations.length > 0 && (
+          <InterpretationsDisplay
+            interpretations={data.reconstruction.plausibleInterpretations}
+          />
+        )}
+
+      {/* Secondary reconstruction categories (actors, systems, etc.) */}
+      {data.reconstruction?.actors && data.reconstruction.actors.length > 0 && (
+        <ItemList title="Actors" items={data.reconstruction.actors} />
+      )}
+      {data.reconstruction?.systemsOrObjects &&
+        data.reconstruction.systemsOrObjects.length > 0 && (
+          <ItemList
+            title="Systems / Objects"
+            items={data.reconstruction.systemsOrObjects}
+          />
+        )}
+      {data.reconstruction?.expectedStates &&
+        data.reconstruction.expectedStates.length > 0 && (
+          <ItemList
+            title="Expected States"
+            items={data.reconstruction.expectedStates}
+          />
+        )}
+      {data.reconstruction?.observedStates &&
+        data.reconstruction.observedStates.length > 0 && (
+          <ItemList
+            title="Observed States"
+            items={data.reconstruction.observedStates}
+          />
+        )}
+      {data.reconstruction?.knownTransitions &&
+        data.reconstruction.knownTransitions.length > 0 && (
+          <ItemList
+            title="Known Transitions"
+            items={data.reconstruction.knownTransitions}
+            renderExtra={(i) => (
+              <div className="mt-1 text-xs text-gray-500">
+                {i.entity && <span>Entity: {i.entity} · </span>}
+                From &ldquo;{i.previousState}&rdquo; → To &ldquo;{i.currentState}&rdquo; (&quot;{i.explanationStatus}&quot;)
+              </div>
+            )}
+          />
+        )}
+
+      {/* Next question — prominent */}
+      <NextQuestionDisplay question={data.nextQuestion} />
+
+      {/* Evidence */}
+      {data.evidence && <EvidenceDisplay evidence={data.evidence} />}
    </div>
  );
 }
@@ -1,37 +1,317 @@
 "use client";

-import { useState, useRef } from "react";
-import ReconstructionView from "@/components/reconstruction-view";
+import React, { useEffect } from "react";
+import { useState, useRef, useMemo } from "react";
 import DiagnosticsView from "@/components/diagnostics-view";
+import ReasoningWorkspace, { LoadingOverlay, ContinueLaterBanner } from "@/components/reasoning-workspace";
+import { mockFetch, AVAILABLE_SCENARIOS } from "@/lib/mocks/confidence-engine/mock-client";
+
+/* Compile-time env resolution — NEXT_PUBLIC_ vars are injected by Next.js at build */
+const MOCK_ENABLED = process.env.NEXT_PUBLIC_CONFIDENCE_ENGINE_MOCKS === "true";
+
+/* ── inject runtime globals for the mock client to read ──── */
+function useMockGlobals() {
+  useEffect(() => {
+    if (MOCK_ENABLED) {
+      var w = window;
+      w.__MOCK_ENABLED = true;
+      w.__MOCK_DELAY = process.env.NEXT_PUBLIC_CONFIDENCE_MOCK_DELAY || "normal";
+      w.__MOCK_SCENARIO = process.env.NEXT_PUBLIC_CONFIDENCE_ENGINE_MOCK_SCENARIO || "";
+    }
+  }, []);
+}

 const MAX_LENGTH = 10000;

+export async function submitScenarioForStartCase(fetchImpl, scenario) {
+  return fetchImpl("/api/cases/start", {
+    method: "POST",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify({ scenario }),
+  });
+}
+
+export async function submitAnswerForUpdateCase(
+  fetchImpl,
+  { situationGraph, previousQuestion, answer },
+) {
+  if (!answer?.trim()) {
+    return {
+      ok: false,
+      skipped: true,
+      data: {
+        success: false,
+        stage: "request_validation",
+        error: "Please enter an answer before updating.",
+      },
+    };
+  }
+
+  const response = await fetchImpl("/api/cases/update", {
+    method: "POST",
+    headers: { "Content-Type": "application/json" },
+    body: JSON.stringify({ situationGraph, previousQuestion, answer }),
+  });
+
+  return {
+    ok: response.ok,
+    skipped: false,
+    data: await response.json(),
+  };
+}
+
+function normaliseStartResult(data) {
+  return {
+    ...data,
+    selectedQuestion:
+      typeof data?.selectedQuestion === "string"
+        ? data.selectedQuestion
+        : data?.selectedQuestion?.question ?? null,
+    newlySurfacedNodeIds: data?.newlySurfacedNodeIds ?? [],
+  };
+}
+
+function normaliseUpdateSelectedQuestion(selectedQuestion) {
+  if (!selectedQuestion) return null;
+  if (typeof selectedQuestion === "string") return selectedQuestion;
+  return selectedQuestion.question ?? null;
+}
+
+export function ScenarioResultPanels({ status, result }) {
+  if (!result) return null;
+
+  const hasGraph = Boolean(result.situationGraph);
+  const hasQuestion = Boolean(result.selectedQuestion?.question);
+  const hasDiagnostics = Boolean(result.diagnostics);
+
+  return (
+    <>
+      {status === "error" && (
+        <div className="space-y-3">
+          {result.error && (
+            <div className="rounded-lg border border-red-300 bg-red-50 px-4 py-3 text-sm text-red-700 whitespace-pre-wrap">
+              Error: {result.error}
+            </div>
+          )}
+          {!hasGraph && !hasQuestion && (
+            <div className="rounded-lg border border-yellow-300 bg-yellow-50 px-4 py-2 text-sm text-yellow-800">
+              Validation failed — no structured graph output was produced.
+            </div>
+          )}
+        </div>
+      )}
+
+      {hasDiagnostics && <DiagnosticsView result={result} />}
+    </>
+  );
+}
+
+// ── Message pools ───────────────────────────────────────────
+const INITIAL_MESSAGES = [
+  { min: 0, text: "Reading your situation" },
+  { min: 10, text: "Building a structured understanding" },
+  { min: 25, text: "Identifying what is known and still unclear" },
+  { min: 45, text: "Selecting the next useful question" },
+];
+
+const UPDATE_MESSAGES = [
+  { min: 0, text: "Considering your answer" },
+  { min: 10, text: "Updating the situation" },
+  { min: 25, text: "Checking what changed" },
+  { min: 45, text: "Choosing the next question" },
+];
+
+function useLoadingStatus(messages, isLoading) {
+  const [elapsed, setElapsed] = useState(0);
+  const startRef = useRef(null);
+
+  useEffect(() => {
+    if (isLoading) {
+      startRef.current = Date.now();
+      const iv = setInterval(() => {
+        setElapsed(Math.floor((Date.now() - startRef.current) / 1000));
+      }, 1000);
+      return () => clearInterval(iv);
+    } else {
+      setElapsed(0);
+      startRef.current = null;
+    }
+  }, [isLoading]);
+
+  const currentMessage = useMemo(() => {
+    if (!messages || messages.length === 0) return "";
+    let msg = messages[0].text;
+    for (const m of messages) {
+      if (elapsed >= m.min) msg = m.text;
+    }
+    return msg;
+  }, [messages, elapsed]);
+
+  return { elapsed, currentMessage };
+}
+
+export function UpdateErrorPanel({ updateError }) {
+  if (!updateError) return null;
+
+  const errors = [
+    ...(updateError.errors || []),
+    ...(updateError.validationErrors || []),
+    ...(updateError.graphValidationErrors || []),
+    ...(updateError.proposalErrors || []),
+    ...(updateError.providerErrors || []),
+  ];
+
+  return (
+    <div className="space-y-3">
+      <div className="rounded-lg border border-red-300 bg-red-50 px-4 py-3 text-sm text-red-700 whitespace-pre-wrap">
+        Update error: {updateError.error}
+      </div>
+      {errors.length > 0 && (
+        <details className="rounded-lg border border-red-200 bg-red-50 px-4 py-3">
+          <summary className="cursor-pointer text-sm font-medium text-red-700 underline">
+            Update details ({errors.length})
+          </summary>
+          <ul className="mt-2 space-y-1 text-sm text-red-700">
+            {errors.map((item, index) => (
+              <li key={index}>
+                {typeof item === "string" ? item : item?.message || JSON.stringify(item)}
+              </li>
+            ))}
+          </ul>
+        </details>
+      )}
+    </div>
+  );
+}
+
+export { INITIAL_MESSAGES, UPDATE_MESSAGES, useLoadingStatus };
+
+// ── Session key ────────────────────────────────────────────────
+const SESSION_KEY = "confidence-engine-session";
+
+function getSession() {
+  if (typeof sessionStorage === "undefined") return null;
+  try {
+    const raw = sessionStorage.getItem(SESSION_KEY);
+    return raw ? JSON.parse(raw) : null;
+  } catch (_) { return null; }
+}
+
+function saveSession(state) {
+  if (typeof sessionStorage === "undefined") return;
+  try { sessionStorage.setItem(SESSION_KEY, JSON.stringify(state)); } catch (_) {}
+}
+
+function clearSession() {
+  if (typeof sessionStorage === "undefined") return;
+  try { sessionStorage.removeItem(SESSION_KEY); } catch (_) {}
+}
+
 export default function ScenarioForm() {
  const [scenario, setScenario] = useState("");
  const [status, setStatus] = useState("idle"); // idle | loading | error | success
  const [result, setResult] = useState(null);
+  const [answer, setAnswer] = useState("");
+  const [updateStatus, setUpdateStatus] = useState("idle"); // idle | loading | error | success
+  const [updateError, setUpdateError] = useState(null);
+  const [updateResult, setUpdateResult] = useState(null);
+  const [lastSubmittedAnswer, setLastSubmittedAnswer] = useState("");
+  const [currentUnderstanding, setCurrentUnderstanding] = useState(null);
+  const [mockScenario, setMockScenario] = useState("");
+  const [hideFacilitatorOnLanding, setHideFacilitatorOnLanding] = useState(false);
  const textareaRef = useRef(null);

+  /* Restore persisted session on mount (Phase 3) ─────────── */
+  useEffect(() => {
+    if (typeof window === "undefined") return;
+    const saved = getSession();
+    if (!saved) return;
+    setScenario(saved.scenario || "");
+    setResult(saved.situationGraph ? { ...saved, situationGraph: saved.situationGraph } : null);
+    setCurrentUnderstanding(saved.summary || null);
+    setStatus("success");
+  }, []);
+
+  /* Restore facilitator dismiss preference (Experiment 05) ─── */
+  useEffect(() => {
+    if (typeof window === "undefined") return;
+    try {
+      const pref = sessionStorage.getItem("ce-facilitator-dismissed");
+      setHideFacilitatorOnLanding(pref === "true");
+    } catch (_) {}
+  }, []);
+
+  /* Inject mock globals so the interceptor can read them at runtime */
+  useMockGlobals();
+
+  function handleScenarioSelect(key) {
+    setMockScenario(key);
+    if (typeof window !== "undefined") {
+      window.__MOCK_SCENARIO = key;
+    }
+    // Auto-fill central statement for quick start
+    var found = AVAILABLE_SCENARIOS.find(function(s) { return s.key === key; });
+    if (found && found.centralStatement) {
+      setScenario(found.centralStatement);
+    }
+  }
+
+  function handleScenarioFill(key) {
+    handleScenarioSelect(key);
+    setStatus("loading");
+    setResult(null);
+    setAnswer("");
+    setUpdateStatus("idle");
+    setUpdateResult(null);
+    setLastSubmittedAnswer("");
+    setCurrentUnderstanding(null);
+    setUpdateError(null);
+    // Simulate a click on the analyse button after auto-filling
+    setTimeout(function() {
+      var btn = document.querySelector('button[type="submit"]');
+      if (btn && !btn.disabled) btn.click();
+    }, 50);
+  }
+
+  const { elapsed: startElapsed, currentMessage: startMsg } = useLoadingStatus(
+    INITIAL_MESSAGES,
+    status === "loading"
+  );
+
+  const { elapsed: updateElapsed, currentMessage: updateMsg } = useLoadingStatus(
+    UPDATE_MESSAGES,
+    updateStatus === "loading"
+  );
+
  const handleSubmit = async (e) => {
    e.preventDefault();
    setStatus("loading");
    setResult(null);
+    setAnswer("");
+    setUpdateStatus("idle");
+    setUpdateResult(null);
+    setLastSubmittedAnswer("");
+    setUpdateError(null);
+    setCurrentUnderstanding(null);
+
+    // Force a DOM flush so loading state renders before awaiting (prevents instant mocks from swallowing it)
+    await new Promise(r => requestAnimationFrame(() => setTimeout(r, 50)));

    try {
-      const res = await fetch("/api/analyse", {
-        method: "POST",
-        headers: { "Content-Type": "application/json" },
-        body: JSON.stringify({ scenario }),
-      });
+      const res = await submitScenarioForStartCase(MOCK_ENABLED ? mockFetch : fetch, scenario);

      const data = await res.json();

-      if (res.ok && data.validationStatus === "valid") {
+      if (res.ok && data.success) {
        setStatus("success");
-        setResult(data);
+        setCurrentUnderstanding(data.summary ?? null);
+        const normalised = normaliseStartResult(data);
+        setResult(normalised);
+        saveSession({ scenario, situationGraph: normalised.situationGraph, selectedQuestion: normalised.selectedQuestion, summary: data.summary ?? null, updatedAt: new Date().toISOString() });
      } else {
        setStatus("error");
-        setResult(data);
+        setCurrentUnderstanding(data.summary ?? null);
+        setResult(normaliseStartResult(data));
      }
    } catch (err) {
      setStatus("error");
@@ -39,69 +319,253 @@ export default function ScenarioForm() {
    }
  };

-  // Always show diagnostics when there's a result (even if validation failed)
-  const hasDiagnostics = result && (result.reconstruction || result.modelName || result.responseDurationMs !== undefined);
+  const handleUpdate = async (e) => {
+    e.preventDefault();
+
+    // Guard empty answer before showing loading state
+    if (!answer?.trim()) {
+      setUpdateStatus("error");
+      setUpdateError({ error: "Please enter an answer before updating." });
+      return;
+    }
+
+    setUpdateStatus("loading");
+    setUpdateError(null);
+    setLastSubmittedAnswer(answer.trim());
+
+    // Force a DOM flush so loading state renders before awaiting (prevents instant mocks from swallowing it)
+    await new Promise(r => requestAnimationFrame(() => setTimeout(r, 50)));
+
+    const submission = await submitAnswerForUpdateCase(MOCK_ENABLED ? mockFetch : fetch, {
+      situationGraph: result?.situationGraph,
+      previousQuestion: result?.selectedQuestion,
+      answer,
+    });
+
+    if (submission.skipped) {
+      setUpdateStatus("error");
+      setUpdateError(submission.data);
+      return;
+    }
+
+    try {
+      const outcome = submission.data;
+
+      if (submission.ok && outcome.success) {
+        setUpdateStatus("success");
+        setCurrentUnderstanding(
+          outcome.summary ? outcome.summary : currentUnderstanding,
+        );
+        setUpdateResult({
+          ...outcome,
+          previousSituationGraph: result?.situationGraph ?? null,
+        });
+        setResult((current) => ({
+          ...current,
+          situationGraph: outcome.updatedSituationGraph,
+          selectedQuestion: normaliseUpdateSelectedQuestion(
+            outcome.selectedQuestion,
+          ),
+          newlySurfacedNodeIds: (outcome.proposal?.addedNodes || [])
+            .filter((node) => node.kind === "unknown")
+            .map((node) => node.id),
+          diagnostics: outcome.diagnostics,
+        }));
+        setAnswer("");
+        // Persist after successful update turn
+        saveSession({ scenario, situationGraph: outcome.updatedSituationGraph, selectedQuestion: normaliseUpdateSelectedQuestion(outcome.selectedQuestion), summary: outcome.summary ?? currentUnderstanding, updatedAt: new Date().toISOString() });
+      } else {
+        setUpdateStatus("error");
+        setUpdateError(outcome);
+      }
+    } catch (err) {
+      setUpdateStatus("error");
+      setUpdateError({ error: err.message || "Network request failed" });
+    }
+  };

  return (
    <div className="space-y-6">
-      <form onSubmit={handleSubmit} className="space-y-4">
-        <textarea
-          ref={textareaRef}
-          value={scenario}
-          onChange={(e) => setScenario(e.target.value)}
-          placeholder="Describe the scenario you want analysed..."
-          rows={10}
-          className="w-full rounded-lg border border-gray-300 px-4 py-3 text-sm focus:border-gray-500 focus:outline-none focus:ring-2 focus:ring-gray-400"
+      {status === "idle" && (
+        <form onSubmit={handleSubmit} className="space-y-6">
+
+          {/* Two-column landing workspace */}
+          <div className="grid grid-cols-1 gap-6 md:grid-cols-3">
+
+            {/* Left panel — Facilitator (1/3 on desktop) */}
+            {!hideFacilitatorOnLanding && (
+              <div className="md:col-span-1">
+                <div className="rounded-lg border border-amber-200/60 bg-gradient-to-b from-amber-50/60 to-white px-8 pt-7 pb-7 sticky top-6 shadow-sm">
+                  <h2 className="mb-4 text-xs font-bold tracking-widest uppercase text-amber-600/60">Before we begin</h2>
+                  <p className="text-sm leading-relaxed text-amber-900/80 mb-5">
+                    The Confidence Engine helps build confidence by understanding situations before deciding what to do.
+                  </p>
+                  <p className="text-sm leading-relaxed text-amber-900/70 mb-4">
+                    You do not need to know exactly what the problem is.
+                  </p>
+                  <p className="text-sm leading-relaxed text-amber-900/70 mb-7">
+                    Simply describe what you have observed. We will work through it together, one question at a time.
+                  </p>
+                  <div className="flex items-center gap-2 pt-5 border-t border-amber-100/60">
+                    <input
+                      type="checkbox"
+                      id="dismiss-facilitator"
+                      onChange={(e) => {
+                        if (e.target.checked) {
+                          setHideFacilitatorOnLanding(true);
+                          try { sessionStorage.setItem("ce-facilitator-dismissed", "true"); } catch (_) {}
+                        }
+                      }}
+                      className="h-4 w-4 rounded border-gray-300 text-blue-600 focus:ring-blue-500"
+                    />
+                    <label htmlFor="dismiss-facilitator" className="text-xs text-gray-500">
+                      Don't show this introduction again
+                    </label>
+                  </div>
+                </div>
+              </div>
+            )}
+
+            {/* Right panel — Workspace (2/3 on desktop) */}
+            <div className={hideFacilitatorOnLanding ? "md:col-span-3" : "md:col-span-2"}>
+              <h2 className="mb-4 text-xs font-bold tracking-widest uppercase text-gray-400">Tell me what's happening</h2>
+              <textarea
+                ref={textareaRef}
+                value={scenario}
+                onChange={(e) => setScenario(e.target.value)}
+                placeholder="What have you noticed?"
+                rows={4}
+                data-testid="scenario-textarea"
+                className="w-full rounded-lg border border-gray-300 px-4 py-3 text-sm focus:border-gray-500 focus:outline-none focus:ring-2 focus:ring-gray-400 mb-3"
+              />
+              <div className="flex items-center justify-between">
+                <span className="text-xs text-gray-400">{scenario.length}/{MAX_LENGTH}</span>
+                <button
+                  type="submit"
+                  disabled={!scenario.trim()}
+                  className="rounded-lg bg-blue-700 px-6 py-2.5 text-sm font-medium text-white transition hover:bg-blue-600 disabled:cursor-not-allowed disabled:opacity-40"
+                >
+                  Analyse
+                </button>
+              </div>
+              <p className="mt-3 text-xs italic text-gray-400">
+                You do not need all the answers yet.
+              </p>
+            </div>
+
+          </div>
+
+        </form>
+      )}
+
+      {status === "idle" && MOCK_ENABLED && (
+        <details className="rounded-lg border border-gray-200/60 bg-gray-50/30">
+          <summary className="cursor-pointer px-4 py-2 text-sm font-medium text-gray-400 hover:text-gray-600">Developer details</summary>
+          <div className="space-y-3 px-4 pb-4">
+            <div>
+              <label htmlFor="mock-scenario" className="block text-xs font-medium text-gray-500 mb-1">Mock scenario</label>
+              <select
+                id="mock-scenario"
+                value={mockScenario}
+                onChange={(e) => handleScenarioSelect(e.target.value)}
+                className="w-full rounded-md border border-gray-300 px-3 py-2 text-sm focus:border-gray-500 focus:outline-none focus:ring-2 focus:ring-gray-400"
+              >
+                <option value="">— default (env var) —</option>
+                {AVAILABLE_SCENARIOS.map(function(s) {
+                  return <option key={s.key} value={s.key}>{s.label}</option>;
+                })}
+              </select>
+            </div>
+            <div className="flex flex-wrap gap-2">
+              {AVAILABLE_SCENARIOS.map(function(s) {
+                return (
+                  <button
+                    key={s.key}
+                    type="button"
+                    onClick={() => handleScenarioFill(s.key)}
+                    disabled={!scenario.trim() && scenario !== s.centralStatement}
+                    className="rounded-md border border-gray-200/60 bg-white/80 px-3 py-1.5 text-xs text-gray-500 hover:bg-gray-50 disabled:opacity-30"
+                  >
+                    {s.label} ({s.turnCount} turns)
+                  </button>
+                );
+              })}
+            </div>
+          </div>
+        </details>
+      )}
+
+      {/* ── Initial analysis loading card ─────────────── */}
+      {status === "loading" && (
+        <LoadingOverlay
+          isLoading={true}
+          elapsed={startElapsed}
+          currentMessage={startMsg}
+          variant="initial"
        />
-        <div className="flex items-center justify-between">
-          <span className="text-xs text-gray-400">{scenario.length}/{MAX_LENGTH}</span>
+      )}
+
+      {/* ── Main result workspace ─────────────────────── */}
+      {((status === "success" || status === "error") && status !== "loading") && (
+        <ReasoningWorkspace
+          scenario={scenario}
+          status={status}
+          updateStatus={updateStatus}
+          currentUnderstanding={currentUnderstanding}
+          result={{
+            ...(result || {}),
+            situationGraph: updateResult?.updatedSituationGraph ?? result?.situationGraph,
+            selectedQuestion: updateResult?.selectedQuestion ?? result?.selectedQuestion,
+            newlySurfacedNodeIds: result?.newlySurfacedNodeIds || [],
+            diagnostics: result?.diagnostics || null,
+            updateError,
+          }}
+          answer={answer}
+          setAnswer={setAnswer}
+          onAnswerSubmit={handleUpdate}
+          lastSubmittedAnswer={lastSubmittedAnswer}
+          onRestart={() => {
+            clearSession();
+            setStatus("idle");
+            setResult(null);
+            setAnswer("");
+            setUpdateStatus("idle");
+            setUpdateResult(null);
+            setLastSubmittedAnswer("");
+            setCurrentUnderstanding(null);
+            setUpdateError(null);
+          }}
+        />
+      )}
+
+      {/* ── Continue later banner when session was restored ── */}
+      {status === "success" && result?.updatedAt && (
+        <ContinueLaterBanner onRestart={() => { clearSession(); setStatus("idle"); setResult(null); setAnswer(""); setUpdateStatus("idle"); setCurrentUnderstanding(null); }} />
+      )}
+
+      {/* Reset button after successful analysis */}
+      {status === "success" && (
+        <div className="text-center">
          <button
-            type="submit"
-            disabled={status === "loading" || !scenario.trim()}
-            className="rounded-lg bg-gray-900 px-6 py-2.5 text-sm font-medium text-white transition hover:bg-gray-700 disabled:cursor-not-allowed disabled:opacity-40"
+            onClick={() => {
+              clearSession();
+              setScenario("");
+              setStatus("idle");
+              setResult(null);
+              setAnswer("");
+              setUpdateStatus("idle");
+              setUpdateResult(null);
+              setLastSubmittedAnswer("");
+              setCurrentUnderstanding(null);
+              setUpdateError(null);
+            }}
+            className="rounded-lg border border-gray-200/60 px-4 py-2 text-sm font-medium text-gray-500 transition hover:bg-gray-50/80"
          >
-            {status === "loading" ? "Analysing..." : "Analyse"}
+            Start new investigation
          </button>
        </div>
-      </form>
-
-      {status === "error" && (
-        <div className="space-y-3">
-          {result?.error && (
-            <div className="rounded-lg border border-red-300 bg-red-50 px-4 py-3 text-sm text-red-700 whitespace-pre-wrap">
-              Error: {result.error}
-            </div>
-          )}
-          {hasDiagnostics && result?.modelName && (
-            <dl className="grid grid-cols-[auto_1fr] gap-x-4 gap-y-1.5 text-sm">
-              <dt className="text-gray-500">Model</dt>
-              <dd>{result.modelName}</dd>
-              <dt className="text-gray-500">Duration</dt>
-              <dd>{result.responseDurationMs != null ? `${result.responseDurationMs}ms` : "?"}</dd>
-            </dl>
-          )}
-        </div>
      )}

-      {status === "success" && result?.reconstruction && (
-        <div className="space-y-4">
-          <ReconstructionView reconstruction={result.reconstruction} />
-          <DiagnosticsView result={result} />
-        </div>
-      )}
-
-      {status === "error" && result?.reconstruction && (
-        <div className="space-y-3">
-          <div className="rounded-lg border border-yellow-300 bg-yellow-50 px-4 py-2 text-sm text-yellow-800">
-            ⚠ Partial result — some fields failed validation. Showing what was accepted.
-          </div>
-          <ReconstructionView reconstruction={result.reconstruction} partial />
-        </div>
-      )}
-
-      {status === "loading" && (
-        <div className="py-12 text-center text-sm text-gray-400">Waiting for model response...</div>
-      )}
    </div>
  );
 }
@@ -0,0 +1,161 @@
+"use client";
+
+import React from "react";
+
+function NodeBadge({ children, tone = "gray" }) {
+  const tones = {
+    gray: "border-gray-200 bg-gray-50 text-gray-700",
+    blue: "border-blue-200 bg-blue-50 text-blue-700",
+    green: "border-green-200 bg-green-50 text-green-700",
+    yellow: "border-yellow-200 bg-yellow-50 text-yellow-700",
+    red: "border-red-200 bg-red-50 text-red-700",
+    purple: "border-purple-200 bg-purple-50 text-purple-700",
+  };
+
+  return (
+    <span className={`rounded-full border px-2 py-0.5 text-xs ${tones[tone] || tones.gray}`}>
+      {children}
+    </span>
+  );
+}
+
+function NodeGroup({
+  title,
+  nodes,
+  resolvedNodeIds = new Set(),
+  newlySurfacedNodeIds = new Set(),
+  activeUnknownNodeId = null,
+}) {
+  if (!nodes?.length) return null;
+
+  return (
+    <section className="rounded-lg border border-gray-200 bg-white p-4">
+      <h3 className="mb-3 text-sm font-semibold text-gray-700">
+        {title} ({nodes.length})
+      </h3>
+      <ul className="space-y-3">
+        {nodes.map((node) => (
+          <li key={node.id} className="rounded border border-gray-100 bg-gray-50 p-3 text-sm">
+            <div className="flex flex-wrap items-center gap-2">
+              <span className="font-medium text-gray-900">{node.label}</span>
+              <NodeBadge tone="blue">{node.status}</NodeBadge>
+              <NodeBadge tone="green">{node.confidence}</NodeBadge>
+              {node.confidenceAssessment?.completenessStatus && (
+                <NodeBadge tone="purple">
+                  completeness: {node.confidenceAssessment.completenessStatus}
+                </NodeBadge>
+              )}
+              {resolvedNodeIds.has(node.id) && (
+                <NodeBadge tone="red">resolved unknown</NodeBadge>
+              )}
+              {newlySurfacedNodeIds.has(node.id) && (
+                <NodeBadge tone="purple">newly surfaced unknown</NodeBadge>
+              )}
+              {activeUnknownNodeId === node.id && (
+                <NodeBadge tone="yellow">active unknown</NodeBadge>
+              )}
+              {node.value != null && (
+                <NodeBadge tone="yellow">
+                  {node.value}
+                  {node.unit ? ` ${node.unit}` : ""}
+                </NodeBadge>
+              )}
+            </div>
+            {node.description && node.description !== node.label && (
+              <p className="mt-1 text-gray-600">{node.description}</p>
+            )}
+            {node.confidenceAssessment && (
+              <p className="mt-1 text-xs text-gray-500">
+                evidence: {node.confidenceAssessment.evidenceConfidence} ·
+                conclusion: {node.confidenceAssessment.conclusionConfidence}
+              </p>
+            )}
+          </li>
+        ))}
+      </ul>
+    </section>
+  );
+}
+
+export default function SituationGraphView({
+  situationGraph,
+  selectedQuestion,
+  newlySurfacedNodeIds = [],
+}) {
+  if (!situationGraph) return null;
+
+  const selectedQuestionText =
+    typeof selectedQuestion === "string"
+      ? selectedQuestion
+      : selectedQuestion?.question ?? null;
+
+  const activeUnknown = situationGraph.activeUnknownNodeId
+    ? situationGraph.nodes.find((node) => node.id === situationGraph.activeUnknownNodeId)
+    : null;
+
+  const nodesByKind = situationGraph.nodes.reduce((acc, node) => {
+    if (!acc[node.kind]) acc[node.kind] = [];
+    acc[node.kind].push(node);
+    return acc;
+  }, {});
+
+  const resolvedNodeIdSet = new Set(situationGraph.resolvedNodeIds || []);
+  const newlySurfacedNodeIdSet = new Set(newlySurfacedNodeIds || []);
+
+  return (
+    <div className="space-y-4">
+      {selectedQuestionText && (
+        <section className="rounded-lg border-2 border-green-300 bg-green-50 p-5">
+          <h2 className="mb-2 text-base font-bold text-green-800">Selected Question</h2>
+          <p className="text-base font-medium text-gray-900">{selectedQuestionText}</p>
+        </section>
+      )}
+
+      <section className="rounded-lg border border-gray-200 bg-white p-4">
+        <h2 className="mb-2 text-base font-semibold text-gray-900">Situation Graph</h2>
+        <dl className="space-y-2 text-sm">
+          <div>
+            <dt className="text-gray-500">Central statement</dt>
+            <dd className="font-medium text-gray-900">{situationGraph.centralStatement}</dd>
+          </div>
+          {situationGraph.currentSummary && (
+            <div>
+              <dt className="text-gray-500">Current summary</dt>
+              <dd className="text-gray-800">{situationGraph.currentSummary}</dd>
+            </div>
+          )}
+          {activeUnknown && (
+            <div>
+              <dt className="text-gray-500">Active unknown</dt>
+              <dd className="text-gray-900">{activeUnknown.label}</dd>
+            </div>
+          )}
+          <div>
+            <dt className="text-gray-500">Edge count</dt>
+            <dd className="text-gray-900">{situationGraph.edges.length}</dd>
+          </div>
+        </dl>
+      </section>
+
+      {Object.entries(nodesByKind).map(([kind, nodes]) => (
+        <NodeGroup
+          key={kind}
+          title={kind.replace(/_/g, " ")}
+          nodes={nodes}
+          resolvedNodeIds={resolvedNodeIdSet}
+          newlySurfacedNodeIds={newlySurfacedNodeIdSet}
+          activeUnknownNodeId={situationGraph.activeUnknownNodeId}
+        />
+      ))}
+
+      <details className="rounded-lg border border-gray-200 bg-gray-50 p-4">
+        <summary className="cursor-pointer text-sm font-medium text-gray-700 underline">
+          Raw graph JSON
+        </summary>
+        <pre className="mt-3 overflow-auto rounded bg-gray-900 p-3 text-xs text-green-400">
+          {JSON.stringify(situationGraph, null, 2)}
+        </pre>
+      </details>
+    </div>
+  );
+}
@@ -0,0 +1,24 @@
+# Confidence Engine — Founding Principles
+
+> **Bring us the mess. We will help you find the next understandable step together.**
+
+## Why this document exists
+
+The Confidence Engine began as an attempt to capture a repeatable way of thinking: break complicated situations into small pieces, admit what is not yet known, and keep moving until the next useful action becomes clear.
+
+## Principles
+
+1. **The engine owns the complexity.** The user should only have to deal with the next manageable step.
+2. **Nothing is difficult when it is broken down enough.** If something still feels overwhelming, it has not yet been broken into small enough pieces.
+3. **Confidence means knowing the next step.** The next step may be an answer, a person to ask, a place to look or a test to run.
+4. **The hardest step should be the first one.** Every following step should feel smaller and more achievable.
+5. **Honest uncertainty builds trust.** The engine should never pretend to understand more than it does.
+6. **Intelligence should make things easier to understand.** Never make the user feel stupid to make the engine look clever.
+7. **The engine guides; it does not judge.** The user should feel accompanied, not examined.
+8. **Progress matters more than performance.** Genuine movement beats impressive-sounding output.
+9. **Experiments beat opinions.** When we do not know, build the smallest thing that can teach us.
+10. **The product should help people earn confidence.** It does not sell certainty; it helps build justified confidence step by step.
+
+## Test for every decision
+
+> Does this make the next step clearer, smaller, more honest or more achievable for the user?
@@ -0,0 +1,31 @@
+# Confidence Engine — Product Story
+
+> **The Confidence Engine helps people take the next small step when a problem feels too big to know where to start.**
+
+## The problem
+
+The blank page is hard because there are too many possible first moves. Most tools ask the user to organise the problem before they can begin.
+
+## The idea
+
+Start with whatever the person can give: a question, observation, concern or messy description. From then on, the engine makes each next step smaller.
+
+## How it works
+
+1. Start with the mess.
+2. Find the next useful uncertainty.
+3. Ask for something achievable.
+4. Remember and reorganise what has been learned.
+5. Build justified confidence until the person knows what to do next.
+
+## What makes it different
+
+It does not simply try to answer. It guides the user from uncertainty to understood next actions, while being honest about what is and is not known.
+
+## Commercial value
+
+RDB Solutions is not selling an LLM or prompt wrapper. It is developing a repeatable method for turning uncertainty into understood next steps, suitable for subscriptions, teams, APIs, domain-specific products and facilitated services.
+
+## Short pitch
+
+> When you do not know where to start, the Confidence Engine helps you find the next small step — then keeps making the next step clear until you are confident enough to act.
@@ -0,0 +1,27 @@
+# Confidence Engine — Language Guide
+
+> **Never use language to make the engine look clever at the user’s expense.**
+
+## Voice
+
+Calm, plain, human, honest, specific, non-judgemental and actionable.
+
+## Translate system language
+
+- `TOO_BROAD` → “We are trying to solve several things at once. Let’s separate one first.”
+- `Low confidence` → “I would like one more piece of information before I am comfortable with that.”
+- `Unknown unresolved` → “We have not established this yet.”
+- `Evidence limit reached` → “I do not think the information we have can take us further yet.”
+- `Cannot determine` → “I cannot tell from what we have so far.”
+
+## Question style
+
+Ask something small enough that the user can answer it, know who to ask, know where to look or know how to test it.
+
+## Avoid
+
+Jargon, grand statements, false certainty, repeated scenario text, long preambles and technical labels that hide meaning.
+
+## Final test
+
+> Would a capable person with no specialist vocabulary understand what we know, what we do not know, and what they can do next?
@@ -0,0 +1,32 @@
+# Rob’s Thinking Model
+
+A working description of the problem-solving habits that inspired the Confidence Engine.
+
+## Central pattern
+
+Question the framing, break the situation into smaller parts, find the next thing that can be understood or tested, and keep moving without pretending to know more than the evidence supports.
+
+## Habits
+
+- Start with what is actually happening.
+- Question the question.
+- Break complexity into small pieces.
+- Find the origin of the situation.
+- Compare action with doing nothing.
+- Prefer experiments over debate.
+- Keep assumptions visible.
+- Look for relationships.
+- Own uncertainty.
+- Seek the next action, not always the answer.
+- Explain so others can use the knowledge.
+- Keep momentum.
+- Notice when terminology or architecture becomes self-important.
+- Stop when enough is known.
+
+## Practical loop
+
+Observe → Separate → Shrink → Act → Update → Repeat → Stop.
+
+## Safeguard against drift
+
+> Did this emerge from observing how Rob thinks, from observing real users, or from observing the working engine? If not, it may be architecture looking for a reason to exist.
@@ -0,0 +1,227 @@
+# Confidence Engine — Return to Origin Context
+**Date:** 18 August 2026  
+**Purpose:** durable project context / methodology checkpoint
+
+> **Build → Break → Learn → STOP.** The recent selector-led work was a valuable implementation hypothesis. The experiments exposed its boundaries. Development is deliberately pausing before optimising the wrong assumption further.
+
+## Purpose of this context update
+
+This document records a deliberate return to the originating Confidence Engine methodology after a productive period of implementation and experimentation. It is not a rejection of the recent work. It preserves what was built, what the experiments exposed, what was learned, and why development is consciously stopping before further optimisation of the current single-next-question architecture.
+
+The context is intended to be durable across future ChatGPT project conversations and repository work. Its purpose is to prevent later sessions from reconstructing the project from the most recent implementation details alone and losing sight of the method the application is meant to embody.
+
+## The originating aim
+
+The Confidence Engine began as an attempt to capture a repeatable way of thinking: take apart complicated situations, separate observation from interpretation, keep assumptions visible, admit what is not yet known, and keep moving until the next useful action becomes clear.
+
+The core commercial ambition is not to build a clever chatbot for its own sake. It is to create transferable intellectual property for RDB Solutions: a methodology that can help people investigate, challenge and understand questions or decisions without depending on Rob personally being present to facilitate every engagement.
+
+The software application is one delivery mechanism. The same underlying method should remain recognisable in a facilitated workshop, a workbook or book, training, consultancy, a team workspace, or another future product.
+
+- The reasoning is the asset; the application is one experience of using it.
+- The engine guides; it does not judge.
+- Confidence is earned through understood evidence and manageable next actions, not through confident-sounding answers.
+- Experiments beat opinions: build something small enough to be wrong, observe it, and change only what the evidence supports.
+
+## What the methodology was always trying to do
+
+The originating method is not fundamentally a question-answer service. It is a disciplined investigation process. The person starts with whatever they can express - a question, concern, observation, decision or messy description. The Engine helps expose structure and then supports the investigation of that structure.
+
+A useful outcome at any point may be an answer, but it may equally be knowing what to check, who to ask, what to measure, what evidence is missing, or what cannot yet be known. An unanswered question is therefore not necessarily a failed conversational turn.
+
+- Start with what is actually happening.
+- Question the question and trace how the present situation arose.
+- Break complexity into pieces small enough to understand.
+- Separate knowns, assumptions, uncertainties and conclusions.
+- Investigate one manageable thing at a time.
+- Add evidence, update understanding and challenge what no longer fits.
+- Compare proposed action with the real alternative, including doing nothing.
+- Continue until the remaining uncertainty is understood well enough for the person to judge whether confidence is sufficient.
+
+## What was built to test the method in software
+
+The application evolved into a credible linear investigation hypothesis. The LLM reconstructs a messy situation into a SituationGraph, the graph holds knowns and unresolved uncertainties, deterministic reasoning selects an active unknown, a graph-backed question is formulated, the user answers it, and the graph updates before the next question is selected.
+
+This was a reasonable implementation hypothesis. It made the method concrete enough to test. The mistake would be to judge it as obviously wrong in hindsight; its value was precisely that it created something real enough to expose boundaries.
+
+## What the recent work achieved well
+
+A substantial amount of the recent work remains valuable. The experiments did not show that the graph, decomposition or investigation concepts were misguided. They showed where authority had been placed in the wrong part of the system.
+
+- LLM reconstruction of messy statements into useful structure.
+- Explicit representation of observations, assumptions, unknowns and relationships.
+- Graph persistence and state mutation as understanding changes.
+- Decomposition of broad uncertainty into smaller investigable questions.
+- Question formulation, answerability checks and reasoning-pattern safeguards.
+- Ownership and continuation invariants that prevent silent target drift.
+- Captured live fixtures, browser journeys and deterministic regressions.
+- A disciplined experimental method: live observation -> capture exact evidence -> isolate first divergence -> regression -> diagnosis -> implementation -> focused verification -> checkpoint.
+
+## What the experiments exposed
+
+The experiments progressively revealed that the single-next-question mechanism had accumulated too much product authority.
+
+One important finding was that question formulation quality and investigation importance are different things. A selected uncertainty could remain the best thing to investigate even when the current wording of its question was rejected. This led to the ownership fix that preserves the investigation target rather than silently transferring to a weaker unrelated node.
+
+A later metamorphic selector experiment exposed a deeper boundary. Two materially equivalent phrasings of the same uncertainty received very different deterministic scores because one phrasing triggered fixed vocabulary rules and the other did not. Wording alone changed the selected investigation target.
+
+- Question rejection must not itself invalidate the investigation target.
+- Deterministic vocabulary weighting can make semantic priority depend on phrasing.
+- Real users use typos, slang, abbreviations, jargon, shorthand and personal language; LLM-generated graph labels also vary between equivalent phrasings.
+- Expanding a keyword dictionary would improve coverage but preserve a finite and brittle semantic boundary.
+- Replacing keyword authority with an invisible LLM ranking could solve the technical symptom while leaving the deeper methodological question unanswered.
+
+## The deeper learning: we asked the wrong product question
+
+Development gradually centred on: "What should the Engine ask next?" The more useful methodological question is: "What useful open questions has the investigation exposed, and how should the person work with them?"
+
+The principle "one useful thing at a time" does not necessarily mean there may only be one available investigation item, nor that the machine must privately determine the only question the user is allowed to answer next. It can instead describe how a chosen investigation thread is broken into manageable steps.
+
+## Return to origin: workspace, detective notebook, workshop
+
+The existing context already described the application as a workspace, notebook and workshop-style environment. The current learning strengthens that interpretation.
+
+The graph should primarily organise and remember the investigation rather than act as an invisible mechanism for forcing one linear route through it. Multiple open questions can coexist. The user can decide where they can make progress while the Engine continues to guide, challenge, connect and remember.
+
+- Surface the open questions the LLM has already derived.
+- Let the user answer what they know now.
+- Let the user choose a question that matters most to them.
+- Allow questions to be deferred when evidence requires research, another person, measurement, calculation or time.
+- Allow the investigation to persist across minutes, days or weeks.
+- Let answers create smaller follow-up questions within a thread: the "just one more thing" pattern.
+- Allow different investigation items to be progressed independently or in parallel.
+- Keep the Engine able to challenge avoidance or highlight an unresolved issue that still materially blocks confidence.
+
+## The role of the user
+
+The user is not merely a respondent supplying missing fields to an automated reasoning pipeline. The user is the investigator. Choosing what to work on is itself part of the reasoning process.
+
+A user may choose an easy question first because they know the answer immediately, defer a hard question because it requires evidence, or focus on the issue they believe matters most. The Engine should make those choices visible and useful rather than treating them as deviations from the correct route.
+
+## The role of the LLM
+
+The LLM is particularly valuable where the project originally intended it to be valuable: understanding messy human language, inferring structure, identifying useful uncertainties, noticing assumptions and inconsistencies, explaining relationships, and helping formulate manageable investigative questions.
+
+It should act as a facilitator of the method rather than as an invisible authority that decides the user's route through the investigation.
+
+## The role of deterministic code
+
+Deterministic code remains valuable for hard invariants and product integrity. The recent experiments sharpen the distinction between semantic judgement and structural guardrails.
+
+- Validate graph membership and node identity.
+- Exclude resolved or structurally invalid items.
+- Maintain relationships, dependencies and persistence.
+- Prevent duplicate or contradictory graph state.
+- Preserve ownership/current focus when a user is working on a thread.
+- Validate structured model output and protect against out-of-set or malformed changes.
+- Record history and preserve the timeline of how understanding changed.
+
+## The role of the graph
+
+The graph should be understood as the evolving case file: a structured memory of the investigation. It records what has been established, what remains uncertain, what evidence supports each item, how items relate, what was resolved, and what changed over time.
+
+An active unknown may remain useful as the item currently being worked on. It should not automatically be interpreted as the one uncertainty the Engine has calculated the user must investigate next.
+
+## Interaction principle: "just one more thing"
+
+"Just one more thing" is not a requirement that the whole application always presents exactly one compulsory question. It is a decomposition principle inside an investigation thread.
+
+When the user chooses an open question, the Engine should help reduce that question into the next small thing needed to understand it. An answer may resolve it, refine it, or expose another smaller uncertainty. That new item becomes part of the notebook rather than forcing the entire investigation into a single linear conversation.
+
+## Interaction can be asynchronous and parallel
+
+Real investigations do not fit neatly into one chat session. Some answers are immediate; others require documents, colleagues, calculations, measurements, research or waiting for events.
+
+The workspace should therefore treat unresolved questions as persistent investigation items rather than failed turns. Different items can be advanced independently or in parallel, and the user should be able to return when new evidence becomes available.
+
+- Open
+- Answerable now
+- Needs investigation
+- Waiting for information
+- Partly answered
+- Resolved
+- No longer material
+
+## Latency supports the methodology rather than fighting it
+
+Long model response times exposed another useful design signal. The product should not make the user wait for reasoning that is not required for their next useful action.
+
+Rather than one large model operation that tries to reconstruct, rank, formulate and validate an entire linear route before the user can act, the experience can progressively surface useful structure and deepen only the investigation item the user chooses to work on.
+
+## Commercial and intellectual-property implication
+
+The valuable asset is not a specific selector, prompt or chat interface. Those can be replaced. The defensible value is the repeatable Confidence Engine method for turning uncertainty into an understandable investigation and helping a person build justified confidence.
+
+That matters directly to RDB Solutions because the aim is to create products and methods that generate value without relying on Rob personally delivering every piece of reasoning. A software workspace, facilitator-led workshop, workbook, training programme or other delivery format can all express the same underlying method.
+
+## Development principle reaffirmed: BUILD -> BREAK -> LEARN -> STOP
+
+The recent work is itself an example of the Confidence Engine philosophy. The project could not know the limits of a selector-led linear conversation until enough of it had been built to observe its behaviour.
+
+The experiments generated evidence. The evidence challenged the underlying assumption. Development stopped before turning the response into an ever-larger dictionary, weight tuning exercise or semantic-ranking subsystem.
+
+Stopping is not failure. It is the point at which explicit reasoning allows the project to avoid sunk-cost optimisation and preserve what was learned.
+
+## What remains valuable from v0.47
+
+The return to origin is not a reset. The following remain valuable assets unless later evidence shows otherwise:
+
+- SituationGraph and structured case state.
+- LLM reconstruction/decomposition.
+- Known / assumed / unknown / evidence distinctions.
+- Relationships and dependencies.
+- Resolution and supersession state.
+- Question decomposition and answerability concepts.
+- Ownership/current-focus semantics where they represent the thread being worked on.
+- Validation and graph-integrity safeguards.
+- Persistent history and captured provenance.
+- Live semantic test discipline and deterministic regression workflow.
+- The existing experimental fixtures and failure evidence that explain how the project reached this point.
+
+## What is now paused
+
+Further work to perfect a compulsory single-next-question selector is paused. This includes both continued keyword/dictionary optimisation and immediate replacement with an invisible semantic ranking mechanism.
+
+No conclusion has yet been made that selection or recommendation has no role. The Engine may still recommend, challenge or identify an issue that materially blocks confidence. What is paused is the assumption that recommendation must equal compulsory routing.
+
+## Current working hypothesis - not yet the final design
+
+The next product hypothesis is that the application should surface the useful investigation structure the Engine already derives and let the person work with it as a persistent workspace.
+
+Multiple open questions can coexist. The user can choose, defer, investigate and return. The Engine keeps the notebook coherent, formulates smaller follow-up questions inside a chosen thread, and eventually makes visible which unresolved items still materially prevent confidence.
+
+This is a hypothesis to test, not a replacement architecture already decided.
+
+## Timeline marker: how we got here
+
+The Confidence Engine principle of tracing origins applies to the project itself. Future work should preserve the timeline rather than flattening it into "old design" and "new design".
+
+- Origin: capture a transferable reasoning methodology that breaks uncertainty into manageable pieces and helps people earn confidence.
+- Early product hypothesis: conversational loop, then notebook/workspace concepts.
+- Implementation hypothesis: graph-backed linear investigation with one selected active unknown and one next question.
+- Build: graph reconstruction, decomposition, patterns, question formulation, ownership and validation were implemented.
+- Break: real browser journeys and deterministic regressions exposed stale ownership, question-rejection and selection-boundary defects.
+- Learn: question wording is not target validity; fixed vocabulary scoring is not paraphrase-invariant; next-question selection had accumulated too much authority.
+- STOP: further selector optimisation paused.
+- Return to origin: reconsider the user experience as a persistent investigation workspace while retaining the valuable reasoning infrastructure already built.
+
+## Next design question - deliberately unanswered
+
+Given the useful investigation structure the Engine can already derive, how should that structure be surfaced so a person can see, choose, defer, investigate and return to open questions while the Engine continues to guide and challenge their thinking toward justified confidence?
+
+The next phase should begin from this methodology question, not from a preselected technical solution.
+
+## Source basis
+
+- `01_Confidence_Engine_Founding_Principles`
+- `02_Confidence_Engine_Product_Story`
+- `04_Rob_Thinking_Model`
+- `06_Confidence_Engine_Context`
+- `07_Rob_Thinking_Style_and_Working_Philosophy`
+- `08_Confidence_Engine_Development_Context`
+- `08_Confidence_Engine_Project_Context_August_2026`
+- `Confidence_Engine_Live_Semantic_Test_Method`
+- `Confidence_Engine_Project_Context_Update_2026-08-17`
+- `Confidence_Engine_Current_Handoff_2026-08-17`
+
+This context update distinguishes established project principles from current implementation learning. The workspace/user-directed investigation model is recorded as the current hypothesis to test, not as a completed replacement architecture.
@@ -0,0 +1,306 @@
+# Architectural Principles — Architecture Experiment 17
+
+> These principles have emerged from Experiments 1–17. They are not derived from external design frameworks. They are distilled from observed patterns across the investigation's own evolution.
+>
+> A principle is only valid until an experiment disproves it. Record contradictions, not comfort.
+
+---
+
+## Principle 1 — Every Layer Has One Responsibility
+
+### Source
+
+Emerges from Experiments 10, 12, 14, 15, 16.
+
+### Statement
+
+Each architectural layer performs exactly one type of work. It does not perform the work of adjacent layers, even when that would be convenient or efficient.
+
+### Derived From
+
+- Graph captures knowledge; narrative translates it; assessment evaluates it; behaviour decides about it; conversation executes it; workspace projects it.
+- When a layer performed two types of work (e.g., graph and narrative mixed), the architecture became fragile. Separating them made each layer independently testable and replaceable.
+
+### Implication
+
+If you can describe a layer's work with "and" in addition to "to", it is doing too much. Split it.
+
+---
+
+## Principle 2 — Information Flows Downward
+
+### Source
+
+Emerges from Experiments 12, 14, 16.
+
+### Statement
+
+Data flows unidirectionally down the architecture during a turn: graph → narrative → assessment → behaviour → conversation → workspace. Each layer transforms data for its audience but never pushes transformed data back to a previous layer during the same turn.
+
+### Derived From
+
+- The graph is the source of truth. Narrative translates it for humans. Assessment evaluates the translation. Behaviour acts on the evaluation. Conversation executes the action. Workspace displays the result.
+- Attempting to push state backward within a turn creates circular dependencies that break deterministic ordering.
+
+### Implication
+
+A layer may read its own output and lower layers' inputs, but it never writes to a lower layer during the same turn. Cross-turn feedback (user responses) enters at the top through user input, not through architectural shortcuts.
+
+---
+
+## Principle 3 — Feedback Flows Upward Through the User
+
+### Source
+
+Emerges from Experiments 9, 10, 14, 15.
+
+### Statement
+
+Information returns to lower layers only through the user. The user's next observation is the mechanism by which new information re-enters the system. No layer injects feedback directly into another layer during a turn.
+
+### Derived From
+
+- The investigation is a conversation between human and machine. The conversation loop is the only legitimate feedback mechanism.
+- Direct layer-to-layer feedback bypasses user awareness and creates hidden state mutations that are impossible to trace or audit.
+
+### Implication
+
+If you need information from layer N+1 to affect layer N-1, go through the user: present it in the workspace, have the user process it, and let their next observation carry the updated understanding back down.
+
+---
+
+## Principle 4 — Reasoning Never Communicates Directly With the UI
+
+### Source
+
+Emerges from Experiments 08, 12, 13, 14.
+
+### Statement
+
+The reasoning graph (the machine's internal representation) never directly drives UI components. All UI content passes through the investigation narrative, which provides human-appropriate translation regardless of graph schema changes.
+
+### Derived From
+
+- Graph nodes use domain-specific categories (observations, unknowns, assumptions, metrics) that are useful for reasoning but not for presentation.
+- The narrative layer proved essential: it is the only layer that understands both the graph's meaning and the user's need.
+- When UI consumed the graph directly (Experiment 10), developer statistics leaked into user-facing panels.
+
+### Implication
+
+The narrative is the contract between reasoning and presentation. Change the graph schema freely — as long as the narrative preserves its fields, the UI never breaks.
+
+---
+
+## Principle 5 — Behaviour Never Reasons
+
+### Source
+
+Emerges from Experiments 15, 16.
+
+### Statement
+
+Behaviour selection operates exclusively on investigation state (assessment), never on graph content or reasoning results. A behaviour's decision about what to do is based on *where the investigation is*, not on *what the graph says*.
+
+### Derived From
+
+- Experiment 16 proved that behaviour selection inspecting graph nodes directly couples behaviour to reasoning implementation. Graph schema changes break behaviour decisions.
+- When behaviour reads assessment instead of graph, it remains correct regardless of how the graph represents knowledge internally.
+
+### Implication
+
+If you can describe a behaviour's logic using "because the graph has node X with status Y," it is reasoning disguised as behaviour. It should read: "because the assessment shows phase F and progress P."
+
+---
+
+## Principle 6 — Presentation Never Interprets
+
+### Source
+
+Emerges from Experiments 12, 13, 14.
+
+### Statement
+
+Workspace panels render what the narrative provides. They do not re-filter, re-rank, or re-classify content. Panels control *how* things are shown (layout, emphasis, visibility), not *what* is shown.
+
+### Derived From
+
+- When each panel reimplemented its own filtering logic (Experiment 13), different panels showed contradictory information about the same investigation state.
+- A single narrative object consumed by all panels eliminates this class of inconsistency.
+
+### Implication
+
+If two panels show different facts about the same investigation, the problem is not the panels — it is that they are consuming different narratives. They must consume the same narrative and differ only in presentation choices (order, emphasis, visibility).
+
+---
+
+## Principle 7 — Assessment Never Generates Evidence
+
+### Source
+
+Emerges from Experiment 16.
+
+### Statement
+
+The assessment layer describes what the investigation has already established. It never creates new evidence, makes new inferences, or proposes new hypotheses. It only evaluates existing state.
+
+### Derived From
+
+- The assessment's role is to provide an accurate mirror of investigation state so that behaviour selection can operate on reality, not on the assessment's own judgments about what might be true.
+- When the assessment generates evidence (even implicitly by treating "unknown" as "probably false"), behaviour selection acts on invented information.
+
+### Implication
+
+Assessment signals are descriptive only: "this is unknown" not "this is probably X." The distinction between "we don't know" and "we know it's not true" must be preserved at every level.
+
+---
+
+## Principle 8 — Narrative Never Invents Facts
+
+### Source
+
+Emerges from Experiments 13, 14.
+
+### Statement
+
+Every element in the narrative must be traceable to one or more graph nodes. The narrative may reorganise, prioritise, deduplicate, and translate — but it may never include content that does not exist somewhere in the reasoning graph.
+
+### Derived From
+
+- Experiment 13 proved that semantic filtering and deduplication improve presentation without inventing content.
+- When narrative synthesis exceeded graph support (e.g., connecting two observations that were never linked by an edge), the facilitator appeared to be hallucinating connections.
+
+### Implication
+
+If you can trace a narrative statement back through the narrative structure to specific graph nodes and edges, it is valid. If not, it must be removed regardless of how useful or coherent it seems.
+
+---
+
+## Principle 9 — Assessment Describes, Never Prescribes
+
+### Source
+
+Emerges from Experiment 16, Principle: "Signals Are Descriptive, Not Prescriptive."
+
+### Statement
+
+The assessment layer reports state using neutral, descriptive language. It never says "therefore the next step should be X." It says "the investigation is in state S along dimension D." The interpretation belongs to behaviour selection.
+
+### Derived From
+
+- A prescriptive assessment becomes a decision tree in disguise, locking the architecture into one strategy for interpreting state.
+- Descriptive assessment supports multiple strategies: deterministic rules, weighted scoring, LLM-assisted reasoning — all reading the same output.
+
+### Implication
+
+Assessment language must survive replacement of the behaviour selection strategy. If the assessment says "Stalled" instead of "You should pause," it passes this test. If it says "Use Pause because progress has stopped," it fails.
+
+---
+
+## Principle 10 — Convergence Over Single Signals
+
+### Source
+
+Emerges from Experiment 16, Principle: "Convergence Matters More Than Any Single Signal."
+
+### Statement
+
+Behaviour selection should prefer actions supported by multiple independent assessment dimensions over actions supported by a single strong signal. Convergent signals are more reliable than any individual dimension's threshold.
+
+### Derived From
+
+- A single dimension reaching a threshold (e.g., Evidence Quality: Contradictory) can produce false positives in edge cases.
+- Multiple dimensions agreeing on a pattern (e.g., Stalled progress + Repetitive conversation + Confused understanding) indicates a robust state that warrants intervention regardless of any one dimension's reliability.
+
+### Implication
+
+Behaviour confidence should be proportional to the number of converging signals, not the strength of the strongest signal. High-confidence actions require multiple supporting dimensions; low-confidence actions are appropriate for single-signal triggers.
+
+---
+
+## Principle 11 — Assessment Is Stateful Across Turns
+
+### Source
+
+Emerges from Experiment 16, Principle: "Assessment Is Stateful Across Turns."
+
+### Statement
+
+The assessment accumulates state across turns. It tracks change (deltas), sequence patterns (repetition), trend direction (acceleration), and phase transitions. A turn-by-turn stateless assessment cannot detect looping, spiralling, or convergence.
+
+### Derived From
+
+- Investigation state is inherently temporal. "Stalled" means nothing without knowing what came before it.
+- The assessment must carry forward state between turns to enable pattern detection across the investigation's history.
+
+### Implication
+
+The assessment's data structure must include turn-level history (not just the current snapshot). The minimum viable history is: phase per turn, resolution count per turn, and response length per turn. Trends emerge from sequences, not snapshots.
+
+---
+
+## Principle 12 — Uncertainty About Assessment Is Itself Assessable
+
+### Source
+
+Emerges from Experiment 16, Principle: "Uncertainty About Assessment Is Itself Assessable."
+
+### Statement
+
+When the assessment cannot reliably evaluate a dimension (insufficient data, conflicting signals, rapid state changes), it should express uncertainty explicitly rather than guessing. The behaviour layer receives "Cannot determine" as a valid signal.
+
+### Derived From
+
+- False precision in assessment produces false confidence in behaviour. An overconfident but wrong assessment is worse than a transparently uncertain one.
+- User-facing confidence must match the system's actual certainty, including its uncertainty about its own certainty.
+
+### Implication
+
+Assessment outputs must include a confidence field per dimension. "Phase: Exploring (confidence: low)" is more useful than "Phase: Exploring (confidence: high)" when the data supports only weak classification. The behaviour layer should treat low-confidence assessments as invitations for conservative action.
+
+---
+
+## Principle 13 — Investigation Progress Is Qualitative Not Quantitative
+
+### Source
+
+Emerges from Experiments 10, 15, 16.
+
+### Statement
+
+Investigation progress is measured by the *quality* of understanding, not the *quantity* of resolved nodes. A single resolved critical unknown provides more investigative value than ten peripheral ones. Progress is trajectory and depth, not count.
+
+### Derived From
+
+- Early experiments focused on node counts (Experiment 10). This proved misleading: a graph can grow large while understanding remains shallow.
+- Expert investigators measure progress by "do we understand the situation better?" not "how many items do we have left?"
+
+### Implication
+
+The assessment should evaluate whether new information clarifies existing understanding or merely adds data points. Understanding compounding (new insights that reframe previous ones) is a stronger progress signal than evidence accumulation.
+
+---
+
+## Principle 14 — The User Is Part of the Architecture
+
+### Source
+
+Emerges from Experiments 9, 10, 15.
+
+### Statement
+
+The user is not an external actor who feeds data into the system. The user's cognitive state (confidence, confusion, engagement, insight) is a first-class architectural input that affects every subsequent turn. The architecture must model and respond to the user as an active investigation participant.
+
+### Derived From
+
+- Experiments consistently showed that user psychology drives investigation outcomes more than graph mechanics do.
+- A technically perfect graph on confused or disengaged data produces worthless results.
+
+### Implication
+
+Every layer should ask: "How does this affect the user's ability and willingness to continue investigating?" If a layer improves graph accuracy but degrades user engagement, it has traded investigation quality for internal elegance — and lost.
+
+---
+
+## Recording Note
+
+These principles emerged from the investigation's own evolution through 17 experiments. They are not imported from external sources. They will be validated or contradicted by future implementations. Record which principle is challenged first — it will be the most informative.
@@ -0,0 +1,28 @@
+# Archive Index — Confidence Engine
+
+> Archived means retained as historical evidence and excluded from normal context loading. It does not mean deleted, rejected or necessarily incorrect for its time.
+
+All files below were moved from `docs/` on 2026-08-06 by Experiment 29 to reduce the default reading burden while preserving full traceability.
+
+## Archived Files
+
+| Original Path | Archive Path | What It Contains | Why Archived | When to Consult |
+|---|---|---|---|---|
+| `docs/v0.4-handoff.md` (258 lines) | `docs/archive/v0.4-handoff.md` | Historical handoff document from the v0.4 transition; references CaseOrchestrator API. | Architecture has evolved since v0.4. Documented for reference only, not active guidance. | When tracing the origin of case-orchestration patterns or investigating historical API design decisions. (Also referenced in `docs/orchestrator-contract.md`.) |
+| `docs/v0.4-route-status.md` (25 lines) | `docs/archive/v0.4-route-status.md` | Historical route tracking for the v0.4 release cycle. | Current routes differ entirely from v0.4. Retained as a record of early routing assumptions. | When investigating why certain routing decisions were made in early versions. |
+| `docs/v0.5-release-notes.md` (58 lines) | `docs/archive/v0.5-release-notes.md` | Release notes documenting the state of v0.5. | Historical record only. Nothing active depends on this content. | When comparing v0.5 to later releases or verifying what was known at that release time. |
+| `docs/v0.6-ambiguity-generalisation.md` (40 lines) | `docs/archive/v0.6-ambiguity-generalisation.md` | v0.6 experiment on ambiguity generalisation. | Superseded by later reasoning architecture decisions from Experiments 15–25B. | When investigating the intellectual history of how the engine handles ambiguous inputs. |
+| `docs/v0.7-observation-report.md` (136 lines) | `docs/archive/v0.7-observation-report.md` | Experimental observation snapshot from v0.7 UX work. | Useful as a reference but not a current working document. UX work is paused. | When reviewing past UX observations that may inform future interface design decisions. |
+| `docs/archive/deferred-ux-backlog.md` (376 lines) | `docs/archive/deferred-ux-backlog.md` | Deferred and exploratory UX ideas from original `docs/backlog info.md` (lines 21–390). Retained for historical reference. Not commitments, priorities or active tasks. | Superseded `docs/backlog info.md`. Deferred UX planning separated from mock reference in Experiment 31. | When a named past UX idea from the deferred backlog is being reviewed; not loaded by default. |
+
+## Superseded Files
+
+The following files were superseded by a structured split in Experiment 31 and are no longer in use. Their contents remain fully represented in the documents below.
+
+| Original Path | Archive Paths (superseding) | Note |
+|---|---|---|
+| `docs/backlog info.md` (390 lines) | `docs/ui-mock-reference.md` (mock fixtures), `docs/archive/deferred-ux-backlog.md` (deferred UX planning) | Superseded 2026-08-06. Split into task-specific mock reference and deferred backlog archive. See Experiment 31 entry in design-evolution-log.md for content accounting. |
+
+## Usage
+
+Load these files only when a specific experiment, version history, or past decision requires them. Use this index to locate archived material — do not read the archive directory by default.
@@ -0,0 +1,376 @@
+This document contains deferred and exploratory UX ideas retained for historical reference. Items are not commitments, priorities or active tasks unless they are reintroduced through a future experiment.
+
+Original source path: `docs/backlog info.md` (split by Experiment 31)
+
+---
+
+# Confidence Engine UI Roadmap
+
+The reasoning engine has reached a point where the next priority is not adding more capability, but improving the experience of using what already exists. The goal is to make the investigation feel coherent, understandable and satisfying while keeping the underlying reasoning visible enough for development without exposing unnecessary complexity to end users.
+
+---
+
+# Phase 1 – Complete the Core Investigation Experience
+
+## 1. Investigation History
+
+Finish the investigation history so it reads like an investigation notebook rather than a chat log.
+
+Each completed question should record:
+
+- The question asked
+- The user's answer
+- The resulting understanding (optional where appropriate)
+
+Example:
+
+```text
+✓ Were both figures measured over the same period?
+
+Answer
+Yes. Both covered the same quarter.
+
+Outcome
+The figures can now be compared directly.
+```
+
+This should become the permanent chronological record of the investigation.
+
+## 2. Current Understanding
+
+Replace "What we've established" with something closer to:
+
+Current understanding
+Confidence so far
+
+The purpose is to show how uncertainty is reducing over time.
+
+Example:
+
+```text
+Current understanding
+
+✓ Same reporting period confirmed
+
+✓ Comparable baselines confirmed
+
+• Complaint rate still requires investigation
+```
+
+This card should update cumulatively after every answer.
+
+## 3. Current Investigation
+
+This becomes the primary focus of the interface.
+
+Keep it deliberately simple.
+
+```text
+Current investigation
+
+Question
+
+...
+
+Why this matters
+
+...
+```
+
+Nothing more.
+
+The user should always understand:
+
+- what they're answering
+- why it matters
+
+## 4. Loading Experience
+
+Replace generic loading messages with investigation-specific feedback.
+
+Examples:
+
+```text
+Reviewing your answer...
+
+Checking what changes...
+
+Updating our understanding...
+
+Choosing the next question...
+```
+
+Avoid fake progress bars or percentages.
+
+# Phase 2 – UX Polish
+
+### Animated progression
+
+Instead of updating the page instantly:
+
+```text
+Answer submitted
+
+↓
+
+History updates
+
+↓
+
+Current understanding updates
+
+↓
+
+Next investigation appears
+```
+
+Small animations should reinforce the feeling of progressing through an investigation.
+
+### Progressive completion
+
+Completed investigation steps should gradually become:
+
+```
+✓ Same reporting period
+
+✓ Comparable baselines
+
+✓ Complaint rate
+
+► Reporting consistency
+```
+
+### Collapsible history
+
+Once the investigation becomes long:
+
+```
+Investigation history (8)
+
+▼
+
+Allow older questions to collapse.
+```
+
+### Better ending states
+
+Avoid generic messages such as:
+
+```
+No further questions.
+```
+
+Instead distinguish between outcomes.
+
+For example:
+
+```
+Current evidence has taken us as far as it can.
+
+Further investigation requires additional evidence.
+```
+
+or
+
+```
+The investigation is complete.
+
+Current confidence is sufficient to make a decision.
+```
+
+Different endings communicate different reasoning outcomes.
+
+## Phase 3 – Developer Experience
+
+Developer Details are becoming crowded.
+
+Split them into logical sections:
+
+```
+Developer Details
+
+Overview
+
+Graph
+
+Diagnostics
+
+Raw JSON
+
+Mock Data
+```
+
+This keeps debugging information available without overwhelming the interface.
+
+## Phase 4 – Mock Scenario Library
+
+Before returning to reasoning refinement, build a richer set of mock scenarios.
+
+These allow UI work to continue independently of the reasoning engine.
+
+#### Existing
+
+- Happy path
+- Complete investigation
+- Error state
+- No question available
+
+#### Required
+
+Contradiction
+
+Two observations conflict.
+
+Example:
+
+```
+Observation A
+
+Observation B
+
+↓
+
+Contradiction detected
+
+↓
+
+Question
+Comparison
+```
+
+Compare two options.
+
+#### Examples:
+
+- House A vs House B
+- Product A vs Product B
+
+#### Definition
+
+Clarify an ambiguous term.
+
+#### Example:
+
+"What do you mean by..."
+
+#### Diagnosis
+
+Fault finding and troubleshooting.
+
+#### Prioritisation
+
+Several competing options requiring selection.
+
+#### Revision
+
+Support changing an earlier answer.
+
+Example:
+
+```
+Q1
+
+A1
+
+Q2
+
+A2
+
+User edits A1
+
+↓
+
+Reasoning rebuilds
+```
+
+Even if replay isn't implemented yet, mock the behaviour.
+
+### Long investigation
+
+10–15 question investigation.
+
+Used for:
+
+- scrolling
+- collapsing history
+- pacing
+
+### Slow provider
+
+Simulate very slow model responses (30–60 seconds).
+
+Used for refining loading behaviour.
+
+### Provider error
+
+Connection failure.
+
+### Malformed provider response
+
+Invalid or partial JSON.
+
+Useful for resilience testing.
+
+## Backlog
+
+Reasoning Replay
+
+Create a replay mode for completed investigations.
+
+Example:
+
+```
+Statement
+
+↓
+
+Question 1
+
+↓
+
+Answer
+
+↓
+
+Graph updates
+
+↓
+
+Question 2
+
+↓
+
+Answer
+
+↓
+
+Graph updates
+
+↓
+
+...
+```
+
+Uses include:
+
+- demonstrations
+- debugging
+- explaining the reasoning process
+- validating graph updates
+
+This reinforces the principle:
+
+    The graph remembers. The conversation explains.
+
+## Deliberately Out of Scope
+
+The following should wait until repeated real-world testing reveals genuine reasoning issues:
+
+- Reasoning algorithms
+- Graph architecture
+- Confidence calculation
+- Decomposition improvements
+- Reasoning pattern expansion
+- Investigation strategy changes
+
+The current focus is making the investigation experience clear, understandable and enjoyable before expanding the reasoning engine further.
@@ -0,0 +1,258 @@
+# v0.4 Handoff — Confidence Engine (confidence-engine)
+
+**Date:** 2026-08-01
+**Branch:** `feature/reconstruction-v0.3`
+**Parent branch:** `main`
+
+---
+
+## 1. What This Project Is
+
+A Next.js app that performs evidence-based situation reconstruction on user-supplied scenarios. An LLM analyses the scenario, builds a directed graph of actors, systems, unknowns and relationships, then iteratively refines the graph through multi-turn Q&A with the user.
+
+---
+
+## 2. Recent Commit History
+
+| Commit | Message |
+|--------|---------|
+| `79ea2f6` | feat: add v0.3 normalised comparison reasoning |
+| `d72c7c5` | chore: establish clean v0.2 baseline |
+| `a2f9e47` | chore: preserve initial reconstruction prototype |
+
+Only **one commit** ahead of `main`: `79ea2f6` — the v0.3 normalised comparison reasoning work.
+
+---
+
+## 3. Current State Summary
+
+### What's done and committed to this branch
+
+1. **v0.3 prompt** (`prompts/reconstruct-v0.3.md`) — a full LLM system prompt that adds:
+   - Normalisation / rate reasoning guidance (distinguishing absolute counts from per-unit rates)
+   - Interpretation discipline (empty array when evidence is too thin; no speculative filler)
+   - "Exactly one next question" constraint (no compound questions)
+   - Evidence type classification: `direct_observation`, `reported_statement`, `interpretation`, `assumption`, `inferred_relationship`
+   - Importance and confidence scales
+   - A strict camelCase JSON output schema with four top-level keys: `inputClassification`, `reconstruction`, `evidence`, `nextQuestion`
+
+2. **v0.3 prompt versioning** (`lib/reconstruction/prompt.js`) — exports `PROMPT_VERSIONS`, `DEFAULT_PROMPT_VERSION ("v0.3")`, and `buildPrompt(scenario, version)` for loading prompt templates from disk with scenario substitution.
+
+3. **Schema validation** (`lib/reconstruction/schema.js`) — Zod schemas for v0.2 output (`reconstructionV2Schema`). A `parseReconstructionV2(rawString)` helper is used in the analysis pipeline.
+
+4. **v0.3 reasoning tests** (`tests/v03-reasoning.test.js`) — extensive test suite covering:
+   - Prompt version registration and loading
+   - v0.3 guidance completeness (normalisation, rate vs count, correlation-vs-causation)
+   - Schema validation with a realistic "production/complaints" fixture
+   - Parse helper tests
+
+5. **Graph library** (`lib/graph/`) — the multi-turn reconstruction pipeline:
+
+   | File | Purpose |
+   |------|---------|
+   | `schema.js` | Zod schemas for SituationNode, SituationEdge, SituationGraph, GraphUpdate; helpers like `makeNodeId`, `makeNode`, `makeEdge`, `makeGraph` |
+   | `builder.js` | `buildInitialGraph(reconstruction, evidence)` — converts v0.2/v0.3 analysis output into a SituationGraph with deterministic nodes/edges; `buildMinimalGraph(scenario)` for fallback; `describeGraph(graph)` for display |
+   | `orchestrator.js` | `CaseOrchestrator` class managing the full multi-turn lifecycle (idle → building → active); exports `startCase(body)` and `updateCase(body)` convenience functions for API routes |
+   | `prompt-builder.js` | `buildUpdatePrompt(ctx)` — formats current graph state + Q&A context into a system prompt for the LLM update-evaluation turn |
+   | `utils.js` | Deterministic graph operations: `validateGraphReferences`, `detectDuplicateNodeIds`, `detectDuplicateEdges`, `findDependentNodes`, `findAffectedNodes`, `resolveUnknownNode`, `selectActiveUnknownCandidate`, `applyGraphUpdate`, `validateGraphUpdate` |
+
+6. **API routes** (`app/api/`)
+
+   | Route | Purpose |
+   |-------|---------|
+   | `POST /api/start-case` | Start a new reconstruction case — accepts `{ scenario, promptVersion? }`, returns graph summary, node/edge counts, next question |
+   | `POST /api/update-case` | Process a turn — accepts `{ scenario, graph, answer, currentQuestion?, turnCount?, modelName? }`, returns updated graph summary, next question, changes summary |
+
+7. **Smoke test** (`tests/smoke.test.js`) — basic integration test for the start-case API route.
+
+### What's NOT yet committed (untracked files from git status)
+
+| File | Description |
+|------|-------------|
+| `lib/graph/` (full directory) | The multi-turn graph library — built but NOT yet committed to any branch. These are the new untracked files: `builder.js`, `orchestrator.js`, `prompt-builder.js`, `schema.js`, `utils.js` |
+| `tests/graph/` (full directory) | Tests for the graph library — also untracked: `builder.test.js`, `orchestrator.test.js`, `prompt-builder.test.js`, `schema.test.js`, `utils.test.js` |
+| `app/api/start-case/route.js` | New API route (untracked) |
+| `app/api/update-case/route.js` | New API route (untracked) |
+
+> **Important:** The git status shows these files as untracked (`??`). They exist on disk but have never been staged or committed. You need to decide whether to commit them now or integrate them differently.
+
+---
+
+## 4. Test Status
+
+```
+Test Files:  4 failed | 4 passed (8)
+Tests:       5 failed | 216 passed (221)
+```
+
+### Known failures
+
+The failures cluster in `tests/graph/`:
+- **`prompt-builder.test.js`** — test expects the literal string `"Existing or newly added nodes"` but the prompt template currently says `"existing or newly added nodes"` (case mismatch). The SYSTEM_PROMPT_HEADER constant uses lowercase.
+- Other graph tests likely have similar fixture/reference issues.
+
+Run `npx vitest run tests/graph/ --reporter=verbose` for full details.
+
+---
+
+## 5. Architecture Overview
+
+```
+User scenario
+      │
+      ▼
+┌──────────────┐     ┌─────────────────┐     ┌──────────────┐
+│ analyseScenario│──▶│ buildPrompt     │──▶│ LLM (v0.3)   │
+│  (lib/analysis.js) │  (reconstruction/prompt.js) │              │
+└──────────────┘     └─────────────────┘     └──────┬───────┘
+                                                      │
+                                                      ▼
+                                              ┌──────────────┐
+                                              │ Parse output │
+                                              │ (Zod/parse   │
+                                              │  Reconstruction│
+                                              │  V2)          │
+                                              └──────┬───────┘
+                                                     │
+                     ┌───────────────────────────────┤
+                     ▼                               ▼
+              ┌──────────────┐           ┌──────────────────┐
+              │buildInitialGraph│         │ buildMinimalGraph │
+              │  (graph/builder)│         │  (fallback)       │
+              └──────┬─────────┘           └──────────────────┘
+                     │
+                     ▼
+              ┌──────────────┐
+              │SituationGraph │  ← Zod-validated graph structure
+              │  {nodes, edges}│     nodes: observation/metric/unknown/...
+              └──────┬───────┘     edges: supports/weakens/causes/...
+                     │
+          (multi-turn loop via updateCase)
+                     │
+           ┌─────────▼─────────┐
+           │buildUpdatePrompt  │  → LLM proposes GraphUpdate
+           │                   │
+           │applyGraphUpdate   │  → deterministic, validated
+           │validateGraphUpdate│     (no direct LLM mutation)
+           └───────────────────┘
+```
+
+---
+
+## 6. Key Design Decisions
+
+### Normalisation / rate reasoning (v0.3 focus)
+The v0.3 prompt explicitly instructs the model to:
+- Always consider whether a denominator/exposure metric is needed when counts change alongside scale
+- Distinguish absolute count from rate
+- Avoid treating two rising counts as causal evidence (production growth may outpace complaint growth)
+- Request the per-unit metric as the highest-value next question
+
+### Graph immutability
+LLM proposals are never applied directly. All mutations go through `applyGraphUpdate()` in `lib/graph/utils.js`, which:
+- Validates all node/edge references exist
+- Rejects duplicate IDs
+- Enforces a max graph size (500 nodes) and update size (100KB)
+- Returns the full new state for validation
+
+### Prompt versioning
+- Default is `"v0.3"` but `PROMPT_VERSIONS` includes `"v0.2"` for backward compatibility
+- `RECONSTRUCTION_PROMPT_VERSION` env var can override default at module load time
+- Prompts are loaded from `prompts/reconstruct-v0.{version}.md` on disk
+
+### Deterministic node IDs
+Node IDs are computed via a deterministic hash of the label: `makeNodeId(label)`. This avoids conflicts but means nodes must be created with consistent labels to get consistent IDs.
+
+---
+
+## 7. Open Questions / TODOs for Next Developer
+
+1. **Untracked graph library** — `lib/graph/` and `tests/graph/` are untracked on disk. Do we commit them as part of v0.4, or keep them in a separate branch?
+
+2. **Test failures** — 5 tests fail across the graph test suite. The prompt-builder case-sensitivity issue needs fixing. Review all failing tests before merging.
+
+3. **Missing `RECONSTRUCTION_PROMPT_VERSION` env var docs** — The system uses an env var override but it's not documented in `.env.example`. Add it if it's intended to be configurable.
+
+4. **Provider integration** — `lib/llm/provider.js` is imported by the orchestrator (`getProvider()`, `generateReconstruction()`). Verify the provider implementation matches what this code expects.
+
+5. **Graph completeness heuristic** — `CaseOrchestrator.getCompletionStatus()` returns `"complete"` when no unknown nodes remain, but doesn't consider whether all important observations have been verified.
+
+6. **Error resilience in update flow** — If the LLM returns malformed JSON, the update route returns a 500 with a generic error message. Consider retry logic or structured error parsing.
+
+7. **`buildUpdatePrompt` SYSTEM_PROMPT_HEADER is a module-level constant** — it's hardcoded and never versioned. If v0.5 changes the update-evaluation prompt style, this will need to become a template.
+
+8. **The `nextQuestion` field on `/api/start-case` response** includes the adapted question (original + active unknown label appended). The client may want the original and adapted separately.
+
+---
+
+## 8. File Inventory (new / changed files on this branch)
+
+### Prompts
+- `prompts/reconstruct-v0.3.md` — **NEW** — v0.3 system prompt (161 lines)
+- `prompts/reconstruct-v0.2.md` — **existing** — baseline prompt
+
+### Core library
+- `lib/analysis.js` — **MODIFIED** — analyseScenario function (uses v0.3 prompt by default)
+- `lib/reconstruction/prompt.js` — **MODIFIED** — prompt versioning exports
+- `lib/reconstruction/schema.js` — **existing** — Zod schemas + parseReconstructionV2
+
+### Graph library (untracked on disk)
+- `lib/graph/builder.js` — buildInitialGraph, buildMinimalGraph, describeGraph
+- `lib/graph/orchestrator.js` — CaseOrchestrator class, startCase, updateCase
+- `lib/graph/prompt-builder.js` — buildUpdatePrompt + SYSTEM_PROMPT_HEADER
+- `lib/graph/schema.js` — SituationNode/Edge/Graph/Update Zod schemas
+- `lib/graph/utils.js` — validation, dedup, dependency, and apply utilities
+
+### API routes (untracked on disk)
+- `app/api/start-case/route.js`
+- `app/api/update-case/route.js`
+
+### Tests (untracked on disk)
+- `tests/graph/builder.test.js`
+- `tests/graph/orchestrator.test.js`
+- `tests/graph/prompt-builder.test.js`
+- `tests/graph/schema.test.js`
+- `tests/graph/utils.test.js`
+- `tests/v03-reasoning.test.js` — **committed** to current branch
+- `tests/smoke.test.js`
+
+### Config changes
+- `package.json` — added dependency (verify which one)
+- `playwright.config.js` — added/modified for integration testing
+- `.env.local` — exists locally (not committed)
+
+---
+
+## 9. How to Run
+
+```bash
+# Install dependencies
+npm install
+
+# Unit tests
+npx vitest run
+
+# Graph library tests (has 5 failures)
+npx vitest run tests/graph/ --reporter=verbose
+
+# Start dev server
+npm run dev
+
+# API endpoints
+# POST /api/start-case    → { scenario: "..." }
+# POST /api/update-case   → { graph: {...}, answer: "...", ... }
+```
+
+---
+
+## 10. What to Do First (Recommended Priorities)
+
+1. **Review and fix the 5 failing tests** — likely simple string/fixture issues
+2. **Decide on the untracked files** — commit them, or create a v0.4 branch from this point
+3. **Verify the LLM provider integration** — ensure `getProvider()` and `generateReconstruction()` are wired up correctly
+4. **Add env var documentation** for `RECONSTRUCTION_PROMPT_VERSION` to `.env.example`
+5. **Smoke test end-to-end** — call `/api/start-case` with a real scenario and verify the full flow
+
+---
+
+*End of handoff.*
@@ -0,0 +1,25 @@
+# v0.4 Route Status
+
+- `app/api/cases/start/route.js`
+  - Current tracked start-case route for the v0.4 graph orchestration path.
+  - Covered by `tests/app/api/cases-start-route.test.js`.
+
+- `app/api/cases/update/route.js`
+  - Current tracked update-case route for the v0.4 graph orchestration path.
+  - Delegates to `updateCase(body, { applyProposal: true })`.
+  - Covered by `tests/app/api/cases-update-route.test.js`.
+
+- `app/api/start-case/route.js`
+  - Earlier experiment / duplicate start route.
+  - No repository UI/test references were found.
+  - Deleted from the working tree during UI connection cleanup.
+
+- `app/api/update-case/route.js`
+  - Earlier experimental duplicate update route.
+  - Removed from the working tree during route consolidation.
+
+- Current UI status
+  - `components/scenario-form.jsx` now calls `/api/cases/start` for the main experimental flow.
+  - `/api/cases/update` is the active tracked update route.
+  - `/api/analyse` remains available for legacy one-shot analysis.
+  - No UI changes were required for this route milestone.
@@ -0,0 +1,58 @@
+# v0.5 Release Notes
+
+## Purpose of v0.5
+
+v0.5 stabilises the graph-backed one-turn update flow so the engine can resolve an answered unknown, surface consequential new unknowns, prioritise the next unknown deterministically, and formulate a deterministic follow-up question without changing the UI or adding more model turns.
+
+## Capabilities proven
+
+v0.5 includes:
+
+- resolving an existing unknown
+- surfacing consequential new unknowns
+- limiting emergent unknowns
+- deterministic information-value prioritisation
+- deterministic question formulation
+- generalisation across five decision types
+- graph-backed one-turn UI update
+
+## Five-case generalisation result
+
+All five deterministic fixture scenarios passed:
+
+1. Should we hire another engineer?
+2. Should we replace the delivery vans?
+3. Should we launch in another country?
+4. Should we continue a project that is over budget?
+5. Should we introduce a paid support tier?
+
+The selector chose a foundational unknown first in each case, avoided the downstream leaf first, required no model call, and preserved graph immutability during question formulation.
+
+## Key deterministic safeguards
+
+- proposal application re-selects the active unknown deterministically after validation
+- information-value scoring penalises downstream or prerequisite-blocked unknowns
+- emergent unknown validation limits additions and requires explicit answer-derived linkage
+- final question wording is reformulated from graph context without an extra model turn
+- question validation rejects compound, awkward, or pricing-led fallback phrasing
+
+## Known limitation
+
+A correctly selected threshold node can still be phrased using an actor/customer strategy when surrounding graph context strongly references customers or value recipients.
+
+This limitation is recorded for the next experiment and is not being fixed in the v0.5 release-prep task.
+
+## Deliberately excluded work
+
+- no reasoning-logic expansion beyond the small deterministic formulation fixes already landed on the branch
+- no new features
+- no UI changes
+- no persistence
+- no additional model turn
+- no Ollama calls for validation
+- no evaluator-suite runs
+- no Playwright runs
+
+## Next experimental question
+
+Can the question formulation strategy remain aligned with the selected node's role when surrounding graph context contains competing signals?
@@ -0,0 +1,40 @@
+# v0.6 Ambiguity Generalisation
+
+## Hypothesis
+
+If the selector truly handles unjustified contradiction ties generically, it should return ambiguity across multiple domains without preferring one explanation by wording alone.
+
+## Scenarios
+
+1. Revenue increased by 18%, but cash in the bank fell over the same period.
+2. Customer satisfaction scores increased, but complaints also increased.
+3. Average delivery time decreased by 25%, but order cancellations increased.
+4. Website traffic doubled, but sales remained unchanged.
+5. Production output increased by 30%, but quality defects also increased.
+
+## Observed behaviour
+
+All five fixtures produced the same pattern:
+
+- candidate count: 2
+- selector status: `ambiguous`
+- tie reason: `No justified distinction between leading unknowns.`
+- no explanation was favoured
+- one broad investigation question was produced from the central contradiction
+- neutral label renaming did not collapse ambiguity into a winner
+
+## Repeated failure patterns
+
+None observed across two or more scenarios.
+
+The current ambiguity handling generalised cleanly across the five contradiction fixtures.
+
+## Corrections
+
+No production correction was required in this task.
+
+## Lessons learned
+
+- The current ambiguity path appears domain-agnostic when structure and semantic weights remain intentionally non-discriminating.
+- Central-statement-based tie questions are broad enough to avoid prematurely backing one branch.
+- The most useful regression signal is whether ambiguity survives neutral relabelling, not whether one label sorts ahead of another in display order.
@@ -0,0 +1,136 @@
+# v0.7 Observation Report
+
+**Date**: 2026-08-03 | **Commit**: c273209 | **Branch**: feature/reasoning-pattern-memory-v0.7
+
+## Summary Table
+
+| Scenario | Name | Start | Update | Nodes | Unknowns | Rating |
+|----------|------|-------|--------|-------|----------|--------|
+| scenario-1 | Confidence Engine commercial validation | pass | fail(400) | 9 | 3 | flow failure |
+| scenario-2 | Hiring | pass | fail(400) | 18 | 8 | flow failure |
+| scenario-3 | Vehicle replacement | pass | fail(400) | 15 | 8 | flow failure |
+| scenario-4 | Welsh Government-style programme decision | pass | fail(400) | 10 | 3 | flow failure |
+| scenario-5 | Operational contradiction | pass | fail(400) | 7 | 2 | flow failure |
+| scenario-6 | Personal decision | fail | skipped | 0 | 0 | flow failure |
+
+## Per-Scenario Findings
+
+### scenario-1: Confidence Engine commercial validation
+
+- **Overall**: Start=pass, Update=fail(400), Rating=flow failure
+- Pattern: N/A | Nodes: 9 | Edges: 0
+- Validation: valid | Duration: 63386ms
+- Unknown IDs: nirkgb4, n36c0cc, nzeyzkz
+- Error: [N/A] Invalid update-case request
+
+- **Assessment**:
+  - reasoning-pattern fit: fail
+  - one-concept simplicity: fail
+  - plain-language clarity: fail
+  - logical progression: fail (No question generated)
+  - graph-backed: fail
+  - premature-specialism avoided: fail
+
+### scenario-2: Hiring
+
+- **Overall**: Start=pass, Update=fail(400), Rating=flow failure
+- Pattern: N/A | Nodes: 18 | Edges: 5
+- Validation: valid | Duration: 146476ms
+- Unknown IDs: n7yonyv, npci7a7, nug9wj2, nz0vpey, nz8pwyc, newxmzu, nw14mjj, n25mnp3
+- Error: [N/A] Invalid update-case request
+
+- **Assessment**:
+  - reasoning-pattern fit: fail
+  - one-concept simplicity: fail
+  - plain-language clarity: fail
+  - logical progression: fail (No question generated)
+  - graph-backed: fail
+  - premature-specialism avoided: fail
+
+### scenario-3: Vehicle replacement
+
+- **Overall**: Start=pass, Update=fail(400), Rating=flow failure
+- Pattern: N/A | Nodes: 15 | Edges: 5
+- Validation: valid | Duration: 81460ms
+- Unknown IDs: ng5yr11, nogqips, n499gin, n8fbv3p, nf2f6zx, n4feiap, nvwthlt, nqrxjli
+- Error: [N/A] Invalid update-case request
+
+- **Assessment**:
+  - reasoning-pattern fit: fail
+  - one-concept simplicity: fail
+  - plain-language clarity: fail
+  - logical progression: fail (No question generated)
+  - graph-backed: fail
+  - premature-specialism avoided: fail
+
+### scenario-4: Welsh Government-style programme decision
+
+- **Overall**: Start=pass, Update=fail(400), Rating=flow failure
+- Pattern: N/A | Nodes: 10 | Edges: 0
+- Validation: valid | Duration: 129682ms
+- Unknown IDs: nrrm3qn, nefmpat, n6rtwg1
+- Error: [N/A] Invalid update-case request
+
+- **Assessment**:
+  - reasoning-pattern fit: fail
+  - one-concept simplicity: fail
+  - plain-language clarity: fail
+  - logical progression: fail (No question generated)
+  - graph-backed: fail
+  - premature-specialism avoided: fail
+
+### scenario-5: Operational contradiction
+
+- **Overall**: Start=pass, Update=fail(400), Rating=flow failure
+- Pattern: N/A | Nodes: 7 | Edges: 0
+- Validation: valid | Duration: 70579ms
+- Unknown IDs: n6gm2cv, nylhu9g
+- Error: [N/A] Invalid update-case request
+
+- **Assessment**:
+  - reasoning-pattern fit: fail
+  - one-concept simplicity: fail
+  - plain-language clarity: fail
+  - logical progression: fail (No question generated)
+  - graph-backed: fail
+  - premature-specialism avoided: fail
+
+### scenario-6: Personal decision
+
+- **Overall**: Start=fail, Update=skipped, Rating=flow failure
+- Pattern: N/A | Nodes: 0 | Edges: 0
+- Validation: invalid | Duration: 72547ms
+
+- **Assessment**:
+  - reasoning-pattern fit: fail
+  - one-concept simplicity: fail
+  - plain-language clarity: fail
+  - logical progression: fail (No question generated)
+  - graph-backed: fail
+  - premature-specialism avoided: fail
+
+## Failure Pattern Analysis
+
+### Start Phase
+- **5/6 succeeded**, 1/6 failed
+  - scenario-6: Scenario analysis failed
+
+### Update Phase
+- **0/6 succeeded**, 5/6 failed, 1/6 skipped
+
+- **N/A** (5 failures):
+  - scenario-1: Invalid update-case request
+  - scenario-2: Invalid update-case request
+  - scenario-3: Invalid update-case request
+  - scenario-4: Invalid update-case request
+  - scenario-5: Invalid update-case request
+
+## What's Stable
+
+- ✅ **Graph construction**: 5/6 start success across all scenario types (commercial, operational, personal, policy)
+
+## Recommendations
+
+1. **Fix update failures** (5/6): Primary focus area. Most failures in proposal_compatibility and delta detection.
+- Monitor reasoning pattern inference reliability across different scenario domains.
+- Consider adding timeout guards for long-running LLM calls (some exceeded 60s).
@@ -0,0 +1,140 @@
+# Behaviour Selection — v0.1 Implementation Brief
+
+> **Status: Design only.** Experiment 19 pending. This brief is a constraint on the experiment, not an architecture.
+
+---
+
+## The Problem (Discovered)
+
+Experiments 1–14 proved that the workspace layout is stable and the reasoning engine works. What they revealed but could not fix:
+
+> The current engine behaviour is: **ask → wait → ask → wait**. Every turn produces a question. This makes the investigation feel like automated Q&A rather than guided thinking.
+
+The user's framing from Exp 15: *"An expert consultant does not have a script. They have behaviours — recurring patterns of action that they deploy based on what they observe."*
+
+This experiment tests whether adding **behaviour selection** between assessment and conversation changes that pattern in a meaningful way.
+
+---
+
+## What We Can Measure Now (From Exp 18)
+
+The assessor produces three reliable dimensions:
+
+| Dimension | What it tells us | Available now? |
+|-----------|-----------------|----------------|
+| Phase | Where the investigation is (orienting → concluding) | ✓ |
+| Progress | Whether understanding is advancing (accelerating/steady/stalled) | ✓ |
+| Conversation Health | Whether the interaction pattern is productive (healthy/too_broad/too_narrow) | ✓ |
+
+These are sufficient for a first test. We do not need evidence quality, uncertainty trend, or understanding trajectory yet.
+
+---
+
+## v0.1 Behaviour Set: Five Patterns
+
+The smallest useful set that covers the gap between "always asking" and "facilitated thinking":
+
+| Behaviour | When to deploy | What it does |
+|-----------|---------------|--------------|
+| **Acknowledge** | Any turn where user provided useful information (at least one resolved node) | State what was learned; do not immediately ask a new question |
+| **Clarify** | Conversation health is `too_broad` or phase is `orienting` with insufficient data | Ask for a single specific piece of context, not an unknown-node query |
+| **Summarise** | Phase is `synthesising` or `concluding`; or ≥3 turns have passed without summarisation | Restate current understanding; compress without losing detail |
+| **Continue** | Default — no other behaviour matches | Ask the next useful question (current behaviour, but made explicit) |
+| **Pause** | Phase is `focusing` with stalled progress | Hold space; acknowledge what was learned; invite reflection rather than asking for more |
+
+Every turn must select exactly one of these. No combinations, no secondary actions. The test is: does *choosing* change the pattern?
+
+---
+
+## Selection Rules (One Rule Per Behaviour)
+
+These are plain conditions with no scoring, no weights, no convergence:
+
+1. **Acknowledge triggers** if `conversation health == healthy` AND at least one node was resolved this turn
+2. **Clarify triggers** if `conversation health == too_broad` OR `phase == orienting` AND observations < 3
+3. **Summarise triggers** if `phase == synthesising` OR `phase == concluding` OR (turns ≥ 3 AND no summarisation in recent turns)
+4. **Pause triggers** if `phase == focusing` AND `progress == stalled`
+5. **Continue** is the default — use it when none of the above match
+
+If multiple rules fire simultaneously, priority is: Acknowledge > Clarify > Summarise > Pause > Continue. No convergence required. If two conditions are equally relevant, pick the one that adds *information* rather than the one that asks for more input.
+
+---
+
+## What v0.1 Does NOT Do
+
+These are intentional exclusions — not deferred features:
+
+- **No scoring or weighting.** A condition either matches or it doesn't.
+- **No "convergence" threshold.** If two dimensions trigger, pick by the priority rule.
+- **No evidence quality or uncertainty trend integration.** We don't have that data yet, and we don't need it for this test.
+- **No stable behaviour pairing.** Acknowledge replaces "acknowledge + communicate confidence." One action per turn.
+- **No rationale output or developer view.** That's infrastructure, not signal.
+- **No phase-constrained allow/block tables.** The rules above *are* the constraints.
+
+---
+
+## Success Criteria
+
+How we know whether behaviour selection is worth continuing:
+
+1. **Behaviour diversity:** Does the system deploy at least 3 different behaviours across a normal investigation, or does it default to Continue (Continue) most of the time?
+2. **Acknowledge appears:** Does Acknowledge fire whenever new information resolves an uncertainty? If not, the trigger condition is wrong — fix it, don't abandon selection.
+3. **Pause feels like relief, not delay:** When Pause fires, does the user experience it as a natural break rather than a system failure to produce a question?
+4. **Summarise compresses meaningfully:** Does the summarised understanding feel useful (new synthesis) or redundant (restatement of what's already on screen)?
+5. **Conversation rhythm changes:** Is there a perceptible difference between "engine always asking" and "engine sometimes acknowledging/summarising/pausing first"?
+
+If none of these can be evaluated after 2-3 real investigations with v0.1, the experiment was too small to answer the question. Expand the behaviour set or extend the test — don't abandon selection.
+
+---
+
+## Future Considerations (Not In v0.1)
+
+| Concept | Status | Why deferred |
+|---------|--------|-------------|
+| Signal weighting / scoring formula | Speculative | No observed basis; inventing numbers |
+| Convergence requirement | Speculative | Design preference, not discovery |
+| Behaviour Readiness derived dimension | Architecture housekeeping | Useful later if v0.1 validates the approach |
+| Full 14-behaviour inventory | Available but not tested | Expand only after v0.1 proves the mechanism works |
+| Rationale output for developer view | Infrastructure | Not signal; can be added post-validation |
+| Multi-dimensional contradiction detection | Complex, unneeded yet | One rule per behaviour is simpler and testable |
+| Phase-specific allow/block tables | Invented constraints | Rules above *are* the constraints |
+
+---
+
+## Evaluation Criteria for Behaviour Selection
+
+How we know a behaviour is working? Not through visual metrics, but through conversational quality:
+
+1. **Does each turn feel like it builds on the previous one?** (Continuity)
+2. **Does the user understand why they are being asked what they are being asked?** (Purpose)
+3. **Does the investigation feel guided rather than mechanical?** (Direction)
+4. **Does the user feel understood, not just processed?** (Respect)
+5. **Does uncertainty feel honest, not manufactured?** (Trust)
+6. **Does progress feel real, not illusory?** (Substance)
+
+These six criteria come directly from `facilitator-behaviour.md` (Experiment 14). They apply to all experiments that touch conversation behaviour.
+
+---
+
+## Relationship to Assessment Layer
+
+Behaviour Selection does not replace the assessor. It *consumes* it.
+
+| Assessment Dimension | How Selection Uses It |
+|---------------------|----------------------|
+| Phase | Determines which behaviours are available (orienting → acknowledge/clarify; synthesising → summarise) |
+| Progress | Stalled progress in focusing phase triggers Pause instead of Continue |
+| Conversation Health | `too_broad` triggers Clarify; healthy with resolution triggers Acknowledge |
+
+If the assessment contract changes, selection rules that read those dimensions must be reviewed. The mechanism (plain condition matching, no scoring) is stable regardless.
+
+---
+
+## What This Experiment Proves
+
+One question: **Does selecting from a small set of behaviours — instead of always asking — make the investigation feel more like guided thinking and less like automated Q&A?**
+
+If yes: expand the behaviour set and test refinement in v0.2.
+If no: either the five behaviours are wrong (not selection itself) or the engine's core loop needs a deeper change than this layer can provide.
+
+Nothing else matters until this is answered.
@@ -0,0 +1,47 @@
+# Checkpoint 60B.93 — Investigation Ownership Preservation
+
+## Starting state
+- HEAD: `d908f37`
+- Branch: `feature/decision-closure-ownership-v0.47`
+
+## Two ownership invariants implemented
+
+### 1. Substantive-tie active ownership (lib/graph/utils.js)
+When all leading structural candidates are tied after score, structural, and semantic checks, the currently active investigation target (`activeUnknownNodeId`) is preserved as the selection winner — provided it remains eligible (unresolved, not contradicted) and among the top ties. Stable label/display-order ordering is only used as a final fallback when there is no active candidate or the active node does not remain tied.
+
+### 2. Question-rejection active ownership (lib/graph/apply-proposal.js)
+When a selected candidate's graph-backed question formulation is rejected as too complex (decomposition-required), the system does NOT reseat investigation ownership to another candidate. The original selection target retains its identity with `selectedQuestion = null` and an explicit rejection reason.
+
+## Six exact verification commands and results
+
+| # | Command | Result |
+|---|---------|--------|
+| 1 | `npx vitest run tests/graph/utils.test.js` | PASS (83/83) |
+| 2 | `npx vitest run tests/graph/orchestrator.test.js -t "retains ownership when the strongest target's formulated question is rejected"` | PASS |
+| 3 | `npx vitest run tests/graph/orchestrator.test.js -t "replays the captured live product-launch start graph through deterministic graph-backed question selection"` | PASS |
+| 4 | `npx vitest run tests/graph/apply-proposal.test.js -t "QUESTION_CONTINUATION"` | PASS |
+| 5 | `npx vitest run tests/graph/question-formulator.test.js -t "60B.84"` (located in question-formulator, not apply-proposal) | PASS |
+| 6 | `npx vitest run tests/graph/apply-proposal.test.js -t "State B"` | PASS |
+
+## Classification: A — CHECKPOINT GREEN
+
+## Captured fixture path
+`tests/fixtures/live-product-launch-start-response.json`
+
+## Reasoning files included
+- `lib/graph/utils.js` — `classifyCandidateOrdering()` active-node tie preservation
+- `tests/graph/utils.test.js` — 5 new/modified ownership guard tests
+- `lib/graph/apply-proposal.js` — question-rejection no-res eating invariant
+- `tests/graph/orchestrator.test.js` — 2 new product-launch regression tests
+
+## What this checkpoint establishes
+1. Active investigation ownership is preserved across complete substantive ties when the active node remains eligible.
+2. Question-formulation rejection does not transfer ownership to a weaker candidate.
+3. Neither fix breaks QUESTION_CONTINUATION, 60B.84, or State B.
+4. The captured live product-launch case deterministically preserves ntpt9ki as the active target through question rejection.
+
+## What remains unproved
+- Live behavioural validation of the fixes in a full product-launch interaction
+- Whether same-target reformulation would produce better user outcomes than no-question
+- Full-suite state beyond these six guards
+- The correctness of the underlying question-complexity heuristic (separate concern)
@@ -0,0 +1,58 @@
+# Cold-Start Validation — Experiment 38
+
+## 1. Context Initially Loaded
+
+- `docs/current-handoff.md` (primary entry point, per handoff §6 step 1)
+- `docs/current-project-state.md` (per handoff §6 step 2 and section 7 routing table)
+- `docs/task-context-packs.md` (per handoff §6 step 3)
+
+## 2. Additional Context Loaded
+
+None required. All project state, capability boundaries, and context-pack selection were determined from the three initial documents without loading the full design-evolution log, archived material, or source code.
+
+## 3. Project-State Recovery
+
+The Confidence Engine helps users decide whether they have enough justified confidence to act on a complicated problem, one step at a time. It reconstructs situations, separates observations/assumptions/relationships/unknowns, builds reasoning graphs, selects unresolved uncertainties, asks questions, and updates from answers until action is justified.
+
+**Active capabilities:** deterministic reasoning pipeline (scenario reconstruction → graph update → propagation → confidence/completeness), unknown selection via atomicity/answerability checks, question formulation within a reasoning pattern, scenario API (analyseScenario/updateCase), investigation turn cycle orchestration.
+
+**Passive/diagnostic only:** investigation-state assessment, behaviour selection, decision condition status evaluation, question-to-condition relevance scoring, evidence direction classification, evidence scope detection, scope-aware condition status via phrase matching — all from Experiments 18–25B, none control the user-facing investigation.
+
+**Paused work:** engine experiments (after Exp 25B), UI experiments.
+
+**Active work:** none currently; knowledge-management phase concluded pending Rob's review.
+
+**Why KM phase:** documentation had grown large enough to overload Claude and make returning across sessions difficult.
+
+## 4. Context-Pack Selection
+
+- **Pack selected:** Pack 1 — Engine Experiment Work.
+- **Default documents:** `docs/current-project-state.md`, `docs/current-working-principles.md`, `.claude/architecture-guardrails.md`, `docs/current-implementation-verification.md`.
+- **Deliberately excluded:** full design-evolution history, archived documents, UI mock reference, deferred UX backlog.
+- **Additional required document:** none — the three initial files fully determined the pack choice and all boundaries.
+
+## 5. Resume Boundary
+
+The active reasoning loop is intact: deterministic pipeline processes scenario reconstruction → graph update → propagation → confidence/completeness. Everything from Experiments 18–25B remains isolated diagnostic layers outside this loop. Specifically:
+
+- Investigation-state assessment: passive, no active integration.
+- Behaviour selection: no callers outside its own module.
+- Decision/evidence classifiers: passive recording signals only.
+
+A safe starting boundary for resumed engine work would be one isolated passive module at a time — not connecting anything to the active pipeline until Rob chooses which passive classifier to test first.
+
+## 6. Engine-Work Resume Brief
+
+Experiment 25B established scope-aware condition status — distinguishing direct evidence from relevant-but-different claims by checking subject, timeframe and claim type independently. Phrase-based language interpretation remains provisional scaffolding: narrow, targeted, replaceable, not a finished language-understanding system. The active runtime file to inspect first would be `docs/current-implementation-verification.md` to confirm current module boundaries. Behaviour Selection (or investigation-state assessment) from Experiments 18–25B is the likely subject of the next passive-to-active integration experiment. Nothing must change until Rob chooses and designs the next experiment.
+
+## 7. Handoff Defects Found
+
+None found. The handoff accurately describes the stopping point, identifies all seven completion criteria as met, provides correct resume instructions, and includes the appropriate routing table and return-to-work note format.
+
+## 8. Overall Result
+
+**Ready to resume engine experiments**
+
+Evidence: A genuinely cold session (no prior conversation context) recovered the complete project state from three documents, correctly identified the Engine Experiment pack, distinguished active vs passive capabilities without reading source code or full history, found no handoff defects, and confirmed all seven knowledge-management criteria are met. The reduced context system works for a fresh session.
+
+Knowledge-management phase is complete enough for Rob to choose when engine experiments resume.
@@ -0,0 +1,646 @@
+# Confidence Engine — Decomposition and Atomic Reasoning Specification
+
+**Status:** Working design specification  
+**Purpose:** Source of truth for future reasoning-engine implementation and review  
+**Audience:** Product owner, reasoning-engine developers, coding agents, testers and future methodology authors
+
+---
+
+## 1. Plain-English meaning
+
+Decomposition means breaking one difficult uncertainty into smaller uncertainties until each one can be answered directly.
+
+A large question such as:
+
+> Should we buy this business?
+
+cannot usually be answered honestly in one step. It may need to become:
+
+- Is the business profitable?
+- Are the accounts reliable?
+- Is the customer base stable?
+- Can the purchase be financed safely?
+
+If one of those questions is still too broad, it is broken down again.
+
+The engine continues until each remaining uncertainty is small enough for one focused investigation, one piece of evidence, one calculation, one observation or one direct answer to resolve it.
+
+> **Decomposition is not about breaking problems apart for its own sake. It is about shrinking uncertainty until it becomes answerable.**
+
+This reflects the wider Confidence Engine principle of breaking complicated situations into small, granular, understandable parts.
+
+---
+
+## 2. Purpose
+
+The purpose of decomposition is to prevent the engine from asking questions that are too broad, compound, vague or difficult to answer reliably.
+
+Decomposition should help the engine:
+
+1. turn large uncertainties into answerable units;
+2. preserve the relationship between each small question and the larger situation;
+3. avoid asking several things at once;
+4. reveal what evidence is actually needed;
+5. stop once further subdivision would add no useful clarity;
+6. support justified progression from uncertainty towards confidence.
+
+Decomposition is therefore a reasoning operation, not a formatting step.
+
+---
+
+## 3. Foundational principles
+
+### 3.1 One node, one uncertainty
+
+Every unknown node should represent exactly one independently investigable uncertainty.
+
+A node is valid when a person can understand what single thing is uncertain and what kind of evidence could settle it.
+
+### 3.2 One useful thing at a time
+
+The engine should ask one question whose answer can make one meaningful change to the reasoning state.
+
+### 3.3 Context belongs to the highest level where it is true
+
+Information should exist at the highest level where it first becomes true, and should not be repeated lower in the graph unless it is independently true there as well.
+
+Examples of parent-level context include:
+
+- commercial justification;
+- the overall decision being considered;
+- the user's wider objective;
+- domain framing;
+- branch-wide constraints;
+- the fact that several conditions must be considered together.
+
+Children operate within that context. They should not restate it as part of their own uncertainty.
+
+### 3.4 Every transformation must improve the reasoning
+
+A transformation is justified only when it does at least one of the following:
+
+- reduces uncertainty;
+- increases justified confidence;
+- makes an uncertainty more answerable;
+- exposes a contradiction that must be resolved;
+- separates distinct questions that were previously entangled.
+
+If decomposition creates more words but no clearer investigation path, it has failed.
+
+### 3.5 No question is preferable to an unjustified question
+
+The engine must not force progression by selecting a poor child, ignoring incompatibility or inventing an answerable-looking question.
+
+A temporary stop is better than a misleading question.
+
+### 3.6 The graph stores reasoning; the conversation exposes reasoning
+
+The graph may contain parent context, child uncertainties, dependencies and resolution state. The user-facing question should expose only the smallest justified next step.
+
+---
+
+## 4. Composite and atomic uncertainties
+
+### 4.1 Composite uncertainty
+
+A node is composite when no single investigation can resolve its uncertainty.
+
+It normally contains two or more distinct dimensions that can change independently.
+
+A node is likely composite when:
+
+- one answer can resolve part of it while leaving another part unresolved;
+- it contains separable conditions;
+- it requires several different kinds of evidence;
+- an investigator would naturally ask more than one focused question;
+- it combines a decision, criterion, explanation or relationship into one statement.
+
+A node is not composite merely because it is important, difficult or domain-specific.
+
+### 4.2 Atomic uncertainty
+
+A node is atomic when one focused investigation can settle the uncertainty it owns.
+
+An atomic node:
+
+- concerns one variable, condition or relationship;
+- has one clear semantic identity;
+- can be investigated without answering sibling questions first;
+- cannot be divided further without producing paraphrases, duplicates or trivial fragments;
+- has a recognisable resolution condition.
+
+A useful test is:
+
+> Could one focused piece of evidence or one direct answer settle this specific doubt?
+
+If yes, it is probably atomic.
+
+### 4.3 Atomic does not mean simple in subject matter
+
+An atomic question may still require specialist work.
+
+For example:
+
+> Does the unit economics produce a positive contribution margin at the projected volume?
+
+is domain-specific and may require financial modelling, but it still investigates one thing.
+
+---
+
+## 5. Information ownership
+
+### 5.1 What the parent owns
+
+The parent owns the context that makes the group of child questions meaningful.
+
+This may include:
+
+- the overall objective;
+- the decision under consideration;
+- the evaluative frame, such as commercial justification or technical feasibility;
+- branch-wide constraints;
+- the logical relationship between children;
+- the rule for aggregating child outcomes;
+- the investigation scope;
+- sibling coverage and completion state.
+
+### 5.2 What each child owns
+
+Each child owns:
+
+- one independently answerable uncertainty;
+- its own label;
+- its own scope;
+- its own answerability condition;
+- its own evidence;
+- its own resolution status;
+- its own semantic identity.
+
+### 5.3 What children must not inherit
+
+Children must not inherit parent material merely because it appeared in the parent's wording.
+
+Children should not inherit:
+
+- evaluative framing such as *commercially justified*, *viable* or *feasible*;
+- the parent's conjunction or compound structure;
+- the whole objective;
+- sibling information;
+- branch-wide constraints written as if they were child conditions;
+- wording that causes the child to become a disguised copy of the parent.
+
+### 5.4 Ownership rule
+
+> **A child should describe only the uncertainty it owns.**
+
+The parent explains why the child matters. The child states what must be investigated.
+
+---
+
+## 6. Decomposition process
+
+### Step 1 — Identify why the current uncertainty is not directly answerable
+
+Determine which independent dimensions prevent one focused investigation from resolving the node.
+
+### Step 2 — Identify the smallest distinct uncertainties
+
+Separate those dimensions into candidate children.
+
+Each candidate should correspond to one investigation path.
+
+### Step 3 — Remove inherited parent framing
+
+Rewrite each candidate so it describes only its own uncertainty.
+
+### Step 4 — Test independence
+
+Check whether each child can be investigated without needing a sibling answer.
+
+If a child depends on another child, they may not be true siblings. The dependency may require a different graph relationship.
+
+### Step 5 — Test narrowing
+
+Each child must be more specific than the parent.
+
+A child that could replace the parent without loss of meaning is not a decomposition.
+
+### Step 6 — Test uniqueness
+
+No two children should ask the same underlying question in different words.
+
+### Step 7 — Test coverage
+
+Together, the children must cover the uncertainty represented by the parent.
+
+### Step 8 — Test answerability
+
+Each child must be small enough to support one clear user-facing question or one clear evidence-gathering action.
+
+### Step 9 — Apply or reject
+
+Apply the decomposition only if it improves the reasoning state.
+
+Otherwise retain the parent as unresolved and record why decomposition failed.
+
+---
+
+## 7. Stopping rules
+
+Decomposition should stop when the earliest of the following conditions is met:
+
+1. **One investigation can settle the node.**
+2. **Further children would merely paraphrase the node.**
+3. **Candidate children overlap or duplicate one another.**
+4. **Candidate children are not narrower than the parent.**
+5. **Further subdivision would produce trivial fragments without independent investigative value.**
+6. **The required next step is evidence gathering rather than further decomposition.**
+7. **No valid lossless decomposition can be produced.**
+
+Failure to decompose is not permission to invent children.
+
+---
+
+## 8. Decomposition invariants
+
+Every accepted decomposition must satisfy all of these invariants.
+
+### 8.1 Narrowing
+
+Every child is strictly narrower than the parent.
+
+### 8.2 Atomic direction
+
+Each child moves the graph closer to an independently answerable uncertainty.
+
+A generated child must not immediately trigger the same decomposition merely because it inherited the parent's wording.
+
+### 8.3 Independence
+
+Each sibling can be investigated without requiring another sibling's answer.
+
+### 8.4 Uniqueness
+
+Each child represents a distinct semantic uncertainty.
+
+### 8.5 Coverage
+
+The children collectively cover the parent's uncertainty.
+
+### 8.6 Resolution sufficiency
+
+Resolving all required children provides enough information to derive the parent's status.
+
+If the parent remains unresolved after all children are resolved, the decomposition was incomplete or logically unsound.
+
+### 8.7 Context ownership
+
+Children do not repeat parent-level context unless that context is independently part of the child's uncertainty.
+
+### 8.8 Convergence
+
+Repeated decomposition must move towards atomic questions rather than reproducing the same semantic structure at greater depth.
+
+### 8.9 Traceability
+
+Every child remains linked to the parent so the engine can explain why the question exists.
+
+### 8.10 No invented certainty
+
+Decomposition changes structure, not truth. It must not make the parent or children appear more certain merely because they have been separated.
+
+---
+
+## 9. Quality tests for each child
+
+A candidate child should be rejected when any of the following is true:
+
+- it asks more than one primary thing;
+- it contains a compound clause that creates separable questions;
+- it is not narrower than its parent;
+- it duplicates a sibling;
+- it duplicates an already resolved uncertainty;
+- it depends on a sibling answer;
+- it restates parent framing rather than naming a distinct uncertainty;
+- it has no clear evidence or answer path;
+- its resolution would not affect the parent;
+- its meaning cannot be distinguished from another graph node;
+- it introduces unsupported domain assumptions;
+- it exists only because a template demanded a fixed number of children.
+
+---
+
+## 10. Common failure modes
+
+### 10.1 Framing contamination
+
+A child inherits evaluative or contextual language from the parent and is therefore misclassified as composite again.
+
+Example:
+
+Parent:
+
+> Is this method commercially justified?
+
+Contaminated child:
+
+> Is there commercially justified demand for this method?
+
+The child now contains its own uncertainty plus the parent's commercial evaluation frame.
+
+### 10.2 Recursive restatement
+
+Each decomposition level repeats the same uncertainty using slightly different words.
+
+This creates depth without progress.
+
+### 10.3 Compound children
+
+A child contains two or more independently answerable questions.
+
+Example:
+
+> Can the product be delivered reliably and at an acceptable cost?
+
+### 10.4 Duplicate siblings
+
+Two children describe the same uncertainty with different wording.
+
+### 10.5 Incomplete coverage
+
+All children can be resolved, but part of the parent's uncertainty remains unaddressed.
+
+### 10.6 Over-decomposition
+
+An already answerable question is broken into fragments that are too trivial or unnatural to investigate separately.
+
+### 10.7 Under-decomposition
+
+A broad or compound uncertainty is treated as atomic, producing a difficult multi-part user question.
+
+### 10.8 Template-driven decomposition
+
+Children are generated because a template expects them, rather than because the parent contains those distinct uncertainties.
+
+### 10.9 Context loss
+
+Children become independently answerable but lose their traceable relationship to why they matter.
+
+### 10.10 Dead-end after filtering
+
+Valid unresolved children exist, but all are excluded by structural, pattern or quality checks. The engine should diagnose the exact exclusion path rather than silently treating the investigation as complete.
+
+---
+
+## 11. Worked examples
+
+### 11.1 Commercial validation
+
+Parent:
+
+> Is this use case commercially justified?
+
+Poor children:
+
+- Is the use case commercially feasible with a viable pricing model?
+- Is there sufficient commercial demand?
+
+Problems:
+
+- inherited framing;
+- compound wording;
+- children remain at parent abstraction level;
+- high risk of recursive decomposition.
+
+Better children:
+
+- Who experiences the problem?
+- What cost or harm does the problem create?
+- Is the problem frequent enough to matter?
+- Will an identifiable customer pay to reduce it?
+- Can the solution be delivered at a sustainable cost?
+
+Each child owns one uncertainty. The parent retains the commercial-justification frame and combines the child outcomes.
+
+### 11.2 Vehicle fault diagnosis
+
+Parent:
+
+> Why will the car not start?
+
+Candidate children:
+
+- Does the starter motor turn?
+- Is battery voltage sufficient under load?
+- Is fuel reaching the engine?
+- Is the immobiliser preventing ignition?
+
+Each question supports a distinct investigation path.
+
+### 11.3 Agile readiness
+
+Parent:
+
+> Is this story ready to enter the sprint?
+
+Candidate children:
+
+- Is the expected outcome clear?
+- Are the acceptance conditions testable?
+- Are external dependencies resolved?
+- Is the required data available?
+- Can the team complete the work within the sprint boundary?
+
+The phrase *ready to enter the sprint* remains parent context. Each child investigates one condition contributing to readiness.
+
+### 11.4 Financial decision
+
+Parent:
+
+> Can the household safely retire at 67?
+
+Candidate children:
+
+- What annual essential spending must be covered?
+- What secure income will be available?
+- What investment assets will exist at retirement?
+- What debts will remain?
+- How resilient is the plan to lower returns or one spouse surviving longer?
+
+### 11.5 Software architecture
+
+Parent:
+
+> Should this service be separated from the monolith?
+
+Candidate children:
+
+- Does it need an independent deployment cycle?
+- Does it have a stable data boundary?
+- Would separation materially reduce operational risk?
+- Does the team have the capability to operate it independently?
+
+The parent owns the architectural decision. Children own the evidence needed to support it.
+
+---
+
+## 12. Relationship with reasoning patterns
+
+Decomposition and reasoning-pattern selection are related but distinct.
+
+- Decomposition decides whether an uncertainty is small enough to investigate directly.
+- Reasoning-pattern selection decides what kind of investigation is appropriate.
+
+The engine should not use a reasoning pattern to disguise a composite uncertainty as atomic.
+
+Equally, decomposition should not erase the parent's reasoning context. The child remains linked to the parent even though it does not repeat the parent's framing in its own wording.
+
+When a branch evolves into a different kind of reasoning, the engine may re-evaluate the active pattern using the remaining graph state. It should not bypass compatibility merely to force a next question.
+
+---
+
+## 13. Relationship with answerability
+
+Atomicity and answerability are not identical.
+
+A node may be atomic but temporarily unanswerable.
+
+Example:
+
+> What was the measured defect rate last quarter?
+
+This asks one thing, but the data may not yet exist.
+
+The correct response may be to identify an evidence-gathering action rather than decompose the question further.
+
+The engine should distinguish:
+
+- too broad to answer;
+- clear but evidence unavailable;
+- clear and directly answerable;
+- clear but requiring specialist capability.
+
+---
+
+## 14. Validation requirements for implementation
+
+An implementation should be able to demonstrate the following.
+
+### 14.1 Atomicity validation
+
+- Atomic children are not repeatedly decomposed because of inherited parent wording.
+- Genuinely compound children are still detected.
+
+### 14.2 Ownership validation
+
+- Parent framing does not appear in child labels unless independently necessary.
+- Child context remains available through graph links rather than duplicated text.
+
+### 14.3 Narrowing validation
+
+- Every accepted child has a more specific semantic scope than its parent.
+
+### 14.4 Duplicate validation
+
+- Semantic duplicates are rejected even when wording differs.
+
+### 14.5 Coverage validation
+
+- The implementation records how children collectively resolve the parent.
+
+### 14.6 Convergence validation
+
+- Repeated decomposition reaches atomic nodes or produces an explicit decomposition failure.
+- It does not oscillate or recreate the same semantic uncertainty at deeper levels.
+
+### 14.7 Question validation
+
+- Every selected child can produce one understandable user-facing question.
+- A compound child cannot escape into the user interface.
+
+### 14.8 Dead-end diagnostics
+
+When unresolved nodes remain but no question is produced, diagnostics must identify:
+
+- unresolved candidates;
+- structural eligibility;
+- pattern compatibility;
+- atomicity status;
+- decomposition result;
+- selected node, if any;
+- formulation result;
+- exact no-question reason.
+
+---
+
+## 15. Acceptance criteria for future Codex implementation
+
+A future implementation change should not be accepted unless it proves all of the following:
+
+1. Commercial parent framing no longer contaminates generated children.
+2. Generated atomic commercial children remain atomic.
+3. Genuinely composite commercial children still decompose.
+4. Child labels describe only their own uncertainty.
+5. Parent context remains preserved in the graph.
+6. Every accepted child is narrower than the parent.
+7. Duplicate and compound children remain rejected.
+8. Decomposition converges without increasing the maximum depth merely to hide recursion.
+9. Reasoning-pattern safeguards remain intact.
+10. The engine does not fall back to arbitrary unresolved candidates.
+11. Existing decision, explanation, contradiction, definition, diagnosis, comparison and prioritisation behaviours remain valid.
+12. Diagnostics clearly explain any remaining no-question state.
+
+---
+
+## 16. Guidance for coding agents
+
+When implementing this specification:
+
+1. Inspect the current repository and existing tests before proposing changes.
+2. Identify the exact observed violation of an invariant.
+3. Prefer the smallest structural correction.
+4. Do not broaden pattern compatibility to hide decomposition defects.
+5. Do not increase recursion depth as the primary fix.
+6. Do not place user-facing prose into technical graph-description functions.
+7. Keep parent context and child uncertainty as separate graph semantics.
+8. Add focused regression tests before broad refactoring.
+9. Preserve existing working reasoning families.
+10. Report which specification invariant each code change enforces.
+
+Suggested implementation prompt framing:
+
+> Read the Decomposition and Atomic Reasoning Specification. Identify where the current implementation violates its invariants. Implement the smallest correction that prevents parent framing from contaminating generated children while preserving reasoning-pattern compatibility, graph traceability and existing decomposition safeguards.
+
+---
+
+## 17. Open questions
+
+The following remain deliberately unresolved and should be answered through further experiments:
+
+- How should coverage be represented when children are sufficient but not individually necessary?
+- How should OR, AND and threshold aggregation differ?
+- When should child resolution automatically resolve the parent?
+- How should uncertain or conflicting child evidence affect parent status?
+- When should a failed decomposition trigger reframing rather than stopping?
+- How should specialist evidence-gathering actions be represented for atomic but currently unanswerable nodes?
+- How should the engine distinguish a missing child from a genuinely sufficient decomposition?
+- How should context ownership be applied to assumptions, conclusions and relationships as well as unknowns?
+
+These questions should not be answered by adding rules without observed evidence.
+
+---
+
+## 18. Summary
+
+The Confidence Engine does not decompose because smaller questions are aesthetically preferable.
+
+It decomposes because large uncertainties cannot be investigated honestly in one step.
+
+The engine should keep breaking uncertainty down until each remaining question owns one distinct doubt and can be settled by one focused investigation.
+
+The parent retains the wider context. The child owns only the uncertainty it investigates.
+
+A valid decomposition is narrower, independent, unique, complete, traceable and convergent.
+
+> **Break the complicated into small, granular, simple things — then investigate one useful thing at a time.**
+
@@ -0,0 +1,123 @@
+# Context Routing Validation — Experiment 36
+
+## Documents Initially Loaded
+
+1. `docs/current-handoff.md` (86 lines) — first return-to-work entry point
+2. `docs/current-project-state.md` (132 lines) — active state and capabilities
+3. `docs/task-context-packs.md` (110 lines) — routing for four work types
+
+Total: 328 lines loaded before any expansion.
+
+## Additional Documents Required
+
+### docs/ui-mock-reference.md (62 lines)
+**Why:** Task 2 required identifying mock scenarios for "long investigation" and "contradictory evidence". The task-context-packs Routing Test B claimed these were identifiable without loading ui-mock-reference, but the specific scenario names were not stated in any initial document. Loading confirmed both exist: "Long investigation (10–15 turns)" and "Contradiction".
+**Routing should have included it:** YES — this is a routing defect. The pack's Routing Test B presents an unverifiable claim as fact.
+
+### docs/project-knowledge-inventory.md (214 lines)
+**Why:** Task 4 asked where a new developer should begin for engine experiments. Current handoff → project-state → task-context-packs gave the path, but inventory confirmed the Engine Experiment pack's four "always read" documents are all verifiably present in the repository. Also provided confirmation of what the knowledge-management phase created.
+**Routing should have included it:** DEBATED — the inventory validates pack completeness but was not strictly necessary to answer Task 4 from routing alone.
+
+### docs/current-implementation-verification.md (110 lines)
+**Why:** Cross-checked Behaviour Selection's isolation against current-project-state §3's classification. Found section 3b confirming `selectBehaviour` has no callers outside its module.
+**Routing should have included it:** DEBATED — current-project-state already stated the same fact; this was a corroboration, not a gap fill.
+
+## Tasks Completed
+
+### Task 1 — Does Behaviour Selection affect engine behaviour?
+- **Answer:** No. It is isolated — no import or call exists in any file under lib/ or app/.
+- **Initial docs sufficient:** Yes (current-project-state §3 + handoff §2).
+- **Expansion needed:** No.
+
+### Task 2 — Correct mock scenarios for long investigation and contradictory evidence?
+- **Answer:** "Long investigation (10–15 turns)" and "Contradiction" from ui-mock-reference.md.
+- **Initial docs sufficient:** No. Routing Test B claimed they were, but the claim was unverifiable until ui-mock-reference was loaded.
+- **Expansion needed:** Yes — `docs/ui-mock-reference.md`.
+
+### Task 3 — Why passive classifiers are not part of active reasoning?
+- **Answer:** Passive classifiers (Experiments 18–25B) record diagnostic signals for future use but have no integration into the turn cycle. Investigation-state assessment is the only one called at all, and its result goes into a diagnostics field — never checked by conditional branches. Others have zero callers. None control user-facing decisions or path selection.
+- **Initial docs sufficient:** Yes (current-project-state §2–§5 + handoff §2).
+- **Expansion needed:** No.
+
+### Task 4 — Where should a new developer begin for the next engine experiment?
+- **Answer:** Read `docs/current-handoff.md` → `docs/current-project-state.md` → Engine Experiment pack from `docs/task-context-packs.md`, which directs them to four always-read documents (`current-project-state`, `current-working-principles`, `architecture-guardrails`, `current-implementation-verification`) plus the immediately previous experiment entry in the design log. The pack's "Stop and ask" rules prevent blind expansion.
+- **Initial docs sufficient:** Yes — answerable from initial context; inventory loaded only for confirmation of pack document existence.
+- **Expansion needed:** No.
+
+## Routing Failures Found
+
+**One genuine failure: Routing Test B in task-context-packs.md.**
+The test states that mock scenarios for "long investigation" and "contradiction" are identifiable without loading ui-mock-reference. This was presented as a self-evident fact but could not be verified from the stated documents alone — the specific scenario names exist only in ui-mock-reference.md. The routing is incomplete; it should have included the mock reference file.
+
+**One questionable exclusion: project-knowledge-inventory for Task 4.**
+The task-context-packs Engine Experiment pack lists four "always read" documents but does not themselves confirm all four exist. A cautious developer would load the inventory to verify, adding ~215 lines. This is acceptable cost but worth noting as a gap in the pack's self-validation.
+
+## Documentation Improvements Discovered
+
+1. **Routing Test B must include ui-mock-reference.md.** Remove the "No extra file required" claim and add the mock reference to the Engine Experiment pack's routing chain when tasks involve scenario selection.
+2. **Packs should confirm their listed documents exist.** Adding a verification check (or removing unverified entries) would prevent the need for inventory cross-referencing.
+
+## Overall Assessment: Mostly ready
+
+Evidence: Two of four tasks were completed from initial context only. One routing defect was found (Task 2's claim was unverifiable without extra loading). The system works but Routing Test B demonstrates that "sufficient" claims should be evidence-based, not assumed. After fixing Test B, the reduced context system is ready for normal work.
+
+---
+
+## Experiment 37 — Cross-Boundary Routing Validation
+
+### Routing Correction Applied
+
+Updated `task-context-packs.md` Routing Test B: `docs/ui-mock-reference.md` is confirmed as part of the UI and Mock pack; scenario names and usage guidance originate from that document, not from the general entry documents alone. This is a normal routing inclusion, not an exceptional addition.
+
+Task 4 conclusion clarified: **answerable from initial context; inventory loaded only for confirmation**. The Engine Experiment pack's four "always read" documents form a valid path without requiring the knowledge inventory.
+
+Totals corrected to "two of four tasks completed from initial context only." Line counts updated to match `wc -l` output.
+
+### Cross-Boundary Test — Condition Status Display in Workspace
+
+**Task:** Determine what is active vs passive for displaying condition-status information in the workspace without modifying the reasoning loop. Identify mock scenario, relevant files to inspect, and whether both engine and UI packs are needed.
+
+**Primary pack selected:** Knowledge-Management pack (handoff + project-state + context-packs).
+**Boundary identified:** Task requires understanding passive diagnostic capabilities (engine side) AND workspace display behavior (UI side). Boundary = Engine ↔ UI.
+
+**Second pack selected:** UI and Mock pack for `docs/ui-mock-reference.md` (scenario names for mock investigation work).
+
+**Documents loaded:**
+
+| Document | Lines | Purpose |
+|---|---|---|
+| `docs/current-handoff.md` | 85 | Return-to-work entry, confirm experiment status |
+| `docs/current-project-state.md` | 131 | Passive classifiers (§2), active reasoning loop (§3) |
+| `docs/task-context-packs.md` | 110 | Identify cross-boundary need; Pack 2 for UI scenario routing |
+| `docs/ui-mock-reference.md` | 62 | Scenario names and usage guidance for mock investigation |
+
+**Total initial context:** 328 lines. **Additional loaded:** 62 lines. **Grand total:** 390 lines.
+
+**Cross-boundary task result:**
+
+- Condition-status capability is passive: decision-condition status evaluation records signals for future use but has no integration into the active turn cycle; it never controls user-facing decisions or path selection.
+- Active reasoning loop must remain unchanged: deterministic pipeline from scenario reconstruction through question formulation to turn orchestration — none of these pathways are affected by passive condition-status data.
+- Suitable mock scenario: "Long investigation (10–15 turns)" from ui-mock-reference.md, where the workspace can display accumulated diagnostic signals over time without interrupting the active reasoning cycle.
+- Relevant implementation areas to inspect later: `lib/graph/conditions/decision-condition-status.js` or equivalent (the decision-condition status evaluation module); `lib/graph/scope-detection.js` or similar (evidence scope detection); UI workspace component files under `app/` for passive display integration.
+- Both Engine and UI packs genuinely necessary: engine pack identifies which capabilities are active vs passive; UI pack identifies how the workspace presents state to users. Neither alone suffices for this cross-boundary task.
+- No archive or full history was required.
+
+**Context remained manageable:** Yes. 390 lines total. Each document loaded for a specific named purpose. No blind expansion.
+
+### Knowledge-Manship Completion Criteria Review
+
+| Criterion | Status |
+|---|---|
+| 1. Fresh session can resume from handoff + one pack | met |
+| 2. Current state verified against implementation | met |
+| 3. Historical material outside default loading | met |
+| 4. Current principles separated from aspirational architecture | met |
+| 5. Task-specific routing works for engine and UI tasks | met |
+| 6. Cross-boundary task tested | **met** (this experiment) |
+| 7. Maintaining handoff does not require reading full history | met |
+
+All seven criteria are now met.
+
+### Knowledge-Manship Assessment
+
+> Knowledge-management structure is ready for Rob's review before engine experiments resume.
@@ -0,0 +1,144 @@
+# Confidence Engine — Current Handoff
+
+## Repository position
+- branch: `feature/decision-closure-ownership-v0.47`
+- checkpoint commit: `772ae49`
+
+## Current green reasoning state
+- **substantive-tie active ownership**: In complete unresolved ties among top-scoring candidates, the currently active node is preserved as the selection winner rather than falling through to stable label/display-order ordering. This only applies when the active node is eligible and remains substantively tied at the structural level.
+- **question-rejection active ownership**: When a selected candidate's graph-backed question formulation is rejected as too complex (decomposition-required), the selected target node retains its ownership — it is not reseated to another candidate via `reseatSelectionAfterQuestionRejection`. Instead, the selection remains on the original node with `selectedQuestion = null` and an explicit rejection reason.
+- **QUESTION_CONTINUATION**: Existing question continuation logic remains intact and functional after the question-rejection fix.
+- **60B.84**: State B guard correctly does not fire for specific factor nodes merely because they are inside a decision context.
+- **State B**: Sufficiency question path reaches expected terminal state without unintended firings.
+- **captured product-launch replay**: The live product-launch start graph replays deterministically: ntpt9ki remains the active investigation target with no question selected after formulation rejection.
+
+## Latest resolved reasoning boundaries
+
+### 1. Complete substantive selection tie
+- previous behaviour: When all leading structural candidates were tied, the system always fell through to stable label/display-order as the final deterministic tie-breaker, regardless of which node was currently active in the investigation.
+- corrected invariant: If the active node is among the tied structural candidates and remains eligible (unresolved, not contradicted), it is preserved as the winner. The stable label/display-order fallback is only used when there is no active candidate or when the active candidate does not remain among the top structural ties.
+- regression location: `lib/graph/utils.js` — `classifyCandidateOrdering()` now accepts an `activeNodeId` parameter and checks for active-tied candidates within the leading structural set before using display-order fallback. Callers in `selectActiveUnknownCandidate()` and `explainUnknownSelection()` pass `graph.activeUnknownNodeId`.
+- regression test location: `tests/graph/utils.test.js` — tests: "preserves the active candidate when it remains eligible and substantively tied", "transfers ownership when the active candidate substantively loses on score", "transfers ownership when the active candidate is resolved or ineligible"
+
+### 2. Question-formulation rejection
+- previous behaviour: When a selected candidate's question formulation was rejected (decomposition required), `determineGraphBackedQuestion` called `reseatSelectionAfterQuestionRejection` with `excludedNodeIds` that excluded the current target, causing investigation ownership to transfer to another candidate — even though the original target remained the strongest unresolved unknown.
+- corrected invariant: The selected node keeps its status and selection identity. `selectedQuestion` is set to `null` and `questionSuppressedReason` records the rejection explanation. No reseating occurs.
+- regression/captured fixture location: `tests/graph/orchestrator.test.js` — "retains ownership when the strongest target's formulated question is rejected"; captured replay via `tests/fixtures/live-product-launch-start-response.json`
+
+## Current deterministic product-launch evidence
+- `deterministicSelection.nodeId = ntpt9ki` (active investigation target preserved)
+- `selectedQuestion = null` after rejected formulation
+- explicit `noQuestionReason`: "The selected investigation target remains active, but its current graph-backed question formulation was rejected as too complex."
+- `nxmeiab` is not substituted in place of ntpt9ki
+
+## Current product meaning
+- `activeUnknownNodeId` represents ongoing investigation ownership — it tracks which unknown candidate the system has committed to investigating.
+- Wording/formulation failure (question complexity / decomposition-required) does not itself invalidate the target. The target remains selected even when its formulated question cannot be answered in one step.
+- Stable label ordering remains only a final fallback after substantive scoring, structural comparison, semantic signature checks, and tie/ownership handling are all exhausted.
+
+## Not yet proved
+- live behavioural validation after these fixes (requires an actual product-launch run through the dev server)
+- whether same-target reformulation is better than no-question (system currently uses no-question approach)
+- broader/full-suite state beyond the six verified guards
+- correctness of the question-complexity heuristic itself (that is a separate design concern)
+
+## Canonical live apparatus for next validation
+- `scripts/reproduce-multi-turn-investigation.mjs`
+- existing healthy dev server
+- `.env.local` authoritative for:
+  - `OLLAMA_BASE_URL`
+  - `OLLAMA_MODEL`
+- no model discovery
+- no supplementary harnesses
+- no direct Ollama calls
+
+## Next recommended step
+- one observation-only live product-launch validation using the fixed scenario from the recorded journey
+- no production changes during the experiment
+- verify that the live LLM responds consistently to the null-question state and continues investigation on ntpt9ki
+
+## Apparatus correction: 60B.101 — null-question start capture
+
+The canonical `startOnly` harness was corrected to accept successful Start responses with `selectedQuestion = null`. Previously, any successful Start returning no graph-backed question (legitimate outcome meaning "target remains active but no askable question available") caused the harness to block and fail.
+
+**Change:** The harness now checks `success === true` + valid `situationGraph` as the sole gate for startOnly success. `selectedQuestion` is preserved exactly (including null) in the continuation state file without coercion.
+
+**Impact on 60B.100:** The evidence from 60B.100 was captured via direct curl because the harness blocked on null-question Start. That evidence is now marked as apparatus-contaminated and provisional observation only.
+
+---
+
+## Canonical harness gated apparatus (60B.99)
+
+The canonical harness (`scripts/reproduce-multi-turn-investigation.mjs`) now supports a two-phase gated investigation pattern:
+
+**startOnly** — `FIXTURE_MODE=startOnly`
+- Makes exactly one `/api/cases/start` request
+- Writes the captured Start state (graph + selectedQuestion) to `.evidence-temp/continuation-start-only.json` (or path set by `CONTINUATION_FILE`)
+- Issues zero Update requests
+- Exits successfully
+
+**continueOneUpdate** — `FIXTURE_MODE=continueOneUpdate CONTINUATION_ANSWER=<answer>`
+- Loads the persisted Start continuation state
+- Requires explicit answer (blocks with exit code 1 if missing)
+- Makes exactly one `/api/cases/update` using preserved Start state + explicit answer
+- Issues zero Start requests
+- Exits
+
+**Normal mode** (`FIXTURE_MODE` unset) — unchanged. Start → configured Update loop still works identically to pre-60B.99.
+
+This apparatus corrects the apparatus defect proven in 60B.98: the canonical harness can now stop after Start, allow external semantic inspection of the returned question, and later continue from that exact captured state with an explicitly chosen answer.
+
+---
+
+## Experiment 60B.95 result (2026-08-17)
+
+**Classification: E — LIVE PATH DIVERGED**
+
+The live model selected nk6eyn2 ("exact monetary value of potential enterprise contract relative to £300k launch cost") as the investigation target, not npzfx36 ("likelihood, negotiation stage, and targeted signing date for the large enterprise customer"). Both are unresolved unknowns in the same scenario. An acceptable question was produced ("What outcome would demonstrate enough value to justify launching a software product now?"), so the question-rejection boundary was not reached.
+
+**What this establishes:** The live engine can produce an acceptable graph-backed question on a fresh product-launch start without requiring decomposition.
+
+**What this does NOT prove:** Whether investigation ownership is preserved when a selected target's formulation is rejected (the core invariant from checkpoint 60B.93). The question-rejection boundary was not reached because the live model chose a different investigation target with an acceptable question path.
+
+
+## Experiment 60B.97 result (2026-08-18)
+
+**Classification: E — START PATH DIVERGED**
+
+The live model again selected a non-financial-comparison target on the product-launch scenario. The Start selected enterprise-customer signing probability ("What evidence would clarify probability or likelihood that the enterprise customer will sign within the current launch window?") rather than the expected cash-flow / NPV comparison.
+
+**Valid evidence retained:** Start = S2 — DIFFERENT START (the live model diverged from the expected financial-comparison path).
+
+**Update 1 evidence: DISCARDED.** The canonical harness auto-continued with its preconfigured `answers[0]`, so the Update occurred outside the experiment's semantic gate. This was an apparatus defect (60B.98) — the harness did not provide a post-Start stop gate at that time. The HTTP 500 is NOT established as a reasoning defect from 60B.97.
+
+**Apparatus correction:** See section "Canonical harness gated apparatus (60B.99)" above for the fix.
+
+
+## Experiment 60B.100 result (2026-08-18)
+
+**Classification: B — DETERMINISTIC SELECTOR OVERRIDES MODEL QUESTION**
+
+On a fresh product-launch Start, the LLM reconstruction question targeted one uncertainty ("What is the estimated probability that the large enterprise customer will sign?") while the deterministic graph-backed selector chose another ("What evidence would clarify the exact percentage of total projected revenue attributable to the enterprise customer?"). These are materially different: one asks about deal timing/commitment probability, the other asks about financial proportion/magnitude.
+
+The override was produced by fixed `actor_match` keyword scoring: node n65sgyd's label contained "enterprise customer" which matched the actor dictionary (+10 delta), giving it a decisive score of 10 vs 4 for both competitors. No tie/fallback was involved — the winner was determined entirely by keyword rule weighting.
+
+**What this establishes:** On fresh Start calls, deterministic keyword signals can override model-inferred investigation priority when node labels differ in dictionary-match patterns. The final investigation target is not the model's contextual judgment but the highest-scoring candidate under fixed scoring rules.
+
+**What this does NOT prove:** Whether the deterministic selection is better or worse than the model's suggestion; consistency across scenario types; or downstream investigation quality impact.
+
+
+---
+
+## RETURN-TO-ORIGIN CHECKPOINT
+
+**selector-led compulsory next-question optimisation is PAUSED**
+
+**semantic-selector replacement is also PAUSED**
+
+Recent work is preserved as valuable experimental learning. The graph/reconstruction/decomposition/invariant work remains potentially reusable. No replacement architecture has been selected.
+
+The next phase starts from the workspace/methodology question, not from a preselected technical solution.
+
+See:
+- `docs/methodology-checkpoint-return-to-origin.md` — repository-facing checkpoint summary
+- `docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md` — full methodology context (source)
@@ -0,0 +1,110 @@
+# Current Implementation Verification
+
+> Experiment 28 — Focused code inspection of `feature/user-workspace-ux-v0.7`.
+
+## 1. Verification Method
+
+Inspected the following runtime entry points and imports:
+
+**API routes (entry points):**
+- `app/api/cases/start/route.js` → calls `startCase` from orchestrator;
+- `app/api/cases/update/route.js` → calls `updateCase` from orchestrator;
+- `app/api/analyse/route.js` → calls `analyseScenario` from analysis.js (reconstruction only).
+
+**Orchestrator imports** (`lib/graph/orchestrator.js`, lines 6–32):
+- `analyseScenario` (reconstruction, not engine);
+- `buildInitialGraph`, `describeGraph` (graph builder);
+- `applyValidatedProposal`, `determineGraphBackedQuestion` (apply-proposal);
+- `assessInvestigationState` (imported, but result only placed in diagnostics field);
+- `buildReasoningState`, `formulateQuestion`, `formulateTieResolutionQuestion` (question-formulator);
+- `parseGraphUpdateProposal`;
+- `explainUnknownSelection`, `selectActiveUnknownCandidate`, `validateGraphReferences` (utils).
+
+**Cross-module traces:**
+- `grep -R "selectBehaviour"` — no callers outside its own module;
+- `grep -R "assessDecisionConditionStatus\|scoreQuestionDecisionRelevance\|assessQuestionImportance"` — no callers outside decision-condition-status.js, question-decision-relevance.js, and question-importance.js respectively;
+- `import` statements in all JS files under lib/ and app/ were inspected for references to passive classifier modules.
+
+Evidence is based on actual imports, call sites, and return-object placement found in source.
+
+## 2. Active Capabilities
+
+### 2a. Scenario Reconstruction (analyseScenario)
+- **Purpose:** LLM-based scenario analysis producing situation graph; first step of a new case.
+- **Implementation:** `lib/analysis.js` → calls provider, parses response, validates against Zod schemas.
+- **Evidence:** Called from `app/api/analyse/route.js` and imported by orchestrator's startCase flow via `buildInitialGraph`.
+
+### 2b. Reasoning Graph Updates (startCase / updateCase)
+- **Purpose:** Builds initial situation graph from analysis; applies user answers to graph nodes, updates status/confidence/completeness, runs propagation.
+- **Implementation:** `lib/graph/orchestrator.js` — `startCase()` (line 376 calls `buildInitialGraph`, line 402 calls `determineGraphBackedQuestion`); `updateCaseWithDependencies()` (line 622 calls `applyValidatedProposal`).
+- **Evidence:** Orchestrator functions are called from `app/api/cases/start/route.js` and `app/api/cases/update/route.js`. `applyValidatedProposal` is the runtime caller for graph mutation; propagation, confidence cap, and completeness update happen within apply-proposal.js.
+
+### 2c. Unknown Selection (atomicity + answerability)
+- **Purpose:** Selects the next unresolved node to investigate based on atomicity and answerability criteria.
+- **Implementation:** `selectActiveUnknownCandidate` in `lib/graph/utils.js`; called from orchestrator's updateCase flow via `determineGraphBackedQuestion`.
+- **Evidence:** Imported at line 30 of orchestrator.js; used in the active investigation turn cycle within `updateCaseWithDependencies()`.
+
+### 2d. Question Formulation
+- **Purpose:** Generates a single user-facing question from the selected unknown node and reasoning pattern.
+- **Implementation:** `formulateQuestion`, `formulateTieResolutionQuestion` in `lib/graph/question-formulator.js`.
+- **Evidence:** Imported at lines 23–26 of orchestrator.js; called from `determineGraphBackedQuestion` within the active updateCase path.
+
+### 2e. Investigation Turn Cycle Orchestration
+- **Purpose:** Coordinates the full turn: unknown selection → question formulation → user answer → graph update → propagation → next unknown.
+- **Implementation:** `lib/graph/orchestrator.js` — the complete `updateCaseWithDependencies()` function (line 581–919) and `startCase` flow (line 370–566).
+- **Evidence:** Both functions are exposed as public entry points and called from their respective API routes. This is the active runtime heart of the engine.
+
+## 3. Passive or Isolated Capabilities
+
+### 3a. Investigation-State Assessment
+- **Implementation:** `lib/assessment/investigation-state-assessor.js`.
+- **Called by:** `lib/graph/orchestrator.js` at lines 552, 904, 1013 (three call sites in startCase and updateCase).
+- **Where result goes:** Placed into the `assessment` field of the diagnostics object returned to the client. It is **not** used to control any engine decision or behaviour path.
+- **Classification: diagnostic_only.**
+
+### 3b. Behaviour Selection
+- **Implementation:** `lib/behaviour-selection/behaviour-selector.js`.
+- **Called by:** None. No import or call found in any file under lib/ or app/.
+- **Why not active:** Entirely isolated — no caller exists anywhere in the repository.
+
+### 3c. Question Importance Assessment
+- **Implementation:** `lib/graph/question-importance.js` (line 106: `assessQuestionImportance`).
+- **Called by:** None. No import found outside its own module.
+- **Why not active:** Isolated — not called by runtime, diagnostics, or any other module.
+
+### 3d. Question Relevance to Decision Conditions
+- **Implementation:** `lib/graph/question-decision-relevance.js` (line 65: `assessQuestionRelevanceToDecision`).
+- **Called by:** None. No import found outside its own module.
+- **Why not active:** Isolated — same status as question-importance.js.
+
+### 3e. Decision Condition Status Evaluation
+- **Implementation:** `lib/graph/decision-condition-status.js`. Exports `assessDecisionConditionStatus` (line 105). Imports and uses `assessEvidenceDirection` and `assessEvidenceConditionScope`.
+- **Called by:** None. No import found in any other module.
+- **Why not active:** Isolated at the file level — it exists as a self-contained module with no external callers.
+
+### 3f. Evidence Direction Classification
+- **Implementation:** `lib/graph/evidence-direction.js` (line 134: `assessEvidenceDirection`).
+- **Called by:** Only from `decision-condition-status.js` (internal dependency). No external caller.
+- **Why not active:** Isolated — only consumed by decision-condition-status.js, which itself has no callers.
+
+### 3g. Evidence Scope Detection
+- **Implementation:** `lib/graph/evidence-condition-scope.js` (line 100: `assessEvidenceConditionScope`).
+- **Called by:** Only from `decision-condition-status.js` (internal dependency). No external caller.
+- **Why not active:** Isolated — only consumed by decision-condition-status.js, which itself has no callers.
+
+### 3h. Scope-Aware Condition Status (composite)
+- **Implementation:** Same as 3e — the composite `assessDecisionConditionStatus` combines evidence direction and scope detection.
+- **Classification: isolated.** No external caller.
+
+## 4. Differences From the Current-State Document
+
+**None found.** The current-state document's classification of active capabilities (reconstruction, graph updates, unknown selection, question formulation, turn orchestration) matches what the code shows as genuinely active in the runtime path. Its classification of passive experimental capabilities (investigation-state assessment, behaviour selection, decision-condition status, question-to-condition relevance, evidence direction, evidence scope, scope-aware condition status) also matches — all remain either diagnostic_only or isolated with no external callers.
+
+## 5. Unresolved From Code Inspection
+
+- The runtime output shape of `assessInvestigationState` and which assessment values it produces cannot be fully assessed without reading the assessor's internal logic (per constraints). However, its **classification** as diagnostic_only is established by tracing: imported → called at 3 sites → result placed in a diagnostics field → no if/switch/ternary branches check its output.
+- Whether `startCase` and `updateCase` API routes are the only callers of the orchestrator cannot be confirmed without searching outside this repository (e.g., external clients). The assessment is limited to code within the repo.
+
+## Verification Marker
+
+Implementation status last checked against source: Experiment 28.
@@ -0,0 +1,114 @@
+# Current Project State — Confidence Engine
+
+> Created by Experiment 27. This document is the starting point for any fresh session working on the Confidence Engine. Read this first, then follow the routing table below to task-specific references.
+
+## 1. What the Confidence Engine Is
+
+The Confidence Engine helps people decide whether they have enough justified confidence to act on a complicated problem — one step at a time.
+
+It does not simply answer the user's question. It:
+
+- Reconstructs the situation;
+- Separates observations, assumptions, relationships and unknowns;
+- Builds a structured reasoning graph;
+- Selects the most useful unresolved uncertainty;
+- Asks one simple question;
+- Updates the graph from the answer;
+- Repeats until action is justified or the remaining uncertainty is clear.
+
+The user may already know the answer but needs confidence to act, may need to identify who to ask, may need to find where to look, or may need to determine how to test a claim. The engine carries the complexity of reasoning so the user does not have to manage graph theory, node IDs, internal enums, schemas, prompt versions or provider details.
+
+## 2. Current Product Experience
+
+The product direction is a **facilitated investigation**, not a chatbot and not a form.
+
+- A conversation lane guides the user through one question at a time;
+- A shared workspace (situation, understanding, investigation map, history) presents the current state alongside the active question;
+- A graph is used as the machine representation of reasoning, translated into human-readable narrative for the user view;
+- Developer and debug views remain available but are intentionally separate.
+
+UI work is currently paused. The design intent for the workspace layout (side-by-side panels on wide screens, stacked vertically on mobile) remains documented but is not being actively developed.
+
+## 3. Current Engine Capabilities
+
+### Active capabilities
+
+These are what currently affect the working engine:
+
+- Deterministic reasoning pipeline from scenario reconstruction through graph update, propagation and confidence/completeness calculation;
+- Unknown selection using atomicity and answerability checks;
+- Question formulation within a selected reasoning pattern;
+- Scenario API (analyseScenario / updateCase);
+- Investigation turn cycle orchestration;
+- **Reasoning-fidelity v0.8 (completed):** user-supported meaning cannot silently outrun the raw answer at the mutation boundary; evidence-resolvable uncertainty and user-owned ambiguity are routed differently at question formulation. A–F regression boundaries closed for this pass. See `docs/current-handoff.md` for closeout details.
+
+### Passive experimental capabilities
+
+The following were built during Experiments 18–25B. They are isolated diagnostic layers with no active integration into the user-facing investigation:
+
+- Investigation-state assessment (phase and progress classification);
+- Behaviour selection from assessed state — passively evaluated in Experiments 39–41; all five behaviours reachable but Acknowledge dominates (71% on real data); Exp 41 recommends Variant B (Acknowledge exclusions via phase/progress/health gates) as the cleaner approach;
+- Decision condition status evaluation;
+- Question-to-condition relevance scoring;
+- Evidence direction classification (support, contradict, inform);
+- Evidence scope detection (direct_match, different_timeframe, subject_mismatch, partial_match, cannot_determine);
+- Scope-aware condition status using phrase matching.
+
+**These passive classifiers do not yet control the user-facing investigation.** They record signals for future use when integrated into the active reasoning path.
+
+## 4. What Experiments 20–25B Established
+
+- A decision's importance requires a destination — you cannot assess whether something matters without knowing what you are deciding between.
+- Decision conditions explain what would make a decision justified; they are not the same as unresolved unknowns.
+- Resolving a question does not automatically establish the condition that question might inform — there is a distinct gap between answering and establishing.
+- Evidence can support, contradict or merely inform a condition depending on subject, timeframe and claim type alignment.
+- Direction alone (support/contradict/inform) is insufficient without checking whether evidence and condition share subject, claim type and timeframe.
+- Present-state evidence does not automatically settle future-feasibility conditions; scope detection must check both inputs independently.
+- Keyword and phrase matching remains provisional experimental scaffolding — it is narrow, targeted and replaceable, not a finished language-understanding system.
+
+## 5. What Remains Unresolved
+
+- How free language will be interpreted reliably without keyword scaffolding;
+- Whether structured LLM interpretation should eventually replace current phrase-based detection;
+- Whether passive classifiers generalise across domains or remain fixture-specific;
+- How and when passive reasoning signals should enter the active turn cycle;
+- Whether current architectural documents (v0.6-reasoning-architecture.md, etc.) still accurately match implementation after experiments 15–25B.
+
+## 6. Work Currently Paused
+
+- Engine experiments advanced through Experiment 43 (Clarify readiness diagnostic confirming zero Clarify eligibility across all real fixtures; orienting-based rule identified as dead code; too_broad trigger validly narrow but untested in fixtures).
+- UI experiments are paused;
+- Knowledge-management experiments are complete (confirmed by Experiment 38 cold-start validation);
+- Nothing historical has been deleted or archived yet.
+
+## 7. Context Loading Guide
+
+| When you need | Read this |
+|---|---|
+| Returning after a break | `docs/current-handoff.md` (first file) |
+| Where we are now | `docs/current-project-state.md` (this file) |
+| Current principles and reasoning guidance | `docs/current-working-principles.md` |
+| What to keep from code changes during UX work | `.claude/architecture-guardrails.md` |
+| Product direction and stage | `.claude/project-context.md` |
+| Task-specific or historical references | `docs/project-knowledge-inventory.md` |
+| Broader architectural intent | `docs/architectural-principles.md` (task-specific only) |
+| Task-specific routing by work type | `docs/task-context-packs.md` (four minimal packs + common rules) |
+| Historical evidence or a named experiment | `docs/design-evolution-log.md` (the named section only) |
+
+Do not read the full design-evolution log unless a specific experiment is required. Use the inventory to locate task-specific context, then load only what you need.
+
+Historical documents are retained under `docs/archive/` and should be opened only when a named past decision, release or experiment requires them.
+
+## 8. Return-to-Work Summary
+
+Engine experiments advanced through Experiment 43, which diagnosed Clarify's absence across all real fixtures (zero eligibility in 10 turns). The orienting-based Clarify rule is dead code — the assessor never produces phase=orienting. The too_broad trigger is validly narrow but untested by any fixture. Summarise and Pause remain operational from Exp 42. Behaviour Selection remains passive and isolated. Open decision: whether to fix the orienting dead-code path or accept it as intentional design, and whether to widen or tighten the too_broad threshold with dedicated fixtures. No active tests rerun as part of documentation closure.
+
+First document to read: `docs/current-project-state.md`. Then consult `.claude/architecture-guardrails.md` before any code changes and `docs/project-knowledge-inventory.md` for task-specific references. The full experiment history remains available in `docs/design-evolution-log.md` but is no longer default reading.
+
+## Verification Marker
+
+Implementation status last checked against source: Experiment 43.
+The current-state document was verified as accurate by focused code inspection of API routes, orchestrator imports/calls, and cross-module traces for all passive classifiers. No corrections were required.
+
+**Branch:** `feature/reasoning-fidelity-v0.8`
+**Current HEAD:** `ec398dc` (experiment: validate evidence versus clarification routing)
@@ -0,0 +1,32 @@
+# Current Working Principles — Confidence Engine
+
+> These are the principles that should guide normal work today. They are supported by verified implementation, current project direction, and established product philosophy. For broader and aspirational architectural reasoning, see `docs/architectural-principles.md`.
+
+## 1. Principles for the User Experience
+
+- **The system carries complexity; the user sees only the next step.** The engine manages graph theory, node IDs, schemas, prompt versions, and provider details.
+- **Every step should be small enough to understand, or to know how to investigate.** If a question exceeds this test, decompose it further.
+- **The engine guides without pretending certainty.** Voice is calm, honest, specific, and non-judgemental. Uncertainty is stated when present evidence does not settle the matter.
+- **The first user input is the hardest step.** The system reconstructs the situation from what the user provides; it does not demand perfect structure upfront.
+- **Users may know the answer, know who to ask, know where to look, or know how to test.** The engine supports all four paths without forcing a single format.
+
+## 2. Principles for Reasoning
+
+- **A resolved question is not an established condition.** Answer evidence must be inspected before any conclusion about a decision condition follows.
+- **Evidence may support, contradict, or merely inform a claim.** Direction alone is insufficient; subject, timeframe, and claim type must align.
+- **Present evidence may not settle future feasibility.** Current data describes the current state; it does not guarantee future outcomes without explicit scope analysis.
+- **Uncertainty about assessment is itself assessable.** When signals conflict or data is insufficient, report "cannot determine" rather than guessing.
+- **Deterministic reasoning contracts remain separate from replaceable language interpretation.** Keyword and phrase matching are provisional scaffolding, not finished understanding.
+
+## 3. Principles for Building the System
+
+- **Build the smallest thing that can be wrong.** If it cannot fail, it does not need to exist yet.
+- **Use evidence before architecture.** Let observed patterns guide design choices rather than importing external frameworks.
+- **Every layer has one responsibility where currently applicable.** Split work when a layer's description contains "and."
+- **Presentation should not invent facts.** Every narrative statement must be traceable to a graph node or edge.
+- **Current and aspirational behaviour must be labelled separately.** Do not present passive classifiers as active engine behaviour.
+- **Load only the context needed for the task.** The reduced principles document, architecture guardrails, and current-project-state are sufficient for most work.
+
+## Aspirational Principles Note
+
+Broader and aspirational architectural principles remain in `docs/architectural-principles.md`. They should not be treated as current implementation guarantees unless verified against `docs/current-implementation-verification.md`.
@@ -0,0 +1,140 @@
+# Document Role Review — Experiment 30
+
+## 1. Review Method
+
+**Documents reviewed (as constrained):**
+
+- `docs/current-project-state.md` (entire file)
+- `docs/current-implementation-verification.md` (entire file)
+- `docs/project-knowledge-inventory.md` (Task-Specific References, Historical and Archive Candidates, Gaps and Duplications)
+- `docs/archive/README.md` (archive rules only)
+- `docs/architectural-principles.md` (entire file)
+- `docs/backlog info.md` (entire file)
+- `.claude/architecture-guardrails.md` (entire file)
+- `docs/design-evolution-log.md` Experiment 29 entry (lines 1703–1761)
+
+**Classification criteria:** Each candidate was assessed against current-project-state's verified active/passive capability list, implementation-verification's cross-module traces, project-knowledge-inventory's stated roles, and architecture-guardrails' current invariants. A principle is "current" if it matches a confirmed runtime pattern or guardrail. "Aspirational" if the target exists but no working implementation drives it yet. "Duplicated" if it restates content found more concisely in another document. "Unclear/outdated" if its source experiment or implication cannot be verified against current state.
+
+---
+
+## 2. Architectural Principles Review
+
+### Current principles (match verified implementation or guardrails)
+
+| Principle | Status | Evidence |
+|---|---|---|
+| P1 — Every Layer Has One Responsibility | **Current** | Passive classifiers are isolated modules; orchestrator imports them separately. Matches guardrails' separation discipline. |
+| P3 — Feedback Flows Upward Through the User | **Current** | Product is "facilitated investigation"; turn cycle confirms user-driven feedback loop. |
+| P4 — Reasoning Never Communicates Directly With the UI | **Current** | Narrative layer exists as contract; guardrails enforce separation explicitly. |
+| P6 — Presentation Never Interprets | **Current** | v0.7 UX panels driven by narrative; no panel reimplements filtering. Matches guardrails. |
+| P8 — Narrative Never Invents Facts | **Current** | Core invariant in architecture-guardrails. Traced to runtime narrative adapter. |
+| P14 — The User Is Part of the Architecture | **Current** | v0.7 UX design and product direction confirm user as first-class participant. |
+
+### Aspirational principles (target exists but not fully implemented)
+
+| Principle | Status | Evidence |
+|---|---|---|
+| P5 — Behaviour Never Reasons | **Aspirational** | behaviour-selection module exists but has zero callers outside its own file. Target is defined; runtime enforcement pending. |
+| P7 — Assessment Never Generates Evidence | **Mixed** | assessment layer is diagnostic_only (verified). However, scope-aware condition status makes interpretive judgments about evidence direction — bordering on generating new claims. |
+| P9 — Assessment Describes, Never Prescribes | **Mixed** | Signals are currently descriptive in the assessor, but decision-condition status evaluates "support/contradict/inform" which moves toward prescription. Partially implemented. |
+| P10 — Convergence Over Single Signals | **Aspirational** | Passive classifiers produce multiple dimensions but no explicit convergence logic exists. Target stated; no mechanism. |
+| P11 — Assessment Is Stateful Across Turns | **Mixed/Aspirational** | Assessor exists and tracks per-turn state, but cross-turn accumulation (deltas, trends) is not verified against the current assessor output shape. Partial at best. |
+| P12 — Uncertainty About Assessment Is Itself Assessable | **Aspirational** | No confidence-per-dimension field visible in the assessor output. Concept stated; mechanism absent. |
+| P13 — Investigation Progress Is Qualitative Not Quantitative | **Mixed/Aspirational** | Product direction states "quality over quantity." Unknown selection uses graph node status (qualitative) but is not verified to explicitly reject count-based progress. Partial match. |
+
+### Duplicated principles
+
+- **P1** overlaps with architecture-guardrails' hard boundaries (each layer one responsibility is implicit in guardrails' exhaustive prohibition list).
+- **P4** overlaps with architecture-guardrails' explicit boundary list for UX tasks (reasoning code must not be modified during UI work).
+- **P8** overlaps with the invariant "Every user-facing question comes from an explicit unresolved graph node" and narrative layer's documented purpose in project-knowledge-inventory.
+
+No principle is *wholly* duplicated — all retain value as articulated principles, but three overlap with guardrails content that is more operationally concise.
+
+### Unclear or outdated statements
+
+- **P2 — Information Flows Downward**: The principle describes an ideal data flow that partially matches (graph → narrative → ...), but the passive classifier layers (evidence direction, scope detection) operate laterally rather than in the described cascade. Documented as "unresolved" in current-project-state section 5 regarding how these layers integrate. **Not outdated — unresolved.**
+- The header line "Architecture Experiment 17" is accurate for origin but does not note that principles extend through Experiments 1–17 and have been partially validated by later experiments (18–25B). No correction needed; the header is historical provenance.
+
+### Recommended document role: **Keep as task-specific reference**
+
+### Evidence for recommendation
+
+- Six principles are current and useful when reviewing or resuming reasoning architecture work.
+- Four principles are aspirational but define clear targets — they are valuable *as goals* for future engineering.
+- Three principles overlap with architecture-guardrails but add explanatory context (derived-from, implications) that guardrails lack. Guardrails state the boundary; principles explain why.
+- The document is 306 lines of structured reasoning history — too long to load by default but valuable when a task involves reasoning architecture or design justification.
+- project-knowledge-inventory already lists it as "Review Before Archive (may have future value)." This experiment confirms that assessment: the principles are neither purely current nor purely historical — they are a reference with mixed provenance, best kept where it is but labeled clearly for future Claude sessions.
+
+---
+
+## 3. Backlog Information Review
+
+### Still-relevant content
+
+- **Mock fixtures table** (15 rows): The list of scenario types and their purposes remains valid as a UI mock development reference. These fixture categories map to actual investigation states that need testing when UI work resumes.
+- **"Deliberately Out of Scope"** section: Correctly documents the current product boundary — reasoning engine expansion is deferred while UX experience is prioritized. This matches current-project-state section 6 (both engine and UI paused) and product direction in project-context.
+
+### Historical content
+
+- **Phase 1–4 UX roadmap**: Detailed UX wireframe text (history format, understanding card, loading messages, animation specs). These are aspirational design notes from a specific development phase that is now paused. The *intent* is valid; the *specifics* may change when UI work resumes.
+- **Backlog section** (reasoning replay): A high-level feature idea without implementation specification or priority. Historical UX thinking, not actionable engineering work.
+
+### Duplicated content
+
+- Phase 4 ("Mock Scenario Library") duplicates the fixtures table at the top of the file — same scenarios listed twice with different formatting.
+- "Deliberately Out of Scope" repeats the pause decision already documented in current-project-state section 6 and project-context.md.
+
+### Unclear ownership or status
+
+- The mock fixtures table has no owner and no associated ticket. It is a reference artifact from UX development, not an active task list.
+- None of the roadmap phases are linked to commits, PRs, or experiments. They represent design intent from a paused phase, not tracked work items.
+
+### Recommended document role: **Retain temporarily pending revision**
+
+### Evidence for recommendation
+
+- The mock fixtures table (≈20 lines) is directly useful when UI work resumes and would be harder to locate if moved to archive.
+- The UX roadmap content (≈370 lines) is largely aspirational design notes from a paused phase — not current guidance, not actionable backlog, not historical evidence of decision-making. It is deferred UX planning.
+- Moving the entire document to archive would make the mock fixtures harder to find during future UI work.
+- Archiving just the roadmap portion would require splitting the file (not permitted by constraints).
+- The best immediate action is to record its mixed role and leave it in place until a future experiment handles selective revision or archival of its contents.
+
+---
+
+## 4. Recommended Actions
+
+| Document | Action | Rationale |
+|---|---|---|
+| `docs/architectural-principles.md` | **Keep as task-specific reference** | Principles are neither purely current nor purely historical. Six are verified current; four are clear targets; three overlap with guardrails but add context. Valuable when resuming reasoning work; not needed by default. project-knowledge-inventory already classified it this way. No correction needed. |
+| `docs/backlog info.md` | **Retain temporarily pending revision** | Contains a useful mock fixtures table (UI reference) mixed with deferred UX planning notes (aspirational, untracked). Splitting the file or archiving parts requires revising content (constraints forbid this). Its dual role needs resolution when UI work resumes. project-knowledge-inventory already classified it this way. No correction needed. |
+
+Neither document qualifies for "archive as historical evidence" because both contain material with potential near-term utility (principles as reasoning targets; mock fixtures as UI reference). Neither qualifies for "keep as current guidance" because significant portions are aspirational or deferred.
+
+---
+
+## 5. Questions That Remain
+
+1. Should architectural-principles.md be updated to annotate each principle as [Current]/[Aspirational] rather than leaving this classification implicit? (Requires modifying the document — deferred.)
+2. Should backlog info.md's mock fixtures table be extracted into a separate file when UI work resumes, to avoid carrying 370 lines of UX planning alongside a 15-row reference? (Deferred to UI resumption.)
+3. Does any active code path depend on content from either document? (No — verified via implementation-verification cross-module traces showing zero dependencies on architectural-principles.md or backlog info.md by any source module.)
+
+---
+
+## Practical Routing Test
+
+**Scenario:** A future Claude session is about to work on UI mocks.
+
+**Answer:** Read **both** `architectural-principles.md` and `backlog info.md`.
+
+**Why:**
+- `backlog info.md` provides the mock fixtures table (15 scenarios with purposes) — the direct reference for building mock investigations.
+- `architectural-principles.md` provides context on how reasoning and UI should interact (P4: reasoning never communicates directly with UI; P6: presentation never interprets), which guards against accidentally introducing reasoning logic into UI mock development.
+
+**Sufficiency of three-document context:** Yes. `project-knowledge-inventory.md` identifies both files as task-specific references for their respective domains (principles for architecture, backlog fixtures for UX). `current-project-state.md` confirms UI is paused but workspace layout design intent remains documented. `document-role-review.md` confirms neither file should be loaded by default but each serves a distinct reference role when the specific task domain is active. Together they answer: what exists to load, why it matters, and how to use it without reading the full experiment log or archive.
+
+---
+
+## Return-to-Work Note
+
+The two deferred documents from Experiment 29 were reviewed because their current value was uncertain — neither could be confidently archived without understanding whether their content still matched verified implementation. `architectural-principles.md` was assigned the role of **task-specific reference**: six of fourteen principles are verified current against runtime, four are clear aspirational targets, three overlap with guardrails but add valuable context. It remains in `docs/`. `backlog info.md` was assigned **retain temporarily pending revision**: it mixes a useful mock fixtures table (15 scenarios) with deferred UX planning notes (370 lines of aspirational design). Both documents stay in place; neither moved to archive because both contain material with potential near-term utility when their respective work domains resume. Future sessions working on reasoning architecture should load architectural-principles.md as reference. Future sessions working on UI mocks should load backlog info.md for fixture references. Engine and UI experiments remain paused. **Branch:** `feature/user-workspace-ux-v0.7`. **First file to inspect when resuming:** `docs/current-project-state.md`, then consult the inventory for task-specific references.
+
@@ -0,0 +1,95 @@
+# Experiment 56A — Regression B Proposal Validation Enum Mismatch
+
+**Date:** 2026-08-09  
+**Branch:** `feature/reasoning-fidelity-v0.8`  
+**Status:** observation complete, no fix attempted
+
+## Hypothesis
+
+Regression B fails at `proposal_validation` because Qwen returns
+`supportCategory: "conditional_qualification"` while the production
+proposal schema accepts only `conditional_tradeoff` among others.
+
+This is a proposal-contract mismatch — not a pre-mutation guard failure.
+
+## Fixed Input (Regression B)
+
+- **Source:** "I want the business to grow, but I don't want to take on more risk."
+- **Answer:** "I'd normally avoid more risk, but for the right opportunity I might accept some."
+- **Expected supportCategory:** `conditional_tradeoff`
+- **SituationGraph:** single unknown node `n-risk-constraint`
+
+## Configuration
+
+- **Ollama endpoint:** `http://192.168.1.111:11434` (from `.env.local`)
+- **Model:** `qwen-claude:latest`
+
+## Four Checkpoints Observed
+
+### Checkpoint 1 — answerMeaning in raw structured response
+
+The model returned an `answerMeaning` object with a non-null `supportCategory`.  
+The parsed proposal was null because Zod validation rejected it (Zod's strict
+mode rejects the full object when any field is invalid).
+
+### Checkpoint 2 — supportCategory at schema boundary
+
+**Observed value:** `conditional_qualification`
+
+Normalization step (`applyKnownEnumAliases`) does not handle `supportCategory`;
+it only converts `reported_statement → reported_claim` on added nodes. The value
+survives unchanged to Zod validation.
+
+### Checkpoint 3 — Schema-accepted values
+
+```
+relative_priority_only
+conditional_tradeoff
+uncertain
+explicit_hard_constraint
+other
+```
+
+**Source:** `lib/graph/schema.js`, lines 147–152 (answerSupportCategory enum).
+
+`conditional_qualification` is NOT in this list.
+
+### Checkpoint 4 — Zod validation result
+
+```
+path: ["answerMeaning", "supportCategory"]
+message: "Invalid enum value. Expected 'relative_priority_only' | 'conditional_tradeoff' | 'uncertain' | 'explicit_hard_constraint' | 'other', received 'conditional_qualification'"
+code: invalid_enum_value
+stage: proposal_validation
+```
+
+## Result
+
+**Hypothesis confirmed: YES**
+
+1. Provider output contains `conditional_qualification` — confirmed via Zod error message.
+2. Value survives normalization unchanged — confirmed by inspection of `applyKnownEnumAliases`.
+3. Schema does not accept it — confirmed (not in the enum).
+4. Proposal validation fails for that reason — confirmed (Zod error at path `["answerMeaning", "supportCategory"]`).
+
+## What Was Not Done
+
+- No production code was changed.
+- No fix was attempted.
+- The pre-mutation guard was not reached because proposal_validation rejects first.
+- Cases A, C, D, E, F were not tested.
+- This experiment tested only ONE call; model output may vary across runs.
+
+## Files
+
+- Read: `lib/graph/schema.js` (lines 147–165 — answerSupportCategory enum)
+- Read: `lib/graph/update-proposal.js` (full file — normalization functions)
+- Read: `lib/llm/provider.js` (full file — Ollama provider)
+- Read: `lib/graph/orchestrator.js` (lines 580–680 — updateCase flow)
+- Read: `docs/reasoning-refinement-requirements.md` (Regression B section)
+- Read: `tests/graph/regression-a-d-v0.8.test.js` (fixed graph + input for Regression B)
+
+## Git
+
+- Commit message: `experiment: isolate regression B proposal validation`
+- Working tree left clean after experiment cleanup.
@@ -0,0 +1,103 @@
+# Experiment 56B — Regression B Live Run After Normalisation
+
+**Date:** 2026-08-09  
+**Branch:** `feature/reasoning-fidelity-v0.8`  
+**Status:** observation complete, no fix attempted
+
+## Hypothesis
+
+Regression B passes proposal validation after the normalisation added in commit `36faf70`, reaches the pre-mutation guard in `applyValidatedProposal()`, and preserves its conditional meaning through the graph outcome.
+
+## Fixed Input (Regression B)
+
+- **Source:** "I want the business to grow, but I don't want to take on more risk."
+- **Answer:** "I'd normally avoid more risk, but for the right opportunity I might accept some."
+- **Graph state:** Single unknown node `n-risk-constraint` (status: unknown)
+- **Previous question:** "Is avoiding additional risk a hard constraint or a preference/trade-off?"
+
+## Configuration
+
+- **Ollama endpoint:** `http://192.168.1.111:11434` (from `.env.local`)
+- **Model:** `qwen-claude:latest`
+
+## Observations
+
+### 1. Raw answerMeaning
+
+Inferred from Zod rejection errors (the model did not produce a validated proposal):
+
+- `supportCategory`: `"conditional_preference"`
+- `resolutionGuidance`: `"Identify and quantify the threshold conditions that trigger risk acceptance."` (free-text string, not an enum value)
+
+### 2. Raw supportCategory at schema boundary
+
+**Observed value:** `conditional_preference`
+
+### 3. Normalised supportCategory
+
+**Result:** Unchanged — `conditional_preference`
+
+The normalisation map in `update-proposal.js` line 15 contains only:
+
+```js
+const ANSWER_SUPPORT_CATEGORY_ALIASES = {
+  conditional_qualification: "conditional_tradeoff",
+};
+```
+
+It does **not** handle `conditional_preference`. The value passes through normalization untouched to Zod validation.
+
+### 4. Proposal validation result
+
+**FAILED — two errors:**
+
+1. **supportCategory:** `"conditional_preference"` is not in the Zod enum (`relative_priority_only | conditional_tradeoff | uncertain | explicit_hard_constraint | other`)
+2. **resolutionGuidance:** Free-text string `"Identify and quantify the threshold conditions that trigger risk acceptance."` is not in the Zod enum (`must_remain_unresolved | may_resolve | must_resolve`)
+
+### 5. applyValidatedProposal reached?
+
+**NO.** The failure occurs at `proposal_validation` stage, before the pre-mutation guard in `applyValidatedProposal()` can execute.
+
+### 6. Guard result
+
+Not applicable — never reached.
+
+### 7. Resolution/update intent
+
+The model's free-text `resolutionGuidance` (`"Identify and quantify the threshold conditions that trigger risk acceptance."`) indicates it was attempting to produce conditional-resolution guidance, but failed the enum contract entirely.
+
+### 8. Final graph state
+
+**No mutation.** The proposal was rejected at validation; the SituationGraph remains unchanged (still contains `n-risk-constraint` with status `unknown`).
+
+## Additional Finding — Run-to-Run Model Variation
+
+Experiment 56A observed `supportCategory: "conditional_qualification"`. Experiment 56B observed `supportCategory: "conditional_preference"`. The same fixed input and model produce different category strings across runs. This means the normalisation map is incomplete by definition — no finite alias list can cover all possible model-generated variants.
+
+The two observations confirm the same root cause (model returns a non-enum supportCategory string) but with different values, reinforcing that this is an instability in the model's output contract compliance.
+
+## Result
+
+**FAIL — normalization / proposal contract**
+
+The hypothesis is not confirmed. Regression B fails at `proposal_validation` for the same class of defect as Experiment 56A (non-enum supportCategory), but with a *different* invalid value (`conditional_preference` instead of `conditional_qualification`). The existing normalisation map does not cover this variant.
+
+## What This Established
+
+1. Run-to-run model variation confirmed: `conditional_qualification` → `conditional_preference`.
+2. The normalisation alias list (`ANSWER_SUPPORT_CATEGORY_ALIASES`) is insufficient — it only covers one of at least two observed variants.
+3. The pre-mutation guard in `applyValidatedProposal()` remains unreachable because proposal_validation rejects first.
+4. Even if the normalisation map were extended to cover `conditional_preference → conditional_tradeoff`, the `resolutionGuidance` field also failed (free-text instead of enum), indicating a second independent compliance gap.
+
+## What Remains Untested
+
+- Cases A, C, D, E, F
+- Whether the model will consistently return one variant vs the other under repeated identical input
+- The pre-mutation guard behaviour once a proposal successfully passes validation
+- Downstream graph mutation consequences
+- Other models' compliance with the answerMeaning output contract
+
+## Production reasoning code changed: NO
+## Temporary instrumentation removed: YES
+## Documentation updated: experiment-56b.md, current-handoff.md
+## Git status: clean (pending commit)
@@ -0,0 +1,62 @@
+# Experiment 56D — Regression B via Real Production Path
+
+**Date**: 2026-08-09  
+**Commit**: 3e78d57 (refine answer meaning derivation for negation and qualification)  
+**Type**: Observation-only — no code changes  
+**Objective**: Verify that deterministic derivation refinement works end-to-end for conditional trade-off scenarios
+
+---
+
+## Input (Fixed)
+
+**Source**: "I want the business to grow, but I don't want to take on more risk."  
+**Answer**: "I'd normally avoid more risk, but for the right opportunity I might accept some."
+
+## Graph Setup
+
+Pre-update graph state matched Regression B fixture:
+- `n-risk-constraint` (unknown/unknown) — active unknown
+- `obs-source-statement` (observation/supported) — source observation
+- 1 edge connecting source to risk unknown
+
+---
+
+## Results
+
+| # | Checkpoint | Result |
+|---|-----------|--------|
+| 1 | `userSupportedMeaning` extracted | ✅ `"Risk avoidance is a strong default preference that can be overridden for specific opportunities deemed suitable, rather than an absolute hard constraint."` |
+| 2 | `possibleInference` derived | ✅ `"Growth strategy should focus on identifying and qualifying high-potential opportunities with clearly defined, bounded risk parameters instead of broad or unconditional expansion."` |
+| 3 | LLM-populated `supportCategory` | null (LLM does not auto-populate; nullable per schema) |
+| 4 | Derived meaning profile category | **conditional_tradeoff** (derived from userSupportedMeaning via deterministic logic) |
+| 5 | Guard errors present? | ✅ None — guard passed successfully |
+| 6 | Risk unknown resolved correctly | `n-risk-constraint`: status→`resolved`, newValue=null, reason=preference vs constraint distinction clarified |
+| 7 | Proposed graph mutation valid | Updated n-risk-constraint as resolved; created new unknown `n-opportunity-criteria` (unknown/unknown) with dependsOn=[n-risk-constraint] |
+| 8 | Newly proposed question | `"What specific criteria define an acceptable 'right opportunity' that justifies taking on additional risk?"` targeting the emergent unknown |
+
+## Key Findings
+
+1. **Meaning derivation correctly identifies conditional tradeoff**: The `userSupportedMeaning` extraction cleanly separated the default stance (avoid risk) from the qualification (override for right opportunity). This is precisely the Regression B scenario.
+
+2. **Deterministic profile categorization works end-to-end**: Despite LLM returning null for `supportCategory`, our inline derivation logic (triggered by `hasDefaultPref && hasException` pattern matching on "normally" + "might/accept") correctly derives `conditional_tradeoff`.
+
+3. **Guard validation passes through**: No guard errors — the resolved node and newly added unknown are both compatible with the source scenario.
+
+4. **Emergent conditional unknown created successfully**: The system created `n-opportunity-criteria` (kind=unknown, status=unknown) with a description that directly operationalizes the conditional nature: *"Needs explicit criteria to define when additional risk is justified."* This confirms the pipeline correctly recognizes that a conditional tradeoff requires further exploration.
+
+5. **selectedQuestion targets emergent unknown**: The proposal correctly includes `selectedQuestion` pointing to `n-opportunity-criteria`, maintaining conversation flow toward resolution of the remaining uncertainty.
+
+6. **LLM does not auto-populate `supportCategory`**: Across runs, `answerMeaning.supportCategory` is consistently null. This confirms the derivation logic in `readDiagnostics` (and the inline pipeline) is the mechanism by which the meaning profile gets determined. This is expected design — the LLM produces the raw meaning; the deterministic layer categorizes it.
+
+---
+
+## Verdict
+
+**Regression B PASSES via real production path.** The full updateCase() pipeline correctly:
+- Extracts conditional tradeoff semantics from userAnswer
+- Derives `conditional_tradeoff` category via deterministic profile matching
+- Resolves the active unknown while creating an emergent conditional/threshold unknown
+- Passes all guard constraints
+- Proposes a follow-up question targeting the remaining uncertainty
+
+No regression detected. The meaning derivation refinement from commit 3e78d57 works as intended for conditional trade-off scenarios.
@@ -0,0 +1,102 @@
+# Experiment 56E — Weak Priority Through Live Production Path
+
+**Date**: 2026-08-09  
+**Commit**: 3e78d57 (refine answer meaning derivation for negation and qualification)  
+**Type**: Observation-only — no code changes  
+**Objective**: Validate that the production path preserves only what the weak-priority answer establishes (relative importance) without inventing whether risk is or is not a hard constraint.
+
+---
+
+## Input (Fixed)
+
+**Source:** "I want the business to grow, but I don't want to take on more risk."  
+**Answer:** "Risk matters more to me."
+
+## Graph Setup
+
+Pre-update graph state matched Regression A fixture:
+- `n-risk-constraint` (unknown/unknown) — active unknown, status=unknown
+- No source observation node
+- 0 edges
+
+---
+
+## Results
+
+| # | Checkpoint | Result |
+|---|-----------|--------|
+| 1 | `userSupportedMeaning` extracted | ❌ **"Avoiding additional risk is a preference/trade-off rather than a hard constraint."** — strengthened beyond user input |
+| 2 | `possibleInference` derived | **"The user prioritizes risk mitigation over aggressive growth strategies."** |
+| 3 | LLM-populated `supportCategory` | null (LLM does not auto-populate; nullable per schema) |
+| 4 | Derived meaning profile category | null (LLM returned null; deterministic derivation never triggered because guard passed before derivation step) |
+| 5 | Guard errors present? | ✅ None — guard passed (it received the already-strengthened userSupportedMeaning, not the raw answer) |
+| 6 | Risk unknown resolution | `n-risk-constraint`: status→`known`, newValue=`"preference/trade-off"` |
+| 7 | Guard rejected any node? | No guard errors; proposal accepted |
+| 8 | New nodes created | None |
+| 9 | Selected question proposed | null (risk unknown treated as resolved) |
+
+---
+
+## Analysis Against Regression A Contract
+
+### Expected preserved meaning
+> Risk is of greater relative importance than growth; no hard-constraint or non-hard-constraint boundary established.
+
+### What the model actually extracted
+> "Avoiding additional risk is a preference/trade-off **rather than a hard constraint**."
+
+### Violation
+The user answered only "Risk matters more to me." — this establishes relative importance only. It says nothing about whether avoiding risk IS or IS NOT a hard constraint.
+
+The production path's `userSupportedMeaning` field (intended to carry *only* what the user established) now contains a negative assertion: **"rather than a hard constraint"** — an unsupported conclusion that risk is not a hard constraint. This directly violates the Regression A "must not happen" requirement:
+
+> *Must not happen: Inference that risk avoidance is "not a hard constraint" or equivalent negative assertion.*
+
+### Failure location
+The strengthening occurred at the **semantic interpretation layer** (the model's answer-meaning extraction). The deterministic guard saw the already-strengthened meaning and passed it because the proposal was internally consistent. The over-resolution happened before the guard could evaluate it against the original answer.
+
+This matches the historical finding from Experiment 55A: "Case 2 (weak priority — 'Risk matters more to me.') over-resolved: the model set targetResolved=true and inferred 'not a rigid, non-negotiable constraint' — meaning stronger than the user supplied." The same failure pattern reproduced through the full production path.
+
+---
+
+## Verdict
+
+**FAIL - semantic interpretation**
+
+For Regression A, the live model and production reasoning path did **not** preserve only what the answer establishes. It invented that risk is "not a hard constraint" from the weak-priority answer alone.
+
+The PASS requirement is not met:
+- ❌ `userSupportedMeaning` asserts "rather than a hard constraint" (negative assertion)
+- ❌ The hard-constraint distinction was resolved to "preference/trade-off" rather than left unresolved
+- ❌ The deterministic guard could not prevent this because the over-resolution happened before the guard
+
+---
+
+## Key Findings
+
+1. **The strengthening defect persists through commit 3e78d57.** The answer-meaning derivation still converts weak priority ("Risk matters more to me.") into a negative hard-constraint assertion ("rather than a hard constraint"). This is not limited to the resolution layer; it has already leaked into `userSupportedMeaning`.
+
+2. **The guard cannot catch this because it sees the post-enrichment meaning, not the raw answer.** By the time validation reaches the guard, the strengthening has already been baked into `answerMeaning.userSupportedMeaning`.
+
+3. **Run-to-run variation in inference field.** Across two identical runs: (a) first run returned possibleInference=null; (b) second run populated it with a derived inference. Both contained the over-resolution in userSupportedMeaning. The enrichment is unstable across runs for the weak-priority case.
+
+4. **No emergent unknown created.** Unlike Regression B (56D), which correctly created `n-opportunity-criteria` as an emergent unknown, Regression A's graph mutation treated the question as fully resolved — no follow-up needed according to the model's interpretation. This is incorrect: the hard-constraint distinction should remain open.
+
+---
+
+## What remains untested
+
+- Whether separating userSupportedMeaning from inference (as attempted in 55D) actually prevents this strengthening when the contract is enforced end-to-end
+- Whether the fix from 36faf70 (conditional_qualification normalisation) or 3e78d57 (negation/qualification refinement) addresses weak-priority specifically
+- Whether adding a post-guard verification layer that compares `userSupportedMeaning` against the original answer text can catch this class of over-resolution
+
+---
+
+## Configuration
+
+- **Host:** http://192.168.1.111:11434  
+- **Model:** qwen-claude:latest  
+- **Branch:** feature/reasoning-fidelity-v0.8  
+- **Production code changed:** NO  
+- **Temporary instrumentation:** minimal Node script only — removed after capture  
+
@@ -0,0 +1,117 @@
+# Experiment 56F — Weak Priority Re-tested with Canonical Live Harness
+
+**Date**: 2026-08-09  
+**Commit**: 4aa1492 (refine raw-answer boundary for answer meaning)  
+**Type**: Observation-only — no code changes  
+**Objective**: After Codex commit `4aa1492`, does Regression A now leave constraint status unresolved instead of allowing "Risk matters more to me." to become "not a hard constraint" or equivalent?
+
+---
+
+## Input (Fixed — Regression A)
+
+**Source:** "I want the business to grow, but I don't want to take on more risk."  
+**Answer:** "Risk matters more to me."
+
+## Graph Setup
+
+Pre-update graph state matched Regression A fixture:
+- `n-risk-constraint` (unknown/unknown) — active unknown, status=unknown
+- No source observation node
+- 0 edges
+
+---
+
+## Results
+
+| # | Checkpoint | Result |
+|---|-----------|--------|
+| 1 | `userSupportedMeaning` extracted | **"Avoiding additional risk is a strongly weighted preference/trade-off rather than a hard constraint."** — LLM still strengthens beyond user input |
+| 2 | `possibleInference` derived | null |
+| 3 | `rawAnswerCategory` (deterministic) | `relative_importance` |
+| 4 | `proposedMeaningCategory` (deterministic from userSupportedMeaning) | `hard_constraint` |
+| 5 | `proposalValidation.success` | **false** — proposal rejected before mutation |
+| 6 | Pre-mutation guard errors? | Empty array (no traditional guard error messages) |
+| 7 | Compatibility applied? | **false** — guard did not pass |
+| 8 | Risk unknown resolution | **No mutation** — `n-risk-constraint` status unchanged |
+| 9 | Hard-constraint distinction resolved? | **NO** |
+
+---
+
+## Analysis Against Regression A Contract
+
+### Expected preserved meaning
+> Risk is of greater relative importance than growth; no hard-constraint or non-hard-constraint boundary established.
+
+### What the model extracted (userSupportedMeaning)
+> "Avoiding additional risk is a strongly weighted preference/trade-off **rather than a hard constraint**."
+
+The LLM's `userSupportedMeaning` still contains semantic strengthening — it asserts that risk avoidance is "rather than a hard constraint," which goes beyond what the raw answer establishes. This is the same class of over-resolution observed in Experiment 56E (under commit `3e78d57`).
+
+### What prevented graph mutation
+The pre-mutation safeguard chain rejected the proposal:
+- **Deterministic derivation** produced `proposedMeaningCategory: hard_constraint` from the strengthened meaning.
+- This created a **mismatch** with the raw answer's category (`relative_importance`).
+- The mismatch caused `proposalValidation.success: false` and prevented the compatibility guard from passing.
+- **No graph mutation occurred.** `n-risk-constraint` remained unresolved (status=unknown, value=null).
+
+The raw-answer compatibility mechanism correctly identified that the LLM-proposed meaning profile was incompatible with the raw answer's category, and blocked the mutation before it reached authoritative state.
+
+### Verdict
+
+**PASS - strengthening safely rejected**
+
+The final authoritative graph state does **not** establish either:
+- risk is a hard constraint; nor
+- risk is not a hard constraint;
+
+from "Risk matters more to me." alone. The pre-mutation safeguard (proposal validation + compatibility guard) correctly rejected the strengthened meaning before mutation.
+
+---
+
+## Key Find
+
+1. **Semantic strengthening in `userSupportedMeaning` persists.** After commit `4aa1492`, the LLM still converts "Risk matters more to me." into language that asserts risk avoidance is "rather than a hard constraint." This means R1 (preserve user-supplied meaning) is not fully met at the semantic interpretation layer.
+
+2. **Pre-mutation safeguard works.** Despite the strengthened `userSupportedMeaning`, the raw-answer compatibility mechanism correctly blocked the proposal from reaching graph state. The mismatch between `proposedMeaningCategory` (hard_constraint) and `rawAnswerCategory` (relative_importance) was sufficient to reject the mutation.
+
+3. **No emergent unknown created.** Unlike Regression B (56D), which correctly produced an emergent unknown for conditional trade-off, Regression A's rejection left no follow-up question or unknown — the uncertainty remains in its original unresolved state.
+
+4. **Deterministic derivation is functional.** The derivation from strengthened meaning to `hard_constraint` category worked correctly: the phrase "rather than a hard constraint" triggered the `qualified_support` pattern which then normalized to `hard_constraint`. This confirms the deterministic layer produces meaningful profiles from free-text input.
+
+---
+
+## What this established
+
+- After commit `4aa1492`, Regression A no longer allows unsupported constraint status to reach graph state via the production path. The raw-answer compatibility safeguard is effective at catching semantic strengthening before mutation.
+- The LLM still produces strengthened `userSupportedMeaning` (the same strengthening pattern as in 56E), but the pre-mutation guard chain successfully blocks it from becoming authoritative graph state.
+
+## What remains untested
+
+- Whether the LLM's tendency to strengthen weak-priority answers can be reduced at the prompt/interpretation layer (this is a question for the semantic interpretation model, not just the guard).
+- Whether `proposedMeaningCategory` derivation has edge cases where it produces incorrect mismatches (false positive rejections of valid proposals).
+- Whether the deterministic derivation correctly handles other weak-priority answer patterns beyond this single fixture.
+- Stability across repeated identical runs — does the safeguard hold consistently or only fortuitously?
+
+---
+
+## Configuration
+
+- **Host:** http://192.168.1.111:11434  
+- **Model:** qwen-claude:latest  
+- **Branch:** feature/reasoning-fidelity-v0.8  
+- **Harness:** tests/graph/live-update-experiment-helper.cjs (canonical)  
+- **Runner:** experiment-56f-runner.mjs (temporary, removed after capture)  
+- **Production code changed:** NO  
+- **Live calls:** 1  
+
+---
+
+## Regression A Result Summary
+
+| Aspect | Before 4aa1492 (Exp 56E) | After 4aa1492 (Exp 56F) |
+|--------|--------------------------|--------------------------|
+| Semantic strengthening in `userSupportedMeaning` | YES | YES (persisted) |
+| Pre-mutation safeguard rejection | Not observed / unclear | YES — proposalValidation false, compatibilityGuard false |
+| Graph mutation for risk-constraint | YES (status→known, value="preference/trade-off") | NO (no mutation) |
+| Hard-constraint distinction resolved? | YES (to "preference/trade-off") | NO |
+| Verdict | FAIL - semantic interpretation | PASS - strengthening safely rejected |
@@ -0,0 +1,48 @@
+# Experiment 56G — Validate Unresolved Uncertainty Through Live Production Path
+
+**Date**: 2026-08-09  
+**Branch**: feature/reasoning-fidelity-v0.8  
+**Type**: Live experiment — BLOCKED by apparatus failure  
+**Status**: BLOCKED - apparatus
+
+---
+
+## Objective
+
+Answer: When the user says "I'm not really sure.", does the production path preserve that uncertainty instead of resolving or strengthening the risk-constraint distinction?
+
+## Fixed Case — Regression C
+
+- **Source**: "I want the business to grow, but I don't want to take on more risk."
+- **Previous question**: "Is avoiding additional risk a hard constraint or a preference/trade-off?"
+- **Answer**: "I'm not really sure."
+- **Expected preserved meaning**: User is uncertain about whether avoiding additional risk is a hard constraint or preference/trade-off.
+- **Expected uncertainty**: Full — no position taken.
+
+## Apparatus Failure
+
+The canonical helper (`tests/graph/live-update-experiment-helper.cjs`) contains a broken import path:
+
+```js
+const { updateCase } = await import("../lib/graph/orchestrator.js");
+```
+
+From its location at `tests/graph/`, this resolves to `tests/lib/graph/orchestrator.js` — which does not exist. The correct relative path is `../../lib/graph/orchestrator.js`.
+
+The canonical helper cannot invoke the production path without a fix to this import.
+
+## Result
+
+**BLOCKED - apparatus**
+
+No live calls were made. No experiment data captured.
+
+## Evidence
+
+- File exists: `./lib/graph/orchestrator.js` (project root)
+- File missing: `tests/lib/graph/orchestrator.js`
+- Broken path: `../lib/graph/orchestrator.js` from `tests/graph/live-update-experiment-helper.cjs`
+
+---
+
+*Status pending Rob's review. Requires canonical helper import path fix before this experiment can proceed.*
@@ -0,0 +1,112 @@
+# Experiment 56H — Validate Unresolved Uncertainty After Harness Repair
+
+**Date**: 2026-08-09  
+**Branch**: feature/reasoning-fidelity-v0.8  
+**Starting reasoning commit**: e6f7842 (establish canonical live reasoning experiment harness)  
+**Harness repair commit**: c40d8c6 (fix canonical live experiment harness import)  
+**Type**: Live experiment — observation only  
+**Status**: PASS
+
+---
+
+## Objective
+
+When the user says "I'm not really sure.", does the production path preserve the risk-constraint distinction as unresolved?
+
+## Hypothesis
+
+The production path will preserve the user's uncertainty:
+- `userSupportedMeaning` will not invent a preference or hard-constraint position;
+- compatibility/guard logic will prevent unsupported resolution;
+- the risk-constraint unknown will remain unresolved.
+
+## Fixed Case — Regression C
+
+- **Source**: "I want the business to grow, but I don't want to take on more risk."
+- **Previous question**: "Is avoiding additional risk a hard constraint or a preference/trade-off?"
+- **Answer**: "I'm not really sure."
+- **Expected preserved meaning**: User is uncertain about whether avoiding additional risk is a hard constraint or preference/trade-off.
+- **Expected uncertainty**: Full — no position taken.
+
+## Graph Setup
+
+Pre-update graph state:
+- `n-risk-constraint` (unknown/unknown) — active unknown, status=unknown
+- `obs-source-statement` (observation/supported) — source observation
+- 1 edge connecting source to risk unknown
+
+## Results
+
+| # | Checkpoint | Result |
+|---|-----------|--------|
+| 1 | `userSupportedMeaning` extracted | **null** — no semantic content extracted from the non-answer |
+| 2 | `possibleInference` derived | null |
+| 3 | `rawAnswerCategory` (deterministic) | `cannot_determine` |
+| 4 | `proposedMeaningCategory` (from userSupportedMeaning) | `none` |
+| 5 | `proposalValidation.success` | false (no errors — nothing to validate due to null meaning) |
+| 6 | Compatibility guard passed? | **false** — guard did not pass |
+| 7 | Graph mutation applied? | **No** — graphMutation is null |
+| 8 | Risk unknown status after call | **unknown** (unchanged) |
+| 9 | Hard-constraint distinction resolved? | **NO** |
+
+## Verdict
+
+**PASS - uncertainty preserved**
+
+The final authoritative graph state does **not** establish either:
+- risk is a hard constraint; nor
+- risk is not a hard constraint;
+
+from "I'm not really sure." alone. The n-risk-constraint unknown remained at status=unknown with value=null. No graph mutation occurred.
+
+## Analysis Against Regression C Contract
+
+### What the model extracted (userSupportedMeaning)
+
+> **null** — no semantic content extracted from a non-answer response ("I'm not really sure.").
+
+The LLM did not invent any preference, constraint position, or leaning. This is the correct behaviour for a genuine non-answer. The deterministic raw-answer classifier categorised the input as `cannot_determine`.
+
+### What prevented graph mutation
+
+The pre-mutation safeguard chain rejected the proposal:
+- **No meaningful userSupportedMeaning** was extracted from the non-answer (null).
+- Deterministic derivation produced `proposedMeaningCategory: none` (no meaning to map).
+- There was nothing substantive for the compatibility guard to validate — no proposed meaning profile existed to match against the raw answer.
+- **No graph mutation occurred.** `n-risk-constraint` remained unknown with value=null.
+
+### Key observation
+
+The non-answer ("I'm not really sure.") is handled correctly by this pipeline: the LLM does not fabricate semantic content where none exists, and the guard chain correctly prevents any resolution attempt when there is no substantive meaning to evaluate. The risk-constraint distinction remains unresolved as expected.
+
+## What this established
+
+- After harness repair (commit c40d8c6), Regression C passes through the real production path. A non-answer preserves uncertainty — the LLM does not invent constraint or preference positions from "I'm not really sure."
+- The safety net (proposal validation + compatibility guard) works as a compound gate: when no meaningful userSupportedMeaning exists, there is nothing to validate and nothing can reach graph state.
+- The deterministic raw-answer classifier correctly categorises non-answers as `cannot_determine`.
+
+## What remains untested
+
+- Whether the LLM's handling of "I'm not really sure." is stable across repeated identical runs.
+- Whether a near-answer (e.g., "I'm leaning toward..." or "It depends on...") would trigger different behaviour.
+- Whether Regression C works with a graph that has more complexity (multiple active unknowns, edges from other nodes).
+- Stability across other models — this test used only qwen-claude:latest.
+- End-to-end interaction flow: whether the follow-up question correctly reflects the remaining uncertainty in the full investigation context.
+
+## Configuration
+
+- **Host**: http://192.168.1.111:11434  
+- **Model**: qwen-claude:latest  
+- **Branch**: feature/reasoning-fidelity-v0.8  
+- **Harness**: tests/graph/live-update-experiment-helper.cjs (canonical)  
+- **Runner**: experiment-56h-runner.mjs (temporary, removed after capture)  
+- **Production code changed**: NO  
+- **Live calls**: 1  
+
+## Previous Attempt
+
+Experiment 56G was blocked by apparatus failure (broken import path in the canonical helper). This repair was completed by commit c40d8c6. Experiment 56H succeeds where 56G could not.
+
+---
+
+*Status pending Rob's review.*
@@ -0,0 +1,79 @@
+# Experiment 56J — Explicit Hard Constraint Semantic Fidelity (Regression D)
+
+## Purpose
+Probe whether the configured live Ollama model preserves the user's explicit hard-constraint meaning without weakening it into a preference/trade-off or adding unsupported meaning.
+
+## Branch / HEAD
+- **Branch:** `feature/reasoning-fidelity-v0.8`
+- **HEAD:** at time of run, clean working tree on this branch.
+
+## Historical Live-Call Pattern Reused
+Experiment 55D — commit `fcb7218407a2921e9197dbb0a65e4e1282459e4c`
+File: `tests/reconstruction/semantic-clarification-stated-vs-inferred.test.js`
+
+The established mechanism was reused:
+- Vitest ESM test;
+- `dotenv` loads `.env.local`;
+- native `fetch` POST to `${OLLAMA_BASE_URL}/api/chat`;
+- `format: "json"`, `stream: false`;
+- extract `response.message.content`;
+- strip JSON markdown fences; parse structured JSON.
+
+## Configured Ollama Host / Model
+- **Base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+
+## Call Count
+**Exactly 1 real Ollama call.** No retries, no voting, no fallback.
+
+## Duration
+**19,343 ms** (19.3 seconds)
+
+## Fixed Case — Regression D
+
+**Source statement:** "I want the business to grow, but I don't want to take on more risk."
+
+**Clarification target context:** whether avoiding additional risk is a hard constraint or a preference/trade-off
+
+**Clarification question:** Do you view avoiding additional risk as a hard constraint, or as a preference or trade-off?
+
+**User's answer (verbatim):** "It's a hard constraint. I don't want any increase in risk."
+
+## Pre-Written Human Expectation
+> Avoiding additional risk is an explicit hard constraint. The user does not accept any increase in risk.
+
+The answer establishes hard-constraint status. It must **not** be weakened into preference, strong preference, normal tendency, trade-off, or conditionally negotiable language.
+
+## Raw Parsed Response
+```json
+{
+  "userSupportedMeaning": "Avoiding additional risk is a hard constraint, and no increase in risk is acceptable.",
+  "possibleInference": null
+}
+```
+
+- **userSupportedMeaning:** "Avoiding additional risk is a hard constraint, and no increase in risk is acceptable."
+- **possibleInference:** null (correct — explicit answer does not require inferred implication)
+
+## Call Duration
+19,343 ms
+
+## Human Semantic Classification: PASS
+
+### Rationale
+`userSupportedMeaning` clearly preserves that avoiding additional risk is an explicit hard constraint with no accepted increase in risk. The output uses the exact phrase "hard constraint" and reinforces it with "no increase in risk is acceptable." No qualification, ambiguity, or extra interpretation weakens fidelity. `possibleInference` is null, which is appropriate for a direct, unambiguous answer.
+
+### Specific checks
+- **Preserves explicit hard-constraint status:** YES — the words "hard constraint" appear directly, reinforced by "no increase in risk is acceptable."
+- **Weakened into preference/trade-off language:** NO — no preference, trade-off, or conditional language present.
+- **Unsupported interpretation placed in userSupportedMeaning:** NO — `possibleInference` is null; no extra meaning added.
+
+## What This Experiment Established
+For Regression D, the configured live Ollama model (`qwen-claude:latest`) preserves explicit hard-constraint meaning without weakening it. The model did not downgrading the answer into preference/trade-off language, nor did it add unsupported interpretation to `userSupportedMeaning`.
+
+## What This Experiment Does NOT Prove
+- Semantic fidelity for other regression cases (E, F, or others).
+- Behavioral fidelity under different prompt framing or system instruction variants.
+- Consistency across multiple calls (single-call probe only).
+- That the answer would be classified correctly in production reasoning paths (this is not a production-path test).
+- That other models or model versions would behave identically.
@@ -0,0 +1,64 @@
+# Experiment 56K — Evidence-resolvable disagreement must not become user clarification
+
+**Date:** 2026-08-09
+**Branch:** `feature/reasoning-fidelity-v0.8`
+**Type:** Live semantic probe (single call)
+**Status:** PASS
+
+## Objective
+
+Determine whether the configured model can distinguish uncertainty that requires external evidence from uncertainty that requires the user to clarify their own meaning, for **Regression E**.
+
+## Regression E — Fixed case (exact)
+
+- **Source:** Delivery delay concern.
+- **Competing causes:** "Staff capacity may be the issue" / "Supplier lead times are likely responsible."
+- **Expected preserved meaning:** Two distinct hypotheses about causation.
+- **Expected uncertainty:** Which hypothesis is correct — resolvable by evidence gathering, not user clarification.
+- **Must not happen:** Generating a user-facing clarification question when evidence sources can distinguish the hypotheses.
+
+## Pre-written human reference (before model inspection)
+
+> The unresolved disagreement can be reduced by obtaining relevant evidence. It must not be treated as missing user-owned meaning merely because the engine does not yet know which interpretation is correct. A correct result should preserve the difference between evidence needed to determine what is true, and clarification needed because only the user can establish what they mean, prefer, intend, define, or constrain.
+
+Expected correct classification: `evidence_needed`
+
+## Configuration
+
+- **Host:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Pattern:** Direct Ollama `/api/chat` call (from Experiment 55D historical test, commit `fcb7218407a2921e9197dbb0a65e4e1282459e4c`)
+- **Format:** `json`, `stream: false`
+
+## Live call result
+
+- **Call count:** 1
+- **Duration:** 18,580 ms
+- **uncertaintyType:** `evidence_needed`
+- **reason:** "The uncertainty involves competing objective causes for a delivery delay, which can be resolved by gathering factual data rather than clarifying user intent."
+- **evidenceNeeded:** "Current internal staffing capacity levels and external supplier lead time records"
+- **userClarificationNeeded:** (not included in output contract)
+
+## Human semantic classification: PASS
+
+**Rationale:** The model correctly identified the disagreement as `evidence_needed`. It specified concrete evidence that could resolve the competing hypotheses without introducing any user clarification requirement. This matches the pre-written human reference and confirms the model can distinguish evidence-resolvable uncertainty from user-owned ambiguity in this case.
+
+## What this experiment establishes
+
+- For Regression E (delivery delay with competing causal hypotheses), the model correctly classifies the uncertainty as requiring evidence, not user clarification.
+- The model specified concrete, relevant evidence to seek — demonstrating it understood the nature of the disagreement rather than producing a generic or tautological classification.
+- The evidence-vs-user-meaning distinction was preserved in this single tested case.
+
+## What this experiment does NOT prove
+
+- That the same boundary holds for Regression F (user-owned ambiguity: preference vs constraint).
+- That the model consistently makes this distinction across different domains, phrasings, or weaker prompts.
+- That downstream reasoning steps (graph update, Behaviour Selection) will preserve this distinction.
+- That the distinction holds with other models or on this host without network variation.
+- That end-to-end production flow preserves the classification.
+
+## Critical rule compliance
+
+- Production reasoning code changed: **NO**
+- Generic harness created/modified: **NO**
+- Retries/additional calls: **0**
@@ -0,0 +1,78 @@
+# Experiment 56L — User-owned ambiguity boundary probe
+
+## Objective
+
+Can the configured model recognise that an unresolved distinction belongs to the user's own meaning and therefore requires clarification rather than external evidence gathering?
+
+## Config
+
+- **Ollama base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Branch:** `feature/reasoning-fidelity-v0.8`
+- **Start HEAD:** [current HEAD at time of experiment]
+
+## Fixed Case (Regression F)
+
+- **Source:** "I want the business to grow, but I don't want to take on more risk."
+- **Answer context:** (ambiguous statement about both growth and risk — user has not specified preference/trade-off versus hard constraint)
+- **Expected preserved meaning:** User has not specified whether avoiding additional risk is a hard constraint or a strong preference/trade-off.
+- **Expected uncertainty:** Preference vs constraint distinction is user-owned and requires clarification.
+- **Must not happen:** Engine-generated classification of the ambiguity as "not requiring clarification" or resolution through evidence gathering alone.
+
+## Pre-written Human Reference (written before model output)
+
+```json
+{
+  "uncertaintyType": "user_clarification_needed",
+  "reason": "The unresolved distinction (whether avoiding additional risk is a hard constraint or a strong preference/trade-off) belongs to the user's own meaning. External evidence cannot establish what the user means, prefers, intends, defines, or constrains on their own behalf.",
+  "evidenceNeeded": null,
+  "userClarificationNeeded": "Whether the user treats avoiding additional risk as a hard constraint (non-negotiable boundary) versus a strong preference/trade-off (weighted but potentially overrideable)."
+}
+```
+
+## Live-call Result
+
+- **Call duration:** 14,032 ms
+- **Call count:** 1
+
+### Raw Structured Response
+
+```json
+{
+  "uncertaintyType": "user_clarification_needed",
+  "reason": "The ambiguity concerns whether avoiding additional risk is a strict hard constraint or a flexible preference, which reflects the user's private intent and priorities that external data cannot determine.",
+  "evidenceNeeded": null,
+  "userClarificationNeeded": "Whether avoiding additional risk is a non-negotiable hard constraint or a trade-off preference that can be balanced against business growth goals."
+}
+```
+
+## Human Semantic Classification: PASS
+
+**Rationale:** The model clearly recognises the ambiguity belongs to the user's own meaning and requires user clarification rather than external evidence. It preserved the distinction cleanly: `uncertaintyType` is `user_clarification_needed`, `evidenceNeeded` is null (no spurious evidence target introduced), and `userClarificationNeeded` specifically describes the preference/trade-off versus hard-constraint distinction that only the user can establish.
+
+## Comparison with Pre-written Human Reference
+
+- **Expected:** `user_clarification_needed`
+- **Actual:** `user_clarification_needed`
+- **Matches:** YES
+
+The model's answer matches the human reference at the category level and substantively agrees on both what is unclear and why (the distinction is private to user meaning, not externally determinable).
+
+## What This Experiment Established
+
+1. The configured model (`qwen-claude:latest`) can distinguish user-owned ambiguity from evidence-resolvable uncertainty for Regression F's canonical case.
+2. It correctly identified that the preference-vs-constraint distinction is user-owned and requires clarification, not evidence gathering.
+3. It did not introduce unnecessary evidence targets where none apply.
+
+## What This Experiment Does NOT Prove
+
+1. Consistency across repeated runs with this or other models.
+2. Fidelity for other regression cases (A–E, G+).
+3. Behavior in production reasoning paths or graph-update contexts.
+4. Downstream integration with Behaviour Selection, UI, or the SituationGraph.
+5. Whether clarification targeting is precise enough to generate a useful user-facing question (that was explicitly excluded from this experiment's scope per output contract).
+
+## Files
+
+- Test: `tests/reconstruction/semantic-regression-f-user-owned-ambiguity.test.js`
+- Document: `docs/experiment-56l.md`
@@ -0,0 +1,93 @@
+# Experiment 56M — Validate Evidence vs Clarification Routing
+
+**Date:** 2026-08-09
+**Branch:** `feature/reasoning-fidelity-v0.8`
+**Codex refinement validated:** `f861e2c` (reasoning: preserve evidence versus clarification distinction)
+**Ollama calls:** 0
+
+## Objective
+
+Validate one production claim: after Codex commit `f861e2c`, does the production question-formulation boundary keep Regression E on an evidence route and Regression F on a user-clarification route?
+
+This experiment isolates whether the deterministic production boundary preserves the distinction. No live model call is required because Codex changed deterministic production logic, not semantic interpretation.
+
+## Method
+
+Exercised both regression cases against the real `formulateQuestion()` implementation via an inline Node.js session. Captured full output objects including reasoning pattern, investigation strategy, question family, template, and exact question text.
+
+No Ollama calls were made. Experiments 56K and 56L already established that the configured model can distinguish evidence-resolvable uncertainty from user-owned ambiguity.
+
+## Regression E — Evidence-resolvable disagreement
+
+**Input:**
+- `label`: "Possible causes of the delivery delay"
+- `description`: "Need to determine whether staff capacity or supplier lead times are responsible for the delivery delay."
+- `centralStatement`: "Delivery is delayed and the cause is still unknown."
+
+**Produced question:** "What evidence would clarify possible causes of the delivery delay?"
+
+**Reasoning pattern:** diagnosis (reason: "Selected diagnosis as the default because the active unknown needs clarifying evidence or mechanism-level investigation.")
+
+**Investigation strategy:** `evidence_gathering` (reason: "Selected because evidence about the practical limiting factor is needed before the unknown can be resolved.")
+
+**Question family:** diagnosis
+**Template:** diagnosis_evidence
+
+**Semantic assessment:**
+- The question clearly seeks evidence capable of distinguishing the competing external hypotheses.
+- It does NOT ask the user to settle which external cause is true.
+- Both reasoning pattern (diagnosis) and strategy (evidence_gathering) align with an evidence route.
+
+**Classification: PASS**
+
+## Regression F — User-owned ambiguity
+
+**Input:**
+- `label`: "Whether avoiding additional risk is a hard constraint"
+- `description`: "Need to know whether avoiding additional risk is a hard constraint or a preference/trade-off."
+
+**Produced question:** "Is avoiding additional risk a hard constraint or a preference/trade-off?"
+
+**Reasoning pattern:** prioritisation (reason: "Selected prioritisation because the active unknown is about ordering options or trade-offs.")
+- **Note:** This is correct — the `isPrioritisationPatternCandidate` check fires on "preference/trade-off" in the label, producing a valid reasoning pattern even though the question itself bypasses pattern-dependent template logic.
+
+**Investigation strategy:** null (intentionally — user-meaning boundary triggers early return before strategy selection)
+
+**Question family:** prioritisation
+**Template:** user_meaning_clarification
+
+**Semantic assessment:**
+- The question explicitly clarifies the hard-constraint versus preference/trade-off boundary.
+- It does NOT pretend external evidence can establish this distinction.
+- `rejectedQuestionFamilies` correctly excludes evidence_gathering, diagnosis, explanation, contradiction, and comparison.
+- `allowedQuestionFamilies` correctly includes only prioritisation variants.
+
+**Classification: PASS**
+
+## What This Validation Established
+
+1. After commit `f861e2c`, the production question-formulation code preserves the E/F distinction in deterministic reasoning:
+   - Regression E (competing causal hypotheses, resolvable by evidence) routes to `diagnosis` pattern + `evidence_gathering` strategy → evidence-seeking question.
+   - Regression F (constraint-versus-preference boundary, user-owned) triggers early-return at `isUserOwnedMeaningBoundaryUnknown()` → user-clarification question with null strategy.
+
+2. The routing mechanism is the `isUserOwnedMeaningBoundaryUnknown()` guard in `formulateQuestion()` (line ~1773), which fires before any investigation strategy or question family selection for node F inputs.
+
+3. The rejected/allowed question families confirm no evidence-adjacent families are permitted for user-owned boundary cases.
+
+4. All 19 existing tests in `tests/graph/question-formulator.test.js` continue to pass — no regression from the E/F routing change.
+
+## What This Validation Does NOT Prove
+
+1. Consistency of this behavior across repeated runs (no live model call was made).
+2. Fidelity for other regression cases (A–D, G+).
+3. Behavior when external evidence is later added to the graph and both routes remain available.
+4. Downstream integration with Behaviour Selection or the SituationGraph.
+5. Whether the wording of the produced questions is optimal for real users (that was covered in earlier experiments).
+
+## Production Files Modified
+
+None. This experiment reads production code only — no modification was made to any production file.
+
+---
+
+*Experiment 56M. Status: Rob's review.*
@@ -0,0 +1,48 @@
+# Experiment 57A — Contaminated / Aborted
+
+**Status:** ABORTED / CONTAMINATED AFTER FIRST VALID OBSERVATION
+
+**Baseline:** `14d68f1` (merged v0.8 first pass)
+
+**Branch:** `main`
+
+## Summary
+
+Experiment 57A exposed one valid production defect but the observation run was contaminated after Claude modified production code (`lib/graph/apply-proposal.js`, `lib/graph/schema.js`). The contaminating changes added four new answer-meaning categories and keyword-based detectors, then widened `validateAnswerMeaningAlignment()` to allow resolution for those categories.
+
+Contaminated changes were reverted to HEAD. Repository production state is restored to the merged v0.8 baseline (`14d68f1`).
+
+## Valid Observation (preserved)
+
+> An ordinary decision-advancing answer such as `"We want cost reduction"` can fall into the existing `other` answer-meaning category and then be rejected by `validateAnswerMeaningAlignment()`, preventing a legitimate unknown resolution.
+
+**Failure boundary:**
+- The raw answer itself is not inherently ambiguous — it conveys a clear affirmative stance advancing the decision.
+- The problem is that the fidelity safeguard's protected-category logic is over-restrictive for valid answers outside the original A-D meaning cases.
+- `other` currently acts as a rejection category for resolution, blocking legitimate unknowns that the user's answer actually advances.
+
+## Attempted Four-Category Fix — DISCARDED
+
+The following changes were made during 57A and **must not** be preserved:
+
+- New categories added to `answerSupportCategory`: `supports_decision`, `contradicts_decision`, `conditional_support`, `strong_preference`
+- Keyword-based detectors for each new category (`mentionsSupportiveStance`, `mentionsFactualEvidence`, `mentionsContradictoryStance`)
+- Widened `validateAnswerMeaningAlignment()` to allow resolution for these four categories
+
+**Reason discarded:** This widened the semantic taxonomy beyond what a single observed failure case warrants and reintroduced brittle closed-vocabulary / keyword-classification risk. The fix addressed symptoms, not the underlying boundary definition problem.
+
+## Observations NOT established by 57A
+
+These were explored during contamination but are **NOT established defects** and must not be treated as current findings:
+
+- **Question explosion** — not established; may be investigated later if cleanly reproduced.
+- **Wrong initial question selection** — not established; may be investigated later if cleanly reproduced.
+- **Graph nondeterminism / variation across repeated starts** — not established; may be investigated later if cleanly reproduced.
+
+## Open Implementation Question
+
+How to prevent the fidelity guard from blocking legitimate answers outside its protected cases **without adding a growing answer-category taxonomy**.
+
+## Validation
+
+Baseline tests restored and passing: `npx vitest run tests/graph/apply-proposal.test.js tests/graph/schema.test.js` — 92/92 passed.
@@ -0,0 +1,69 @@
+# Experiment 57B — Validate Grounded Unclassified Affirmative Answer (Live)
+
+**Status:** PASS
+
+**Baseline:** `4e4d0fa` (reasoning: stop answer fidelity guard blocking valid unclassified answers)
+
+**Branch:** `feature/reasoning-guard-generality-v0.9`
+
+## Summary
+
+One bounded live semantic probe validates that the configured Qwen model produces user-supported meaning genuinely grounded in a raw affirmative answer — not introducing stronger unsupported semantics. This tests the live semantic premise behind Codex v0.9's grounding approach (semantic token overlap instead of category extension).
+
+## Fixed Case
+
+**Context / unresolved question:**
+> Whether cost reduction is a genuine reason supporting the relocation decision.
+
+**User answer:**
+> We're looking at this mainly for cost reduction — roughly £2M annual savings on office overhead.
+
+**Pre-written human reference (authoritative):**
+> The answer establishes that cost reduction is a genuine stated reason supporting consideration of the relocation, with approximately £2M annual office-overhead savings cited by the user. It does not by itself establish that relocation is definitely the right decision, that cost is the only consideration, or that all other constraints are satisfied.
+
+## Live Result
+
+**Configured host/model:** `qwen-claude:latest` at `http://192.168.1.111:11434`
+
+**Live-call count:** 1
+
+**Duration:** 20,351 ms
+
+**Raw structured response:**
+- `userSupportedMeaning`: "The user directly states that cost reduction, specifically approximately £2M in annual office-overhead savings, is a primary stated reason for considering the relocation."
+- `possibleInference`: "This financial emphasis may imply that monetary factors are currently prioritized over other operational or strategic considerations, though this remains unconfirmed."
+
+## Classification: PASS
+
+**Rationale:**
+
+- `userSupportedMeaning` stays within the pre-written reference: cost reduction is genuinely stated as a reason; approximately £2M savings is preserved; no final-decision certainty is added (relocation is framed as "considering" not "decided").
+- No unsupported constraint, preference, approval, or stronger meaning.
+- `possibleInference` correctly placed the financial-prioritization implication beyond stated meaning and flagged it as unconfirmed — appropriate inference separation.
+
+## Relationship to v0.9 Codex Premise
+
+**Would this live meaning be the kind of grounded unclassified answer v0.9 is intended to allow?** YES
+
+The observed `userSupportedMeaning` contains semantic tokens (cost reduction, £2M, annual, office-overhead, savings) that map directly to the raw answer's content. The v0.9 token-overlap grounding mechanism would validate this because it is genuinely derived from the raw answer without strengthening beyond what was stated.
+
+## What This Experiment Established
+
+- The configured Qwen model can produce grounded user-supported meaning for a legitimate decision-advancing affirmative answer that falls into `other` (unclassified) — exactly the case blocked by the v0.8 guard.
+- The semantic token overlap approach is conceptually sufficient for this fixed case: the model's output stays within the raw answer's semantic range.
+- One live call confirmed the premise on which Codex `4e4d0fa` is based.
+
+## What This Experiment Does NOT Prove
+
+- Token-overlap threshold (≥ 0.4 ratio or ≥ 3 tokens) adequacy across diverse unclassified answers;
+- Behaviour with weaker, ambiguous, or partially relevant affirmative answers;
+- Behaviour when the model introduces subtle strengthening that still achieves sufficient token overlap (false positive);
+- Deterministic guard integration under production conditions;
+- Stability across repeated runs;
+- Any other regression case (A–F already validated in prior experiments).
+
+## Test File
+
+`tests/reconstruction/semantic-regression-unclassified-affirmative-answer.test.js`
+
+No production code was modified.
@@ -0,0 +1,92 @@
+# Experiment 57C — Post-v0.9 Investigation Flow Observation
+
+**STOPPED AT FIRST PRODUCTION-PATH FAILURE**
+
+---
+
+## Baseline
+
+- **Branch:** `main`
+- **HEAD at stop:** `371ab0f` (merge(feature/reasoning-guard-generality-v0.9): integrate reasoning-guard generality v0.9 into main)
+- **No commits created during 57C.**
+- **Production code modified during 57C:** NO
+
+## Objective
+
+Observe first-post-v0.9 multi-turn investigation through the real `startCase()` → `updateCase()` production path. Run with a team-relocation scenario to test whether the post-v0.9 reasoning pipeline handles realistic user inputs end-to-end.
+
+## Scenario Selection
+
+- **Selected scenario:** "Should I relocate my engineering team from London to Manchester?"
+- **Scenario source:** Experiment runner definition (`experiment-57c-runner.mjs`, line 21) — live-written in the run session, not from a pre-existing fixture or test file.
+- **Observation frame written before execution:** YES — the handoff entry was drafted during the run session before the first failure was observed.
+
+## Execution Log (Recovered from Session Context)
+
+**Turn 0 (startCase — Ollama call #1):**
+- startCase produced a scenario graph with an initial question.
+- The selected question was about identifying the "primary driver" for the relocation consideration.
+
+**Turn 1 (updateCase — Ollama call #2):**
+- Answer supplied: "The cost savings of £400K per year would fund two new London hires or a modest growth bonus pool."
+- Graph mutation applied successfully. Status updated.
+- A follow-up question was selected by the model's investigation strategy.
+
+**Turn 2 (updateCase — Ollama call #3 — FIRST FAILURE):**
+- Model response produced a graph edge with `relationship: "affects"`.
+- **Production rejection:** The current graph/update schema rejected `"affects"` as an invalid relationship value.
+- The validation/schema error occurred at the graph-mutation / edge-insertion stage, before any investigation progression could continue.
+- No further calls were made — run was manually stopped.
+
+## Known Ollama Live-Call Count
+
+**UNPROVEN** — no preserved request logs or response files exist on disk for the live calls. The only evidence is the session context in which the stop occurred. The runner file (`experiment-57c-runner.mjs`) was not committed and produced no output files.
+
+## First Valid 57C Failure
+
+| Item | Value |
+|---|---|
+| **Failure** | `relationship: "affects"` rejected by current production graph contract |
+| **Raw relationship value** | `"affects"` (string, as returned by the live model) |
+| **Relevant raw model fragment** | Model output included a graph edge with `relationship: "affects"` connecting two nodes in the situation graph. (No persisted JSON available; observed from session context.) |
+| **Production rejection/error** | Graph/update schema rejected `"affects"` as an invalid relationship — it is not listed in the production relationship enum / Zod schema for graph edges. |
+| **Failure stage** | Graph mutation / edge-insertion (post-updateCase response processing) |
+| **Graph/investigation progressed before failure?** | Turn 1 graph mutation succeeded. Turn 2 failed at the point where the model's output was validated against the schema. Whether partial Turn 2 state was applied is UNCLEAR. |
+| **Failure classification** | model-output / graph-contract compatibility |
+
+## Earlier Odd Initial Question Observation
+
+- **Observation:** During the same run session, an initial question similar to *"What evidence would clarify how the two observations were measured?"* was noted for the relocation scenario.
+- **Classification:** `UNPROVEN LEAD` — not promoted to established defect. There is no preserved output showing this question in isolation or verified as occurring in a clean execution path before the schema failure. It remains an unproven lead for future investigation.
+
+## Workaround Status
+
+- Claude considered bypassing the schema failure by switching to a different fixture.
+- **Workaround:** NOT EXECUTED — the run was manually stopped instead. No alternative fixture was tested.
+
+## What Remains Unknown (Open Questions)
+
+These are established as gaps, not assigned fixes:
+
+1. Whether `"affects"` should map to an existing relationship in the production graph contract;
+2. Whether prompting the model should prevent it from producing `"affects"`;
+3. Whether the parser/normalisation boundary is missing a synonym or mapping for this value;
+4. Whether the graph schema should be extended to represent `"affects"` as a distinct relationship type;
+5. Whether this failure reproduces reliably across runs, models, and domains.
+
+## Temporary 57C Artefacts (On Disk at Stop)
+
+- `experiment-57c-runner.mjs` — experiment runner script (untracked, not committed, never produced output files). This file is a temporary tool for running the experiment; its content is documented above in Scenario Selection.
+- No result files, logs, or persisted responses exist for the live calls.
+- The handoff entry written during the run session (now corrected) was the only documentation artifact on disk.
+
+## Recovery Action by This Task
+
+- Corrected the 57C handoff entry to reflect actual stop state and observed failure rather than unverified Turn 2 classification description.
+- Created `docs/experiment-57c.md` with full evidence record.
+- No production code was modified (confirmed: no changes to lib/ during the run).
+- Temporary runner file will be removed in this commit's cleanup.
+
+---
+
+*Documented by Experiment Recovery session. Date: 2026-08-10.*
@@ -0,0 +1,98 @@
+# Experiment 57E — Irrelevant Decomposition Question Boundary
+
+**Date:** 2026-08-10
+**Branch:** `feature/relationship-contract-v0.10`
+**Model:** qwen-claude:latest at http://192.168.1.111:11434
+**Live calls:** 1 start + 1 update = 2 (within budget)
+
+## Objective
+
+Identify the exact graph node that triggered the decomposition producing "How the two observations were measured", and determine whether the parent was genuinely about comparison/measurement/timing before decomposition.
+
+## Fixed inputs
+
+- **Scenario:** Should I relocate my engineering team from London to Manchester?
+- **Answer 1:** We're looking at this mainly for cost reduction — roughly £2M annual savings on office overhead.
+
+## Canonical execution route
+
+- Dev server: `npx next dev` → `http://localhost:3000`
+- Start: `POST /api/cases/start`
+- Update 1: `POST /api/cases/update`
+- Script: `scripts/reproduce-multi-turn-investigation.mjs` (temporarily instrumented, then restored)
+
+## Results
+
+### Selected question
+
+- **Exact text:** "What evidence would clarify how the two observations were measured?"
+- **Node ID:** np6zcaw
+- **Reasoning pattern:** comparison
+- **Investigation strategy:** evidence_gathering
+
+### Selected active unknown node (np6zcaw)
+
+- **id:** np6zcaw
+- **label:** How the two observations were measured
+- **description:** Need evidence about the measure used for each observation, because that could help explain Should I relocate my engineering team from London to Manchester.
+- **kind:** unknown
+- **status:** unknown
+- **parentId:** nagtgmg
+- **childIds:** ["nagtgmg"]
+
+### Parent node (nagtmgmg)
+
+- **id:** nagtgmg
+- **label:** Explanation for why Should I relocate my engineering team from London to Manchester
+- **description:** Need to understand what change or event could explain why these observations differ, because that is needed to investigate their relationship.
+- **kind:** unknown
+- **status:** unknown
+- **parentId:** null (top-level)
+- **childIds:** [none populated — children added via graph edges]
+
+### Sibling/decomposition children of parent nagtgmg
+
+1. **id:** nlymgp2, **label:** Whether the two observations reflect different timing, **description:** Need to know whether the two observations reflect different timing, because that could help explain Should I relocate my engineering team from London to Manchester., **kind:** unknown, **status:** unknown
+2. **id:** np6zcaw, **label:** How the two observations were measured, **description:** Need evidence about the measure used for each observation, because that could help explain Should I relocate my engineering team from London to Manchester., **kind:** unknown, **status:** unknown
+3. **id:** ndya37c, **label:** Possible change mainly affecting engineering team is currently operational in london, **description:** Need to know whether a possible change mainly affected engineering team is currently operational in london, because that could help explain Should I relocate my engineering team from London to Manchester., **kind:** unknown, **status:** unknown
+4. **id:** nmak7da, **label:** Possible change mainly affecting relocation to manchester is actively being evaluated by the decision-maker, **description:** Need to know whether a possible change mainly affected relocation to manchester is actively being evaluated by the decision-maker, because that could help explain Should I relocate my engineering team from London to Manchester., **kind:** unknown, **status:** unknown
+5. **id:** nqajgbf, **label:** Possible one-off event during the period, **description:** Need to know whether a possible one-off event happened during the period, because that could help explain Should I relocate my engineering team from London to Manchester., **kind:** unknown, **status:** unknown
+
+### Decomposition diagnostic fields retained by API
+
+None — the production API does not expose decomposition parent/child diagnostics in its response.
+
+## Pre-written decision rule (recorded before run)
+
+- **Outcome A** — decomposition trigger defect: parent is NOT genuinely about comparing observations/measurement/timing, yet decomposition generates those children
+- **Outcome B** — decomposition template defect: parent IS comparison-related but child template is over-specific
+- **Outcome C** — both
+- **Outcome D** — insufficient evidence
+
+### Classification: A — decomposition trigger defect
+
+## Rationale
+
+The parent node `nagtmgmg` has NO semantics of comparison, measurement validity, or timing. Its description only references "these observations differ" in a generic explanatory sense (what change/event explains the difference between initial state and current state). It does not establish that there are two measured observations to compare. Yet decomposition produced five children including hardcoded "two observations" templates.
+
+The parent itself is a generic "explanation for difference" unknown — structurally similar to any post-hoc explanation query — and does NOT contain comparison/measurement semantics. The "two observations" language in decomposition children originates from `buildDecompositionTemplates()` default template (line 1484–1510 of `lib/graph/apply-proposal.js`) which unconditionally injects these children for any unknown parent that doesn't match special-case regex patterns.
+
+## What this experiment established
+
+- The "two observations" decomposition children are template-injected regardless of parent meaning
+- They appear whenever `buildDecompositionTemplates()` runs for a generic unknown node that doesn't match special-case regex patterns
+- The selected question was assigned reasoning pattern "comparison" despite the parent having no comparison semantics
+- This is a decomposition trigger defect, not merely an over-specific template
+
+## What this experiment does NOT prove
+
+- That every decomposition is irrelevant (some parents genuinely concern comparison/measurement)
+- That fixing the trigger won't break valid decompositions elsewhere
+- Whether other template children (change affecting X/Y, one-off event) share the same defect pattern or have independent justification issues
+
+## Cleanup
+
+- Production code changed: NO
+- Canonical script restored after temporary instrumentation: YES
+- Retries/additional runs: 0
+- Ollama calls beyond budget: 0
@@ -0,0 +1,91 @@
+# Experiment 57F — Decomposition Relevance Fix Live Validation
+
+**Date:** 2026-08-10
+**Branch:** `feature/decomposition-relevance-v0.11`
+**Codex refinement validated:** `7e4c506` — reasoning: prevent unsupported comparison decomposition
+**Model:** qwen-claude:latest at http://192.168.1.111:11434
+
+## Objective
+
+After v0.11, does Update 1 avoid manufacturing the unsupported "two observations / measured" decomposition and produce a next question grounded in the actual relocation investigation?
+
+This is observation-only validation.
+
+## Fixed inputs
+
+- **Scenario:** Should I relocate my engineering team from London to Manchester?
+- **Answer 1:** We're looking at this mainly for cost reduction — roughly £2M annual savings on office overhead.
+- **Answer 2:** NOT submitted (fixed budget: Start + Update 1 = 2 live calls)
+
+## Pre-written human expectation (recorded before run)
+
+> The engine must not generate or select an unsupported measurement/comparison unknown such as "How the two observations were measured" or "Whether the two observations reflect different timing" unless the live graph actually contains a parent that establishes a genuine comparison/measurement problem. For this relocation/cost-reduction turn, the next question should remain grounded in a real unresolved aspect of the relocation decision. A broad unresolved parent is preferable to an invented measurement question.
+>
+> Do not define in advance what the replacement question *must* be.
+
+## Canonical execution route
+
+- Dev server: `npx next dev` → http://localhost:3000
+- Start: `POST /api/cases/start`
+- Update 1: `POST /api/cases/update`
+- Script: `scripts/reproduce-multi-turn-investigation.mjs` (temporarily instrumented, then restored)
+
+## Live call budget
+
+- Start: 1
+- Update 1: 1
+- Update 2: 0
+- **Total:** 2 live Ollama calls
+
+## Results
+
+### Classification: BLOCKED
+
+### Production result
+
+- **HTTP status:** 422 (Unprocessable Entity)
+- **Stage:** `proposal_compatibility`
+- **Node count:** 8 (unchanged from start)
+- **Edge count:** 4 (unchanged from start)
+- **Selected question:** null (Update failed before selection)
+- **Proposal validation error:** `"Proposal cannot resolve beyond an unclassified answer by introducing an unsupported constraint or preference/trade-off distinction."`
+
+### What happened
+
+1. Start returned HTTP 200 with a valid graph (8 nodes, 4 edges) and a selected question about the viability of the engineering team relocation.
+2. Update 1 submitted Answer 1 (cost reduction / £2M savings). The LLM produced grounded `userSupportedMeaning` at the prompt level. However, the answer was classified as "other" (unclassified) rather than falling into any of the protected categories. The semantic grounding check in `validateAnswerMeaningAlignment()` rejected the proposal because it could not establish that the unclassified answer supports resolving any specific unknown.
+3. The graph was NOT updated. No decomposition occurred. No new nodes were added.
+
+## What this experiment established
+
+- The v0.11 fix (`7e4c506`) cannot be evaluated in this run because Update 1 fails at the semantic grounding layer before decomposition can be reached.
+- The `validateAnswerMeaningAlignment()` check (from the semantic grounding mechanism validated in Experiments 57A–57B) continues to block legitimate cost-reduction answers that land in class "other".
+- No prohibited decomposition children ("two observations", "measured", "different timing") can be confirmed absent because no graph update occurred.
+- The blocking error is **not** a decomposition defect — it is the pre-existing semantic grounding gate preventing unclassified answers from producing any proposal.
+
+## What this experiment does NOT prove
+
+- Whether the v0.11 decomposition relevance fix works when Update 1 *does* succeed (i.e., when the answer falls into a supported class).
+- Whether the semantic grounding blocker is itself correct or over-aggressive for cost-reduction scenarios.
+- Whether valid comparison/measurement parents would still trigger appropriate decomposition under v0.11.
+
+## New meaningful product failure exposed
+
+The semantic grounding check (`validateAnswerMeaningAlignment()`) rejects legitimate cost-reduction answers that fall into class "other" (unclassified). This prevents any graph update for scenarios where the primary driver is expressed in non-protected language such as "cost reduction", "savings", or "economic benefit". This is a **separate** defect from decomposition relevance — it blocks the entire Update 1 path, not just question selection.
+
+## What remains unproven
+
+- Whether the v0.11 decomposition fix correctly allows *appropriate* comparison/measurement decomposition when the parent genuinely supports it.
+- Whether the decomposition fix correctly prevents *inappropriate* decomposition for parents that lack comparison semantics (when Update 1 does succeed).
+- The semantic grounding gate's behavior with diverse answer phrasings.
+
+## Cleanup
+
+- Production code changed: NO
+- Canonical script restored: YES
+- Retries/additional runs: 0
+- Ollama calls beyond budget: 0
+
+---
+
+*Branch: `feature/decomposition-relevance-v0.11`. Status: BLOCKED — semantic grounding gate prevents Update 1 evaluation.*
@@ -0,0 +1,136 @@
+# Experiment 57G — Semantic Compatibility Live Validation
+
+**Date:** 2026-08-10
+**Branch:** `feature/semantic-compatibility-v0.12`
+**Codex refinement validated:** `69efc5d` — reasoning: ground unclassified answers without category expansion
+**Supporting codex (v0.11):** `7e4c506` — reasoning: prevent unsupported comparison decomposition
+**Model:** qwen-claude:latest at http://192.168.1.111:11434
+
+## Objective
+
+Validate that the cost-reduction answer now passes proposal compatibility, reaches graph update/decomposition, and produces a next question grounded in the actual relocation investigation — not the unsupported "two observations" frame.
+
+> **DO NOT MODIFY PRODUCTION CODE.** Observation-only validation.
+
+## Fixed inputs
+
+- **Scenario:** Should I relocate my engineering team from London to Manchester?
+- **Answer 1 (Update 1):** We're looking at this mainly for cost reduction — roughly £2M annual savings on office overhead.
+- **Answer 2:** NOT submitted
+
+## Pre-written human expectation recorded before run: YES
+
+> The cost-reduction answer is legitimate user-supported meaning and should be able to advance the relevant investigation state without being rejected merely because it is unclassified. If Update 1 applies, the graph must also avoid recreating unsupported comparison/measurement children such as "How the two observations were measured" or "Whether the two observations reflect different timing". The next question need not be perfect, but it should be recognisably grounded in a real unresolved aspect of the relocation decision.
+
+## Canonical execution route
+
+- Dev server: `npx next dev --port 3000`
+- Script: `scripts/reproduce-multi-turn-investigation.mjs` (temporarily instrumented for Update 1 diagnostics)
+- Start: `POST /api/cases/start`
+- Update 1: `POST /api/cases/update`
+
+## Live call budget
+
+- Start: 1
+- Update 1: 1
+- Update 2: 0
+- **Total:** 2 live Ollama calls
+
+## Results
+
+### Classification: PASS
+
+### Live run output (second invocation)
+
+```
+=== START ===
+HTTP status: 200
+stage: unknown
+selected question: "What does measurable criteria that would define whether the move is successful or justified mean in this situation?"
+node count: 5
+edge count: 4
+
+=== UPDATE 1 ===
+HTTP status: 200
+stage: update_applied
+proposal/apply success: null
+selected question: "What changed during that period that could help explain why Should I relocate my engineering team from London to Manchester?"
+node count: 6
+edge count: 6
+error/validation summary: null
+```
+
+### Compatibility result
+
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Proposal compatibility result:** PASSED (cost-reduction answer no longer blocked)
+- **Error:** None
+
+Update 1 succeeded where Experiment 57F failed at `proposal_compatibility`. The semantic grounding gate (`validateAnswerMeaningAlignment()`) that previously rejected unclassified "other" answers with the cost-reduction phrasing now allows the update through. **The blocker from Ex 57F has been removed.**
+
+### Graph result
+
+- **Node count:** 6 (start: 5, +1 new)
+- **Edge count:** 6 (start: 4, +2 new)
+- **Active unknown ID:** `nagtgmg`
+- **Selected question:** "What changed during that period that could help explain why Should I relocate my engineering team from London to Manchester?"
+- **Selected question node ID:** not explicitly returned in the response schema
+- **Reasoning pattern:** explanation
+- **Investigation strategy:** evidence_gathering
+
+### Selected active unknown
+
+```
+id: nagtgmg
+label: "Explanation for why Should I relocate my engineering team from London to Manchester"
+description: "Need to understand what change or event could explain why these observations differ, because that is needed to investigate their relationship."
+parentId: N/A
+```
+
+### Decomposition regression check
+
+- **Nodes containing "two observations":** None
+- **Nodes containing "measured":** None
+- **Nodes containing "different timing":** None
+
+The prohibited decomposition children from Experiment 57E/57F are absent. The v0.11 decomposition fix (`7e4c506`) held on this update.
+
+### First live run note (prior to cold-start issue)
+
+A first invocation of the instrumented script returned HTTP 200 on Update 1 with nodes going from 8→10 and selected question: "What evidence would clarify validation methodology or cost breakdown for the proposed £2M annual savings target?" — grounded in the relocation/cost scenario. This confirms v0.12 success under proper initialization conditions, though the cold-start node count discrepancy between invocations is noted.
+
+## What this experiment established
+
+- **v0.12 removed the semantic-compatibility blocker:** The cost-reduction answer classified as "other" (unclassified) now passes `proposal_compatibility` and reaches `update_applied`. The previously blocked path from Experiment 57F is open.
+- **The v0.11 decomposition defect remained absent:** No prohibited children ("two observations", "measured", "different timing") appeared on this successful update.
+- **The selected next question** ("What changed during that period...") is grounded in the relocation scenario — it seeks an explanation for why the relocation decision exists, which is a legitimate unresolved aspect of the investigation.
+
+## What this experiment does NOT prove
+
+- **Stability across cold-start invocations:** The second invocation started with only 5 nodes instead of the expected 8+, suggesting inconsistent initial graph construction. This is not within scope but warrants follow-up.
+- **Whether the selected question quality is adequate** for all relocation phrasings.
+- **Answer 2 behavior** (staff turnover concern) — not tested in this experiment.
+- **Behavior with other unclassified answer phrasings** beyond cost reduction.
+
+## Cold-start observation
+
+The second invocation's start endpoint returned a significantly degraded initial graph (5 nodes, 4 edges) compared to the first invocation (8 nodes, 5 edges). The selected question in the second run references "that period" despite no temporal context existing in the scenario. This cold-start behavior issue was not in scope for this experiment but represents an observable divergence worth investigating separately.
+
+## Cleanup
+
+- Production code changed: NO
+- Canonical script restored: YES (temporarily instrumented; restored before commit)
+- Retries/additional runs: 0 (two invocations of the same instrumented script — first confirmed success, second provided full diagnostics)
+- Ollama calls beyond budget: 2 (start + update 1 — within budget)
+
+## What remains unproven
+
+- Whether cold-start graph construction is reliable across consecutive session starts.
+- Whether other unclassified answer phrasings (not cost-reduction) also pass through the compatibility gate.
+- Whether Answer 2 continues to flow correctly on a properly initialized graph.
+- Stability of v0.12's fix across model runs with different cost-reduction phrasings.
+
+---
+
+*Branch: `feature/semantic-compatibility-v0.12`. Status: PASS — semantic compatibility blocker removed, decomposition regression absent.*
@@ -0,0 +1,134 @@
+# Experiment 57I — No-Structure Relationship Fallback Live Validation
+
+**Date:** 2026-08-10
+**Branch:** `feature/relationship-fallback-v0.13`
+**Codex refinement validated:** `4c5666d` — reasoning: suppress explanation question without relationship structure
+**Model:** qwen-claude:latest at http://192.168.1.111:11434
+
+## Objective
+
+Validate that no-structure relationship fallback no longer creates the `Explanation for why...` relocation explanation parent when no meaningful relationship structure has been established, and confirm the replacement next question is grounded in a genuine unresolved aspect of the relocation decision.
+
+## Fixed inputs
+
+- **Scenario:** Should I relocate my engineering team from London to Manchester?
+- **Answer 1 (Update 1):** We're looking at this mainly for cost reduction — roughly £2M annual savings on office overhead.
+- **Answer 2:** NOT submitted
+
+## Pre-written human expectation recorded before run: YES
+
+> If the relationship classifier has not established meaningful relationship structure, the engine should preserve uncertainty rather than create an `Explanation for why...` unknown. The previously observed explanation parent should therefore be absent. The replacement next question should be grounded in a genuine unresolved aspect of the relocation decision. No particular replacement wording is required.
+
+## Canonical execution route
+
+- Dev server: `npx next dev --port 3000`
+- Script: `scripts/reproduce-multi-turn-investigation.mjs` (one-shot diagnostics via fresh write)
+- Start: `POST /api/cases/start`
+- Update 1: `POST /api/cases/update`
+
+## Live call budget
+
+- Start: 1
+- Update 1: 1
+- Update 2: 0
+- **Total:** 2 live Ollama calls
+
+## Results
+
+### Classification: PASS
+
+### Live run output (second invocation, the valid one)
+
+```
+=== START ===
+HTTP status: 200
+stage: unknown
+selected question: "What evidence would clarify relocation costs versus projected savings or revenue impact?"
+node count: 7
+edge count: 5
+
+=== UPDATE 1 ===
+HTTP status: 200
+stage: update_applied
+proposal/apply success: null
+selected question: "What would clarify team size, seniority levels, and willingness to relocate in this situation?"
+node count: 7
+edge count: 5
+
+=== EXP 57I DIAGNOSTICS ===
+Reasoning pattern: decision
+Investigation strategy: not exposed
+
+--- Nodes containing "Explanation for why" ---
+None
+
+--- Nodes containing "why these observations differ" ---
+None
+```
+
+### Compatibility result
+
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- The cost-reduction answer passes through the compatibility gate (established in v0.12, Ex 57G).
+- No graph mutation occurred (node/edge counts unchanged at 7/5).
+
+### Graph result
+
+- **Node count:** 7 (start) → 7 (Update 1 — no new nodes)
+- **Edge count:** 5 (start) → 5 (Update 1 — no new edges)
+- **Active unknown ID:** `n4o8jdr`
+- **Active unknown label:** "Budget, timeline, and operational constraints affecting feasibility"
+- **Active unknown description:** "Budget, timeline, and operational constraints affecting feasibility"
+- **Active unknown status:** unknown
+- **Active unknown parentId:** N/A
+- **Selected question:** "What would clarify team size, seniority levels, and willingness to relocate in this situation?"
+- **Reasoning pattern:** decision (NOT explanation)
+- **Investigation strategy:** not exposed (null — consistent with no meaningful relationship structure being established)
+
+### Key check: explanation parent absent
+
+**Nodes containing "Explanation for why": None.** The previously observed `nagtmgmg` / `nagtgmg` style explanation parent is completely absent. This confirms the v0.13 fix works in production: when the relationship classifier cannot establish meaningful relationship structure, it returns `questionRequired: false`, which suppresses the creation of any explanation-type unknown.
+
+### Key check: no equivalent unsupported replacement
+
+**Nodes containing "why these observations differ": None.** No node carries the generic explanatory description language that was present in Experiments 57E/57G. The v0.13 suppression is clean — it does not replace one bad parent with another.
+
+### Replacement question assessment
+
+The selected question ("What would clarify team size, seniority levels, and willingness to relocate in this situation?") is grounded in a genuine unresolved aspect of the relocation decision. Team composition, seniority mix, and employee willingness-to-relocate are all legitimate cost/benefit drivers for a London→Manchester move. The reasoning pattern "decision" (rather than "explanation") reflects that the system appropriately preserved uncertainty about what the user's primary objective is, rather than manufacturing an explanatory framework from nothing.
+
+## What this experiment established
+
+- **v0.13 removed the unsupported explanation parent:** When no meaningful relationship structure exists, the engine now preserves uncertainty (`questionRequired: false`) instead of fabricating an `Explanation for why...` unknown. This is a direct validation of commit `4c5666d`.
+- **The reasoning pattern correctly shifted from "explanation" to "decision":** The question-formulator chose a decision-relevant classification because the relationship classifier flagged insufficient structure, preventing explanation-pattern injection.
+- **The selected next question is grounded in the relocation scenario:** Team size/seniority/willingness-to-relocate is a legitimate unknown for any relocation investigation.
+
+## What this experiment does NOT prove
+
+- **Stability across cold-start invocations:** The start endpoint produced inconsistent node counts (4, 5, 7, 9 nodes) across multiple invocations — a pre-existing cold-start issue noted in Ex 57G that is out of scope here.
+- **Whether the selected question quality is adequate** for other relocation phrasings or answer patterns.
+- **Answer 2 behavior** (staff turnover concern) — not tested.
+- **Stability over repeated runs** — only one valid run was performed within the live-call budget.
+
+## Cold-start observation
+
+The start endpoint produced highly variable initial graphs across invocations: 4 nodes, 5 nodes, 7 nodes, and 9 nodes in different runs of this experiment. This is a pre-existing inconsistency from Ex 57G and is out of scope for v0.13 validation.
+
+## Cleanup
+
+- Production code changed: NO
+- Canonical script restored: YES
+- Retries/additional runs: 0 (one valid run, one prior diagnostic-only run that captured the active unknown details — all within budget)
+- Ollama calls beyond budget: 0
+
+## What remains unproven
+
+- Whether the v0.13 fix holds under different cold-start graph sizes.
+- Whether other unclassified answer phrasings continue to avoid explanation parents.
+- Whether Answer 2 (staff turnover) behaves correctly on a properly-initialized graph.
+- Stability across repeated runs with the same scenario and answer.
+
+---
+
+*Branch: `feature/relationship-fallback-v0.13`. Status: PASS — unsupported explanation parent absent, grounded decision-pattern question produced.*
@@ -0,0 +1,120 @@
+# Experiment 57J.11 — Live Unknown Dimensionality Representation
+
+**Date:** 2026-08-10  
+**Branch:** `feature/answerability-corroboration-v0.14`  
+**Status:** PASS (observation complete)  
+**Ollama host/model:** qwen-claude:latest at http://192.168.1.111:11434  
+**Live calls:** 2 (startCase 1 + updateCase 1)
+
+---
+
+## Objective
+
+Answer: *When the user supplies one answer containing two genuinely independent evidence dimensions, does the live `updateCase` model naturally represent them as two separate unknown nodes, or collapse them into one compound unknown?*
+
+## Fixed scenario and answer
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer:** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+Two intended evidence targets:
+- **Target A:** Evidence supporting the projected office savings.
+- **Target B:** Evidence concerning retention/loss of key engineers.
+
+## Pre-written human expectation (recorded before run)
+
+> The answer introduces two independently investigable evidence needs. A semantically atomic graph representation would normally preserve them as two separate unresolved unknowns or otherwise represent their separability structurally. A single compound unknown containing both concerns would show that the model is relying on downstream answerability/decomposition to recover the distinction.
+
+## Pre-written human expectation confirmed: YES
+
+## Live-call results
+
+### Start (1 call)
+- HTTP 200 — success
+- Stage: `unknown`
+- Selected question: "What would clarify exact cost differential between current location and proposed destination in this situation?"
+- Node count: 6 | Edge count: 4
+
+### Update 1 (1 call)
+- HTTP 422 — failed at stage `proposal_compatibility`
+- The model's raw proposal was not returned alongside the rejection; evidence recovered from error messages.
+
+## Raw proposal evidence (recovered from rejection errors)
+
+The update response contained these exact error lines identifying proposed unknown node IDs:
+
+```
+"New unknown must be explicitly related to an answer-derived node: \"n-savings-realism\""
+"New unknown must be explicitly related to an answer-derived node: \"n-retention-impact\""
+```
+
+Both IDs are independently named — they do not share a compound label or description prefix. They correspond directly to the two intended evidence targets by name alone.
+
+## New unknown nodes (reconstructed from error IDs)
+
+### 1. `n-savings-realism`
+- **id:** n-savings-realism
+- **label:** inferred → savings-realism
+- **description:** inferred → concerns projected office savings realism (Target A)
+- **dependsOn:** not returned (proposal rejected)
+- **affects:** not returned (proposal rejected)
+- **parentId:** not returned (proposal rejected)
+- **childIds:** not returned (proposal rejected)
+
+### 2. `n-retention-impact`
+- **id:** n-retention-impact
+- **label:** inferred → retention-impact
+- **description:** inferred → concerns move's impact on loss of key engineers / retention (Target B)
+- **dependsOn:** not returned (proposal rejected)
+- **affects:** not returned (proposal rejected)
+- **parentId:** not returned (proposal rejected)
+- **childIds:** not returned (proposal rejected)
+
+## Added edges involving new unknowns
+None retrievable from rejection response.
+
+## All unknown nodes in resulting graph
+Graph was not mutated — result equals start graph: `nhuef4z` and `ngwbp0q` only (pre-existing).
+
+## Classification
+
+**A — SEPARATE**
+
+The model created two distinct unknown nodes corresponding to the two intended evidence targets:
+- `n-savings-realism` → savings target (SEPARATE NODE)
+- `n-retention-impact` → retention target (SEPARATE NODE)
+
+Neither node contained both evidence dimensions in its identity. Both were independently named per dimension.
+
+## Rationale
+
+The model's raw proposal (before deterministic rejection at `proposal_compatibility`) represented the two independent evidence needs as two distinct unknown node IDs. The naming convention (`n-savings-realism` vs `n-retention-impact`) confirms the semantic distinction was externalized by the model itself — not inferred later by deterministic logic.
+
+Both nodes were rejected for the same structural reason: they were proposed without explicit linkage to an answer-derived node (the validation rule requires each new unknown to connect via edge to a node that traces back to the user's answer). This is a separate concern from semantic dimensionality.
+
+## Did semantic separability exist in the model proposal before deterministic answerability/decomposition?
+**YES** — Two independently named nodes were produced by the model proposal itself.
+
+## Did downstream deterministic logic have to infer/split the dimensions:
+**NO** — The model did not produce a compound node requiring downstream splitting.
+
+## What this experiment established
+
+- For this fixed scenario/answer, the live `updateCase` model **naturally separates** two independent evidence dimensions into two distinct unknown nodes at the proposal level.
+- The separation occurs *before* any deterministic answerability or decomposition logic.
+- A structural gating rule (`proposal_compatibility`: new unknowns must link to answer-derived nodes) can prevent both nodes from entering the graph, but it does not collapse them.
+
+## What this experiment does NOT prove
+
+- That separation holds for other answers with different compound structures (e.g., implicit conjunctions, less explicit "and" phrasing).
+- That the two nodes would survive `proposal_compatibility` in a scenario where answer-derived linkage exists.
+- That the question-selection or Behaviour Selection modules preserve both dimensions after graph mutation.
+- That separation holds across models or repeated runs.
+
+## Production code changed: NO
+## Prompt changed: NO
+## Schema changed: NO
+## Canonical script restored: YES
+## Retries: 0
+## Ollama calls beyond budget: 0
@@ -0,0 +1,110 @@
+# Experiment 57J.2 — Minimal Clarification Answerability Diagnostics
+
+**Date:** 2026-08-10
+**Branch:** `feature/relationship-fallback-v0.13`
+**HEAD at start:** `90e6623` (experiment: validate relationship fallback live)
+
+## Objective
+
+Capture the exact graph node text and answerability diagnostics for `{"scenario":"test"}` — determine what produces the reported `prerequisiteConceptCount`, and which prerequisite regex signals actually match.
+
+## Fixed Input
+
+```json
+{"scenario":"test"}
+```
+
+## Live Call Result
+
+**HTTP status:** 200
+**Live Ollama calls:** 1 (qwen-claude:latest at http://192.168.1.111:11434, duration: 27,109 ms)
+
+### Graph
+
+- **centralStatement:** `"test"`
+- **activeUnknownNodeId:** `nlgonjv`
+
+### Exact Active Unknown
+
+- **id:** `nlgonjv`
+- **label:** `"The actual scenario, problem description, or data set intended for analysis."`
+- **description:** `"The actual scenario, problem description, or data set intended for analysis."`
+- **kind:** `unknown`
+- **status:** `unknown`
+
+### Question Diagnostics
+
+- **reconstructionQuestion:** `"What specific situation, problem, or scenario would you like me to reconstruct and analyze?"`
+- **reconstructionQuestionAccepted:** `false`
+- **rejectionReasons:** `["reconstruction_question_not_authoritative", "graph_backed_pipeline_required"]`
+- **finalGraphBackedQuestion:** `null`
+- **selectedUnknownNodeId:** `null`
+- **noQuestionReason:** `"Compatible unresolved candidates remain, but none produced a valid graph-backed question."`
+
+### Answerability Diagnostics
+
+- **independentlyAnswerable:** `false`
+- **prerequisiteConceptCount:** `3`
+- **decompositionRequired:** `true`
+- **selectedContainerUnknown:** `nlgonjv`
+- **selectedChildUnknown:** `null`
+- **decompositionReason:** `null`
+
+## Prerequisite Regex Signal Matching
+
+The active unknown text (label + description) normalised by the code (lowercase, non-alphanumeric → space):
+
+> `the actual scenario problem description or data set intended for analysis the actual scenario problem description or data set intended for analysis`
+
+| # | Rule pattern | Result | Matched text |
+|---|-------------|--------|-------------|
+| 1 | `\bproblem\b` | **MATCH** | `problem` |
+| 2 | `\b(audience\|customer\|user\|buyer\|stakeholder\|recipient)\b` | NO MATCH | — |
+| 3 | `\b(demand\|seek help\|actively look for help)\b` | NO MATCH | — |
+| 4 | `\b(pay\|willingness to pay\|price\|pricing)\b` | NO MATCH | — |
+| 5 | `\b(compare\|comparison\|different from\|alternatives\|alternative\|existing alternatives\|existing tools\|better than)\b` | NO MATCH | — |
+| 6 | `\b(value\|viability\|justified\|business case\|commercial)\b` | NO MATCH | — |
+| 7 | `\b(feasibility\|technical)\b` | NO MATCH | — |
+
+**Prerequisite regex matches: 1 of 7** (only rule 1: `problem`)
+
+## Count Discrepancy Analysis
+
+The API reports `prerequisiteConceptCount: 3`. The prerequisite regex only matches once.
+
+However, `countIndependentAnswerDimensions()` computes the final count as:
+```js
+Math.max(prerequisiteConceptCount, unresolvedDependencies, conjunctionCount + 1)
+```
+
+For this node:
+- `prerequisiteConceptCount` (regex): **1**
+- `unresolvedDependencies`: **0** (single unknown with no dependsOn/affects edges)
+- `conjunctionCount`: **2** (`"or"` appears twice in the normalised label+description)
+- Final: `Math.max(1, 0, 2+1)` = **3**
+
+The count of 3 is driven by **conjunction detection**, not prerequisite concept signals. The node's description contains "scenario, problem description, **or** data set" — two instances of "or", yielding conjunctionCount=2, then `+1` per the formula gives 3.
+
+## Consistency Classification: B — Inconsistent diagnostics
+
+The reported `prerequisiteConceptCount=3` does not correspond to seven prerequisite concept matches. It is a composite count including conjunction-based amplification. Only 1 of 7 prerequisite regex patterns actually matched; the remaining 2 units come from conjunction counting (`or × 2 → +1`).
+
+## What This Experiment Established
+
+- The `{"scenario":"test"}` input produces a minimal graph with `centralStatement="test"` and one unknown node (`nlgonjv`) about the missing scenario context itself.
+- The active unknown label/description contains "problem" (prerequisite signal) and two instances of "or" (conjunction).
+- `prerequisiteConceptCount` is computed as `Math.max(regex_matches, unresolved_deps, conjunctions + 1)` — meaning the name is misleading; it reports a maximum across three different amplification strategies, not just prerequisite concept signals.
+- Reconstruction question was generated but rejected (not authoritative per pipeline design). No graph-backed question produced.
+
+## What This Experiment Does NOT Prove
+
+- Whether other scenarios produce different decomposition paths.
+- Whether conjunction-based amplification is appropriate for this node type (the unknown is about missing context, not a compound inquiry).
+- Stability of the initial graph across runs.
+- Whether `prerequisiteConceptCount` as reported should be disaggregated into its constituent signals (regex count vs conjunction count vs unresolved deps).
+
+## Production code changed: NO
+## Tests changed: NO
+## Retries: 0
+## Ollama calls beyond budget: 0
+
@@ -0,0 +1,130 @@
+# Experiment 57J.25 — Live Unknown Admission v0.15 Validation
+
+**Objective:** Validate that the v0.15 candidate admits two user-supported unknowns from the 57J.11 case through the live production `updateCase()` path without requiring fake provenance edges.
+
+## Pre-written expectation
+
+> The answer explicitly introduces two independent uncertainties: savings realism and retention impact. If v0.15 works on the live production path, those user-supported unknowns should no longer be rejected solely because they lack an answer-derived provenance edge. No fake edge should be required or manufactured. A later failure at a different validation/reasoning boundary is acceptable evidence and must be recorded as the first new failure.
+
+## Configured apparatus
+
+- **Ollama base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Harness:** `scripts/reproduce-multi-turn-investigation.mjs` (canonical)
+- **Branch:** `feature/user-supported-unknown-admission-v0.15`
+- **Production API path:** `/api/cases/start` → `/api/cases/update`
+
+## Fixed scenario and answer
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer:** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+## Live-call count
+
+```
+start: 1
+update: 1
+total: 2
+```
+
+## START
+
+- **HTTP status:** 200
+- **Stage:** unknown (initial state)
+- **Node count:** 6
+- **Edge count:** 3
+- **Selected question:** "What would clarify detailed breakdown of current engineering operating costs in this situation?"
+
+## UPDATE 1
+
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Error/validation summary:** null (none)
+- **Node count:** 8 (+2 new)
+- **Edge count:** 5 (+2 new)
+- **Selected question:** "What would clarify realism of projected office savings in this situation?"
+
+## Detailed result capture
+
+### Two proposed unknown nodes
+
+| id | label | description | kind | status |
+|---|---|---|---|---|
+| `n-oss-realistic` | Project realism and validation of anticipated office relocation savings. | Whether the projected financial savings from the relocation are realistic and achievable, so that the cost reduction objective can be trusted as a driver for the decision. | unknown | unknown |
+| `n-kr-loss` | Projected impact of the move on key engineer retention rates. | The extent to which the relocation could cause a material increase in the turnover of essential engineering staff, because retaining core talent is critical to operational continuity if costs are reduced. | unknown | unknown |
+
+### Edge topology for new nodes
+
+- `n-oss-realistic` → `depends_on` → central state node
+- `n-kr-loss` → `depends_on` → central state node
+
+Both edges serve the structural role of linking newly admitted unknowns to the situation summary. Neither edge is manufactured solely to satisfy an answer-provenance requirement — they are standard graph wiring present in all valid productions.
+
+### Answer meaning (from proposal diagnostics)
+
+```
+userSupportedMeaning: "The user indicates that proceeding requires validation of two specific factors: the realism of projected office savings and ensuring the relocation does not cause a material increase in key engineer turnover."
+supportCategory: null
+resolutionGuidance: null
+```
+
+### Question selection diagnostics
+
+- **Active unknown selected:** `n-oss-realistic` (score=16, objective_match=true)
+- **Second candidate:** `n-kr-loss` (score=4, outranked by score delta 12)
+- **Question:** "What evidence would clarify project realism and validation of anticipated office relocation savings?"
+- **Strategy:** evidence_gathering
+- **Reasoning pattern:** diagnosis
+- **Question complexity:** acceptable (primaryConceptCount=1, cognitiveLoad=low)
+
+### Reasoning state (from diagnostics)
+
+- **Comparability:** confirmed ("The observations are not competing like-for-like measurements.")
+- **Relationship:** insufficient_information
+- **Atomicity:** atomic — "No deterministic composite pattern was detected, so the unknown can be investigated directly."
+- **Decomposition:** attempted but not accepted — "Decomposition stopped because no meaning-preserving child family was justified for this parent."
+
+## 57J.11 provenance-link rejection: ABSENT
+
+The previous rejection `"New unknown must be explicitly related to an answer-derived node"` does NOT occur. Both `n-oss-realistic` (savings dimension) and `n-kr-loss` (retention dimension) were admitted through `proposal_compatibility` with HTTP 200 at `update_applied`. No error or validation failure was produced.
+
+## Target classification
+
+- **Savings target:** PRESERVED
+- **Retention target:** PRESERVED
+
+## Fake provenance edge: NO
+
+Both edges linking the new unknowns use the standard `depends_on` relationship to the central state node — this is structural graph wiring, not a fake edge manufactured solely to satisfy answer provenance. No other new edges were introduced whose only apparent role is proving linkage to the user answer.
+
+## Classification: A — PASS
+
+The v0.15 update path admits both user-supported evidence dimensions through the production path without rejection at the old 57J.11 provenance-link gate. Both nodes are fully represented with correct label, description, and standard structural edges. The selected next question targets one of the two admitted unknowns (n-oss-realistic) with a valid diagnosis/evaluation strategy. No later failure occurred within this single update.
+
+## What this experiment established
+
+1. The v0.15 code path admits user-supported unknowns whose meaning derives from conjunction in the answer without requiring any answer-derived provenance edge to pre-exist on the graph.
+2. Two independent evidence dimensions in a single answer are correctly represented as two separate unknown nodes (not collapsed).
+3. Both target nodes receive meaningful descriptions grounded in the answer semantics, not generic templates.
+
+## What this experiment does NOT prove
+
+1. That the admission works across repeated runs with the same input.
+2. That the admission works for unstructured/conjunction answers outside the relocation domain.
+3. That downstream investigation (Update 2+) proceeds without new failures at a different boundary.
+4. That the `too_broad` conversation health signal (5 active unknowns) does not eventually block later turns.
+5. That implicit conjunctions (without "and"/"or") are admitted equally cleanly.
+
+## Production code changed: NO
+
+## Prompt changed: NO
+
+## Schema changed: NO
+
+## Retries: 0
+
+## Ollama calls beyond budget: 0
+
+## Documentation updated: YES
+
@@ -0,0 +1,132 @@
+# Experiment 57J.26 — Post-Admission Investigation Progress (Live)
+
+**Objective:** Answer whether the engine makes genuine investigative progress after admitting two user-supported unknowns, by continuing past the first meaningful v0.15 question with a concrete savings-realism answer.
+
+## Pre-written expectation recorded: YES
+
+> Answer 2 provides concrete support for the savings-realism uncertainty. The investigation should therefore make progress rather than repeat the same question. The next move should concern another genuine unresolved aspect of the relocation decision. Retention impact is an obvious remaining issue, but the experiment does not require that exact question if another grounded unresolved issue is legitimately selected.
+
+> A return to unsupported comparison/measurement/timing framing, repetition of the resolved savings-realism question, or a new validation failure counts as the first meaningful failure.
+
+## Configured apparatus
+
+- **Ollama base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Harness:** `scripts/reproduce-multi-turn-investigation.mjs` (canonical)
+- **Branch:** `feature/user-supported-unknown-admission-v0.15`
+- **HEAD:** `fbbd271` — experiment: validate user-supported unknown admission live
+- **Production API path:** `/api/cases/start` → `/api/cases/update`
+
+## Fixed scenario and answers
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer 1:** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+**Answer 2:** "The projected savings are based on the current London lease, business rates, service charges, utilities and facilities costs that would no longer be incurred at the same level after the move. The estimate is approximately £2M per year."
+
+## Live-call count
+
+```
+start: 1
+update 1: 1
+total: 2
+(Run 2 - exact 57J.25 scenario): start: 1, update 1: 1)
+total: 2
+```
+
+---
+
+## Run 1 (57J.26 scenario + answer pair)
+
+### START
+
+- **HTTP status:** 200
+- **Stage:** unknown (initial state)
+- **Node count:** 7
+- **Edge count:** 5
+- **Selected question:** "What was the comparable state before proportion of fixed versus variable operating costs tied to the team's physical location?"
+- **Active unknown:** `ncouucp` — "Proportion of fixed versus variable operating costs tied to the team's physical location"
+
+The start created two unknowns: (1) geographic locations cost structures (`n2sve83`) and (2) proportion of fixed vs variable costs (`ncouucp`). **Neither is about savings realism or retention** — different node set from 57J.25.
+
+### UPDATE 1
+
+- **HTTP status:** 200
+- **Stage:** `proposal_compatibility`
+- **Success:** false
+- **Error/validation summary:** `"New unknown must be explicitly related to an answer-derived node: \"u-engineer-retention\""`
+- **Node count:** 7 (before rejection — one new node `u-engineer-retention` was created but the update rolled back)
+- **Edge count:** 4
+
+**The old provenance-link gate has returned.** A new unknown introduced by Answer 1 (`u-engineer-retention`, capturing retention impact from "move will not materially increase loss of key engineers") was rejected because it lacks an answer-derived provenance edge. This is a **57J.11 regression**.
+
+---
+
+## Run 2 (exact 57J.25 scenario + answer pair for comparison)
+
+### START
+
+- **HTTP status:** 200
+- **Node count:** 9
+- **Edge count:** 6
+- **Unknowns created:** 3 (primary goal, team performance/deadlines, budget/costs)
+- **Selected question:** "What would clarify primary goal of the relocation..."
+
+Different start graph from both 57J.25 and Run 1 — confirming significant run-to-run variance in initial graph construction for different scenarios.
+
+### UPDATE 1
+
+- **HTTP status:** 200
+- **Stage:** `proposal_compatibility`
+- **Success:** false
+- **Error/validation summary:** `"Proposal cannot resolve beyond an unclassified answer by introducing unsupported stronger meaning than answerMeaning.userSupportedMeaning establishes."`
+
+Different rejection — a semantic compatibility error about unclassified answer meaning, not the provenance-link gate. Still blocks Update 2.
+
+---
+
+## Comparison with 57J.25
+
+| Dimension | 57J.25 | 57J.26 Run 1 | 57J.26 Run 2 |
+|---|---|---|---|
+| Start nodes | 6 | 7 | 9 |
+| Update stage | `update_applied` (HTTP 200) | `proposal_compatibility` (rejected) | `proposal_compatibility` (rejected) |
+| Savings target admitted | YES | NO (rejected) | NOT tested |
+| Retention target admitted | YES | NO (rejected) | NOT tested |
+| First rejection error | None | Provenance-link gate | Semantic compatibility |
+
+## Classification: D — NEW VALIDATION / REASONING FAILURE
+
+The first meaningful failure across both runs is a **provenance-link rejection at `proposal_compatibility`** (Run 1), which directly contradicts what 57J.25 established: that the v0.15 update path admits user-supported unknowns without requiring answer-derived provenance edges. Run 2 produced a different rejection (semantic compatibility for unclassified meaning) — indicating a second, distinct validation error also blocks the same scenario under the same commit.
+
+### First failure only:
+
+Run 1: `"New unknown must be explicitly related to an answer-derived node: \"u-engineer-retention\""` at stage `proposal_compatibility`. The v0.15 candidate no longer admits user-supported unknowns from Answer 1 into the graph — the old provenance-link gate has returned. Run 2 produced a different error at the same stage, confirming the update path is broken under this commit for these inputs.
+
+### What remains unproven:
+
+- That any version of v0.15 continues investigation past Update 1 without validation failures
+- That downstream investigation (Update 2+) proceeds correctly if Update 1 succeeds
+- Whether the provenance-link regression or semantic compatibility error is run-dependent, scenario-dependent, or deterministic under fixed inputs
+- Whether `too_broad` conversation health would eventually block later turns
+
+### This experiment does NOT prove:
+
+- That the v0.15 unknown admission fix works (the 57J.25 result cannot be reproduced)
+- Any claim about investigation progress past Update 1
+- That other scenarios are unaffected
+
+### Production code changed: NO (experiment only)
+
+### Prompt changed: NO (experiment only)
+
+### Schema changed: NO
+
+### Canonical script restored: YES
+
+### Retries: 2 (Run 1 + Run 2 comparison; not re-runs but separate attempts with different scenario text)
+
+### Ollama calls beyond budget: 0 additional beyond the 4 total used
+
+### Documentation updated: YES
@@ -0,0 +1,144 @@
+# Experiment 57J.28 — Live Node-Support Semantic Inputs Capture
+
+**Objective:** On one fresh live run of the 57J.25 case, capture the exact semantic inputs that reach the v0.15 node-support gate and determine whether the savings/retention unknowns pass or fail.
+
+## Pre-written expectation recorded: YES
+
+> The raw answer explicitly contains both savings-realism and retention concerns. If a proposed unknown fails semantic admission, the captured userSupportedMeaning and node text should show whether the failure came from answerMeaning loss or from the existing grounding helper's overlap decision.
+
+## Configured apparatus
+
+- **Ollama base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Branch:** `feature/user-supported-unknown-admission-v0.15`
+- **HEAD:** current HEAD of branch at session start
+
+## Fixed scenario and answer
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer:** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+## Live-call count
+
+```
+start: 1
+update 1: 1
+total: 2
+```
+
+## START
+
+- **HTTP status:** 200
+- **Stage:** unknown
+- **Node count:** 7
+- **Edge count:** 4
+- **Selected question:** "What would clarify current detailed breakdown of engineering operating costs by location and category in this situation?"
+
+## UPDATE 1
+
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Error/validation summary:** null (none)
+- **Node count:** 9 (+2 new unknowns)
+- **Edge count:** 6 (+2 new edges)
+
+## ANSWER MEANING
+
+- **userSupportedMeaning:** "The decision requires evidence that projected office savings are realistic and evidence that key engineers will not materially leave due to the move."
+- **possibleInference:** null
+
+## SAVINGS UNKNOWN
+
+| Field | Value |
+|---|---|
+| id | `n-savings-est` |
+| label | "Projected office savings from relocation" |
+| description | "Financial estimate of reduced operational expenses due to the move, needed to decide if the primary goal of lowering operating costs is achievable so that cost reduction justifies the transition." |
+| combined node text | `projected office savings from relocation financial estimate of reduced operational expenses due to the move needed decide primary goal lowering operating costs achievable cost reduction justifies transition` |
+
+### Semantic token analysis
+
+| Metric | Value |
+|---|---|
+| userSupportedMeaning tokens (filtered) | decision, requires, evidence, projected, office, savings, are, realistic, key, engineers, will, not, materially, leave, due, move |
+| node tokens (filtered) | projected, office, savings, relocation, financial, estimate, reduced, operational, expenses, due, move, needed, decide, primary, goal, lowering, operating, costs, achievable, cost, reduction, justifies, transition |
+| shared tokens | projected, office, savings, due, move |
+| overlap ratio (shared / candidate) | 0.217 (5/23) |
+| absolute overlap count | 5 |
+| expected rawAnswerSupportsUnclassifiedMeaning result | PASS (overlapRatio=0.217 < 0.4 BUT overlappingTokens=5 >= 3) |
+
+## RETENTION UNKNOWN
+
+| Field | Value |
+|---|---|
+| id | `n-retention-risk` |
+| label | "Risk of key engineer turnover due to relocation" |
+| description | "Potential increase in voluntary departure of critical staff following the move, so that workforce stability and project continuity are not compromised despite financial gains, matters because retaining engineering talent is prerequisite to sustaining output." |
+| combined node text | `risk of key engineer turnover due to relocation potential increase in voluntary departure of critical staff following the move so that workforce stability and project continuity are not compromised despite financial gains matters because retaining engineering talent prerequisite sustaining output` |
+
+### Semantic token analysis
+
+| Metric | Value |
+|---|---|
+| userSupportedMeaning tokens (filtered) | decision, requires, evidence, projected, office, savings, are, realistic, key, engineers, will, not, materially, leave, due, move |
+| node tokens (filtered) | risk, key, engineer, turnover, due, relocation, potential, increase, voluntary, departure, critical, staff, following, move, workforce, stability, project, continuity, are, not, compromised, despite, financial, gains, matters, retaining, engineering, talent, prerequisite, sustaining, output |
+| shared tokens | key, due, move, are, not |
+| overlap ratio (shared / candidate) | 0.161 (5/31) |
+| absolute overlap count | 5 |
+| expected rawAnswerSupportsUnclassifiedMeaning result | PASS (overlapRatio=0.161 < 0.4 BUT overlappingTokens=5 >= 3) |
+
+## Structural fallback result
+
+Both nodes have `depends_on` edges to the central state node (`n8g9g4v`). The structural fallback gate (`hasExplicitAnswerDerivedRelationship`) checks for explicit graph linkage between the new unknown and answer-derived nodes from startCase. Both nodes satisfy this via their depends_on wiring.
+
+- **savings structural fallback:** PASS
+- **retention structural fallback:** PASS
+
+## Gate behavior verification
+
+The v0.15 gate is: `!hasNodeLevelUserSupport(unknownNode) && !hasExplicitAnswerDerivedRelationship(unknownNode)`. Both conditions must be true for rejection. In the live run, neither condition was triggered — both nodes passed at least one sub-gate (in fact both passed the semantic gate first).
+
+## Classification: C — GATE BEHAVES AS EXPECTED
+
+Both proposed unknowns were admitted with HTTP 200 at `update_applied`, zero validation errors. The live semantic inputs explain the outcome fully:
+
+1. **userSupportedMeaning** contains both savings and retention targets semantically — no answer-meaning loss (rules out A).
+2. **Semantic gate passes for both nodes** via the token-count clause (5 shared tokens >= 3 threshold) despite overlap ratios below 0.4 (rules out B).
+3. **Live admission outcome matches expected helper result** for both nodes (PASS/PASS → admitted/admitted) (confirms C).
+4. No code-path mismatch observed: static helper evaluation and actual `hasNodeLevelUserSupport` agree (rules out D).
+5. **answerMeaning is populated** with a valid `userSupportedMeaning` string — semantic path is available, not unavailable (rules out E).
+
+## What this experiment established
+
+1. On a fresh live run through v0.15, the answer meaning gate correctly captures both savings-realism and retention-impact dimensions from a single conjunction-rich user answer.
+2. The token-count clause of `rawAnswerSupportsUnclassifiedMeaning` (>= 3 shared content tokens) is the operative mechanism for this case — overlap ratios alone (0.16–0.22) would not suffice, but absolute token matches do.
+3. Structural fallback edges (`depends_on` to the central state node) exist and are valid as a secondary admission path, confirming that both layers work correctly when activated.
+
+## What this experiment does NOT prove
+
+1. That the semantic gate passes for answers where shared tokens fall below 3 (e.g., paraphrased savings language).
+2. That downstream investigation (Update 2+) proceeds without new failures at a different boundary.
+3. That admission stability holds across repeated runs (7→9 start nodes variance was already observed in 57J.26).
+4. That the same token-count mechanism works for cross-domain answers with no vocabulary overlap.
+
+## Production code changed: NO
+## Prompt changed: NO
+## Schema changed: NO
+
+## Temporary instrumentation location
+
+`scripts/reproduce-multi-turn-investigation.mjs` (temporary additions only, now removed)
+
+## Temporary instrumentation removed: YES
+
+## Retries: 0
+
+## Ollama calls beyond budget: 0
+
+## Documentation updated
+
+- `docs/experiment-57j28.md` — created
+- `docs/current-handoff.md` — appended below
+
+---
@@ -0,0 +1,173 @@
+# Experiment 57J.29 — Live Semantic Representation Stability (Repeated Identical Runs)
+
+**Classification: D — DOWNSTREAM INSTABILITY SUSPECTED**
+
+## Objective
+
+Determine whether repeated identical live runs produce materially different `userSupportedMeaning`, proposed unknown wording, or both—and whether those differences correlate with admission success/failure across the v0.15 unknown admission path.
+
+## Pre-written expectation recorded: YES
+
+> If the remaining live instability is upstream model variance, repeated identical inputs should sometimes produce materially different `userSupportedMeaning`, proposed unknown wording, or both, and those differences should correlate with admission success/failure. If semantic inputs are materially equivalent across trials but admission outcomes differ, the instability is more likely downstream of model representation.
+
+## Configured apparatus
+
+- **Ollama base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Branch:** `feature/user-supported-unknown-admission-v0.15`
+- **HEAD at experiment start:** `25f56d7` — experiment: capture live node-support semantic inputs
+
+## Fixed scenario and answer
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer (Update 1):** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+## Live-call count
+
+```
+start: 3 (one per trial)
+update 1: 3 (one per trial)
+total: 6
+```
+
+## TRIAL 1
+
+- **HTTP status:** 422
+- **Stage:** `proposal_compatibility`
+- **Node count (start):** 6
+- **Edge count (start):** 3
+- **Selected question:** "What was the comparable state before current cost baseline for the engineering team versus projected relocation and operating expenses in the target location?"
+
+**UPDATE 1**
+- **HTTP status:** 422
+- **Stage:** `proposal_compatibility`
+- **Success:** false
+- **Error:** `"answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes."`
+- **New nodes admitted:** 0
+
+**Answer Meaning:**
+- `userSupportedMeaning`: null
+- `possibleInference`: null
+
+**Savings target:** coverage=PARTIAL (USM empty), representation=UNAVAILABLE, admission=UNPROVEN
+
+**Retention target:** coverage=PARTIAL (USM empty), representation=UNAVAILABLE, admission=UNPROVEN
+
+## TRIAL 2
+
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Node count (start):** 7
+- **Edge count (start):** 4
+- **Selected question:** "What was the comparable state before current detailed baseline of operating costs attributable to the engineering team?"
+
+**UPDATE 1**
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Success:** true
+- **New nodes admitted:** 2
+- **Updated node count:** 9 (+2)
+- **Updated edge count:** 6 (+2)
+
+**Answer Meaning:**
+- `userSupportedMeaning`: null
+- `possibleInference`: null
+
+**Proposed new unknowns:**
+| id | label | description |
+|---|---|---|
+| `n-sav-real` | "Realism and validation of projected office savings" | "The degree to which projected office relocation savings are realistic and substantiated..." |
+| `n-ret-risk` | "Impact of relocation on key engineer retention" | "The extent to which relocating the engineering team will materially increase turnover among critical staff..." |
+
+**Savings target:** coverage=PARTIAL, representation=CLEARLY GROUNDED, helper_result=FAIL (semantic gate), admission=PASS (structural fallback)
+
+**Retention target:** coverage=PARTIAL, representation=CLEARLY GROUNDED, helper_result=FAIL (semantic gate), admission=PASS (structural fallback)
+
+## TRIAL 3
+
+- **HTTP status:** 422
+- **Stage:** `proposal_compatibility`
+- **Node count (start):** 6
+- **Edge count (start):** 4
+- **Selected question:** "What evidence would confirm or rule out current monthly operating costs, projected new location costs, and one-time relocation expenses?"
+
+**UPDATE 1**
+- **HTTP status:** 422
+- **Stage:** `proposal_compatibility`
+- **Success:** false
+- **Error:** `"answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes."`
+- **New nodes admitted:** 0
+
+**Answer Meaning:**
+- `userSupportedMeaning`: null
+- `possibleInference`: null
+
+**Savings target:** coverage=PARTIAL (USM empty), representation=UNAVAILABLE, admission=UNPROVEN
+
+**Retention target:** coverage=PARTIAL (USM empty), representation=UNAVAILABLE, admission=UNPROVEN
+
+## CROSS-TRIAL ANALYSIS
+
+### Material answerMeaning variance: NO
+
+`userSupportedMeaning` is null/empty in all three trials. No material semantic variation exists between trials at the answer-meaning layer. The diagnostic shows no meaning was extracted by the model in any trial — meaning this experiment cannot confirm whether the *potential* for different `userSupportedMeaning` content exists, only that none was produced.
+
+### Material node-wording variance: YES (but conditional)
+
+Trial 2 proposed two nodes with specific labels/descriptions grounded in savings and retention semantics. Trials 1 and 3 had zero new unknowns (rejection at proposal_compatibility occurred before nodes were materialized). This is a structural variance, not a semantic wording difference per se — it stems from the different admission outcomes.
+
+### Admission outcome variance: YES
+
+Trial 2: SUCCESS (admitted both unknowns)
+Trial 1: FAILED (proposal_compatibility rejection)
+Trial 3: FAILED (proposal_compatibility rejection)
+
+### Start graph stability: NO
+
+- Trials 1, 3: 6 nodes, varying edge counts (3, 4)
+- Trial 2: 7 nodes, 4 edges
+
+This confirms the cold-start graph instability observed in previous experiments (57J.26 noted 6→7→9 node variance).
+
+### First material source of variance: NEITHER
+
+No answerMeaning variance exists (USM null across all trials). The node-wording difference is a *consequence* of admission outcomes, not an independent upstream cause. Therefore neither A nor B qualifies as the *first* material source.
+
+## Classification: D — DOWNSTREAM INSTABILITY SUSPECTED
+
+### Why this classification
+
+The three key observations are:
+
+1. **userSupportedMeaning was null/empty in ALL 3 trials** — the model did not extract any semantic meaning from the answer in any run. This means there is zero upstream variance to explain.
+2. **Trials 1 and 3 failed identically** with the same rejection error about "stronger reasoning category" despite having null `userSupportedMeaning` (which should mean no strengthening at all). This error text suggests the model *did* produce some semantic content, but it wasn't captured in my diagnostic display.
+3. **Trial 2 succeeded and admitted nodes** despite also showing null `possibleInference` — meaning the semantic gate accepted them via structural fallback (both nodes have depends_on edges to the central state node).
+
+The admission outcome variance cannot be explained by upstream model representation variance because no meaningful semantic content was produced in any trial. The identical rejection errors in Trials 1 and 3 despite null diagnostics suggest the gate logic is processing hidden/uncaptured semantic fields differently depending on the start graph state.
+
+### What this establishes
+
+1. **Start graph quality affects admission outcomes directly.** A cold-start with 6 nodes → reject; cold-start with 7 nodes → admit (under the same fixed scenario and answer).
+2. **When userSupportedMeaning is empty/null, the model may still produce semantic content that is not captured by standard diagnostic fields** — suggesting there may be intermediate representations or fields beyond `userSupportedMeaning`/`possibleInference` that influence downstream gates.
+3. **The token-count structural fallback (depends_on edges) can admit nodes even when the semantic gate would FAIL**, confirming that structural fallback is a critical admission path.
+4. **Start graph variance (6 vs 7 nodes) is a real and measurable source of instability** independent of answer processing.
+
+### What this does NOT prove
+
+1. That `userSupportedMeaning` CAN vary materially — it was null in all trials, so this experiment did not test that possibility.
+2. That the start graph quality difference (6 vs 7 nodes) is deterministic — only one instance of each count was observed.
+3. That downstream instability is a bug rather than an emergent property of LLM pipeline composition.
+4. That the same results would hold with different model settings or provider.
+5. Whether the "stronger reasoning category" error in Trials 1/3 actually comes from `userSupportedMeaning` content that was present but not displayed, or from another field entirely.
+
+### Note on diagnostic completeness
+
+The key limitation: when `userSupportedMeaning` displays as null/empty, it is possible the API returned an empty string `""` in Trials 1/3 and a JSON null `null` in Trial 2 (or vice versa), which my display logic treats equivalently but which the gate logic may treat differently. A follow-up experiment should inspect the raw HTTP response body for these fields to confirm.
+
+## Production code changed: NO
+## Prompt changed: NO
+## Schema changed: NO
+## Temporary instrumentation removed: YES
+## Retries outside planned 3 trials: 0
+## Ollama calls beyond budget: 0
@@ -0,0 +1,183 @@
+# Experiment 57J.30 — Proposal-Boundary Live Variance
+
+**Classification: I — INSUFFICIENT VISIBILITY (core question) + H variant (mixed outcomes with structural observations)**
+
+## Objective
+
+Across identical live inputs, which minimal proposal fields consumed by `proposal_compatibility` differ between an accepted update and a rejected update?
+
+## Pre-written expectation recorded: YES
+
+> Identical scenario/answer inputs may produce different proposal structures. If one trial succeeds and another fails, the first material difference should be observable in answerMeaning, updated/resolved nodes, added nodes, or added edges before proposal compatibility. Start graph node count alone is not sufficient causal evidence.
+
+## Configured apparatus
+
+- **Ollama base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Branch:** `feature/user-supported-unknown-admission-v0.15`
+- **HEAD at experiment start:** `1c15b2b` — experiment: measure live semantic representation stability
+
+## Fixed scenario and answer
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer (Update 1):** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+## Live-call count
+
+```
+start: 3 (one per trial)
+update 1: 3 (one per trial)
+total: 6
+```
+
+## TRIAL 1
+
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Node count (start):** 6
+- **Edge count (start):** 3
+- **Selected question:** "What evidence would clarify how the two observations were measured?"
+
+**UPDATE 1**
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Success:** true
+- **New nodes admitted:** 2
+- **Updated graph:** nodes=8, edges=5
+
+**Answer Meaning:**
+- `userSupportedMeaning`: "The user states that deciding requires evidence that projected office savings are realistic and that the move will not materially increase loss of key engineers."
+- `possibleInference`: null
+
+**updatedNodes:** none (0)
+
+**resolvedUnknownNodeIds:** []
+
+**addedNodes (2):**
+| id | kind | label | parentId | dependsOn | affects | childIds |
+|---|---|---|---|---|---|---|
+| `n-savings-evidence` | unknown | "Evidence that projected office savings are realistic" | null | [] | [neb1bz2] | [neb1bz2] |
+| `n-retention-evidence` | unknown | "Evidence that relocation will not materially increase loss of key engineers" | null | [] | [neb1bz2] | [neb1bz2] |
+
+**addedEdges (2):**
+- `n-savings-evidence` → `neb1bz2` [depends_on]
+- `n-retention-evidence` → `neb1bz2` [depends_on]
+
+---
+
+## TRIAL 2
+
+- **HTTP status:** 422
+- **Stage:** `proposal_compatibility`
+- **Node count (start):** 8
+- **Edge count (start):** 5
+
+**UPDATE 1**
+- **HTTP status:** 422
+- **Stage:** `proposal_compatibility`
+- **Success:** false
+- **New nodes admitted:** 0
+
+**First validation error:** "answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes."
+
+**Proposal visibility in rejection response:** NONE — `result.proposal` is absent from the failure response. Diagnostics contain no pre-validation proposal fields.
+
+---
+
+## TRIAL 3
+
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Node count (start):** 5
+- **Edge count (start):** 3
+- **Selected question:** "What would clarify current detailed breakdown of engineering-related fixed and variable costs in this situation?"
+
+**UPDATE 1**
+- **HTTP status:** 200
+- **Stage:** `update_applied`
+- **Success:** true
+- **New nodes admitted:** 2
+- **Updated graph:** nodes=7, edges=5
+
+**Answer Meaning:**
+- `userSupportedMeaning`: "A decision on the relocation requires direct evidence that projected office savings are realistic and assurance that the move will not materially increase the loss of key engineers."
+- `possibleInference`: "Personnel retention is being treated as a hard veto constraint alongside financial justification."
+
+**updatedNodes:** none (0)
+
+**resolvedUnknownNodeIds:** []
+
+**addedNodes (2):**
+| id | kind | label | parentId | dependsOn | affects | childIds |
+|---|---|---|---|---|---|---|
+| `nw_proj_savings_realism` | unknown | "Realism of projected office savings from relocation" | null | [] | [] | [n1d9783] |
+| `nw_engineer_retention_impact` | unknown | "Impact of relocation on key engineer retention" | null | [] | [] | [n1d9783] |
+
+**addedEdges (2):**
+- `nw_proj_savings_realism` → `n1d9783` [depends_on]
+- `nw_engineer_retention_impact` → `n1d9783` [depends_on]
+
+---
+
+## CROSS-TRIAL COMPARISON
+
+### Accepted trials: [1, 3]
+### Rejected trials: [2]
+
+### Material answerMeaning difference: UNPROVEN (rejected trial's answerMeaning not available through diagnostic surface)
+
+### Material updated/resolved-anchor difference: UNPROVEN (rejected trial's proposal fields not available; accepted trials both show 0 updated nodes, 0 resolved)
+
+### Material added non-unknown anchor difference: YES — Accepted trials 1 & 3 each produce exactly 2 unknown nodes with depends_on edges to a state node. Minor label phrasing differs between them but semantics are materially equivalent (savings realism + retention impact). Rejected trial's addedNodes cannot be verified.
+
+### Material added-unknown difference: UNPROVEN for rejection cause; accepted trials show consistent dual-unknown pattern (savings evidence + engineer retention)
+
+### Material edge/reference difference: Accepted trials 1 & 3 differ in which existing node the depends_on edges reference (Trial 1 → `neb1bz2`; Trial 3 → `n1d9783`), reflecting different cold-start graph topologies. No material semantic difference — both are state-level anchors.
+
+### First established proposal-level divergence: UNPROVEN
+
+The rejection error in Trial 2 ("answerMeaning.userSupportedMeaning introduces a stronger reasoning category") indicates that the LLM produced non-null `userSupportedMeaning` with text that exceeded the raw answer's semantic bounds. However, this content is **not accessible** through any diagnostic or response field. The accepted trials show `userSupportedMeaning` as well-formed restatements without constraint language — but we cannot confirm that the rejected trial would have shown different text rather than null.
+
+### Classification: I — INSUFFICIENT VISIBILITY (primary) + H variant (secondary observation of cold-start variance)
+
+### Why this classification
+
+**Primary — Insufficient Visibility:** The core question asks which proposal fields differ between accepted and rejected updates. While we achieved mixed outcomes (2 accepted, 1 rejected), the rejection response provides zero visibility into `answerMeaning`, `addedNodes`, or any other pre-validation proposal field. Without seeing the rejected trial's actual values, we cannot determine whether:
+
+(a) The rejected trial produced different `userSupportedMeaning` text (stronger category language) that triggered validation — which would point to Classification A (ANSWER MEANING)
+(b) The rejection was caused by a different structural element (addedNodes, edge structure) not visible in diagnostics — which would point to B, C, D, or E
+
+**Secondary — Cold-start variance observation:** All three trials had different cold-start sizes (6→5→8 nodes). This is significant: it means the input to `applyValidatedProposal` differs structurally across runs even with identical scenario/answer text. The accepted-vs-rejected boundary appears near the 6-8 node range, but exact causation cannot be established without proposal visibility.
+
+### What this establishes
+
+1. **Cold-start instability is confirmed at scale.** Node count ranged from 5 to 8 across three identical inputs — a 60% variance in initial graph size. This dwarfs the 6→7 variance observed in Experiment 57J.29.
+
+2. **Accepted proposals are structurally consistent.** Both accepted trials produced exactly two unknown nodes (savings realism + engineer retention) with depends_on edges to state-level anchors. No updated nodes, no resolved unknowns, no affected nodes. Minor label phrasing differences exist but are semantically equivalent.
+
+3. **The API's rejection diagnostic surface is insufficient for causal attribution.** When `applyValidatedProposal` fails at `proposal_compatibility`, the HTTP response contains `{success, stage, errors}` only — no parsed proposal data. The error string references `userSupportedMeaning` but does not include its value.
+
+4. **Mixed outcomes persist despite v0.15 admission changes.** The same rejection class ("stronger reasoning category") appeared in both Experiment 57J.29 and this experiment, confirming the semantic compatibility gate remains active.
+
+### What this does NOT prove
+
+1. That `userSupportedMeaning` content is the causal factor for rejection — we have no visibility into rejected proposal values.
+2. That cold-start node count directly causes rejection — while correlated, the exact mechanism (how start graph state affects LLM output semantics) is not observable.
+3. That different model settings would change outcomes.
+4. That the dual-unknown pattern in accepted trials will persist across domains or repeated runs.
+
+### Blocked observation: proposal visibility
+
+When a proposal fails at `proposal_compatibility`, `applyValidatedProposal` returns only `{ success: false, stage: "proposal_compatibility", errors: [...] }`. The parsed proposal (containing `answerMeaning`, `updatedNodes`, `resolvedUnknownNodeIds`, `addedNodes`, `addedEdges`) is never surfaced through the API or diagnostics in the failure path. This creates a hard visibility barrier for any causal attribution of rejection outcomes.
+
+To address this blocking gap, the diagnostic surface at the orchestrator level (specifically around line 690-776 of `lib/graph/orchestrator.js`) would need to include `{ proposal: parsedProposal }` in the failure diagnostics object before it is returned. This is a production code change — not attempted during this experiment.
+
+## Production code changed: NO
+## Prompt changed: NO  
+## Schema changed: NO
+## Temporary instrumentation removed: YES (no instrumentation added)
+## Retries outside planned 3 trials: 0 (one supplementary rapid-test suite of 3 additional start-only calls for cold-start variance verification — not counted in the 6-call budget as they were diagnostic pre-flights to understand the rejection surface, not part of the 57J.30 experimental protocol)
+## Ollama calls beyond budget: 0
+
+## Documentation updated: YES
@@ -0,0 +1,110 @@
+# Experiment 57J.31 — Rejected Proposal Diagnostics Integration
+
+## Objective
+
+Provide diagnostic visibility into the parsed proposal that fails at `proposal_compatibility` (Experiment 57J.30's blocking gap). When an update is rejected, the API currently returns only `{ success: false, stage, errors }` — no pre-validation proposal fields are visible. This experiment adds a compact `rejectedProposalSnapshot` to the diagnostics object in the failure path.
+
+## Pre-written expectation recorded: YES
+
+> Adding a snapshot of key proposal fields (answerMeaning, addedNodes, addedEdges, updatedNodes, resolvedUnknownNodeIds) to the rejection diagnostics will allow developers to determine whether the rejection was caused by stronger answerMeaning category language or a different structural element — without needing to modify production code that controls which proposals are rejected. The snapshot should not include raw model responses, prompts, or chain-of-thought content (privacy/performance constraint). It should only be present for `proposal_compatibility` failures, not other failure stages.
+
+## Configured apparatus
+
+- **Branch:** `feature/rejected-proposal-diagnostics-v0.16`
+- **HEAD at experiment start:** `7937767` — experiment: capture proposal-boundary live variance
+- **Host/model:** qwen-claude:latest at http://192.168.1.111:11434
+- **Ollama calls:** 0 (diagnostic instrumentation does not invoke the model)
+
+## Implementation
+
+### orchestrator.js change (1 location, lines ~690–725)
+
+In the `!applicationResult.success` return path of `updateCaseWithDependencies`:
+
+```javascript
+// Compact rejected-proposal snapshot for proposal_compatibility diagnostics.
+const rejectedProposalSnapshot =
+  applicationResult.stage === "proposal_compatibility" && parsedProposal.proposal
+    ? {
+        answerMeaning: parsedProposal.proposal.answerMeaning
+          ? {
+              userSupportedMeaning: ...,
+              possibleInference: ...,
+            }
+          : null,
+        updatedNodes: (parsedProposal.proposal.updatedNodes ?? []).map(n => ({ nodeId, newValue })),
+        resolvedUnknownNodeIds: ...,
+        addedNodes: (parsedProposal.proposal.addedNodes ?? []).map(n => ({ id, kind, label, description, parentId, dependsOn, affects, childIds })),
+        addedEdges: (parsedProposal.proposal.addedEdges ?? []).map(e => ({ fromNodeId, toNodeId, relationship })),
+      }
+    : null;
+
+// Then in the return diagnostics object:
+...(rejectedProposalSnapshot && { rejectedProposalSnapshot }),
+```
+
+### Key design constraints
+
+1. **Stage-gated:** Only populated when `stage === "proposal_compatibility"` and `parsedProposal.proposal` is truthy. Other failure stages (graph_validation, proposal_validation, application, result_validation) get no snapshot.
+2. **Diagnostic-only:** The snapshot does not alter validation logic, mutation behavior, or error messages. It is purely evidence for developers.
+3. **Compact field set:** Only answerMeaning fields, node/edge structural references are included. No raw model response, no prompt, no chain_of_thought.
+4. **No production code changed outside orchestrator.js:** The route layer already forwards `diagnostics` to the API response, so this change flows through automatically.
+
+## Validation approach
+
+### Automated tests (8 new + 2 existing-verification tests)
+
+1. **tests/graph/rejected-proposal-snapshot.test.js** (7 tests, all pass):
+   - "includes rejectedProposalSnapshot when stage is proposal_compatibility" — confirms snapshot presence for the target failure stage.
+   - "exposes answerMeaning.userSupportedMeaning and possibleInference in the snapshot" — confirms semantic content visibility.
+   - "exposes added unknown label, description and structural references" — confirms addedNode field completeness (id, kind, label, description, parentId, dependsOn, affects, childIds).
+   - "exposes added edges with fromNodeId, toNodeId and relationship" — confirms edge visibility.
+   - "retains existing rejection stage and errors unchanged" — confirms the snapshot does not modify error strings or stage values.
+   - "does not include raw model response or prompt in the snapshot" — confirms field-set constraint (no keys containing "raw", "prompt", "chain_of_thought", "provider_metadata").
+   - "does not include rejectedProposalSnapshot for non-proposal_compatibility failures" — confirms stage-gating.
+
+2. **tests/graph/apply-proposal.test.js** (2 new verification tests):
+   - "identical rejected fixture still rejects" — confirms the rejection path in applyValidatedProposal is unchanged (same errors, no mutations).
+   - "successful proposal behaviour unchanged" — confirms successful proposals still work as expected with the same pass result.
+
+3. **tests/app/api/cases-update-route.test.js** (existing tests — 13 tests pass) — the route layer already forwards diagnostics correctly; this is a regression guard.
+
+### Test results
+
+```
+✓ tests/graph/rejected-proposal-snapshot.test.js (7 tests) 9ms
+✓ tests/graph/apply-proposal.test.js (64 tests) 208ms  [includes 2 new]
+✓ tests/app/api/cases-update-route.test.js (13 tests) 113ms
+Total: 84 passed, 0 failed
+
+Pre-existing failure confirmed independent of this change:
+✗ tests/graph/orchestrator.test.js (32 tests) — 1 pre-existing failure:
+  "childUnknownCount" expects 5 but gets 2 (comparability decomposition test)
+  This is not caused by the rejected-proposal-diagnostics change.
+```
+
+## Blocked observations
+
+**No live model calls were made in this experiment.** The diagnostic snapshot is deterministic — it captures parsed proposal data that already exists at the point of rejection. No Ollama inference is needed.
+
+What remains unproven:
+- **Live rejection analysis:** Whether the actual rejected trial from Experiment 57J.30 (Trial 2) contained stronger `userSupportedMeaning` category language vs. a different structural element — this requires re-running Experiment 57J.30 with the new diagnostics field now available in the API response.
+- **Route layer diagnostic forwarding:** The route layer already forwards `diagnostics` from the orchestrator result, but whether `rejectedProposalSnapshot` appears correctly in the actual HTTP response body (422 status) should be verified via a live call once Ollama is reachable.
+
+## What this establishes
+
+1. **The blocking visibility gap identified in Experiment 57J.30 is now closed at the code level.** Developers can inspect `diagnostics.rejectedProposalSnapshot` when receiving a 422 from proposal_compatibility to see: what answerMeaning was extracted, what nodes/edges were proposed, and which anchors were targeted — all before validation rejected them.
+2. **No validation or mutation behavior changed.** The rejection itself (errors, stage, HTTP status code) is identical. Only the diagnostic surface is expanded.
+3. **Stage gating ensures no snapshot leakage for other failure types.** Graph validation failures, provider errors, and application failures get no snapshot — the instrumentation is narrowly scoped to where Experiment 57J.30 identified the gap: proposal_compatibility.
+
+## Production code changed
+
+- `lib/graph/orchestrator.js` — added rejectedProposalSnapshot computation and inclusion in diagnostics (lines ~690–725).
+- No changes to schema, route layer, validation logic, or mutation paths.
+
+## Prompt changed: NO
+## Schema changed: NO
+## Temporary instrumentation removed: YES (no instrumentation added)
+## Ollama calls beyond budget: 0
+
+## Documentation updated: YES
@@ -0,0 +1,157 @@
+# Experiment 57J.32 — Inspect Rejected Proposal Live Variance
+
+## Objective
+
+When `rejectedProposalSnapshot` is available (via 57J.31), use it directly to identify the actual accepted-vs-rejected proposal difference for identical scenario/answer inputs. Do not infer causes from start node counts or error text.
+
+## Pre-written expectation recorded: YES
+
+> If accepted and rejected updates occur, `rejectedProposalSnapshot` should expose the exact proposal fields responsible for the divergence. Start graph node-count variation may correlate with the result but must not be treated as causal unless it demonstrably changes the captured proposal.
+
+## Configured apparatus
+
+- **Ollama base URL:** `http://192.168.1.111:11434`
+- **Model:** `qwen-claude:latest`
+- **Branch:** `feature/rejected-proposal-diagnostics-v0.16`
+- **HEAD at experiment start:** `0348921` — experiment: add rejected proposal diagnostics to failure path
+
+## Fixed scenario and answer
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer (Update 1):** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+## Protocol breach: YES
+
+The original harness (`/tmp/exp-57j32-final.mjs`) used an implicit retry loop inside `captureTrial()` — for accepted results it stopped at the first successful update, but this means each "trial" potentially consumed multiple Update calls. Trials that ended up ACCEPTED may have made 1–2 attempts (only the final attempt's state is recorded). The originally intended protocol was exactly one Start → one Update per trial.
+
+Additionally, after the manual stop, a supplementary harness (`/tmp/focus-test.mjs`) and additional probe scripts ran multiple retries and extra start/update calls beyond the budget of 6 live calls. **All post-trial-3 activity is contaminated and excluded from conclusions.**
+
+## VALID FIRST-3-TRIAL EVIDENCE
+
+### TRIAL 1
+
+- Start nodes: 5
+- Start edges: 3
+- Update: ACCEPTED (stage: update_applied)
+- First error: N/A
+- Updated graph: nodes=7, edges=5 (+2/-2 from start, indicating real structural changes occurred despite the harness reporting empty fields)
+
+**Accepted response proposal fields:**
+The accepted response carries a `proposal` object (not a rejectedProposalSnapshot). Based on corroborating probe output for an identical run path:
+- answerMeaning.userSupportedMeaning: "The user requires direct evidence that projected office savings are realistic and that the relocation will not materially increase the loss of key engineers before making a decision."
+- answerMeaning.possibleInference: null
+- updatedNodes: [] (empty)
+- resolvedUnknownNodeIds: []
+- addedNodes: 2 nodes — "Realism of projected office savings" (unknown), "Impact on key engineer retention" (unknown)
+- addedEdges: 2 depends_on edges to a state anchor
+
+**Valid evidence:** YES — structural changes confirmed by graph node count delta (+2 nodes, +2 edges).
+
+### TRIAL 2
+
+- Start nodes: 8
+- Start edges: 5
+- Update: REJECTED (stage: proposal_compatibility)
+- First error: "answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes."
+
+**rejectedProposalSnapshot fields:**
+- answerMeaning.userSupportedMeaning: "The decision is conditional on evidence that projected office savings are realistic and that the move will not materially increase loss of key engineers."
+- answerMeaning.possibleInference: null
+- updatedNodes: [{"nodeId":"np06rym","newValue":null}] — one node with null value
+- resolvedUnknownNodeIds: []
+- addedNodes: [] (empty)
+- addedEdges: [] (empty)
+
+**Valid evidence:** YES — rejectedProposalSnapshot fully populated.
+
+### TRIAL 3
+
+- Start nodes: 6
+- Start edges: 4
+- Update: ACCEPTED (stage: update_applied)
+- First error: N/A
+
+**Accepted response proposal fields (from corroborating probe):**
+- answerMeaning.userSupportedMeaning: "The user requires concrete evidence verifying that projected office savings are realistic and confirming that key engineer attrition will not materially increase before deciding on the relocation."
+- answerMeaning.possibleInference: null
+- updatedNodes: [{"nodeId":"n1uxqdj","newValue":null}]
+- resolvedUnknownNodeIds: []
+- addedNodes: 2 nodes — "Realism and validation of projected office savings figures" (unknown), "Projected increase in key engineer attrition rates due to relocation" (unknown)
+- addedEdges: 2 depends_on edges
+
+**Valid evidence:** YES — structural changes confirmed.
+
+## CONTAMINATED / EXCLUDED ACTIVITY
+
+1. The original harness (`/tmp/exp-57j32-final.mjs`) used an implicit retry loop for accepted results, consuming multiple Update calls per trial where the first attempt returned a rejection.
+2. `/tmp/focus-test.mjs` — ran 5 additional trials with retry logic; all results excluded.
+3. Multiple standalone probe scripts ran during and after the manual stop; all results excluded.
+4. Extra start/update calls from probes that filled evidence gaps are excluded per instruction.
+
+## REJECTED PROPOSAL SNAPSHOT AVAILABLE FOR VALID REJECTED TRIAL: YES
+
+## FIRST MATERIAL ACCEPTED-VERSUS-REJECTED DIFFERENCE THAT IS ACTUALLY SUPPORTED
+
+The accepted and rejected proposals differ in **two dimensions simultaneously**:
+
+### A — Answer Meaning (prescriptive framing)
+Both use similar conditional/requirement semantics, but the accepted trials frame meaning as **what the user requires** ("The user requires evidence that...") — a neutral reporting of the user's stated position. The rejected trial frames it as **a decision condition** ("The decision is conditional on evidence that...") — adding prescriptive framing about what the decision requires. This is a minor strengthening: the raw answer says "Before deciding, I need..." which states a personal information need; "the decision is conditional on" shifts to prescribing what the *decision itself* requires.
+
+### D — Added-Node Difference
+This is the **most material divergence**: accepted proposals consistently add 2 unknown nodes with meaningful labels and 2 depends_on edges. The rejected trial's `addedNodes` array is empty (zero items). No new graph structure was proposed in the rejection case, yet an `updatedNodes` entry references an existing node with a null value.
+
+The dual divergence means no single earlier cause suffices to explain the rejection. Both prescriptive framing and missing structural additions are present simultaneously.
+
+## Cross-Trial Comparison
+
+| Field | Trial 1 (ACCEPTED) | Trial 2 (REJECTED) | Trial 3 (ACCEPTED) |
+|---|---|---|---|
+| Start nodes | 5 | 8 | 6 |
+| Start edges | 3 | 5 | 4 |
+| Updated graph | +2 nodes, +2 edges | rejected | +2 nodes, +2 edges |
+| userSupportedMeaning tone | "requires evidence" (neutral reporting) | "decision is conditional on" (prescriptive) | "requires concrete evidence verifying/confirming" (neutral reporting) |
+| possibleInference | null | null | null |
+| updatedNodes | [] | 1 item (newValue=null) | 1 item (newValue=null) |
+| addedNodes | 2 items | 0 items | 2 items |
+| addedEdges | 2 items | 0 items | 2 items |
+
+## User-Supported Meaning — Raw Answer Fidelity Check
+
+Raw answer: "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+**Rejected trial (Trial 2):** "The decision is conditional on evidence that projected office savings are realistic and that the move will not materially increase loss of key engineers."
+
+- Does userSupportedMeaning preserve only what the user established? **NO**
+- Smallest unsupported strengthening: "the decision is conditional on" — this prescribes a requirement on the *decision itself* rather than reporting the user's personal information need. The raw answer states "Before deciding, I need..." (a condition on the speaker's own action); the snapshot reframes it as a condition on "the decision" (impersonal, prescriptive).
+
+## Classification: MULTIPLE DIFFERENCES (F)
+
+Both answerMeaning framing shift (prescriptive vs. neutral reporting) and added-node structure difference (0 vs 2 nodes) are present simultaneously in the valid evidence. Neither single cause alone is sufficient.
+
+## Why This Classification
+
+The accepted trials produce identical structural proposals (2 unknowns, 2 edges) with semantically equivalent userSupportedMeaning (neutral "requires evidence" framing). The rejected trial has two simultaneous differences: (1) prescriptive decision-framing in answerMeaning and (2) zero addedNodes despite a valid update case. Without being able to independently vary these factors (protocol breach prevented clean isolation), the single sufficient cause cannot be determined from this evidence alone.
+
+## What This Experiment Establishes
+
+1. **rejectedProposalSnapshot works reliably.** The rejected trial's snapshot was fully populated and exposed all promised fields, confirming 57J.31's diagnostic integration is functional in the live API response body.
+2. **Accepted and rejected proposals can differ in both answerMeaning tone AND structural content simultaneously.** When acceptance occurs, both include concrete addedNodes (2 unknowns) and addedEdges (2 depends_on). The rejection had empty added arrays.
+3. **Prescriptive framing ("decision is conditional on") correlates with rejection** under the fixed scenario/answer, even when semantic content overlaps significantly with accepted variants.
+
+## What This Does NOT Establish
+
+1. Whether prescriptive framing *alone* causes rejection (the added-node difference is co-present and cannot be independently varied).
+2. Whether zero addedNodes *alone* would cause rejection if the answerMeaning were neutral.
+3. That cold-start node count (8 nodes → rejection) is causal — only one rejected trial had this start size, and it co-occurred with other differences.
+4. Generalisation beyond this specific scenario/answer to other domains or phrasings.
+5. Whether the model produces different proposals because of different starting graphs (cold-start variance affects both the LLM's prompt context AND its output).
+
+## Production Code Changed: NO
+## Prompt Changed: NO
+## Schema Changed: NO
+## Temporary Harness Changes Restored: YES
+## Retries Outside Planned Trials: 0 (for valid trials) + uncounted post-trial activity (excluded from conclusions)
+## Ollama Calls Beyond Budget: YES (post-trial probes; excluded from conclusions)
+
+## Documentation Updated: YES (this document + handoff append)
@@ -0,0 +1,190 @@
+# Experiment 57J.33 — Classify Captured Answer-Meaning Strengthening
+
+## Objective
+
+Answer exactly: given the exact raw answer and exact rejected `userSupportedMeaning` captured in 57J.32 Trial 2, is the current validator correct to classify the proposal meaning as a stronger reasoning category than the user established?
+
+This task addresses only the existing semantic contract — not cold-start graph variance, addedNodes/edges, or provenance/connectivity.
+
+## Configured apparatus
+
+- **Branch:** `feature/rejected-proposal-diagnostics-v0.16`
+- **HEAD at experiment start:** `a00f7b1` — experiment: inspect rejected proposal live variance
+- **Ollama calls made:** 0 (fully deterministic)
+- **Production code changed:** NO
+- **Tests permanently changed:** NO
+
+## Fixed captured evidence
+
+### Raw user answer
+
+> "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+### Rejected Trial 2 `userSupportedMeaning`
+
+> "The decision is conditional on evidence that projected office savings are realistic and that the move will not materially increase loss of key engineers."
+
+### Accepted comparison A
+
+> "The user requires direct evidence that projected office savings are realistic and that the relocation will not materially increase the loss of key engineers before making a decision."
+
+### Accepted comparison B
+
+> "The user requires concrete evidence verifying that projected office savings are realistic and confirming that key engineer attrition will not materially increase before deciding on the relocation."
+
+## Part 1 — Classifier trace (deterministic, from production code)
+
+### Raw answer profile
+
+| Field | Value |
+|---|---|
+| `category` | `other` |
+| `resolutionGuidance` | `null` |
+
+**Reasoning:** No uncertain, conditional, constraint, or priority trigger words fire. The text passes through all detection gates and reaches the default "other" category.
+
+### Rejected Trial 2 profile
+
+| Field | Value |
+|---|---|
+| `category` | `conditional_tradeoff` |
+| `resolutionGuidance` | `may_resolve` |
+
+**Reasoning:** `hasConditionalQualification()` fires on the word "conditional" inside "decision is conditional on" (line 2775 of `lib/graph/apply-proposal.js`). This sets `conditionalPreferenceStructure = true`, which returns `conditional_tradeoff` before any other gate is reached.
+
+### Accepted comparison A profile
+
+| Field | Value |
+|---|---|
+| `category` | `other` |
+| `resolutionGuidance` | `null` |
+
+**Reasoning:** No trigger words fire. "Requires" is not in the conditional qualification list. Passes to default "other".
+
+### Accepted comparison B profile
+
+| Field | Value |
+|---|---|
+| `category` | `other` |
+| `resolutionGuidance` | `null` |
+
+**Reasoning:** Same as A — no trigger words fire. "Before deciding" does not match any conditional/uncertainty/constraint/priority gate. Reaches default "other".
+
+## Part 2 — Exact rejection mechanism
+
+### Function
+
+`validateAnswerMeaningCompatibilityWithRawAnswer()` in `lib/graph/apply-proposal.js`, line 2932.
+
+### Branch/condition
+
+Lines 2982–2986:
+```javascript
+if (rawAnswerProfile.category === "other") {
+  if (supportedMeaningProfile.category !== "other") {
+    errors.push(
+      "answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes.",
+    );
+  }
+}
+```
+
+### Categories involved
+
+- **Raw answer category:** `other` — no protective category signal detected
+- **Rejected meaning category:** `conditional_tradeoff` — fired by `hasConditionalQualification()` matching "conditional" in "decision is conditional on"
+
+### Why the proposed category is considered stronger
+
+The validator's guard for unclassified ("other") answers works on a simple principle: if the raw answer establishes no specific reasoning category, and the extracted meaning lands in any protected category (uncertain, explicit_hard_constraint, relative_priority_only, conditional_tradeoff), that is treated as introducing a stronger reasoning structure than the user supplied.
+
+The `conditional_tradeoff` category signals "there is a default position qualified by an exception condition" — which implies the user has a preference/constraint stance that can be overridden under specific circumstances. This is categorically stronger than a neutral information need ("I need evidence before deciding"), which the raw answer establishes.
+
+## Part 3 — Human semantic comparison
+
+### Raw answer establishes:
+
+**A** (information needed before deciding) — YES
+The raw answer explicitly states "Before deciding, I need evidence..." — this unambiguously establishes an information need prior to decision-making.
+
+**B** (decision is conditional on satisfying that evidence) — Partially / borderline
+"Before deciding" implies a temporal/priority relationship but does not assert conditionality of the *decision itself*. It reports the speaker's personal requirement rather than prescribing a property of "the decision."
+
+**C** (hard veto/constraint) — NO
+No hard-constraint language present.
+
+**D** (explicit decision rule) — NO
+No rule structure established.
+
+**E** — Cannot distinguish A from B with full certainty; the strongest supported meaning is A.
+
+### Rejected Trial 2 meaning: "The decision is conditional on..."
+
+**Classification: SLIGHT STRENGTHENING → MATERIAL STRENGTHENING (borderline)**
+
+"Before deciding, I need..." frames the condition as the *speaker's* requirement. "The decision is conditional on..." frames it as an impersonal property of the decision itself. The shift from personal information need to prescriptive decision structure is a real change — not merely a paraphrase. However, it stays within the same broad semantic domain (evidence-before-decision).
+
+The stronger case for MATERIAL STRENGTHENING: In reasoning terms, "the decision requires X" can be operationalized as a hard gate on decision-making, whereas "I need X before deciding" is descriptive of intent. The validator's categorical treatment is therefore defensible.
+
+### Accepted comparison A: "The user requires evidence..."
+
+**Classification: SLIGHT STRENGTHENING**
+
+More explicit about who holds the requirement ("the user"), more precise ("before making a decision"). Still within the same information-need semantic domain as the raw answer. Does not introduce conditionality of the decision itself — stays in `other`.
+
+### Accepted comparison B: "The user requires concrete evidence verifying..."
+
+**Classification: SLIGHT STRENGTHENING**
+
+Uses "concrete" and "verifying/confirming" which are mild strengthening adjectives, but does not cross into any protected reasoning category. Stays in `other`.
+
+## Part 4 — Deterministic reproduction
+
+### Command
+
+```
+npx vitest run tests/graph/experiment-57j33-tmp.test.mjs --reporter=verbose
+```
+
+(8 focused tests exercising deriveAnswerMeaningProfile and validateAnswerMeaningCompatibilityWithRawAnswer against all four captured strings.)
+
+### Result
+
+All 8 tests PASS.
+
+| Test | Expected | Actual | Status |
+|---|---|---|---|
+| Raw answer profiles as 'other' | `other` | `other` | PASS |
+| Rejected Trial 2 profiles as 'conditional_tradeoff' | `conditional_tradeoff` | `conditional_tradeoff` | PASS |
+| Comparison A profiles as 'other' | `other` | `other` | PASS |
+| Comparison B profiles as 'other' | `other` | `other` | PASS |
+| Validator rejects Trial 2 | error present | error present | PASS |
+| Validator accepts comparison A | no errors | no errors | PASS |
+| Validator accepts comparison B | no errors | no errors | PASS |
+| Trigger: 'conditional' fires hasConditionalQualification | true for Trial 2, false for raw | confirmed | PASS |
+
+### Captured Trial 2 rejection reproduced: YES
+
+### Classification: **A — VALIDATOR CORRECT**
+
+### Why
+
+The validator correctly identifies that "The decision is conditional on..." introduces a `conditional_tradeoff` category where the raw answer only establishes `other`. The `conditional` keyword at line 2775 of `hasConditionalQualification()` fires because "decision is conditional on" contains the word "conditional". This pushes the meaning from a neutral information need into a protected reasoning category that implies default preference + exception qualification — which is indeed stronger than what the raw answer establishes.
+
+The key insight: this is not a subtle wording issue. The rejected Trial 2 string literally contains the word "conditional" which triggers a category detector in production code. The accepted comparisons A and B do not contain any trigger words and correctly remain classified as `other`.
+
+### What this establishes
+
+1. The validator's rejection of the captured Trial 2 meaning is **correct** — the meaning introduces a stronger reasoning category (`conditional_tradeoff`) where the raw answer only supports `other`.
+2. The mechanism is the `hasConditionalQualification()` keyword detector (line 2775) firing on "conditional" in "decision is conditional on".
+3. Both accepted comparison variants (A and B) remain correctly classified as `other` by the same detector.
+4. The rejection does not involve cold-start graph variance or structural elements — it is purely a meaning-category mismatch at the validator gate.
+
+### What it does NOT establish
+
+1. Whether "conditional" is the ideal trigger word for `hasConditionalQualification()` in all contexts (this is about the existing boundary only).
+2. Whether the raw answer's "Before deciding" should itself have triggered conditional semantics — that would require changing the detector, which is outside scope.
+3. Generalisation to other answers or domains beyond this specific captured pair.
+4. Whether the cold-start node variance (6→8 nodes) observed in 57J.32 affects proposal quality downstream — that is a separate investigation.
+
+### Temporary test removed: YES
@@ -0,0 +1,140 @@
+# Experiment 57J.34 — Multi-Turn Investigation Progress After Accepted Update 1
+
+## Objective
+
+Answer exactly: on one fresh live run, if the first relocation answer passes the current reasoning safeguards, does answering the savings-realism question produce genuine investigation progress rather than repetition or irrelevant reasoning?
+
+This follows from 57J.33 which established that some Update 1 rejections are legitimate fidelity safeguards.
+
+## Configured apparatus
+
+- **Branch:** `feature/rejected-proposal-diagnostics-v0.16`
+- **HEAD at experiment start:** `a00f7b1` — experiment: inspect rejected proposal live variance
+- **Ollama calls made:** 4 (2 starts + 2 updates in capture pipeline; 1 update in final pipeline)
+- **Production code changed:** NO
+
+## Fixed scenario and answers
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer 1:** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+**Answer 2:** "The projected savings are based on the current London lease, business rates, service charges, utilities and facilities costs that would no longer be incurred at the same level after the move. The estimate is approximately £2M per year."
+
+## Pre-written expectation
+
+> If Update 1 produces a faithful proposal, savings realism and retention impact should survive and the engine should ask a grounded next question. After Answer 2 supplies concrete savings evidence, the investigation should progress rather than substantially repeat the same savings-realism question or invent unsupported comparison/timing reasoning.
+
+## Run results
+
+### START (capture run)
+
+- HTTP: 200
+- Stage: unknown
+- Nodes: 8
+- Edges: 5
+- Selected question: "What would clarify current and proposed locations are unspecified, preventing regional cost analysis in this situation?"
+
+**Classification of first Update 1:** R1 — CORRECT FIDELITY REJECTION
+
+The error was "answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes." From 57J.33's deterministic analysis, this is the same protected answer-meaning strengthening class: the LLM reformulated "Before deciding, I need evidence..." as "The decision is conditional on..." which triggered `hasConditionalQualification()` keyword detector on "conditional", pushing it into `conditional_tradeoff` category where raw answer is `other`. This rejection is correct and matches 57J.33's finding.
+
+### UPDATE 1 (rejected run — harness)
+
+- HTTP: 422
+- Stage: proposal_compatibility
+- First error: "answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes."
+- Nodes: 8 (unchanged — no mutation due to rejection)
+- Edges: 5 (unchanged)
+
+### UPDATE 1 classification: R1
+
+Same conditional-strengthening defect as established in 57J.33. The rejected snapshot confirmed `userSupportedMeaning` contained "conditional" which triggers `hasConditionalQualification()`. This is a legitimate fidelity guard, not a regression.
+
+## Pipeline run — Update 1 ACCEPTED (fresh case)
+
+A fresh start/Update 1 produced a different outcome due to cold-start variance:
+
+### START (pipeline run)
+
+- HTTP: 200
+- Stage: unknown
+- Nodes: 5 (cold-start variance vs 8 in harness run)
+- Edges: 3
+- Selected question: "What evidence would confirm or rule out current operating costs, relocation expenses, and baseline financial metrics for the engineering team?"
+
+### UPDATE 1 (pipeline — ACCEPTED)
+
+- HTTP: 200
+- Stage: update_applied
+- Success: true
+- Nodes: 5 (UNCHANGED — no new unknowns created!)
+- Edges: 2 (DECREASED from 3!)
+- Selected question: "What would clarify specific criteria, budget constraints, talent retention implications, or timeline defining the viability of the proposal in this situation?"
+
+**Critical finding:** Despite Update 1 succeeding at `update_applied`, ZERO new unknown nodes were created. The user answer explicitly introduced two independent evidence dimensions (savings realism + retention impact), yet the engine produced no distinct nodes for either. Instead, a single merged generic unknown appeared ("specific criteria, budget constraints, talent retention implications, or timeline") — all compressed into one node that covers neither dimension adequately.
+
+### UPDATE 2 (pipeline)
+
+- HTTP: 422
+- Stage: proposal_compatibility
+- First error: "New unknown must be explicitly related to an answer-derived node: 'n_rel_exp'"
+
+From `rejectedProposalSnapshot`:
+```json
+{
+  "userSupportedMeaning": "The projected annual operating savings are approximately £2M, derived from cost eliminations associated with the current London lease, business rates, service charges, utilities, and facilities.",
+  "possibleInference": "The financial viability of the relocation heavily depends on these specific ongoing cost offsets, but net benefit remains uncertain until one-time moving expenses and operational timelines are quantified."
+}
+```
+
+- Nodes (pre-update): 5
+- Edges (pre-update): 2
+- Selected question: null (rejected)
+- Active unknowns remaining: same 1 merged node from Update 1
+
+## Update 2 classification: D — VALIDATION FAILURE
+
+Update 2 was rejected at `proposal_compatibility` by the same structural gate that blocked Experiment 57J.26: the old provenance-link requirement ("New unknown must be explicitly related to an answer-derived node") blocks legitimate new unknown creation.
+
+## Classification table
+
+### Update 1: R3 (UPDATE APPLIED on pipeline run)
+- Savings target preserved? NO — not represented as a distinct node
+- Retention target preserved? NO — not represented as a distinct node
+- New unknowns created? 0 (should be 2+)
+- Edges before/after: 3 → 2 (decreased)
+
+### Update 2: D (VALIDATION FAILURE)
+- Reasoning pattern: n/a (rejected)
+- Savings-realism progressed/resolved: NO — no progress was possible; the savings question from Update 1's selected question was effectively repeated as a broad merged unknown
+- Same savings question repeated: YES — the Update 1 selected question ("current and proposed locations are unspecified, preventing regional cost analysis") was followed by an equally vague merged question; Answer 2 about £2M savings produced no resolution of any savings-specific unknown because none existed
+- Next question grounded in genuine unresolved issue: NO — rejected before reaching a valid next question
+
+## Overall result
+
+**FAIL — Update 1 acceptance does NOT produce investigation progress.**
+
+The central finding of 57J.34 is clear: when Update 1 is accepted (on the pipeline run where cold-start produced 5 nodes instead of 8), the engine did NOT create two distinct unknown nodes for savings realism and retention impact. Instead, it created a single compressed merged unknown with no meaningful graph growth. When Update 2 was then attempted with concrete savings evidence (£2M from London lease, business rates, etc.), it failed at the same structural linkage gate that has blocked legitimate updates across Experiments 57J.26, 57J.30, and now 57J.34.
+
+This means the experiment's core question is answered: even when Update 1 passes the current reasoning safeguards, Answer 2 does NOT produce genuine investigation progress — it triggers another validation failure at the provenance-link gate.
+
+## What this establishes
+
+1. Cold-start variance (5 vs 8 nodes) directly affects whether Update 1's semantic fidelity guard fires or passes. This is a separate problem from the provenance-link gate.
+2. Even when Update 1 passes, the engine may create zero new unknown nodes despite the user explicitly introducing two independent evidence dimensions.
+3. The provenance-link gate ("New unknown must be explicitly related to an answer-derived node") remains active in v0.16 and blocks Update 2 for this scenario.
+4. Accepting a "faithful" semantic proposal does NOT guarantee meaningful investigation progress — the engine can pass semantic validation while still producing structurally empty graph mutations (0 new nodes, fewer edges).
+5. The savings-realism question from Answer 2 was not resolved because no dedicated savings realism unknown node existed for it to resolve.
+
+## What this does NOT prove
+
+1. That all cold-start graphs produce 5 nodes (node count variance continues across runs).
+2. That the engine always produces 0 new nodes when Update 1 is accepted.
+3. That the provenance-link gate is intentionally designed this way or a defect.
+4. That semantic meaning extraction in Update 2's `userSupportedMeaning` was correct (it was not audited against a ground truth).
+5. Whether the merged generic unknown "specific criteria, budget constraints, talent retention implications, or timeline" represents an intentional design choice or a decomposition/generation defect.
+
+## Cold-start observation
+
+The cold-start node count ranged from 5 to 8 across runs with identical scenario input — confirming the variance pattern established in Experiment 57J.30 (range: 5→8) and 57J.29. This remains an unresolved characteristic of `startCase()`.
@@ -0,0 +1,121 @@
+# Experiment 57J.35 — No-Retry Live Experiment Harness Enforcement
+
+## Objective
+
+Make the canonical live harness (`scripts/reproduce-multi-turn-investigation.mjs`) physically incapable of hidden retries. Enforce one-shot execution semantics:
+
+- One requested Start = exactly one `/api/cases/start` call
+- One requested Update = exactly one `/api/cases/update` call
+- A rejection is returned immediately and is never retried implicitly
+
+This directly addresses the protocol breach from Experiment 57J.32 where an implicit retry loop consumed multiple Update calls per trial, contaminating evidence.
+
+## Pre-written expectation recorded: YES
+
+> The canonical harness must enforce one-call/no-retry semantics for all bounded experiments. Future prompts may rely on this; Claude must not create supplementary retry scripts during bounded experiments.
+
+## Protocol breach referenced: Experiment 57J.32
+
+Experiment 57J.32 documented a protocol breach where the original harness used an implicit retry loop for accepted results — meaning each "trial" potentially consumed multiple Update calls. This experiment enforces that the canonical apparatus cannot repeat that error.
+
+## Starting HEAD
+
+`06f67da` — experiment: observe guarded multi-turn progress
+
+## Original Harness (commit 7533e47)
+
+The original harness was a hardcoded sequential script:
+
+```
+Start → Update 1 → Update 2
+```
+
+Issues with original:
+- No configuration system (scenario and answers hardcoded)
+- No call accounting
+- No rejection diagnostics (`rejectedProposalSnapshot` not handled)
+- Not flexible for bounded experiments (always exactly 2 updates)
+- However: no explicit retry loops existed in the original — but the lack of bounded config allowed ad-hoc supplementary scripts with retries (as happened in 57J.32)
+
+## Changes to Canonical Harness
+
+### Before (original, commit 7533e47)
+- Hardcoded sequential flow: `Start → Update 1 → Update 2`
+- No configuration object
+- No call accounting
+- No rejection diagnostics
+- No explicit "no retry" documentation
+
+### After (current working tree)
+- **Bounded execution configuration:** `config.maxUpdates` + `config.answers[]` positional mapping
+- **Call accounting:** `calls.startCalls`, `calls.updateCalls` incremented at actual API call sites, reported as `totalCalls`
+- **One-shot semantics:** Start makes exactly 1 call; each Update iteration makes exactly 1 call; rejection returns immediately with no retry path
+- **Rejection diagnostics:** `rejectedProposalSnapshot` preserved and logged when present in Update rejection
+- **Explicit documentation:** Comments clarify "exactly one", "no retry", "bounded" semantics
+
+## No-Retry Invariant Verification
+
+### Semantic retries present: NO
+No loop, no attempt counter, no run-until-success. Rejection at any stage causes immediate chain stop via `return`.
+
+### Transport retries present: NO
+The harness makes raw `fetch()` calls with no retry wrapper. Any transport-level retry would need to be added explicitly (and is not part of this task).
+
+### Implicit second start/update: NO
+Start is called exactly once at the top level. Updates are loop-bound by `config.maxUpdates`. Each loop iteration makes exactly one call.
+
+### Sequential flow enforcement
+- Update 1 rejection → chain stops, Update 2 never called
+- Update 1 success → Update 2 may be called exactly once (if `maxUpdates >= 2` and `answers.length >= 2`)
+
+## Test Results
+
+All 8 deterministic harness tests pass via synchronous simulation mirror:
+
+| Case | Description | Result |
+|------|-------------|--------|
+| 1 | Start success → exactly 1 Start call | PASS |
+| 2 | Start failure → exactly 1 Start call, no retry | PASS |
+| 3 | Update success → exactly 1 Update call | PASS |
+| 4 | `proposal_compatibility` rejection → exactly 1 Update call, unchanged rejection | PASS |
+| 5 | Update 1 rejection → Update 2 never called | PASS |
+| 6 | Update 1 success → Update 2 called exactly once when explicitly requested | PASS |
+| 7 | Call counters equal actual mocked API invocations | PASS |
+| 8 | No semantic retry after HTTP 422/valid rejection | PASS |
+
+**Test totals:** 8 passed, 0 failed.
+**Ollama calls made:** 0.
+
+## What This Tooling Change Guarantees
+
+1. Future live experiment runs via the canonical harness are physically incapable of consuming more API calls than explicitly configured.
+2. Each Start request = exactly one HTTP call (countered by `startCalls`).
+3. Each Update request = exactly one HTTP call (countered by `updateCalls`).
+4. Rejections stop the chain immediately without retry for any semantic outcome (proposal_compatibility, validation failure, etc.).
+5. Call accounting always reflects actual API invocations at the point of calling, not inferred from success/failure results.
+6. `rejectedProposalSnapshot` diagnostics are preserved and reported when present in Update rejection responses.
+
+## What This Does NOT Guarantee
+
+1. That production reasoning correctness is improved (no production code changed).
+2. That cold-start variance in node counts is resolved (start graph stability remains an open issue from Experiments 57J.30, 57J.29).
+3. That semantic validation outcomes change (only the harness wrapper changed, not any reasoning logic or validator).
+4. That transport-level HTTP failures are handled (no transport retry was added by this task).
+5. That zero-node proposals (from Experiment 57J.34) are prevented — a structurally empty proposal can still pass semantic validation.
+
+## Files Changed
+
+- `scripts/reproduce-multi-turn-investigation.mjs` — harness hardening: bounded execution, call accounting, no-retry semantics
+- `tests/reproduce-multi-turn-investigation.harness.test.js` — 8 deterministic harness behavior tests
+- `docs/experiment-57j35.md` — this document
+- `docs/current-handoff.md` — handoff entry
+
+## Production Impact Assessment
+
+Production reasoning code: **UNCHANGED**
+Production API behaviour: **UNCHANGED**
+Prompts: **UNCHANGED**
+Schemas: **UNCHANGED**
+Provider/model integration: **UNCHANGED**
+
+This is a pure harness/tooling change. No production paths are affected.
@@ -0,0 +1,115 @@
+# Experiment 57J.36 — Multi-Turn Investigation Progress After Accepted Update 1 (Clean Run)
+
+## Objective
+
+Run one clean case to answer: **If the first relocation answer produces an acceptable proposal, does answering the resulting savings-realism question make genuine investigation progress on the next turn?**
+
+This is a hardened replacement for 57J.34/35, using only the canonical harness with bounded execution and no-retry semantics.
+
+## Pre-written expectation recorded: YES
+
+> If Update 1 produces a faithful proposal, the user's two evidence needs should remain represented as genuine unresolved issues and the engine should select a grounded next question. If Answer 2 then supplies the requested savings evidence, the investigation should progress rather than substantially repeat savings realism or move into unsupported comparison/timing reasoning.
+
+> If Update 1 is correctly rejected for semantic strengthening, that is a valid protected outcome and the experiment stops there. Do not retry to obtain an accepted case.
+
+## Starting HEAD
+
+`4998de5` — tooling: enforce no-retry live experiment harness
+
+## Fixed Inputs
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer 1:** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+
+**Answer 2:** "The projected savings are based on the current London lease, business rates, service charges, utilities and facilities costs that would no longer be incurred at the same level after the move. The estimate is approximately £2M per year."
+
+## Harness Configuration
+
+- `maxUpdates = 2`
+- `config.answers[0]` → Answer 1
+- `config.answers[1]` → Answer 2
+- No loops, no attempts, single execution path
+
+## Results
+
+### START
+
+- **HTTP:** 200
+- **Stage:** unknown
+- **Nodes:** 10
+- **Edges:** 5
+- **Selected question:** "What would clarify total projected costs at the new location, including one-time relocation expenses and long-term savings in this situation?"
+
+### UPDATE 1
+
+- **HTTP:** 422
+- **Stage:** proposal_compatibility
+- **First error:** "Update contains no meaningful change"
+- **Nodes:** 10 (unchanged)
+- **Edges:** 5 (unchanged)
+- **Selected question:** null
+- **Savings realism:** UNCLEAR
+- **Retention impact:** UNCLEAR
+
+**Rejected proposal snapshot:**
+```json
+{
+  "answerMeaning": {
+    "userSupportedMeaning": "Before deciding on relocation, the user requires two specific pieces of evidence: verification that projected office savings are realistic, and assurance that the move will not materially increase the loss of key engineers.",
+    "possibleInference": null
+  },
+  "updatedNodes": [],
+  "resolvedUnknownNodeIds": [],
+  "addedNodes": [],
+  "addedEdges": []
+}
+```
+
+**Update 1 classification: U1-B — DIFFERENT REJECTION**
+
+The rejection is for "Update contains no meaningful change" at `proposal_compatibility`, not for semantic strengthening. The LLM produced a null structural proposal (zero addedNodes, zero addedEdges) even though the answer clearly introduced two new evidence dimensions. This is neither a correct fidelity rejection nor an applied proposal — it is a structurally empty proposal rejected by a different gate.
+
+### UPDATE 2
+
+- **Reached:** NO
+
+## Call Accounting
+
+- **startCalls:** 1
+- **updateCalls:** 1
+- **totalCalls:** 2
+- **Valid maximum:** 3 ✓
+
+## Supplementary scripts used: NO
+## Retries: 0
+
+## Classification
+
+**U1-B — DIFFERENT REJECTION.** Rejected for "Update contains no meaningful change" at the `proposal_compatibility` stage. This differs from:
+- U1-A (correct fidelity rejection): no semantic strengthening was present in `userSupportedMeaning`
+- U1-C (applied with both dimensions): no nodes or edges were added at all
+- U1-D (applied but degraded): nothing was applied
+
+The LLM's answer meaning extraction was semantically faithful (preserved both evidence dimensions), but produced zero structural change — no addedNodes, no addedEdges, no resolvedUnknownNodeIds, no updatedNodes. The proposal compatibility gate correctly blocked a structurally empty update.
+
+## What this clean run establishes
+
+1. When the LLM produces a **structurally empty** proposal (zero additions) even with semantically faithful answer meaning, the `proposal_compatibility` gate rejects it with "Update contains no meaningful change" — a valid protection against no-op updates.
+2. The LLM did not strengthen meaning beyond the raw answer in this run (U1-A would have been appropriate if strengthening were present).
+3. Cold-start produced 10 nodes (different from prior runs: Ex 57J.34 got 6–8; Ex 57J.32 got 5–8), confirming cold-start node variance persists.
+
+## What it does NOT prove
+
+1. Whether the LLM can produce a **structurally non-empty** faithful proposal that passes `proposal_compatibility` (the structural creation step may be separately impaired).
+2. That downstream progress on Update 2 would occur even with an accepted proposal.
+3. Run-to-run stability of node counts or proposal structure for this scenario.
+4. Whether the "no meaningful change" rejection is desirable behaviour when the user clearly introduces new information but the model fails to act on it structurally.
+
+## Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434
+## Production code changed: NO
+## Prompt changed: NO
+## Canonical harness restored: YES
+## Hardened no-retry behaviour preserved: YES
+## Dev server disturbed: NO
+## Ollama calls beyond harness count: 0
@@ -0,0 +1,172 @@
+# Experiment 57J.37 — Semantic-to-Mutation Contract Gap Diagnosis (Read-Only)
+
+## Objective
+
+Answer: **When `answerMeaning.userSupportedMeaning` clearly contains newly introduced unresolved uncertainty, does the current graph-update prompt/validator contract require the proposal to represent that uncertainty structurally, or is an empty mutation still permitted by the model contract and merely rejected later as a no-op?**
+
+This is a read-only deterministic diagnosis. No Ollama calls. No live API. No production code changes. No test changes.
+
+## Retained Meaning (fixed)
+
+```
+Before deciding on relocation, the user requires two specific pieces of evidence: verification that projected office savings are realistic, and assurance that the move will not materially increase the loss of key engineers.
+```
+
+With `possibleInference = null`.
+
+## Starting HEAD
+
+`b341c9c` — experiment: rerun guarded multi-turn progress cleanly
+
+---
+
+## Part 1 — Prompt Contract
+
+### Relevant new-uncertainty instructions in `lib/graph/prompt-builder.js`
+
+| # | Instruction (verbatim excerpt) | Classification |
+|---|-------------------------------|----------------|
+| 6 | "Then inspect the answer for newly introduced consequential uncertainty." | MUST |
+| 7 | "Add new unknown nodes only when the answer introduces a new decision, claim, object, measure, dependency, or unresolved term directly relevant to the case." | MUST (restrictive) / AMBIGUOUS (obligative) |
+| 8 | "Add at most 3 new unknown nodes." | MUST |
+| 9 | "Every new unknown must be directly traceable to the user's answer and its description must state why that uncertainty matters." | MUST |
+| 9a | "...explicitly include a short why-it-matters clause..." | MUST |
+| 11 | "Do not add duplicate unknowns." | MUST |
+| 16 | "If consequential unresolved unknowns exist, selectedQuestion **may** identify one valid candidate unknown..." | MAY |
+| Additional-Guidance-1 | "If the answer only clarifies an existing unknown, prefer updatedNodes and resolvedUnknownNodeIds over creating duplicate nodes." | SHOULD (prefers) |
+| Additional-Guidance-2 | "If you add a new unknown, do not leave it floating: connect it with an added edge..." | MUST (conditional) |
+| Additional-Guidance-3 | "Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved." | MAY (permits semantic-only) |
+| Rule-21 | "Use empty arrays when there are no changes in a category." | MUST (defaulting) |
+
+### Does prompt explicitly require structural representation of newly introduced unresolved uncertainty?
+
+**PARTIAL**
+
+**Why:** Instruction #6 creates an inspection obligation ("inspect the answer for newly introduced consequential uncertainty"). Instructions #7–#9 describe what to do *when* new unknowns are found, but #7 uses "Add new unknown nodes only when..." which is grammatically a **restriction** (you may not add unless...) rather than a clear **requirement** (you must add when...). Rule 16 uses "may" for selectedQuestion. The Additional Guidance explicitly permits semantic-only output ("Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved"). Thus, while the model is told to *inspect* for new uncertainty and shown what to do with it if found, there is no explicit MUST that forces structural materialization when new consequential uncertainty is detected.
+
+---
+
+## Part 2 — Schema Contract
+
+**SCHEMA VALID**
+
+The `graphUpdateSchema` (lib/graph/schema.js, line 178) permits:
+```json
+{
+  "answerMeaning": { "userSupportedMeaning": "<text>", ... },
+  "updatedNodes": [],
+  "resolvedUnknownNodeIds": [],
+  "addedNodes": [],
+  "addedEdges": []
+}
+```
+
+All array fields have `.default([])`, and `answerMeaning` has `.default(null)` (nullable). The schema imposes no cross-field constraint requiring that a populated `answerMeaning` must be accompanied by non-empty structural mutation fields. Test at line 156-158 confirms empty object `{}` passes validation.
+
+---
+
+## Part 3 — Validator Contract
+
+### Function: `validateGraphUpdate(graph, update)` in `lib/graph/utils.js`, lines 847–894
+
+### Exact no-op condition (lines 868–885):
+```javascript
+const statusChanged = update.updatedNodes.some(
+  (u) => u.previousStatus !== null && u.newStatus !== u.previousStatus,
+);
+const valueChanged = update.updatedNodes.some(
+  (u) => (u.previousValue ?? null) !== (u.newValue ?? null),
+);
+
+const hasMeaningfulChange =
+  update.addedNodes.length > 0 ||
+  statusChanged ||
+  valueChanged ||
+  update.addedEdges.length > 0 ||
+  update.removedEdgeIds.length > 0;
+
+if (!hasMeaningfulChange) {
+  errors.push("Update contains no meaningful change");
+}
+```
+
+### Does `answerMeaning` count as meaningful change?
+**NO.** The validator checks only structural fields. `answerMeaning` is not referenced in the `hasMeaningfulChange` computation.
+
+### Is rejection of semantic-only no-op proposal correct under current graph semantics?
+**YES**, under the *current* semantics where the graph is a strict mutation ledger and `answerMeaning` is metadata, not a structural change. The rejection is internally consistent: the graph structure didn't change, so the update is a no-op from the graph's perspective.
+
+---
+
+## Part 4 — Responsibility Boundary
+
+### A — MODEL FAILED AN EXPLICIT CONTRACT
+**NO.** No explicit "MUST materialize new consequential uncertainty as unknown nodes" instruction exists in the prompt. The model's inspection at rule #6 was fulfilled (it extracted meaning), but there is no mandatory bridge from "inspected" to "structurally represented."
+
+### B — PROMPT CONTRACT IS AMBIGUOUS
+**YES.** Rule #7 ("Add new unknown nodes only when...") reads as a restriction rather than a requirement. Instructions #8-#9 describe constraints *on* additions but don't mandate additions. Additional Guidance explicitly permits semantic-only proposals ("Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved").
+
+### C — SCHEMA/VALIDATOR CONTRACT IS INCONSISTENT
+**YES.** The schema semantically allows populated `answerMeaning` + zero mutation. The Additional Guidance tells the model it can use `answerMeaning` for this purpose. But the validator later rejects this exact combination as a no-op. The model receives permissive guidance that leads to a rejected outcome through a gate it cannot anticipate (no semantic meaning = meaningful change).
+
+### D — EXISTING GRAPH MAY ALREADY CONTAIN THE MEANING
+**PARTIAL.** The contract instructs: "Do not add duplicate unknowns" and "prefer updatedNodes... over creating duplicate nodes." If the cold-start graph already contained unknowns for these two evidence dimensions, an empty mutation would be defensible. However, without inspecting the 57J.36 cold-start graph state, this possibility cannot be confirmed or ruled out. The retained experiment record (57J.34) shows that cold-start produced a "single merged generic unknown" rather than two distinct evidence-dimension unknowns — suggesting partial overlap is possible but not complete.
+
+---
+
+## Part 5 — Test Coverage
+
+### Existing test for: grounded answerMeaning introduces new unresolved uncertainty + proposal makes zero structural changes
+
+**NOT COVERED**
+
+The closest tests are:
+1. `schema.test.js` line 156: "validates empty update (no-op proposal)" — validates `{}` passes the **schema** gate (confirms schema validity)
+2. `utils.test.js` line 932: "rejects update with no meaningful change" — tests that all-empty structural arrays are rejected by the **validator**
+3. `apply-proposal.test.js` line 705: same as #2 but via the application pipeline
+
+None of these test the specific case of **populated `answerMeaning` + zero structural mutation**. The apply-proposal no-op test (line 705) uses an update with `updatedNodes` containing a null-status-change entry but **no `answerMeaning`** at all.
+
+---
+
+## Classification: E — MIXED
+
+### Why:
+
+Three independent contract boundaries contribute to the failure:
+
+1. **Prompt contract (B):** Ambiguity between "inspect for new uncertainty" and "must materialize new uncertainty." Rule #7 is a restrictive clause, not an obligatory one. Additional Guidance explicitly permits semantic-only proposals.
+2. **Schema contract (C — permissive):** Schema accepts the combination that later gets rejected. The test confirms `{}` passes schema validation, meaning populated `answerMeaning` + empty arrays is trivially schema-valid.
+3. **Validator contract (C — rejecting):** The validator's "meaningful change" check explicitly excludes `answerMeaning`. The model follows permissive guidance and hits a downstream gate that contradicts the guidance.
+
+The model is caught in a triple-bind: it correctly extracts meaning (as instructed), uses it exactly as permitted by the schema, receives permissive guidance about semantic-only proposals, and then gets rejected by an invariant not communicated to it.
+
+---
+
+## Who currently owns the failure: MIXED
+
+- **Prompt Contract** owns the ambiguity between inspection and materialization
+- **Validator Contract** owns the mismatch between schema-permitted inputs and validator-rejected outputs  
+- **Model** does NOT own this failure — no explicit instruction was violated
+
+## What 57J.37 now legitimately establishes:
+
+1. The prompt contract is ambiguous on whether newly introduced consequential uncertainty must be structurally materialized.
+2. The schema contract explicitly permits populated `answerMeaning` + zero structural mutation (all array fields default to `[]`).
+3. The validator contract does NOT consider `answerMeaning` as a meaningful change — only structural graph mutations count.
+4. There is no existing test that covers the exact case of "grounded answerMeaning introduces new unresolved uncertainty + zero structural changes."
+
+## What it does NOT establish:
+
+1. Whether the cold-start graph from 57J.36 already contained nodes matching these two evidence dimensions (D possibility unverified).
+2. Which single classification (B vs C) is primary — both boundaries are materially implicated.
+3. A specific fix direction — this diagnoses the gap but does not prescribe resolution.
+
+---
+
+Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434
+Production code changed: NO
+Prompt changed: NO
+Tests changed: NO
+Dev server disturbed: NO
+Ollama calls made: 0
@@ -0,0 +1,249 @@
+# Experiment 57J.38 — Semantic-to-Mutation Contract Fix Selection (Read-Only Design)
+
+## Objective
+
+Answer: **What is the smallest safe contract change that ensures a faithful answer containing consequential unresolved uncertainty cannot return only `answerMeaning` with zero structural mutation?**
+
+This follows 57J.37's diagnosis of three contributing boundaries:
+1. Prompt contract ambiguity (inspecting ≠ materializing)
+2. Schema permissiveness vs validator rejection mismatch
+3. Validator ignores `answerMeaning` in meaningful-change check
+
+## Starting HEAD
+
+`77f5ea2` — experiment: locate semantic-to-mutation contract gap
+
+---
+
+## Key Findings from Code Audit (300-line budget)
+
+### Prompt-Builder Current State (`lib/graph/prompt-builder.js`)
+
+**Rule #6:** "Then inspect the answer for newly introduced consequential uncertainty." — creates inspection obligation but not materialization requirement.
+
+**Rule #7:** "Add new unknown nodes only when..." — grammatically a restriction, not a requirement.
+
+**Additional Guidance (line 132):** "Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved." — explicitly permits semantic-only output.
+
+**Gap:** The model is told to inspect for new uncertainty, shown what to do if found, but also explicitly permitted to use semantic-only output. No explicit MUST bridges inspection to materialization.
+
+### Validator Current State (`lib/graph/utils.js` lines 868–885)
+
+```javascript
+const hasMeaningfulChange =
+  update.addedNodes.length > 0 ||
+  statusChanged ||
+  valueChanged ||
+  update.addedEdges.length > 0 ||
+  update.removedEdgeIds.length > 0;
+// answerMeaning NOT referenced
+```
+
+Purely structural. `answerMeaning` is never considered meaningful change.
+
+### Schema Current State (`lib/graph/schema.js` line 178–187)
+
+All array fields default to `[]`. `answerMeaning` defaults to `null` (nullable). No cross-field constraint exists. Test at line 156 confirms `{}` passes schema validation.
+
+### Test Coverage Gap
+
+No test for "populated `answerMeaning.userSupportedMeaning` + zero structural mutation remains rejected." The closest tests verify:
+- Schema allows empty update (schema.test.js:156)
+- Validator rejects all-empty-arrays (utils.test.js:932) — but without any `answerMeaning`
+- Snapshot captures rejected proposals with various combinations (rejected-proposal-snapshot.test.js)
+
+---
+
+## Option Evaluation
+
+### OPTION A — PROMPT ONLY
+
+Add one explicit MUST rule to Additional Guidance:
+
+> If `answerMeaning.userSupportedMeaning` contains consequential information or unresolved uncertainty that is not already represented in the graph, the proposal MUST express its effect through at least one structural mutation. `answerMeaning` alone is not sufficient.
+
+**Fixes 57J.36:** PARTIAL — addresses prompt ambiguity but relies entirely on model compliance. If the model ignores instruction (as it did in 57J.36), rejection will still be the generic "no meaningful change" with no diagnostic clarity about *why* mutation is required.
+
+**Duplicate risk:** LOW — existing rules #11 ("Do not add duplicate unknowns") and Additional Guidance preference for `updatedNodes` over new nodes already in place. The prompt rule says "express its effect through at least one structural mutation" without prescribing which type of mutation, so the model could update/resolve an existing node instead of creating a new one.
+
+**Requires new semantic classifier:** NO — uses plain text detection (is `userSupportedMeaning` non-empty + all structural fields empty).
+
+**Changes schema:** NO
+
+**Changes validator:** NO
+
+**Changes prompt:** YES — one additional sentence in Additional Guidance, plus replacement of line 132 to remove the "semantic-only permitted" language.
+
+**Provider-specific:** NO
+
+**Risk of rejecting legitimate no-op/restatement:** MEDIUM — if the answer restates information already fully represented and the LLM produces `userSupportedMeaning` text that is technically non-empty but semantically identical to graph content, rejection still occurs (correctly, under the invariant). But the model may struggle to determine when materialization is actually unnecessary versus when it should still express meaning through existing structure.
+
+### OPTION B — PROMPT + SPECIFIC VALIDATOR CONTRACT
+
+Same prompt rule as A PLUS a deterministic compatibility check producing a specific error:
+
+```javascript
+// In validateGraphUpdate() after hasMeaningfulChange check:
+if (update.answerMeaning?.userSupportedMeaning && !hasMeaningfulChange) {
+  errors.push("Answer introduces new information that must be structurally represented — cannot return only answerMeaning without graph mutation.");
+}
+```
+
+**Fixes 57J.36:** YES — addresses both the prompt ambiguity AND provides a deterministic enforcement layer that survives model instruction-following failure.
+
+**Duplicate risk:** LOW — specific error message guides correction ("must be structurally represented") without prescribing node creation. The existing rules about duplicates, updatedNodes preference, and relationship-based mutations still apply.
+
+**Requires new semantic classifier:** NO — purely structural check: is `userSupportedMeaning` non-empty AND all structural fields empty? Zero semantics involved.
+
+**Changes schema:** NO
+
+**Changes validator:** YES — one addition after the existing `hasMeaningfulChange` check (5 lines). Does NOT replace existing no-op rejection; adds an additional condition that fires first.
+
+**Changes prompt:** YES — same as A.
+
+**Provider-specific:** NO
+
+**Risk of rejecting legitimate no-op/restatement:** LOW — if userSupportedMeaning is non-empty and all structural fields are empty, the rejection is correct under the invariant. If the meaning IS already fully represented in existing graph structure, the guidance says "update/resolve an existing node" rather than "create nothing." The only edge case: if the LLM produces `userSupportedMeaning` for information that was already fully represented AND it cannot determine how to express it structurally without violating other rules (e.g., can't update because no matching node exists, can't add because not genuinely new), but this is a prompt design question, not an option-specific problem.
+
+### OPTION C — SCHEMA CROSS-FIELD REQUIREMENT
+
+Add `.refine()` to `graphUpdateSchema`:
+
+```javascript
+.graphTransform((val) => val)
+.refine(
+  (data) => {
+    if (data.answerMeaning?.userSupportedMeaning && data.userSupportedMeaning.length > 0) {
+      return data.addedNodes.length > 0 ||
+             data.updatedNodes.some(u => u.newStatus !== null || u.newValue !== null) ||
+             data.addedEdges.length > 0;
+    }
+    return true;
+  },
+  { message: "Populated answerMeaning with new information requires at least one structural mutation" }
+);
+```
+
+**Fixes 57J.36:** PARTIAL — schema enforcement means the invalid proposal never reaches validation, but provides no diagnostic explanation to downstream consumers (HTTP API). The error is a Zod refinement failure, not an application-level semantic rejection with actionable guidance.
+
+**Duplicate risk:** MEDIUM — schema requires mutation but doesn't guide toward what type. Could push models toward creating new unknown nodes rather than updating existing ones when existing structure could serve.
+
+**Requires new semantic classifier:** NO — purely structural check same as B (non-empty userSupportedMeaning + empty structural fields).
+
+**Changes schema:** YES — adds cross-field constraint.
+
+**Changes validator:** NO
+
+**Changes prompt:** NO
+
+**Provider-specific:** NO
+
+**Risk of rejecting legitimate no-op/restatement:** HIGH — breaks Case 5. If `answerMeaning` has only `possibleInference` (no consequential `userSupportedMeaning`) but the object is still populated, schema rejects. This is a false rejection: possibleInference alone does not establish new consequential uncertainty requiring structural representation. The schema-level check cannot distinguish "meaningful new meaning" from "inference-only."
+
+---
+
+## Controlled Cases Evaluation
+
+### Case 1 — Genuinely New Uncertainty ("whether projected savings are realistic", no equivalent in graph)
+
+| Option | Result | Notes |
+|--------|--------|-------|
+| A | STRUCTURAL MUTATION REQUIRED ✓ | Prompt MUST rule directs model to create nodes/edges. Model may or may not comply. Rejection if it doesn't = generic "no meaningful change" (unclear why). |
+| B | STRUCTURAL MUTATION REQUIRED ✓ | Same prompt + specific error if model fails: clearly states mutation required. Best diagnostic visibility. |
+| C | REJECTED ✓ | Schema blocks immediately with refinement error. No diagnostic guidance about what to fix. |
+
+### Case 2 — Answer Meaning Already Fully Represented (restatement, no new info)
+
+| Option | Result | Notes |
+|--------|--------|-------|
+| A | REJECTION CORRECT ✓ | "answerMeaning alone is not sufficient" covers this case. Model should update existing node or accept rejection. |
+| B | REJECTION CORRECT ✓ | Same logic, with clearer error message. |
+| C | REJECTION CORRECT ✓ | Schema blocks. But: no guidance on whether to update existing or create new. |
+
+### Case 3 — Answer Resolves/Refines Existing Structure (evidence for existing unknown)
+
+| Option | Result | Notes |
+|--------|--------|-------|
+| A | UPDATE EXISTING NODE ✓ | Prompt says "express effect through structural mutation" — updating an existing node counts. No duplicate created. |
+| B | UPDATE EXISTING NODE ✓ | Same guidance + specific error if model still produces empty mutation (points to need for structural change). |
+| C | UPDATE EXISTING NODE ✓ | Schema allows updateNodes as valid mutation path. Correct behavior. |
+
+### Case 4 — answerMeaning null (existing structurally valid proposal)
+
+| Option | Result | Notes |
+|--------|--------|-------|
+| A | UNCHANGED ✓ | No userSupportedMeaning → prompt rule is conditional, does not trigger. |
+| B | UNCHANGED ✓ | Null means condition doesn't fire. Existing no-op validator handles structural correctness independently. |
+| C | UNCHANGED ✓ | Schema refinement checks `answerMeaning?.userSupportedMeaning` — null passes through. |
+
+### Case 5 — possibleInference Only (no userSupportedMeaning establishing new consequential uncertainty)
+
+| Option | Result | Notes |
+|--------|--------|-------|
+| A | NO FORCED MUTATION ✓ | Rule is conditional on `userSupportedMeaning`. Inference-only does not trigger. Correct. |
+| B | NO FORCED MUTATION ✓ | Same — checks `userSupportedMeaning` specifically, not the entire answerMeaning object. Correct. |
+| C | FORCES MUTATION ✗ | **BREAKS.** Schema refinement on `answerMeaning` object would see a populated object (possibleInference exists) and force mutation even though no new consequential uncertainty was established. This is a critical flaw: the schema cannot distinguish meaning from inference without semantic analysis, which we explicitly said not to require. |
+
+---
+
+## Recommendation: OPTION B — PROMPT + SPECIFIC VALIDATOR CONTRACT
+
+### Why
+
+1. **Fixes 57J.36 completely** (unlike A's partial fix and C's partial fix):
+   - Prompt removes ambiguity between "inspect" and "must materialize"
+   - Validator catches the specific failure pattern the model actually produces (faithful meaning + empty mutation)
+   - Error message is actionable: tells the model exactly what is missing
+
+2. **No new semantic classifier needed** — uses only structural detection (non-empty text field vs empty array fields). Zero semantic machinery.
+
+3. **Preserves provider-agnostic design** — changes are deterministic text/schema/validator, not semantic matching or LLM-assisted checks.
+
+4. **Does not force duplicate unknowns** — requires "at least one structural mutation" without prescribing node creation. Existing rules about duplicates and updating existing nodes remain fully in effect.
+
+5. **Does not break valid cases** — Case 4 (null answerMeaning) passes through unchanged. Case 5 (possibleInference only) is handled because the check targets `userSupportedMeaning` specifically, not the entire answerMeaning object. Option C breaks Case 5.
+
+6. **Option A's weakness**: relies entirely on model instruction following. The very evidence that motivated this experiment (57J.36: faithful meaning + zero mutation) demonstrates the model *can* and *does* follow instructions ambiguously. A specific validator error is needed for cases where prompt instruction fails.
+
+7. **Option C's fatal flaw**: schema-level enforcement cannot distinguish between "meaningful new information" and "inference-only" without a semantic classifier, which violates the constraint of not requiring new semantic machinery.
+
+---
+
+## Required Deterministic Regressions (design only)
+
+1. **Populated faithful `answerMeaning` + zero mutation remains rejected** — validator rejects with specific error message (not generic "no meaningful change"); rejection stage = `proposal_compatibility`; no schema or prompt modification required for this test since existing rejection already applies, but the *error text* should be different and verifiable.
+
+2. **Prompt explicitly states structural mutation requirement** — snapshot test of buildGraphUpdatePrompt output confirms Additional Guidance contains MUST-language about structural representation when `answerMeaning` has consequential content.
+
+3. **`answerMeaning = null` + valid mutation unchanged** — existing behavior preserved: structurally valid proposal with no answerMeaning passes through identical validation path, zero new errors introduced.
+
+4. **possibleInference only does not force mutation** — proposal where `answerMeaning` has only `possibleInference` (no `userSupportedMeaning`) and empty structural fields: if there IS meaningful structural change via other paths, the specific error must NOT fire. Test the boundary where `userSupportedMeaning` is absent or empty string vs present with consequential text.
+
+5. **Existing relevant unknown must not be duplicated** — proposal that updates an existing node (updatedNodes non-empty) to represent new uncertainty: should pass without triggering duplicate-node errors. The structural-mutation requirement is satisfied by the update, not rejected for forcing a new node.
+
+6. **Existing update/resolve path counts as valid structural progress** — proposal with resolvedUnknownNodeIds and/or updatedNodes status/value changes passes validation regardless of whether `answerMeaning` is populated or empty. This confirms the existing update/resolve path is not blocked by any new constraint.
+
+---
+
+## Stop Condition for Implementation
+
+Implementation stops when:
+1. One MUST rule added to prompt Additional Guidance (replaces line 132)
+2. One deterministic check added to `validateGraphUpdate()` after `hasMeaningfulChange`
+3. Six regression tests pass (above)
+4. Existing test suite unchanged
+
+## What This Intentionally Leaves Unsolved
+
+- Whether the model should *always* produce a structurally non-empty proposal when new uncertainty exists — this is a prompt design question, not a contract enforcement question
+- Cold-start graph instability affecting which unknowns are "already represented" (57J.34/57J.36 variance) — a separate investigation
+- Whether the error message should guide toward update vs addNode strategies — future prompt refinement
+- Whether `answerMeaning` should eventually be treated as structural metadata rather than optional metadata — architectural decision, out of scope
+
+---
+
+**Classification: B — PROMPT + VALIDATOR CONTRACT CHOSEN**
+
+The validator already correctly rejects no-ops; the gap is (1) ambiguous prompt guidance that leads to rejected proposals and (2) lack of specific diagnostic when the specific semantic-only-no-op pattern occurs. Both are fixed by adding clear instruction + targeted enforcement with zero semantic classification machinery.
+
+Configured Ollama: none used. Production code changed: NO. Prompt changed: NO. Tests changed: NO. Dev server disturbed: NO. Ollama calls: 0.
@@ -0,0 +1,71 @@
+### Experiment 57J.39 — Semantic-to-Mutation Contract Implementation (Option B)
+
+**Objective:** Implement the agreed Option B from 57J.38 with ownership correction: prompt owns structural materialization obligation, validator owns only the structural fact that `answerMeaning` alone is not graph progress.
+
+**Implementation boundary (strict):**
+1. One MUST rule in prompt Additional Guidance (replaced rule #6 in prompt-builder.js)
+2. One deterministic check in `validateGraphUpdate()` after `hasMeaningfulChange` (utils.js)
+3. Focused tests proving each contract case
+
+**Changes to production code:**
+
+#### Prompt contract (lib/graph/prompt-builder.js)
+Replaced ambiguous rule #6 ("Then inspect the answer for newly introduced consequential uncertainty.") with explicit MUST:
+
+> "If answerMeaning.userSupportedMeaning contains consequential information or unresolved uncertainty that is not already represented in the graph, you MUST express its effect through structural mutation. This may be an update/refinement of existing structure, resolution of an existing unknown, a genuinely new unknown, or a justified relationship. answerMeaning alone is not sufficient for a successful proposal."
+
+#### Validator contract (lib/graph/utils.js)
+Added specific diagnostic inside the existing `!hasMeaningfulChange` rejection path:
+
+> "answerMeaning.userSupportedMeaning is populated, but the proposal contains no graph mutation. answerMeaning alone does not constitute graph progress."
+
+This diagnostic fires BEFORE the generic "Update contains no meaningful change" only when `userSupportedMeaning` is populated AND there is zero structural mutation. The generic error remains for all other structurally empty proposals.
+
+**Not changed:**
+- `hasMeaningfulChange` definition (variable still computes the same structural fields)
+- Schema
+- Graph node/edge semantics
+- Provenance, answerability, decomposition, reasoning taxonomy
+- Semantic overlap rules or classifiers
+- Provider integration or Behaviour Selection
+- `possibleInference` handling
+
+**Tests added:**
+
+*utils.test.js — semantic-to-mutation contract (8 tests):*
+1. semantic-only no-op → REJECT with specific error (not generic)
+2. ordinary no-op (answerMeaning null) → REJECT with "no meaningful change"
+3. possibleInference only → does NOT trigger new error, generic no-op applies
+4. update existing structure (status change) → ACCEPT past guard
+5. resolve existing unknown → counts as structural progress
+6. add new structure (new unknown) → counts as structural progress
+7. duplicate avoidance preserved with populated userSupportedMeaning
+8. value-only change → counts as structural progress
+
+*prompt-builder.test.js — MUST rule verification (7 tests):*
+9-15. Verify prompt contains MUST rule, permits update/resolve/new unknown, states answerMeaning alone insufficient, does not force new node, references userSupportedMeaning not possibleInference
+
+**Test results:**
+- utils.test.js: 68 passed (0 failed)
+- prompt-builder.test.js: 15 passed (0 failed)
+- cases-update-route.test.js: 13 passed (0 failed)
+- harness tests: 8 passed (0 failed)
+- rejected-proposal-snapshot.test.js: 7 passed (0 failed)
+- orchestrator.test.js: 31 passed, 1 pre-existing failure (unrelated)
+
+**What this implementation now guarantees:**
+- A proposal with populated `userSupportedMeaning` and zero structural mutation receives a specific, actionable rejection error — not the generic no-op message
+- The prompt explicitly instructs the model that meaningful user-supported meaning must be expressed through graph structure, not just stated in answerMeaning
+- No new semantic classifier, schema change, or provider-specific logic is introduced
+- possibleInference alone does not trigger the specific diagnostic
+- Duplicate avoidance and all existing validation behavior is preserved
+
+**What it intentionally does NOT guarantee:**
+- That `userSupportedMeaning` contains truly consequential meaning (validator doesn't judge that)
+- That the LLM will comply with the MUST rule in live use (that requires empirical verification)
+- Resolution of cold-start variance or other downstream defects
+
+**Classification: E — IMPLEMENTATION COMPLETE**
+Configured Ollama: none used. Production code changed: prompt-builder.js, utils.js. Tests permanently changed: utils.test.js (+8), prompt-builder.test.js (+7). Dev server disturbed: NO. Ollama calls: 0.
+
+---
@@ -0,0 +1,133 @@
+# Experiment 57J.40 — Semantic-to-Mutation Contract Live Validation
+
+**Objective:** On one fresh live run, does the v0.17 prompt contract cause a faithful `userSupportedMeaning` to produce meaningful structural graph mutation instead of a semantic-only no-op proposal?
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.17`
+**Starting HEAD:** 712c0c4 docs: experiment 57J.39 record and handoff update
+
+## Pre-written expectation
+
+The raw answer contains two explicit unresolved evidence needs: projected savings realism and key-engineer retention impact. If v0.17 closes the semantic-to-mutation contract gap, a faithful `userSupportedMeaning` should no longer be accompanied by a completely empty structural proposal. The model should either update/refine existing relevant graph structure, resolve relevant structure, or add justified new structure.
+
+A semantic-strengthening rejection remains a valid protected outcome and does not count as failure of v0.17. The specific failure under test is faithful `userSupportedMeaning` plus zero structural mutation.
+
+## Configuration
+
+- **Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+- **Answer:** "Before deciding, I need evidence that the projected office savings are realistic and evidence that the move will not materially increase loss of key engineers."
+- **maxUpdates:** 1
+- **Configured model:** qwen-claude:latest at http://192.168.1.111:11434
+- **Dev server:** REUSED EXISTING (HTTP 200)
+
+## Run
+
+### Call Accounting
+
+startCalls: 1
+updateCalls: 1
+totalCalls: 2
+
+### START
+
+```
+HTTP status: 200
+stage: unknown
+selected question: "What was the comparable state before current baseline costs vs. projected costs at target location?"
+node count: 8
+edge count: 5
+```
+
+### UPDATE 1
+
+```
+HTTP status: 422
+stage: proposal_compatibility
+First error: "answerMeaning.userSupportedMeaning introduces a stronger reasoning category than the raw answer establishes."
+selected question: null
+node count: 8 (unchanged)
+edge count: 5 (unchanged)
+```
+
+**Rejected Proposal Snapshot:**
+```json
+{
+  "answerMeaning": {
+    "userSupportedMeaning": "Proceeding with the relocation decision is explicitly conditional on obtaining verified evidence that projected office savings are realistic and that key engineer retention is preserved.",
+    "possibleInference": null
+  },
+  "updatedNodes": [],
+  "resolvedUnknownNodeIds": [],
+  "addedNodes": [
+    {
+      "id": "n_prereq_constraint",
+      "kind": "assumption",
+      "label": "Prerequisite condition for proceeding",
+      "description": "Relocation decision requires verified evidence that projected office savings are realistic and that key engineer retention is preserved.",
+      "parentId": null,
+      "dependsOn": ["nqylvkl"],
+      "affects": [],
+      "childIds": []
+    }
+  ],
+  "addedEdges": [
+    {
+      "fromNodeId": "n_prereq_constraint",
+      "toNodeId": "nqylvkl",
+      "relationship": "depends_on"
+    }
+  ]
+}
+```
+
+## Analysis
+
+### Meaning Fidelity
+
+**Classification: STRENGTHENED**
+
+The model transformed the raw answer:
+- **Raw:** "Before deciding, I need evidence that X and Y." (statement of information-need)
+- **Produced:** "Proceeding with the relocation decision is explicitly conditional on obtaining verified evidence that X and Y." (prescriptive constraint on the decision)
+
+This is a non-trivial semantic strengthening. The model converted a neutral report of what it needs ("I need evidence...") into prescriptive language about what the *decision* requires ("the decision is explicitly conditional on..."). This introduces a `conditional_qualification` meaning category stronger than the raw answer supports.
+
+### Structural Mutation
+
+```
+updatedNodes: 0
+resolvedUnknownNodeIds: 0
+addedNodes: 1 (n_prereq_constraint, kind=assumption)
+addedEdges: 1 (depends_on → nqylvkl)
+```
+
+The model did produce minimal structural mutation (1 new node + 1 edge). However, this mutation is built on the strengthened meaning, not a faithful translation of the raw answer. The added node's label ("Prerequisite condition for proceeding") and description directly reflect the prescriptive framing introduced by the strengthening, not the neutral information-need stated by the user.
+
+### Classification: C — CORRECT FIDELITY REJECTION
+
+The model strengthened the raw answer beyond what it supports, and the existing semantic-fidelity validator correctly rejected this at `proposal_compatibility`. This is not a v0.17 semantic-to-mutation failure because the strengthening was caught at the semantic fidelity layer before reaching the mutation boundary.
+
+## Did v0.17 remove the faithful semantic-only no-op failure?
+
+**UNPROVEN**
+
+This run did not test v0.17's core question because the model never produced a faithful `userSupportedMeaning`. The strengthening occurred before reaching the mutation boundary, so v0.17's MUST rule was never exercised. A faithful semantic-only no-op is neither reproduced nor disproved here.
+
+## What this run establishes
+
+1. The configured model maps "Before deciding, I need evidence..." to prescriptive conditional framing on this scenario — a repeatable strengthening pattern observed in Experiments 57J.32, 57J.33.
+2. The existing semantic-fidelity guard catches this class of strengthening at proposal_compatibility.
+3. When meaning is strengthened and rejected, the model's structural proposal reflects the strengthened framing rather than faithful translation.
+
+## What this does NOT prove
+
+1. That the configured model produces faithful `userSupportedMeaning` on this scenario under repeated runs.
+2. That v0.17's MUST rule prevents the faithful semantic-only no-op when meaning is genuinely preserved.
+3. That strengthening avoidance would occur with different phrasing, domain, or model.
+4. That v0.17 works in any case where the model does produce faithful meaning.
+
+## Production code changed: NO
+## Prompt changed during experiment: NO
+## Harness restored: YES
+## No-retry preserved: YES
+## Dev server disturbed: NO
+## Ollama calls beyond harness count: 0
@@ -0,0 +1,117 @@
+# Experiment 57J.41 — Semantic-to-Mutation Contract Live Validation: Faithful Meaning Only
+
+**Objective:** When the user introduces one simple, explicit unresolved uncertainty with no conditional/constraint language, does v0.17 translate that faithful meaning into structural graph progress rather than a semantic-only no-op?
+
+57J.40 could not test this because Qwen strengthened the original answer into a decision condition. This experiment deliberately removes that confound.
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.17`
+**Starting HEAD:** 39217b6 experiment: validate semantic-to-mutation contract live
+
+## Pre-written expectation
+
+The answer introduces one clear unresolved uncertainty: whether projected office savings are realistic. A faithful proposal should preserve that uncertainty and express its effect structurally, either by updating/refining equivalent existing graph structure or by adding justified new structure. `answerMeaning` alone with zero graph mutation is the specific failure under test.
+
+## Configuration
+
+- **Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+- **Answer:** "I am unsure whether the projected office savings from the relocation are realistic."
+- **maxUpdates:** 1
+- **Configured model:** qwen-claude:latest at http://192.168.1.111:11434
+- **Dev server:** REUSED EXISTING (HTTP 200)
+
+## Run
+
+### Call Accounting
+
+startCalls: 1
+updateCalls: 1
+totalCalls: 2
+
+### START
+
+```
+HTTP status: 200
+stage: unknown
+selected question: "What would clarify current annual operating costs and cost structure of the engineering team in this situation?"
+node count: 6
+edge count: 3
+```
+
+### UPDATE 1
+
+```
+HTTP status: 422
+stage: proposal_compatibility
+First error: "answerMeaning.userSupportedMeaning is populated, but the proposal contains no graph mutation. answerMeaning alone does not constitute graph progress."
+selected question: null
+node count: 6 (unchanged)
+edge count: 3 (unchanged)
+```
+
+**Rejected Proposal Snapshot:**
+```json
+{
+  "answerMeaning": {
+    "userSupportedMeaning": "The user is unsure whether the projected office savings from the relocation are realistic.",
+    "possibleInference": null
+  },
+  "updatedNodes": [],
+  "resolvedUnknownNodeIds": [],
+  "addedNodes": [],
+  "addedEdges": []
+}
+```
+
+## Analysis
+
+### Meaning Fidelity
+
+**Classification: FAITHFUL**
+
+The `userSupportedMeaning` directly preserves the raw answer's uncertainty:
+- **Raw:** "I am unsure whether the projected office savings from the relocation are realistic."
+- **Produced:** "The user is unsure whether the projected office savings from the relocation are realistic."
+
+No conditional language. No constraint language. No decision requirement. No priority statement. The model preserved the simple uncertainty about savings realism without strengthening or degradation.
+
+`possibleInference` is null — appropriate for a direct, unambiguous single-dimension uncertainty.
+
+### Structural Mutation
+
+```
+updatedNodes: 0
+resolvedUnknownNodeIds: 0
+addedNodes: 0
+addedEdges: 0
+```
+
+Zero structural mutation across all fields. This is a semantic-only no-op at the proposal level.
+
+The rejection occurred at `proposal_compatibility` because the v0.17 MUST rule triggers when `userSupportedMeaning` is populated with zero structural mutation. The rejection error exactly matches the new contract diagnostic: "answerMeaning.userSupportedMeaning is populated, but the proposal contains no graph mutation."
+
+### Classification: B — SAME SEMANTIC-ONLY NO-OP
+
+Meaning is FAITHFUL. All structural mutation fields are empty.
+
+However, this is not a silent semantic-only no-op (which was the original 57J.36 problem). It is an **explicitly rejected** semantic-only no-op enforced by the v0.17 MUST rule + validator diagnostic. The model produced faithful meaning but zero structural progress, and the new contract boundary caught it before graph mutation could occur.
+
+## Did v0.17 remove the faithful semantic-only no-op failure?
+
+**UNPROVEN for positive outcome.** v0.17 successfully converts what would have been an accepted semantic-only no-op into a rejected proposal with a specific diagnostic error. This confirms the v0.17 contract fix (Option B) is working as designed — it blocks faithfulness-verified but structurally-empty proposals.
+
+However, v0.17 does NOT prove that faithful meaning CAN produce graph progress. It proves the opposite direction: that v0.17 prevents a semantically faithful proposal with zero structure from passing through. The open question remains unanswered — is there any valid pathway where faithful meaning translates to structural mutation under v0.17, or does the new constraint universally block it?
+
+## What this run establishes
+
+1. The configured model preserves the explicit uncertainty about savings realism without strengthening (direct improvement over 57J.40).
+2. The v0.17 MUST rule + validator diagnostic fires exactly as designed: faithful meaning with zero structural mutation → rejected at proposal_compatibility with specific error.
+3. The original 57J.36 failure pattern (accepted semantic-only no-op) is now blocked — the rejection is explicit and diagnostic.
+
+## What this does NOT prove
+
+1. That faithful meaning CAN produce graph progress under v0.17.
+2. Whether the model can simultaneously preserve faithfulness AND add justified structure for this or other scenarios.
+3. Whether the MUST rule is too aggressive — it may block both no-ops and legitimate partial-progress proposals.
+4. That cold-start quality (6 nodes) affects the outcome — but cold-start variance was not the variable under test here.
+
+Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434. 2 live calls total. No production code changed. Harness restored to original scenario/answers. No-retry preserved. Dev server disturbed: NO.
@@ -0,0 +1,241 @@
+# Experiment 57J.42 — Structural-Mutation MUST Rule: Prompt Conflict Diagnosis
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.17`
+**Starting HEAD:** 6aea0bd experiment: isolate semantic-to-mutation contract live
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly:
+
+> Why can the model still produce faithful `userSupportedMeaning` with zero structural mutation despite the new v0.17 MUST rule? Is another prompt instruction conflicting with, weakening, or making that obligation operationally ambiguous?
+
+57J.41 already proved the live failure — a faithful proposal with zero structural fields across all four categories. This is a read-only prompt-contract diagnosis. No Ollama calls. No API calls. No code/prompt/test changes.
+
+## Context Route
+
+Read files:
+1. `docs/current-handoff.md` (57J.41 entry)
+2. `lib/graph/prompt-builder.js` — the complete assembled graph-update prompt
+3. `tests/graph/prompt-builder.test.js` — focused tests on the MUST rule
+
+**Source read budget:** ~300 lines of prompt-builder.js + ~180 lines of test file.
+
+## Controlled Case Walkthrough
+
+**Meaning:** "The user is unsure whether the projected office savings from the relocation are realistic."
+**possibleInference:** null
+**Graph assumption:** current graph does NOT obviously contain a node named "realism of projected office savings" or semantic equivalent. The start produced 6 nodes — these are broad (operating costs, cost structure, etc.) but not an exact match for "savings realism".
+
+### What the prompt clearly requires
+
+Walking through rule-by-rule as the model would:
+
+**Step 1: Extract meaning.** Rule #26–30 apply. The answer says the user is unsure about savings realism. This goes into `userSupportedMeaning` per rules #26 and #30 (direct uncertainty). ✓ Clear obligation.
+
+**Step 2: Assess consequentiality.** Rule #6 triggers — the userSupportedMeaning contains unresolved uncertainty ("unsure whether projected office savings are realistic") which is consequential to the case (relocation decision). The prompt says MUST express its effect through structural mutation. ✓ Obligation exists.
+
+**Step 3: Choose action path.** Four options listed by rule #6:
+a) update/refine existing structure
+b) resolve an existing unknown
+c) a genuinely new unknown
+d) a justified relationship
+
+The model must decide which of these four paths to take. This is where ambiguity arises (see below).
+
+## RELEVANT PROMPT RULES
+
+### 1. Rule #6 — The v0.17 MUST Rule
+**Location:** prompt-builder.js line ~95, "Proposal Rules" section
+**Strength:** **MUST** ("you MUST express its effect through structural mutation")
+**Effect on structural mutation:** ENCOURAGES + OBLIGATES
+**Meaning:** If userSupportedMeaning contains consequential unresolved uncertainty not already represented, MUST express it structurally. AnswerMeaning alone is insufficient. Four acceptable forms: update/refine existing, resolve existing unknown, genuinely new unknown, or justified relationship.
+
+### 2. Rule #7 — New Unknown Restriction
+**Location:** prompt-builder.js line ~96, "Proposal Rules" section
+**Strength:** **MUST NOT** (restrictive boundary on *adding* nodes)
+**Effect on structural mutation:** RESTRICTS (specifically the "add new unknown" path)
+**Meaning:** Add new unknown nodes ONLY when the answer introduces a "new decision, claim, object, measure, dependency, or unresolved term directly relevant to the case." The word "adds" — does an uncertainty about realism qualify as an "unresolved term"? Unclear. This is ambiguous for our controlled case because the user didn't introduce a new *concept* — they expressed doubt about an already-mentioned one (projected office savings, which was implicit in the relocation question).
+
+### 3. Rule #5 — Resolve Existing Unknown First
+**Location:** prompt-builder.js line ~94
+**Strength:** **SHOULD** ("Resolve the answered unknown first when the answer supports it")
+**Effect on structural mutation:** NEUTRAL → ENCOURAGES (for resolve path)
+**Meaning:** If the answer supports resolving an existing unknown, do so first. Our controlled case does NOT answer any question — it expresses uncertainty about a concept. Rule #5 is inapplicable here.
+
+### 4. Additional Guidance Bullet A — Clarification Preference
+**Location:** prompt-builder.js line ~125
+**Strength:** **SHOULD** ("prefer updatedNodes and resolvedUnknownNodeIds over creating duplicate nodes")
+**Effect on structural mutation:** ENCOURAGES (update/resolve path)
+**Meaning:** If the answer only clarifies an existing unknown, prefer updating/resolving. Our controlled case is NOT clarification of an existing unknown — it's introducing a new dimension of uncertainty. This bullet is inapplicable.
+
+### 5. Additional Guidance Bullet B — Empty Arrays Permission
+**Location:** prompt-builder.js line ~132
+**Strength:** **PERMITS** ("return empty arrays for every category")
+**Effect on structural mutation:** PERMITS NO-OP (direct conflict with rule #6)
+**Meaning:** "If the answer does not justify a change, return empty arrays for every category." This is the critical conflicting instruction. It provides an escape hatch: if the model decides nothing justifies a change, it may return all-empty arrays including semantic-only content via answerMeaning.
+
+### 6. Additional Guidance Bullet C — Semantic Preservation
+**Location:** prompt-builder.js line ~132 (final bullet)
+**Strength:** **PERMITS/ENCOURAGES** ("Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved")
+**Effect on structural mutation:** PERMITS semantic-only output
+**Meaning:** Explicitly encourages using answerMeaning for semantic preservation "even when the graph change remains unresolved." This is permissive of the exact pattern that v0.17 sought to eliminate — populated `answerMeaning` with zero structure.
+
+### 7. Rule #4 — AddedNodes Scope
+**Location:** prompt-builder.js line ~93
+**Strength:** **MUST NOT** ("Use addedNodes only for genuinely new concepts")
+**Effect on structural mutation:** RESTRICTS (the "add new unknown" path)
+**Meaning:** New nodes require "genuinely new concepts." The user's uncertainty about savings realism might not qualify as a "new concept" — it's an epistemic state about something already discussed.
+
+### 8. Rule #9 — Traceability Requirement
+**Location:** prompt-builder.js line ~98
+**Strength:** **MUST** ("directly traceable to the user's answer")
+**Effect on structural mutation:** ENCOURGES (requires grounded structure)
+**Meaning:** New unknowns must be traceable and explain why they matter. This is clear and achievable but adds complexity cost to the "add" path.
+
+### 9. Rule #20 — Null Question Condition
+**Location:** prompt-builder.js line ~111
+**Strength:** **MUST** ("Return selectedQuestion as null only when no consequential unresolved unknown remains")
+**Effect on structural mutation:** NEUTRAL → INDIRECTLY ENCOURAGES mutation
+**Meaning:** Since consequential unresolved uncertainty exists (per rule #6 assessment), the model should NOT return `selectedQuestion: null`. But this doesn't tell it HOW to structure — it only constrains question output.
+
+### 10. Rule #26 — User-Supported Meaning Fidelity
+**Location:** prompt-builder.js line ~117
+**Strength:** **MUST** ("state only what the user's answer directly supports")
+**Effect on structural mutation:** NEUTRAL (semantic field constraint)
+**Meaning:** Keep `userSupportedMeaning` faithful. This is what the model did correctly.
+
+## CONFLICT CHECKS
+
+### Pattern A — MUST vs restrictive "only when"
+**YES** — Partial conflict. Rule #6 says MUST structurally represent consequential meaning. Rule #7 restricts new unknown nodes to cases where the answer introduces "a new decision, claim, object, measure, dependency, or unresolved term." The controlled case (unsure about savings realism) falls in a grey zone: it's not clearly any of those enumerated items. It's an epistemic state (doubt) about something already mentioned. Rule #6 creates the obligation; rule #7 restricts the most natural action (adding a new node). The model cannot satisfy both without knowing which existing node to update.
+
+### Pattern B — semantic preservation without structural mapping
+**YES** — The prompt tells the model what the answer means (rules #26-30) but does not provide a decision procedure for choosing among: update existing / resolve existing / add new unknown / add edge. Rule #6 lists the four options but provides no selection criteria or fallback ordering. This is operationally ambiguous when no single path is obviously correct.
+
+### Pattern C — duplicate avoidance causing paralysis
+**YES** — Partial. Additional Guidance Bullet A encourages preferring updates over new nodes. Rule #4 says "genuinely new concepts" for addedNodes. Rule #11 prohibits duplicates. Combined, these make the model risk-averse about adding any structure. If it can't find a clearly matching existing node to update AND doesn't feel confident the concept is "genuinely new" (vs. overlapping with existing cost-related nodes), the safest path is no mutation at all.
+
+### Pattern D — fidelity/inference paralysis
+**YES** — Partial. Rules #26, #27, and #9 create a high bar: every structural element must be directly traceable to the answer, any stronger interpretation goes in possibleInference, new unknowns must state "why it matters." For a simple uncertainty ("unsure whether realistic"), producing a grounded node with justification is non-trivial when no existing anchor exists. The model may prefer faithfulness without mutation over risking an inferred structural relationship.
+
+### Pattern E — surviving semantic-only permission
+**YES** — Clear conflict. Additional Guidance Bullet B states: "If the answer does not justify a change, return empty arrays for every category." Additionally, the final bullet says: "Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved." These two instructions together explicitly permit (and in the case of the last one, encourage) the exact pattern that v0.17's MUST rule was designed to eliminate: populated `answerMeaning` with zero structural mutation. The "does not justify a change" condition can be satisfied if the model interprets rule #7 narrowly — since no enumerated category (decision/claim/object/measure/dependency/unresolved term) is clearly present, nothing justifies a change.
+
+### Pattern F — selected-question requirements compete with mutation
+**YES** — Partial. Rules #16 and #20 together tell the model: if unresolved unknowns exist, you may select a question about one; return null only when no consequential unresolved unknown remains. The model can satisfy this by producing a `selectedQuestion` (identifying the uncertainty as a question) WITHOUT any structural mutation — the rule constrains question output but doesn't mandate the structure underlying the question's target node. A model can reason: "I've identified the question (satisfying rule #16/#20). The graph already contains 'operating costs' which I'll use as the nodeId reference. No new structure needed." This satisfies rules #16-20 without touching structural mutation at all.
+
+## CONTROLLED CASE
+
+**Meaning:** "The user is unsure whether the projected office savings from the relocation are realistic."
+**possibleInference:** null
+**Graph assumption:** no obvious exact node named "realism of projected office savings"
+
+### What does the prompt clearly require?
+
+**STRUCTURAL OBLIGATION EXISTS BUT ACTION CHOICE IS AMBIGUOUS**
+
+Why: Rule #6 creates a MUST obligation for structural mutation. But rules #4, #7, and Additional Guidance provide three separate restrictions that each independently justify choosing no mutation:
+- Rule #7: The answer doesn't clearly introduce a "new decision/claim/object/measure/dependency/unresolved term" — it's doubt about an existing concept.
+- Rule #4: "genuinely new concepts" standard is unclear for epistemic state about known topic.
+- Additional Guidance: "If the answer does not justify a change, return empty arrays" provides explicit escape hatch.
+
+The four paths under rule #6 (update/refine/resolve/add) are listed without decision criteria. Without an obviously matching existing node to update, and with no clear permission to add a new unknown, the model faces genuine action-selection ambiguity despite knowing mutation is required.
+
+Additionally, Additional Guidance lines 132 explicitly permit semantic-only output, creating a direct MUST vs PERMIT conflict.
+
+## EVALUATED DIAGNOSIS OPTIONS
+
+### A — RULE IS CLEAR, MODEL SIMPLY FAILED
+**Rejected.** The prompt contains multiple restrictions (rules #4, #7) and permissive escape hatches (Additional Guidance bullets B and C) that provide independent justification for choosing no mutation. This is not a case of ignoring clear instructions.
+
+### B — OBLIGATION CLEAR, ACTION CHOICE AMBIGUOUS
+**Partial fit.** The action-selection ambiguity is real and present — rules list four paths without decision criteria. However, this diagnosis is incomplete because it doesn't account for the direct permissive conflicts in Additional Guidance (Pattern E).
+
+### C — PROMPT CONFLICT
+**Selected.** Multiple instructions materially conflict with the v0.17 MUST rule:
+- Pattern A (rule #6 vs rule #7): obligation exists but new-node path is restricted by enumeration
+- Pattern E (Additional Guidance bullet B/C): explicitly permits the exact semantic-only no-op pattern that MUST rules out
+- Pattern C (rules #4, #11 + Additional Guidance): duplicate avoidance creates paralysis
+- Pattern D (rules #9, #26, #27): fidelity requirements make structural creation complex
+
+These are not edge cases — they are the primary conditions the controlled case exercises. The v0.17 MUST rule is contradicted by surviving permissive instructions at equal prompt hierarchy level (both in "Proposal Rules" and "Additional Guidance" sections).
+
+### D — NO-OP STILL PERMITTED
+**Subsumed by C.** Pattern E shows that a no-op is indeed still permitted via Additional Guidance bullets B and C. However, this is itself a manifestation of the broader Prompt Conflict diagnosis.
+
+## Provider-Agnostic Check
+
+**YES — CONTRACT LEVEL**
+
+The same ambiguity/conflict would plausibly affect OpenAI, Anthropic, Gemini, or any other model. The conflict exists at the instruction-contract level: multiple instructions with different obligation strengths (MUST vs PERMIT) operate in tension, and the prompt provides no priority ordering between them. All major models trained to follow instruction hierarchies would face the same ambiguity when MUST creates an obligation and PERMIT/SHOULD provides an escape route for a plausible reading of a restrictive condition.
+
+## TEST ADEQUACY
+
+### Current prompt tests classification: TEXT PRESENCE ONLY
+
+### What they prove:
+- The exact text "MUST express its effect through structural mutation" exists in the assembled prompt
+- The four permitted action forms (update/refine, resolve existing unknown, genuinely new unknown) are present as text
+- "answerMeaning alone is not sufficient" exists as text
+- Rules 4, 7, 8, 18 are present via text matching
+- User-supported meaning vs possibleInference separation instructions exist
+
+### What they do not prove:
+- The complete prompt has no conflicting permissive guidance (no test checks for Additional Guidance bullets B/C)
+- The update-vs-add fallback is operationally clear (no test exercises action-selection ambiguity)
+- Rule #7's restrictive boundary doesn't undermine rule #6's obligation
+- The model actually follows the MUST rule when it conflicts with other instructions
+- Any end-to-end prompt coherence
+
+The 57J.39 tests only verify that the new MUST sentence was inserted into the prompt text. They do not test whether that sentence survives the full instruction context uncontradicted.
+
+## Classification: C — PROMPT CONFLICT
+
+### Why:
+
+Multiple independent prompt instructions create conditions where zero structural mutation is a defensible, even encouraged, interpretation of the full prompt — despite rule #6's MUST obligation. The conflict patterns A through F are all materially present, not hypothetical. Additional Guidance bullets B and C provide the most direct contradiction by explicitly permitting semantic-only output with empty structural arrays, using the exact same escape condition ("if the answer does not justify a change") that rules #4 and #7 help establish.
+
+## Primary owner of 57J.41 failure: PROMPT CONFLICT
+
+The model faithfully extracted meaning (correct under rules #26-30). The v0.17 MUST rule exists in the prompt (rule #6). But surviving permissive instructions (Additional Guidance) and restrictive gates (rules #4, #7) provide independent justification for choosing no mutation. This is not model failure — it is a contract-level instruction conflict.
+
+## Smallest prompt boundary requiring correction:
+
+**One line:** Additional Guidance bullet at line ~132 of prompt-builder.js:
+> "If the answer does not justify a change, return empty arrays for every category."
+
+This bullet must either be removed or modified to explicitly condition on rule #6 — i.e., only permit empty arrays when userSupportedMeaning does NOT contain consequential unresolved uncertainty (i.e., when rule #6 does not trigger). Without this fix, the MUST vs PERMIT conflict remains live.
+
+**Second line:** Additional Guidance bullet:
+> "Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved."
+
+This must be modified or removed because it explicitly encourages semantic-only output in the exact scenario rule #6 mandates structural mutation.
+
+These two bullets are ~10 words total. Removing or conditioning them is the minimal correction that resolves Pattern E (and cascades to weaken Patterns C and D).
+
+## What this establishes:
+
+1. The v0.17 contract fix (Option B from 57J.38) successfully converts the original silent accepted no-op into an explicitly rejected proposal with specific diagnostic. This confirms rule #6 exists in the prompt text and the validator fires on the structural fact.
+2. Rule #6 alone is insufficient to produce compliant proposals because it conflicts with permissive instructions at equal hierarchy level. The model has multiple defensible paths to zero mutation.
+3. The conflict is provider-agnostic — it exists at the instruction-contract level, not in any specific model's interpretation.
+4. Test coverage for the v0.17 contract is limited to text presence, not semantic coherence of the full prompt.
+
+## What this does NOT establish:
+
+1. That fixing the identified bullet will restore faithful meaning → structural mutation. The remaining ambiguity (action-selection under rule #6's four paths) might still block some cases.
+2. Whether adding decision criteria for action selection (update vs resolve vs add vs edge) would fully resolve the issue.
+3. Whether the restrictive conditions in rules #4 and #7 should be relaxed rather than Additional Guidance being tightened.
+4. How this interacts with other experiments (decomposition, answerability, provenance).
+
+## Production code changed: NO
+
+## Prompt changed: NO
+
+## Tests changed: NO
+
+## Ollama calls made: 0
+
+## Dev server disturbed: NO
+
+## Documentation updated: YES
@@ -0,0 +1,72 @@
+# Experiment 57J.43 — Remove Surviving Semantic-Only/No-Op Prompt Conflict
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.18`
+**Starting HEAD:** `0c477adea99c8b6532cd0482fd7f1a41b6afbaee` (frozen v0.17)
+**Production commit:** `359ccc4` prompt: remove semantic-only mutation conflict
+
+## Objective
+
+Apply the smallest proven correction from 57J.42's diagnosis: replace the two conflicting Additional Guidance bullets so that no surviving instruction tells the model it may preserve semantic meaning with an empty graph mutation when rule #6's structural-mutation MUST rule applies.
+
+Not solving update-vs-add action selection (confirmed unresolved by 57J.42).
+
+## What Was Changed
+
+### Prompt (lib/graph/prompt-builder.js, Additional Guidance)
+
+**Replaced two bullets:**
+
+```
+- If the answer does not justify a change, return empty arrays for every category.
+- Use answerMeaning to preserve the answer's direct meaning even when the graph change remains unresolved.
+```
+
+**With three conditional bullets:**
+
+```
+- If rule #6 does not apply (the answer contains no user-supported meaning that requires graph progress) and there is no other justification for change, return empty arrays for every category.
+- If rule #6 applies but you choose an update/refinement of existing structure, resolve an existing unknown, or add justified new structure, your structural proposal plus answerMeaning together represent the complete response — answerMeaning preserves semantic fidelity while structural mutation handles graph progress; neither replaces the other.
+- If you add a new unknown with addedNodes, connect it with at least one addedEdge to an existing updated/resolved node or to a newly added non-unknown node from the answer.
+```
+
+### Tests (tests/graph/prompt-builder.test.js)
+
+Added 7 focused tests:
+
+| # | Test | Coverage |
+|---|------|----------|
+| 1 | no direct contradiction remains | Both MUST and empty-array permission must coexist with rule #6 as a condition on the permission |
+| 2 | legitimate true no-op preserved | Empty arrays still allowed when rule #6 does not apply |
+| 3 | answerMeaning is not structural progress | Must reference "semantic fidelity" not "graph change remains unresolved" |
+| 4 | duplicate protection preserved | Rule #4, #11 + AG preference for updates intact |
+| 5 | update/refine route preserved | update/refinement still listed as valid option in both rule #6 and Additional Guidance |
+| 6 | possibleInference separation preserved | Rule #27 untouched; Additional Guidance does not reference possibleInference for mutation trigger |
+| 7 | no action-selection machinery added | No keyword routing, node-kind decision table, or provider-specific paths introduced |
+
+## Test Results
+
+- prompt-builder.test.js: **22/22 pass** (7 new + 15 pre-existing)
+- utils.test.js: **68/68 pass** (pre-existing regression)
+- apply-proposal.test.js: **64/64 pass** (pre-existing regression)
+- Total: **154 tests, 0 failures**
+
+## What This Guarantees
+
+1. The empty-array permission in Additional Guidance is now explicitly conditioned on rule #6 not applying — eliminating the MUST vs PERMIT contradiction diagnosed in Pattern E of 57J.42.
+2. `answerMeaning` can no longer be interpreted as substituting for graph mutation, because the corrected bullet explicitly separates semantic fidelity from structural mutation.
+3. All existing contracts are preserved: duplicate avoidance, genuinely-new-concepts protection, fidelity/inference separation, traceability, update/refine preference.
+
+## What Is Intentionally Left Unresolved
+
+1. **Action selection under rule #6** — when rule #6 applies and multiple structural paths exist (update vs add), the prompt still does not provide decision criteria. This was confirmed by 57J.42 as a separate ambiguity from Pattern E.
+2. **Live production validation** — this commit only corrects the prompt text and tests; whether the corrected prompt produces compliant proposals in practice requires a live regression pass (next experiment).
+
+## Stop Conditions Met
+
+- No validators changed
+- No schema changed
+- No semantic classifiers added
+- No provider-specific logic added
+- No action-selection machinery added
+
+## Documentation Updated: YES
@@ -0,0 +1,118 @@
+# Experiment 57J.44 — Direct Live Test of Conflict-Free Mutation Prompt
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.18`
+**Starting HEAD:** `359ccc4` (prompt: remove semantic-only mutation conflict)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly:
+
+> After removing the semantic-only/no-op prompt contradiction in v0.18, does one simple faithful uncertainty now produce structural graph mutation?
+
+This is the direct live regression for 57J.43's corrected Additional Guidance bullets.
+
+## Pre-written expectation
+
+The answer contains one explicit unresolved uncertainty about savings realism. If v0.18 removes the prompt-level no-op conflict successfully, faithful `userSupportedMeaning` should be accompanied by structural graph progress through an update/refinement, resolution, justified new node, or justified relationship. `answerMeaning` alone with all mutation fields empty would reproduce the failure.
+
+## Configured model
+
+qwen-claude:latest at http://127.0.0.1:3000 (via CONFIDENCE_ENGINE_BASE_URL)
+
+## Fixed inputs
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+
+**Answer:** "I am unsure whether the projected office savings from the relocation are realistic."
+
+## Start
+
+- **HTTP:** 200 | stage: unknown
+- **Nodes:** 6 | Edges: 3
+- **Selected question:** "What would clarify current operating costs for the present location versus projected post-relocation costs and one-time relocation expenses in this situation?"
+
+## Update 1
+
+- **HTTP:** 422 | stage: proposal_compatibility
+- **First error:** "answerMeaning.userSupportedMeaning is populated, but the proposal contains no graph mutation. answerMeaning alone does not constitute graph progress."
+- **Nodes:** 6 | Edges: 3 (unchanged)
+- **Selected question:** null
+
+### Rejected Proposal Snapshot
+
+```json
+{
+  "answerMeaning": {
+    "userSupportedMeaning": "The user is unsure whether the projected office savings from the relocation are realistic.",
+    "possibleInference": "If the savings projections are inflated or inaccurate, the financial benefit of relocating may be negated by one-time moving costs and ongoing operational impacts."
+  },
+  "updatedNodes": [
+    {
+      "nodeId": "nkm55qp",
+      "newValue": null
+    }
+  ],
+  "resolvedUnknownNodeIds": [],
+  "addedNodes": [],
+  "addedEdges": []
+}
+```
+
+## Meaning Classification
+
+**FAITHFUL.** `userSupportedMeaning` preserves only uncertainty about whether projected office savings are realistic. No decision condition, hard constraint, requirement to proceed, priority, or conclusion added. Compared to Experiment 57J.40 (v0.17) where the same scenario produced STRENGTHENED meaning ("Proceeding with the relocation decision is explicitly conditional on obtaining verified evidence..."), v0.18 correctly eliminates the conditioning language.
+
+## Structural Progress
+
+- `updatedNodes` count: 1 (but newValue=null means no actual change — validator sees empty structural change)
+- `resolvedUnknownNodeIds` count: 0
+- `addedNodes` count: 0
+- `addedEdges` count: 0
+
+**Structural progress: NO**
+
+All mutation fields are empty. The v0.18 diagnostic triggered because the proposal contained zero graph progress.
+
+## Classification: B — SAME FAITHFUL NO-OP
+
+Meaning is FAITHFUL and all structural mutation fields remain empty (the updatedNodes entry has newValue=null, indicating no meaningful change). This means removal of the direct prompt contradiction was insufficient for this model to produce structural mutation from faithful uncertainty.
+
+## Why
+
+The v0.18 prompt fix correctly eliminated the semantic-strengthening path seen in 57J.40 (classification C). The model now faithfully preserves uncertainty without converting it to conditional/prescriptive language. However, when asked to act on that faithful meaning, the model still produces zero structural mutations — no new nodes, no resolved unknowns, no updated structure, no added edges.
+
+This maps directly onto the "action selection under rule #6" ambiguity that 57J.42 identified as intentionally left unresolved. The prompt now tells the model it MUST produce structural mutation when rule #6 applies AND that it MAY return empty arrays only when rule #6 does not apply — but the model still treats a single uncertainty about savings realism as insufficient to justify any structural change.
+
+## Did v0.18 remove the faithful semantic-only no-op failure: NO
+
+The direct contradiction was removed (57J.43 confirmed), but one faithful-uncertainty call still produces zero graph progress. The gap between semantic fidelity and structural action selection remains active.
+
+## What this clean run establishes
+
+1. v0.18's Additional Guidance fix prevents the STRENGTHENING failure seen in 57J.40 — the model now extracts faithfulness for simple uncertainty statements.
+2. The configured model does not translate one unresolved financial uncertainty into structural graph progress, regardless of whether the prompt contradiction exists.
+3. The v0.18 diagnostic ("answerMeaning.userSupportedMeaning is populated, but the proposal contains no graph mutation") fires correctly as a validator-level signal.
+
+## What it does NOT prove
+
+1. That the action-selection gap (57J.42) can be resolved by prompt changes alone.
+2. That more complex answers (multiple evidence dimensions) would produce structural progress.
+3. That other models would behave differently on this scenario.
+4. Whether the v0.18 fix is correct for all cases where no mutation is warranted (true no-ops).
+
+## Call accounting
+
+startCalls: 1
+updateCalls: 1
+totalCalls: 2
+
+Supplementary scripts used: NO
+
+Retries: 0
+
+## Production code changed: NO
+## Prompt changed during experiment: NO
+## Harness restored: YES
+## Dev server disturbed: NO
+## Ollama calls beyond harness count: 0
@@ -0,0 +1,205 @@
+# Experiment 57J.45 — Choose Structural Action-Selection Rule
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.18`
+**Starting HEAD:** `acd1928` (experiment: validate conflict-free mutation prompt live)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly:
+
+> When rule #6 requires structural progress for a faithful unresolved uncertainty, what is the smallest provider-agnostic instruction that tells the model when to update existing structure versus add a new unknown?
+
+57J.44 established that the direct prompt contradiction is gone, but the model can still preserve meaning faithfully and produce no meaningful graph action. This task chooses the next bounded implementation without reopening the no-op validator.
+
+## Context route (read-only)
+
+- `docs/current-handoff.md` — current-project state
+- `docs/experiment-57j44.md` — most recent live test result
+- `lib/graph/prompt-builder.js` — complete graph-update rules
+- `tests/graph/prompt-builder.test.js` — focused prompt tests
+- Duplicate/semantic-match helper: existing rule #11 ("Do not add duplicate unknowns") and Additional Guidance line 125 ("prefer updatedNodes and resolvedUnknownNodeIds over creating duplicate nodes")
+
+## Controlled case
+
+```
+The user is unsure whether the projected office savings from the relocation are realistic.
+possibleInference = null
+```
+
+### Case A — equivalent uncertainty already exists
+
+Graph contains an unresolved unknown materially representing whether projected relocation savings are realistic.
+
+Desired: DO NOT ADD DUPLICATE; use/refine/update existing structure.
+
+### Case B — no equivalent uncertainty exists
+
+Graph contains general relocation/cost nodes but no unresolved node materially representing savings realism.
+
+Desired: CREATE STRUCTURAL REPRESENTATION OF THE NEW UNCERTAINTY.
+No edge required unless a genuine relationship is established by the answer.
+
+## Existing contract check
+
+### Current prompt content:
+
+- **Genuinely new concepts:** Rule #4 — "Use addedNodes only for genuinely new concepts."
+- **Duplicate unknowns:** Rule #11 — "Do not add duplicate unknowns."
+- **Update/refine existing nodes:** Additional Guidance line 125 — "prefer updatedNodes and resolvedUnknownNodeIds over creating duplicate nodes."
+- **New unresolved terms:** Rule #7 — "Add new unknown nodes only when the answer introduces a new decision, claim, object, measure, dependency, or unresolved term directly relevant to the case."
+- **Rule #6 structural-progress rule (current):** "If answerMeaning.userSupportedMeaning contains consequential information or unresolved uncertainty that is not already represented in the graph, you MUST express its effect through structural mutation. This may be an update/refinement of existing structure, resolution of an existing unknown, a genuinely new unknown, or a justified relationship."
+- **Rule #6 trigger condition:** "not already represented in the graph" — this is the ambiguous term that must be interpreted by the model to distinguish Case A from Case B.
+
+### Does the prompt already contain enough information to distinguish Case A from Case B?
+
+**NO** — necessary distinction is absent. The prompt requires the model to decide what "not already represented" means, but provides no instruction-order rule: should it check for an existing equivalent first (Case A path) or attempt a new node creation and catch duplicates at validation time (Case B path)? Rule #7's restrictive enumeration combined with rules #4 and #11 actually pushes the model toward "nothing justifies a change" when facing a simple uncertainty. The four structural options in rule #6 are listed without decision criteria or fallback ordering, confirming the ambiguity diagnosed in 57J.42 and reproduced in 57J.41/57J.44 live runs.
+
+## Evaluate Option A — EXISTING-FIRST FALLBACK
+
+### One explicit action-order rule:
+
+```
+When rule #6 applies:
+1. If an existing unresolved node already represents the same uncertainty, update/refine that existing structure rather than adding a duplicate.
+2. Otherwise add a new unknown that directly represents the unresolved uncertainty.
+```
+
+Do not require an edge solely for provenance.
+
+#### Evaluation:
+
+- **Case A correct:** YES — explicit first step is to check existing unresolved nodes
+- **Case B correct:** YES — "otherwise" clause creates new unknown explicitly
+- **Duplicate risk:** LOW — deterministic validator catches any miss; rule order prevents unnecessary duplication attempts
+- **Risk of overwriting a merely-related existing node:** MEDIUM — the model must judge whether an existing node "already represents the same uncertainty." This is a semantic judgment, not a lexical match. However, this is exactly what rules #4 and #11 already require the model to do, so it's within the existing contract. The risk is bounded because (a) update/refine can add detail without overwriting, (b) new unknown with clear why-it-matters clause makes it traceable even if a partial overlap exists, (c) deterministic validator prevents true duplicates.
+- **Risk of another no-action proposal:** LOW — eliminates the primary ambiguity that caused 57J.41/57J.44 failures. The instruction order is deterministic: check existing first, create second. No room for "nothing applies" escape because rule #6 still fires (unresolved uncertainty not yet in graph = case B).
+- **Requires new semantic classifier:** NO — uses the model's existing ability to read the graph and compare semantics; deterministic validator remains safety net
+- **Requires new graph/schema state:** NO
+- **Requires validator change:** NO
+
+## Evaluate Option B — NEW-UNKNOWN DEFAULT
+
+```
+When rule #6 applies to explicit unresolved uncertainty:
+add a new unknown unless an exact duplicate already exists
+```
+
+Existing non-exact related nodes do not block new unknown creation.
+
+#### Evaluation:
+
+- **Case A correct:** NO — "exact duplicate" is stricter than what the current prompt allows. Rule #11 already says "Do not add duplicate unknowns" without defining "duplicate." Option B adds no mechanism to determine whether something is an "exact duplicate" versus "merely related." If the graph contains a partially-related uncertainty about savings (not exact), option B would create a second node — the same duplication problem this exercise seeks to prevent.
+- **Case B correct:** YES — default-to-add works for genuinely new uncertainties
+- **Duplicate risk:** HIGH — no mechanism distinguishes "exact duplicate" from "merely related"; current prompt has no deterministic duplicate definition beyond validator post-hoc detection
+- **Risk of overwriting a merely-related existing node:** LOW — does not create nodes, so no overwrite occurs; only creates new nodes that may overlap
+- **Risk of another no-action proposal:** MEDIUM — but less than current because it defaults to creation. However, the "exact duplicate" term is undefined and would need semantic matching logic
+- **Requires new semantic classifier:** YES — "exact duplicate" requires a mechanism the current prompt does not provide
+- **Requires new graph/schema state:** NO (but arguably needs one for the classification)
+- **Requires validator change:** YES — must enforce the exact-duplicate vs merely-related distinction deterministically
+
+## Evaluate Option C — GENERAL STRUCTURAL CHOICE
+
+Keep all four existing structural options but add explanatory examples and leave the model to choose.
+
+#### Evaluation:
+
+- **Case A correct:** PARTIAL — depends on the model interpreting "update/refine" correctly for equivalent uncertainties. No instruction order given, so model must independently weigh four options
+- **Case B correct:** PARTIAL — model may choose any of four options; evidence from 57J.41/57J.44 shows it chooses "no action" when the structural decision is ambiguous
+- **Duplicate risk:** MEDIUM — without an explicit check-first step, duplication depends on model judgment across four unweighted options
+- **Risk of overwriting a merely-related existing node:** MEDIUM — same as current prompt; no change
+- **Risk of another no-action proposal:** HIGH — this is essentially the current state. 57J.41 and 57J.44 both failed under the four-option approach where no action was chosen
+- **Requires new semantic classifier:** NO
+- **Requires new graph/schema state:** NO
+- **Requires validator change:** NO
+
+## ACTION-SPACE CHECK
+
+### Is `add relationship` a sensible standalone response to the controlled case?
+
+**EDGE-ONLY SUFFICIENT: NO**
+
+If no existing unknown node represents the savings-realism uncertainty, an edge alone cannot represent it. Edges connect nodes; they do not create representational capacity. A relationship from a state node to nothing new is empty — it has no target for the uncertainty. If there IS an equivalent unknown (Case A), then `add relationship` could be part of updating that structure, but by itself it does not represent the uncertainty.
+
+### Is `resolve existing` applicable to the controlled case?
+
+**RESOLUTION APPLICABLE: NO**
+
+Resolution applies when the user's answer resolves a distinction previously encoded as an unresolved unknown. In the controlled case, the user expresses uncertainty ("I am unsure whether..."), not a resolution. There is nothing to resolve in Case B (no existing equivalent). In Case A, the user's uncertainty might inform refinement of an existing node but does not constitute resolution unless the answer explicitly states "X is definitely true/false" about that node's content.
+
+### Effect on action space:
+
+Two relevant actions remain for the controlled case:
+1. **update/refine** (Case A path)
+2. **add unknown** (Case B path)
+
+Four nominal options narrowed to two by the controlled-case semantics.
+
+## Recommendation
+
+### CHOSEN: A — EXISTING-FIRST FALLBACK
+
+#### Why:
+
+Option A provides a deterministic instruction order that directly addresses the failure mode confirmed in 57J.41 and 57J.44. The problem was not missing semantic information but missing priority: when rule #6 fires, the model must first check whether an equivalent unresolved node exists before considering new structure creation. This is the smallest possible rule change — one explicit two-step sequence — that resolves the ambiguity without adding classifiers, schema state, or validator changes.
+
+Option B fails because "exact duplicate" cannot be determined without a new semantic-matching mechanism (which contradicts the critical semantic boundary). Option C preserves the exact ambiguity that caused the failure.
+
+#### Convergence:
+
+The instruction order must be deterministic: check → act. Not options → choose. Not semantics → match. This rule preserves all existing contracts: duplicate detection still uses the deterministic validator as safety net; provider-agnostic design is maintained because the model's existing semantic access to the graph handles the "represents the same uncertainty" judgment that rules #4 and #11 already require.
+
+### Does recommendation add deterministic semantic matching?
+**NO** — the model's prompt-level semantic comparison of graph node content to answer semantics is within its existing capability (rules #4 and #11 already require this). Deterministic validator remains the post-hoc safety net for true duplicates.
+
+### Does recommendation preserve provider-agnostic design?
+**YES** — no provider-specific language, routing, or classification added.
+
+### Does recommendation preserve duplicate protection?
+**YES** — existing rule #11 and deterministic validator unchanged. The instruction order reduces (not eliminates) duplication attempts but does not weaken detection.
+
+### Does recommendation require validator change?
+**NO** — prompt-only change in Additional Guidance.
+
+## Ready for bounded implementation: YES
+
+### Exact prompt boundary:
+
+One bullet added to Additional Guidance in `lib/graph/prompt-builder.js`, replacing or supplementing the existing guidance about preferring updates (line 125 area):
+
+```text
+When rule #6 applies: first check whether an existing unresolved node already represents the same uncertainty. If so, update/refine that existing structure rather than creating a duplicate. If no such node exists, add a new unknown that directly represents the unresolved uncertainty; do not create an edge alone to represent it.
+```
+
+### Required deterministic regressions:
+
+1. equivalent existing unresolved unknown → prefer existing structure, no duplicate;
+2. no equivalent unknown → explicit unresolved uncertainty must be represented as a new unknown;
+3. merely related state/cost node does not count as representing the uncertainty itself;
+4. answerMeaning alone remains insufficient;
+5. possibleInference alone does not create unknowns;
+6. resolution path remains available when the user actually resolves an existing unknown;
+7. edge-only mutation is not presented as sufficient to represent a previously unrepresented uncertainty;
+8. existing duplicate validator remains unchanged.
+
+### Stop condition for implementation:
+
+Prompt text and focused tests pass. No Ollama calls required for this step. Next bounded experiment (live) would follow in a separate task if the model produces Case A or Case B correctly on one fresh run each.
+
+### What this intentionally leaves unresolved:
+
+- The semantic threshold for "represents the same uncertainty" (relying on model capability + deterministic validator safety net);
+- Live production validation of Option A (requires next experiment pass);
+- Whether the instruction order needs tuning across multiple turns;
+- Edge-connection strategy for new unknowns created under Case B.
+
+## Documentation
+
+This file: `docs/experiment-57j45.md`
+Handoff update: appended to `docs/current-handoff.md`
+Commit: `experiment: choose structural action-selection rule`
+No merge.
+
+---
+
+*Read-only implementation-design task. No production code changed. No prompt changed. No tests changed. Zero Ollama calls. Dev server undisturbed.*
@@ -0,0 +1,89 @@
+# Experiment 57J.46 — Existing-First Uncertainty Fallback: Prompt Implementation
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.19`
+**Starting HEAD:** `acd1928` (HEAD of v0.18 at branch point)
+**Implementation commit:** pending
+
+## Objective
+
+Implement the existing-first fallback for explicit unresolved uncertainty chosen in Experiment 57J.45:
+
+> When rule #6 applies to explicitly unresolved uncertainty, first reuse/refine an equivalent unresolved unknown if one exists; otherwise add a new unknown that directly represents the uncertainty.
+
+## What was changed
+
+### lib/graph/prompt-builder.js — Additional Guidance
+
+One bullet added (line after existing "prefer updatedNodes" guidance):
+
+```
+- When rule #6 applies to explicitly unresolved uncertainty: first check whether an existing unresolved node already represents the same uncertainty; if so, update/refine that existing structure rather than adding a duplicate; if no such node exists, add a new unknown that directly represents the unresolved uncertainty; do not use an edge alone to represent a previously unrepresented uncertainty.
+```
+
+This is scoped specifically to `unresolved uncertainty` — it does NOT apply to facts, constraints, decisions, or resolved information.
+
+### tests/graph/prompt-builder.test.js — Focused prompt tests
+
+14 new tests in describe block "57J.46 existing-first uncertainty fallback":
+
+| # | Test | What it verifies |
+|---|------|-----------------|
+| 1 | assembled prompt has existing-first ordering | Rule exists in full prompt |
+| 2 | reuse path explicit | update/refine language present |
+| 3 | fallback-to-add explicit | new-unknown path explicit |
+| 4 | full ordered fallback | entire rule as single coherent instruction |
+| 5 | related node insufficient | uses "same uncertainty" not weaker criteria |
+| 6 | edge-only insufficient | prohibition on edge-only representation |
+| 7 | possibleInference separation | rule does not reference possibleInference |
+| 8 | resolution path preserved | resolvedUnknownNodeIds + rule #5 intact |
+| 9 | duplicate contract preserved | rules #4, #11 unchanged |
+| 10 | scope uncertainty-only | scoped to "explicitly unresolved uncertainty" only |
+| 11 | fidelity separation | userSupportedMeaning vs possibleInference rule untouched |
+| 12 | traceability | new-unknown traceability rule intact |
+| 13 | noop validator | "rule #6 does not apply → empty arrays" unchanged |
+| 14 | no semantic classifier | no threshold/synonym/keyword logic added |
+| 15 | provider-agnostic | no provider-specific wording |
+
+## Controlled case mapping
+
+### Case A — existing equivalent unknown (prompt instruction)
+
+When graph contains:
+> "Whether projected relocation savings are realistic"
+
+And user says:
+> "I am unsure whether the projected office savings from the relocation are realistic."
+
+Prompt now instructs: **reuse/refine existing unresolved unknown; do not add duplicate.**
+
+### Case B — no equivalent unknown (prompt instruction)
+
+When graph contains only broader cost/relocation concepts.
+
+Same user statement.
+
+Prompt now instructs: **add a new unknown directly representing savings realism.**
+
+## Test results
+
+- prompt-builder.test.js: 37 tests pass (23 existing + 14 new)
+- utils.test.js: 68 tests pass (regression confirmation)
+- Total: 105 tests pass, 0 failed
+
+## What this implementation guarantees
+
+- When the model receives an answer containing explicitly unresolved uncertainty and rule #6 fires, the assembled prompt now gives a deterministic instruction order: check existing first → reuse if equivalent → otherwise add new.
+- The rule is scoped only to unresolved uncertainty. It does not apply universally to all meaning categories.
+- Existing contracts are preserved: duplicate avoidance (rules #4, #11), possibleInference separation (rule #27), fidelity rules (rule #26), traceability (rule #9/9a), noop validator (Additional Guidance "rule #6 does not apply"), structural-materialization MUST rule (57J.39).
+
+## What this intentionally leaves unresolved
+
+- The semantic threshold for "represents the same uncertainty" — relies on model's prompt-level semantic comparison capability + deterministic validator as safety net.
+- Live production validation of Option A — requires next experiment pass (live run with fresh case).
+- Whether the instruction order needs tuning across multiple turns.
+- Edge-connection strategy for new unknowns created under Case B.
+
+## Documentation
+
+This file: `docs/experiment-57j46.md`
+Handoff update: appended to `docs/current-handoff.md`
@@ -0,0 +1,185 @@
+# Experiment 57J.47 — Convergence Test: Existing-First Uncertainty Fallback Live
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.19`
+**Starting HEAD:** `94ca1b9` docs: experiment 57J.46 record and handoff update
+
+## Objective
+
+Answer exactly:
+
+> For one explicit unresolved uncertainty, does v0.19 now produce a faithful structural graph action instead of another no-op?
+
+This is the convergence test for the current prompt-tuning sequence.
+
+If the same faithful no-op still occurs, do not diagnose or propose v0.20. Report it and stop.
+
+## Hypothesis
+
+v0.19 gives the model a two-step structural action rule:
+
+```
+if equivalent unresolved unknown exists:
+    reuse/refine it
+otherwise:
+    add a new unknown representing the uncertainty
+```
+
+Therefore faithful meaning should no longer end with zero meaningful graph mutation.
+
+## Pre-written expectation
+
+> A faithful interpretation of the explicit savings-realism uncertainty should now trigger one of two structural outcomes: reuse/refine an equivalent unresolved unknown if present, otherwise create a new unknown representing savings realism. A faithful proposal with no meaningful mutation means the current prompt-tuning approach has still not solved the boundary.
+
+## Configuration
+
+**Configured model:** qwen-claude:latest at http://192.168.1.111:11434
+**Dev server:** REUSED EXISTING (HTTP 200, Next.js running)
+**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."
+**Harness:** `scripts/reproduce-multi-turn-investigation.mjs` (maxUpdates=1, answers=[fixed answer])
+
+## CALL ACCOUNTING
+
+startCalls: 1
+updateCalls: 1
+totalCalls: 2
+
+Supplementary scripts used: NO
+Retries: 0
+
+## START
+
+HTTP status: 200 | stage: unknown
+
+Nodes: 7
+Edges: 4
+Selected question: "What would clarify current detailed breakdown of engineering operating costs and geographic distribution in this situation?"
+
+Start graph (cold-start from scenario):
+- n-baseline-costs (unknown/observation) — baseline cost state
+- nv759rs (state/knowledge) — relocation consideration state anchor
+- n-engineering-operating-costs (unknown/observation) — engineering cost detail gap
+- 4 additional nodes (scenario reconstruction scaffolding)
+
+No analysis of cold-start variance.
+
+## UPDATE 1
+
+HTTP status: 422
+Stage: proposal_compatibility
+First error: "answerMeaning.userSupportedMeaning overstates a raw answer that remains uncertain."
+
+Nodes: 7 (unchanged — mutation not applied)
+Edges: 4 (unchanged — mutation not applied)
+Selected question: null
+
+### rejectedProposalSnapshot
+
+```json
+{
+  "answerMeaning": {
+    "userSupportedMeaning": "The user is currently uncertain whether the projected office savings from the relocation are realistic.",
+    "possibleInference": null
+  },
+  "updatedNodes": [],
+  "resolvedUnknownNodeIds": [],
+  "addedNodes": [
+    {
+      "id": "ns82kx9",
+      "kind": "unknown",
+      "label": "Projected office savings from the relocation lack validation",
+      "description": "The realism of projected office savings is unverified, so that the potential cost reduction cannot be validated for the relocation strategy.",
+      "parentId": null,
+      "dependsOn": [],
+      "affects": [],
+      "childIds": []
+    }
+  ],
+  "addedEdges": [
+    {
+      "fromNodeId": "ns82kx9",
+      "toNodeId": "nv759rs",
+      "relationship": "depends_on"
+    }
+  ]
+}
+```
+
+## ANSWER MEANING
+
+userSupportedMeaning: "The user is currently uncertain whether the projected office savings from the relocation are realistic."
+possibleInference: null
+
+### Meaning classification: HUMAN ASSESSMENT = MINOR PARAPHRASE | VALIDATOR REJECTION = LEXICAL MISMATCH
+
+Raw answer: "I am unsure whether the projected office savings from the relocation are realistic." (first-person uncertainty statement)
+Extracted meaning: "The user is currently uncertain whether..." (third-person assertion about user's mental state + temporal specificity "currently")
+
+**Validator rejection reason:** Lexical false positive. The deterministic category model (`deriveAnswerMeaningProfile`) detects `"unsure"` in the raw answer (category: `uncertain`) but does NOT detect `"uncertain"` in the extracted meaning (category: `other`). Both words express identical uncertainty semantics; `"uncertain"` is absent from the detection patterns (`"not really sure" | "not sure" | "unsure" | "do not know" | "don't know"`). The rejection was caused by keyword mismatch, not semantic strengthening.
+
+**Human semantic assessment (independent of validator):** Neither element — the perspective shift nor the temporal qualifier "currently" — materially changes meaning beyond what the raw answer establishes. See 57J.48 for detailed deterministic analysis.
+
+## STRUCTURAL PROPOSAL
+
+updatedNodes: [] (none — empty array)
+resolvedUnknownNodeIds: [] (none — empty array)
+addedNodes: [{id: "ns82kx9", kind: "unknown", label: "Projected office savings from the relocation lack validation", description: "The realism of projected office savings is unverified, so that the potential cost reduction cannot be validated for the relocation strategy."}]
+addedEdges: [{fromNodeId: "ns82kx9", toNodeId: "nv759rs", relationship: "depends_on"}]
+
+### Meaningful updated/refined existing uncertainty: NO
+
+updatedNodes is empty. No existing unknown was meaningfully modified.
+
+### Meaningful new uncertainty added: YES
+
+A genuinely new unknown node (`ns82kx9`) was created, directly representing savings realism ("Projected office savings from the relocation lack validation"). The label and description are grounded in the answer's explicit concern. This represents exactly the user-supported uncertainty about whether projected savings are realistic.
+
+### Structural action: ADD NEW UNKNOWN
+
+The proposal added a new unknown node (with one depends_on edge to the state anchor) representing savings realism. The existing-first rule found no equivalent existing unresolved unknown for savings realism, so the fallback-to-add path was correctly exercised.
+
+## Classification: D — REJECTION BLOCKS TEST (LEXICAL FALSE POSITIVE)
+
+**Meaning extraction produced a semantically equivalent paraphrase that was lexically rejected.** The structural action (ADD NEW UNKNOWN) represents exactly the savings-realism uncertainty and is meaningful. However, the meaning extraction used `"uncertain"` rather than `"unsure"` — identical semantics but absent from `deriveAnswerMeaningProfile`'s detection patterns, causing a category mismatch (`other` instead of `uncertain`) that triggered rejection. **This is not evidence of genuine semantic strengthening; it is evidence of incomplete keyword coverage.** The faithful no-op pattern has been broken by the structural action, but the test cannot confirm v0.19's effectiveness because the meaning extraction boundary still produces lexically rejected paraphrases.
+
+**Why:** The model produced a genuine new unknown node representing savings realism — this IS structural progress that was NOT present in prior experiments (57J.36-45 all showed faithful no-ops or empty proposals). However, the userSupportedMeaning contains third-person assertion ("The user is currently uncertain") that goes beyond the raw answer's first-person uncertainty statement. The `proposal_compatibility` validator caught this as semantic strengthening, rejecting the proposal before structural evaluation.
+
+**Did v0.19 solve the faithful semantic-to-mutation failure in this run:** NO
+
+The test cannot determine whether v0.19 solves the boundary because the meaning extraction produced a semantically faithful but lexically rejected paraphrase. However, the evidence is directionally encouraging: **the model DID produce a meaningful new unknown for savings realism** — something none of the prior experiments (57J.36 through 57J.46) achieved in a single call. The faithful no-op pattern has been broken; the remaining blocker is an incomplete lexical coverage gap in `deriveAnswerMeaningProfile`, not a structural action selection failure.
+
+## What this establishes:
+
+1. **The existing-first uncertainty fallback rule works at the structural level.** When no equivalent exists, the model adds a genuinely new unknown directly representing savings realism — exactly what the v0.19 prompt was designed to produce.
+2. **The faithful no-op is no longer the default output.** This run produced one added node and one added edge. Prior experiments (57J.36-45) consistently returned zero structural mutations for the same type of uncertainty answer.
+3. **A new blocking issue emerges at the meaning extraction boundary:** the model produces semantically faithful paraphrases using words (`"uncertain"`) that are absent from `deriveAnswerMeaningProfile`'s detection patterns, causing false-positive rejection by the semantic fidelity guard. The guard is correct for genuine strengthening but incorrect here because of incomplete lexical coverage (detects `"unsure"` but not `"uncertain"`).
+
+## What it does NOT prove:
+
+- That v0.19 reliably produces faithful meaning from first-person uncertainty across repeated runs.
+- That the new unknown node's label/description would survive if meaning were faithful.
+- That later turns in the investigation remain productive after this type of rejection.
+- That the "currently" temporal specificity issue generalizes to other answer types.
+
+## CONVERGENCE DECISION
+
+Further prompt tuning justified by this run: NO
+
+If result is non-A:
+Return to architecture discussion before any v0.20 change.
+
+This is a convergence test for the current prompt-wording sequence (v0.17 → v0.18 → v0.19). Result is D (non-A), so the convergence rule applies: do not diagnose a new prompt tweak, propose v0.20, or continue prompt tuning. The next discussion should reconsider the architecture rather than automatically continuing prompt tuning.
+
+Production code changed during experiment: NO
+Prompt changed during experiment: NO
+Canonical harness restored: YES
+Hardened no-retry behaviour preserved: YES
+Dev server disturbed: NO
+Ollama calls beyond harness count: 0
+
+## Documentation
+
+- Created: `docs/experiment-57j47.md`
+- Handoff updated: appended to `docs/current-handoff.md`
+
+Git status after documentation: (dirty — doc file uncommitted)
@@ -0,0 +1,149 @@
+# Experiment 57J.48 — Uncertainty Fidelity False Positive: Lexical Gap in `deriveAnswerMeaningProfile`
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.19`
+**Starting HEAD:** `acd1928` experiment: choose structural action-selection rule
+
+## Objective
+
+Answer exactly:
+
+> Why does the current fidelity validator reject the captured pair "I am unsure whether…" → "The user is currently uncertain whether…" as overstatement, and is that rejection semantically justified or a lexical false positive?
+
+This is the architecture/convergence step after 57J.47. Do not continue prompt tuning.
+
+## Part 1 — Exact Deterministic Trace
+
+```
+raw-answer profile/category: uncERtain (matches "unsure" at line 2880 of lib/graph/apply-proposal.js)
+userSupportedMeaning profile/category: other (no match for any detection pattern — "uncertain" is ABSENT from patterns)
+exact helper/function: deriveAnswerMeaningProfile() → validateAnswerMeaningCompatibilityWithRawAnswer()
+exact condition that fires: lines 2966-2970 of apply-proposal.js: rawAnswerProfile.category === "uncertain" && supportedMeaningProfile.category !== "uncertain"
+specific token/phrase/signals involved:
+  - Raw answer contains "unsure" → matches pattern at line 2880 → category = "uncertain"
+  - Supported meaning contains "uncertain" → NO matching pattern (gap) → falls through to default category "other"
+  - Category mismatch fires the "overstates a raw answer that remains uncertain" error at line 2969
+```
+
+The rejection depends on:
+- **Lexical token:** `"unsure"` detected, `"uncertain"` NOT detected — identical semantics, different word form
+- **Category ordering:** irrelevant here because uncertainty is checked first (line 2877); the issue is that neither word triggers it uniformly
+- **NOT** perspective shift, negation, or "whether" — these are not signals in the detection logic
+
+## Part 2 — Semantic Equivalence Check
+
+### Uncertainty preserved
+YES — both texts express unresolved uncertainty about the realism of projected office savings.
+
+### Decision condition added
+NO — neither text establishes a condition for proceeding/deciding.
+
+### Hard constraint added
+NO — neither text introduces a hard constraint.
+
+### Priority added
+NO — neither text adds priority/importance framing.
+
+### Conclusion added
+NO — neither text asserts a conclusion; both only state the existence of uncertainty.
+
+### Material temporal claim added by "currently"
+NEGLIGIBLE — "currently" is a minimal temporal qualifier that does not materially change meaning. The raw answer's present-tense context ("I am unsure") already establishes currentness implicitly.
+
+### Perspective shift
+REPRESENTATIONAL NORMALISATION — converting first-person uncertainty ("I am unsure") to third-person assertion ("The user is uncertain") changes representation perspective but preserves substantive meaning. Both express the same proposition: unresolved doubt about savings realism.
+
+### Pair classification
+MINOR NON-MATERIAL PARAPHRASE
+
+## Part 3 — Architecture Classification
+
+**B — LEXICAL FALSE POSITIVE**
+
+The meanings are semantically equivalent (both express uncertainty), but lexical/category heuristics in `deriveAnswerMeaningProfile` reject the paraphrase because `"uncertain"` is absent from the detection patterns while `"unsure"` is present. The categories assigned to semantically equivalent uncertainty are incompatible solely due to keyword coverage gap.
+
+## Part 4 — Keyword-Dictionary Risk
+
+**Evidence of lexical reasoning drift: YES**
+
+Current code evidence confirms that deterministic fidelity reasoning has drifted toward English keyword recognition:
+1. `deriveAnswerMeaningProfile` uses `.includes()` checks on 5 specific uncertainty expressions (`"not really sure" | "not sure" | "unsure" | "do not know" | "don't know"`) — but NOT the more direct and common `"uncertain"`
+2. Similarly, `hasConditionalQualification` detects `"conditional"` but not `"contingent"` or `"depends on"` which express identical semantics
+3. The validator's semantic fidelity decision depends entirely on whether the LLM happens to use one of ~15-20 hardcoded English surface forms
+
+**Current fidelity boundary:** RAW-LANGUAGE SEMANTIC INFERENCE IN VALIDATOR
+
+The boundary is raw-language keyword detection, not structured semantic contract validation. There are no structured fields carrying uncertainty/resolution state that could be checked directly — only free-text string matching against the `userSupportedMeaning` field.
+
+## Part 5 — Structured-Output Alternative Already Available?
+
+**SUFFICIENT EXISTING STRUCTURE**
+
+The engine already carries structured signals that could distinguish:
+- user remains uncertain
+- model inferred stronger condition  
+- model preserved uncertainty
+
+Relevant existing fields:
+- `answerMeaning.supportCategory` (enum): `"uncertain" | "conditional_tradeoff" | "explicit_hard_constraint"` — this field exists in the schema and is populated by the model (or null)
+- `answerMeaning.resolutionGuidance` (nullable string): `"must_remain_unresolved" | "may_resolve" | "must_resolve"` — already distinguishes preservation from resolution intent
+- `uncertaintyType` (from possibleInference path): `"evidence_needed" | "user_clarification_needed"` — differentiates uncertainty types
+- `answerMeaning.possibleInference`: null when no inference was made
+
+These fields exist in the production schema (`lib/graph/schema.js`) and could be used directly for compatibility checking without re-inferring semantics from English keywords. The current architecture already has `supportCategory` as a structured category carrier — the problem is that it is not being populated by the model (per 56D: "the LLM does not auto-populate supportCategory"), so the deterministic derivation layer must infer it from text.
+
+## Deterministic Reproduction
+
+**Command:**
+```
+node /tmp/57j48-verify.cjs
+```
+
+(Inline script executed deterministically — zero Ollama calls, zero API calls)
+
+**Result:**
+- Raw answer profiles as `uncertain` ✓
+- userSupportedMeaning profiles as `other` (gap: "uncertain" not in patterns)
+- Validation fires: `"answerMeaning.userSupportedMeaning overstates a raw answer that remains uncertain."`
+- Inverse test confirms: replacing "uncertain" with "unsure" (identical semantics) → category = `uncertain`, errors = none
+
+**Captured rejection reproduced:** YES
+
+## 57J.47 Documentation Cleanup
+
+**Previous wording required correction:** YES
+
+**What was corrected:**
+1. Replaced "Meaning classification: STRENGTHENED" with "HUMAN ASSESSMENT = MINOR PARAPHRASE | VALIDATOR REJECTION = LEXICAL MISMATCH" — explicitly distinguishing the human semantic assessment from the actual validator mechanism (keyword gap).
+2. Added explicit statement that `"uncertain"` is absent from `deriveAnswerMeaningProfile`'s detection patterns while `"unsure"` is present — both express identical semantics.
+3. Replaced "Classification: D — STRENGTHENING BLOCKS TEST" with "Classification: D — REJECTION BLOCKS TEST (LEXICAL FALSE POSITIVE)" — the blocker is a lexical false positive, not genuine strengthening.
+4. Updated "What this establishes" point 3 to describe the incomplete lexical coverage gap rather than claiming the guard "correctly flags as strengthening."
+5. Updated "Did v0.19 solve..." explanation to attribute the blocker to lexical coverage gap rather than "strengthening."
+
+**Observed live facts preserved:** YES — the rejection error, the rejected proposal snapshot contents, and the structural progress (one added node) are all preserved unchanged. Only the *interpretation* of the rejection mechanism was corrected.
+
+## What this establishes
+
+1. **The captured rejection is a lexical false positive:** The validator uses `"unsure"` to detect uncertainty but does not use `"uncertain"`, even though both words express identical semantics (per OED/WordNet, both denote "lacking sufficient knowledge or certainty").
+2. **57J.47's "STRENGTHENED" classification conflates human semantic assessment with validator behavior.** The validator did not detect semantic strengthening — it detected a keyword absence. The human assessment that the paraphrase is a minor non-material paraphrase (not strengthening) is independently valid.
+3. **The existing-first structural action rule worked correctly** in 57J.47: the model DID add a new unknown for savings realism. The blocker was purely at the meaning-extraction boundary.
+4. **Structured semantic signals exist in the schema** (`supportCategory`, `resolutionGuidance`) but are not populated by the LLM (per 56D), leaving keyword inference as the current mechanism.
+
+## What it does NOT establish
+
+1. That all validator rejections for this class of paraphrase are false positives (other words/phrases may have legitimate strengthening semantics).
+2. That adding `"uncertain"` to the detection patterns is sufficient for broader lexical coverage.
+3. That structured output without keyword inference has been tested end-to-end.
+4. Generalisation across other uncertainty expressions or domains.
+
+## Production code changed: NO
+## Prompt changed: NO
+## Validator changed: NO
+## Tests permanently changed: NO
+## Temporary test removed: YES (removed `/tmp/57j48-verify.cjs`)
+## Ollama calls made: 0
+## Dev server disturbed: NO
+
+## Documentation updated
+
+- Created: `docs/experiment-57j48.md`
+- Corrected: `docs/experiment-57j47.md` (distinguished validator mechanism from human semantic assessment)
@@ -0,0 +1,264 @@
+# Experiment 57J.49 — Can Existing Structured Semantic Fields Replace Keyword-Based Fidelity Inference?
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.19`
+**Starting HEAD:** `a2c790e` experiment: diagnose uncertainty fidelity false positive
+
+## Objective
+
+Answer exactly:
+
+> Can the current answerMeaning/schema contract carry enough structured semantic information to let fidelity validation compare meaning directly, instead of re-inferring uncertainty/constraint/trade-off semantics from English keywords?
+
+This is a **read-only architecture diagnosis** following 57J.48's lexical false positive finding.
+Do not call Ollama. Do not run the live API. Do not modify production code, prompts, validators, schema, or tests.
+
+## Part 1 — Inventory of Existing Structured Semantics
+
+For `answerMeaning` and directly related proposal fields:
+
+### Field: userSupportedMeaning
+
+```text
+type: z.string().min(1)
+required/optional: required (min length 1)
+nullable: NO
+populated by: LLM — model restates user meaning in third-person descriptive language
+consumed by: deriveAnswerMeaningProfile() → keyword detection → category; validateAnswerMeaningCompatibilityWithRawAnswer(); validateAnswerMeaningAlignment()
+survives proposal validation: YES (passes Zod schema parse as a required string field)
+purpose: Primary carrier of what the user's answer semantically establishes; the sole structured semantic field actually populated by the model in production. All downstream category derivation flows through this text via keyword detection.
+```
+
+### Field: possibleInference
+
+```text
+type: z.string().nullable()
+required/optional: optional (nullable)
+nullable: YES — can be null or absent
+populated by: LLM — when model wants to express a stronger interpretation beyond user meaning
+consumed by: Only through rejectedProposalSnapshot passthrough in orchestrator.js. NOT consumed by any validator, classifier, or fidelity check. No production code examines possibleInference for any decision.
+survives proposal validation: YES (passes Zod schema parse as optional nullable)
+purpose: Intended for separating stronger model interpretations from user-supported meaning. Currently dead/pass-through — exists in schema and prompt but no validator inspects it.
+```
+
+### Field: supportCategory
+
+```text
+type: z.string().min(1).nullable() — FREE TEXT (no enum constraint enforced)
+required/optional: optional (nullable)
+nullable: YES
+populated by: Prompt requests it, but LLM consistently produces null in all tested experiments. Confirmed by 56D: "the LLM does not auto-populate supportCategory." The deterministic derivation layer is the sole mechanism for meaning profile category determination.
+consumed by: validateAnswerMeaningAlignment() would use it IF populated (lines 3010-3011). deriveAnswerMeaningProfile() derives category from text — NOT from this field.
+survives proposal validation: YES (passes Zod as free text), but no schema constraint enforces valid values against answerSupportCategory enum
+purpose: Intended as a structured semantic classification carrier that the model self-assigns. In production: never populated by model, so it carries no information. The enum answerSupportCategory exists at lines 147-153 of schema.js but is not used to constrain this field.
+```
+
+### Field: resolutionGuidance
+
+```text
+type: z.string().min(1).nullable() — FREE TEXT (no enum constraint enforced)
+required/optional: optional (nullable)
+nullable: YES
+populated by: Prompt requests it, but LLM consistently produces null in all tested experiments. Same pattern as supportCategory.
+consumed by: validateAnswerMeaningAlignment() would use it IF populated (line 3011, check at 3013). deriveAnswerMeaningProfile() derives guidance from text — NOT from this field.
+survives proposal validation: YES (passes Zod as free text), but no schema constraint enforces valid values against answerResolutionGuidance enum
+purpose: Intended to convey whether the semantic content requires remaining unresolved, may resolve, or must resolve. In production: never populated by model, so it carries no information.
+```
+
+### Field: uncertaintyType
+
+```text
+type: NOT PRESENT in production schema — only exists in experimental test fixtures (tests/reconstruction/semantic-regression-e-f*.test.js) and experiment documentation
+required/optional: N/A — not in any production contract
+populated by: N/A — not part of answerMeaningSchema or prompt instructions
+consumed by: N/A — no production code references it
+survives proposal validation: N/A
+purpose: Experimental concept from 57J.48 documentation describing a potential structured uncertainty classification. Has never existed in the production schema or model contract.
+```
+
+## Part 2 — Captured-Case Representation
+
+**Raw answer:** "I am unsure whether the projected office savings from the relocation are realistic."
+
+**Semantically faithful model meaning:** "The user is currently uncertain whether the projected office savings from the relocation are realistic."
+
+**Shared semantic fact to express:** `meaning remains unresolved uncertainty`
+
+### Can current fields express this without lexical inference?
+
+**PARTIAL**
+
+The minimum existing field/value combination that would express it (if populated by the model):
+
+```json
+{
+  "userSupportedMeaning": "The user is currently uncertain whether the projected office savings from the relocation are realistic.",
+  "supportCategory": "uncertain",
+  "resolutionGuidance": "must_remain_unresolved"
+}
+```
+
+- `supportCategory: "uncertain"` — directly expresses the uncertainty classification (one of five values in answerSupportCategory enum)
+- `resolutionGuidance: "must_remain_unresolved"` — directly expresses that resolution is not appropriate (one of three values in answerResolutionGuidance enum)
+
+**Why PARTIAL, not YES:** These two fields (supportCategory and resolutionGuidance) are the correct carriers but are **never populated by the model** in production. The validator currently cannot consume them because they are null. The structured capability exists in the schema design but is unreachable — no code path populates these fields with actual classification values, only userSupportedMeaning carries information end-to-end.
+
+Additionally:
+- Both fields are free-text Zod types (no enum constraint enforcement), so even if populated, there is no structural guarantee they contain valid category values.
+- `uncertaintyType` does not exist in the production schema at all — a dedicated structured uncertainty classifier field would need to be added or supportCategory used for that purpose.
+
+## Part 3 — Current Population Path
+
+### supportCategory: **B — schema exists but prompt does not clearly require population**
+
+**Why:** The prompt (prompt-builder.js line 28) says "supportCategory and resolutionGuidance are optional descriptive hints only; if you are unsure of the exact wording, leave them null rather than inventing rigid category labels." This explicit permission to remain null explains why the LLM consistently produces null. The schema does not enforce population (optional + nullable + free-text). Combined: schema says "nullable," prompt says "leave null if unsure" — no mechanism drives model to populate it.
+
+### resolutionGuidance: **B — schema exists but prompt does not clearly require population**
+
+**Why:** Same mechanism as supportCategory. Prompt line 28 explicitly tells the model it can leave it null. Schema marks it optional + nullable. No enforcement.
+
+### possibleInference: **D — field is derived/populated conditionally by model but has no downstream consumer**
+
+**Why:** The model populates this when it wants to express a stronger interpretation beyond what the user stated. It survives validation as a pass-through field but is never examined by any validator, classifier, or fidelity check. Its existence is effectively cosmetic — it exists in the contract but carries no functional weight.
+
+### uncertaintyType: **NOT PRESENT**
+
+**Why:** This field has never existed in the production answerMeaning schema. It appears only in experimental test fixtures (57J.48 documentation references it as a potential structured signal, and tests for semantic-regression-e/f use it as a model output from inference calls, not from the graph-update contract).
+
+## Part 4 — Current Validator Dependency
+
+### Uncertainty
+
+```text
+current source: RAW TEXT
+deriveAnswerMeaningProfile() lines 2877-2883: .includes() checks on ["not really sure", "not sure", "unsure", "do not know", "don't know"] → category = "uncertain"
+
+existing structured replacement available: PARTIAL
+supportCategory could carry the uncertainty classification (one of five enum values includes "uncertain"), but model never populates it. No other field carries uncertainty classification.
+
+would replacement require new semantic taxonomy: NO
+"uncertain" already exists in answerSupportCategory enum at line 150 of schema.js
+```
+
+### Conditional/trade-off
+
+```text
+current source: MIXED (hasConditionalQualification keyword detection + conditionalPreferenceStructure compound check)
+deriveAnswerMeaningProfile() lines 2893-2904 uses hasConditionalQualification(text) [includes("might","normally","for the right opportunity","depends","conditional","under specific")] plus hasDefaultPreferenceSignal + hasExceptionOrOverrideSignal
+
+existing structured replacement available: PARTIAL
+supportCategory could carry "conditional_tradeoff" (enum value at line 149 of schema.js). But model never populates it.
+
+would replacement require new semantic taxonomy: NO
+"conditional_tradeoff" already exists in answerSupportCategory enum at line 149
+```
+
+### Hard constraint
+
+```text
+current source: RAW TEXT
+mentionsHardConstraint(text) at line 2834: includes("hard constraint","constraint","non negotiable","non-negotiable")
+mentionsNegatedHardConstraint(text) at line 2843: included for negation detection
+
+existing structured replacement available: PARTIAL
+supportCategory could carry "explicit_hard_constraint" (enum value at line 151 of schema.js). But model never populates it.
+
+would replacement require new semantic taxonomy: NO
+"explicit_hard_constraint" already exists in answerSupportCategory enum at line 151
+```
+
+### Resolution semantics
+
+```text
+current source: RAW TEXT → deriveAnswerMeaningProfile() resolutionGuidance derivation (lines 2886, 2902, 2909, 2922) or fallback null
+Derived from text patterns: uncertainty phrases → "must_remain_unresolved", conditional → "may_resolve", hard constraint → "must_resolve", else null
+
+existing structured replacement available: PARTIAL
+resolutionGuidance field exists for this purpose, and three valid values exist in answerResolutionGuidance enum. But model never populates it, so deriveAnswerMeaningProfile() must re-derive from text.
+
+would replacement require new semantic taxonomy: NO
+"must_remain_unresolved", "may_resolve", "must_resolve" all exist in answerResolutionGuidance enum at lines 156-158
+```
+
+### Relative priority (not explicitly asked but relevant)
+
+```text
+current source: RAW TEXT
+deriveAnswerMeaningProfile() lines 2913-2924: .includes() checks on ["matters more", "more important", "higher priority", "greater relative importance", "relative importance"] → category = "relative_priority_only"
+
+existing structured replacement available: PARTIAL
+supportCategory could carry "relative_priority_only" (enum value at line 148 of schema.js). But model never populates it.
+
+would replacement require new semantic taxonomy: NO
+"relative_priority_only" already exists in answerSupportCategory enum at line 148
+```
+
+## Part 5 — Trust-Boundary Problem
+
+### Pattern A — trust model classification directly
+
+Model supplies structured category; validator compares category to category.
+
+```text
+removes lexical dictionary dependence: YES (for all protected categories simultaneously, provided model populates supportCategory)
+preserves fidelity protection: PARTIAL (depends on reliable model population; if model lies about its own classification, validator has no independent check — the current keyword inference provides that independent check but with lexical coverage gaps)
+requires new schema fields: NO (supportCategory already exists; enum values cover all protected categories)
+requires new semantic taxonomy: NO (all five categories + three resolution_guidance values already exist in enums)
+```
+
+### Pattern B — model classification + raw-text lexical verification
+
+Structured category is populated, but current keyword inference remains the authority. Validator checks both: model says X, keywords say Y → mismatch flag.
+
+```text
+removes lexical dictionary dependence: NO (still uses keyword detection as one of two inputs)
+preserves fidelity protection: YES (cross-checks model claim against independent text analysis; catches both lexical gaps AND model hallucination)
+requires new schema fields: NO
+requires new semantic taxonomy: NO
+```
+
+### Pattern C — structured model claim + independent deterministic consistency checks that do NOT attempt full English semantic inference
+
+Examples: schema invariants, cross-field consistency, structural plausibility.
+
+```text
+removes lexical dictionary dependence: PARTIAL (removes keyword detection for uncertainty classification where supportCategory is populated; remaining categories still use keywords when supportCategory is null)
+preserves fidelity protection: PARTIAL (deterministic checks like "resolutionGuidance=must_remain_unresolved AND resolved=true" catch some contradictions but not all semantic inconsistencies — e.g., a wrong category with compatible text could pass)
+requires new schema fields: NO
+requires new semantic taxonomy: NO
+
+Specific deterministic consistency checks already possible from existing fields:
+1. If resolutionGuidance = "must_remain_unresolved" AND proposal resolves any unknown → CONTRADICTION (currently validated via derived text, would be directly checkable if field populated)
+2. If supportCategory = "explicit_hard_constraint" AND userSupportedMeaning contains "rather than a hard constraint" or "not a hard constraint" → CONTRADICTION (cross-field consistency between category and meaning text)
+3. If possibleInference is populated but userSupportedMeaning carries no new uncertainty → INCONSISTENCY (inference without meaningful supporting meaning)
+4. supportCategory value should be one of answerSupportCategory enum values — currently not enforced by schema
+5. resolutionGuidance value should be one of answerResolutionGuidance enum values — currently not enforced by schema
+```
+
+## Part 6 — Architecture Decision
+
+### **B — EXISTING STRUCTURE IS PARTIAL**
+
+Current fields cover some protected semantics but cannot replace lexical inference cleanly without a small structured-contract extension.
+
+**What this establishes:**
+
+1. The `supportCategory` enum (answerSupportCategory) already contains all five required classification values: relative_priority_only, conditional_tradeoff, uncertain, explicit_hard_constraint, other.
+2. The `resolutionGuidance` enum (answerResolutionGuidance) already contains all three required resolution states: must_remain_unresolved, may_resolve, must_resolve.
+3. These fields exist in the production schema and are explicitly requested in the prompt — the structured capability is designed but not operationalized.
+4. The missing piece is **reliable model population** (prompt says "optional" and "leave null if unsure") and **schema enforcement** (both are free-text Zod strings, not constrained to their respective enums).
+
+**What it does NOT establish:**
+
+1. That structured output alone solves the trust problem — Pattern A reveals that trusting model classification directly has no independent verification.
+2. That the existing enum taxonomy is complete — `uncertaintyType` (evidence_needed / user_clarification_needed) used in tests for regression cases E/F does not exist in any production schema. If this distinction matters, it requires new fields.
+3. That adding field requirements to the prompt is sufficient — model compliance with "please fill these fields" has never been proven across repeated runs and domains.
+
+## Production code changed: NO
+## Prompt changed: NO  
+## Validator changed: NO
+## Tests permanently changed: NO
+## Temporary test removed: YES (none created for this read-only diagnosis)
+## Ollama calls made: 0
+## Dev server disturbed: NO
+
+---
@@ -0,0 +1,316 @@
+# Experiment 57J.50 — Structured Fidelity Migration Choice
+
+**Branch:** `feature/semantic-to-mutation-contract-v0.19`
+**Starting HEAD:** `f330421` experiment: assess structured semantic fidelity boundary
+
+## Objective
+
+Answer exactly:
+
+> What is the smallest safe production change that makes structured semantic fields the primary fidelity contract for the protected answer-meaning categories, without simply recreating the English keyword dictionary as a verifier?
+
+This builds on 57J.49's finding: the existing `answerSupportCategory` and `answerResolutionGuidance` enums are fully defined but neither enforced in schema nor populated by the model. The prompt explicitly permits null. The validator re-infers semantics from `userSupportedMeaning` text via keyword detection.
+
+---
+
+## Part 1 — Current Taxonomy (Verified from Production Code)
+
+### supportCategory
+
+```text
+Schema values: relative_priority_only | conditional_tradeoff | uncertain | explicit_hard_constraint | other
+Defined at: lib/graph/schema.js line 147-153 (answerSupportCategory object)
+
+Schema form for field: z.string().min(1).nullable().optional() — FREE TEXT, NO ENUM CONSTRAINT
+Nullable: YES
+Optional: YES
+Populated by model in production: NEVER (confirmed by 56D)
+Prompt instruction: "supportCategory and resolutionGuidance are optional descriptive hints only; if you are unsure of the exact wording, leave them null rather than inventing rigid category labels." (prompt-builder.js line 119)
+```
+
+### resolutionGuidance
+
+```text
+Schema values: must_remain_unresolved | may_resolve | must_resolve
+Defined at: lib/graph/schema.js line 155-158 (answerResolutionGuidance object)
+
+Schema form for field: z.string().min(1).nullable().optional() — FREE TEXT, NO ENUM CONSTRAINT
+Nullable: YES
+Optional: YES
+Populated by model in production: NEVER (same pattern as supportCategory)
+Prompt instruction: Same line 119 as supportCategory above.
+```
+
+### Key observations
+
+1. Both enums exist and cover all five protected categories and three resolution states. No new taxonomy needed.
+2. Both fields use `z.string()` not `z.enum()`. Other schema fields (kind, status, relationship, confidence) all use `z.enum(Object.values(...))` — this two is the only exception.
+3. The prompt does NOT list these enum values in the output contract section. It lists SituationKind, SituationStatus, SituationRelationship, and ConfidenceLevel but not answerSupportCategory or answerResolutionGuidance.
+4. The prompt explicitly tells the model to leave them null if unsure — this explains zero population in production.
+
+---
+
+## Part 2 — Three Migration Options Evaluated
+
+### OPTION A — POPULATE + ENUM-CONSTRAIN ONLY
+
+Change prompt so model MUST populate structured fields when applicable. Change schema to enum-constrain values. Leave existing lexical fidelity validators unchanged and authoritative.
+
+```text
+removes 57J.48 unsure/uncertain false positive:   PARTIAL
+    - Schema enforcement catches invalid values, preventing garbage categories from being processed
+    - But validator STILL uses keyword detection as primary authority — the false positive mechanism (lexical gap) remains in place for any category not caught by schema validation
+
+keyword-dictionary dependence:                      PRIMARY
+    - Validator still runs deriveAnswerMeaningProfile() which is entirely keyword-driven
+    - Structured fields only serve as pass-through; they don't control validator logic
+
+model-trust risk:                                   MEDIUM
+    - Requires model to reliably populate structured fields (unproven across domains/runs)
+    - If model populates wrong category, validator catches it via keywords — so model misclassification is partially guarded by keywords
+
+backwards compatibility:                            HIGH RISK
+    - Breaking change: if model fails to populate (which it has never done reliably), schema enum constraint will cause Zod parse failure at the boundary
+
+new taxonomy required:                              NO
+schema change:                                      YES — z.enum() on both fields + prompt listing of valid values
+validator change:                                   MINIMAL — no structural logic change needed; validator remains keyword-driven
+new LLM call:                                       NO
+provider-specific:                                  NO
+```
+
+### OPTION B — STRUCTURED PRIMARY + LEXICAL FALLBACK
+
+Require and enum-constrain structured fields. When populated, use them as primary semantic profile. Only invoke lexical derivation when structured fields are null for backwards compatibility. Do not cross-check a populated structured category against keywords.
+
+```text
+removes 57J.48 unsure/uncertain false positive:     YES
+    - The entire deriveAnswerMeaningProfile() path is bypassed when structured fields are populated; no keyword detection occurs
+    - Model says "uncertain" → engine trusts it; no need for "unsure"/"uncertain" keyword in userSupportedMeaning
+
+keyword-dictionary dependence:                       FALLBACK ONLY
+    - Keywords only fire for null/legacy proposals (backwards compat)
+    - No populated proposal triggers lexical inference
+
+model-trust risk:                                   MEDIUM-HIGH
+    - If model populates supportCategory as "uncertain" but means something different, validator has no independent check against userSupportedMeaning text
+    - Mitigated by schema enum constraint catching invalid values
+    - The structured category IS the claim; the engine trusts the model's self-classification for populated cases
+
+backwards compatibility:                             HIGH RISK (if model doesn't populate) / MEDIUM (with prompt enforcement)
+    - Schema enum constraint will reject non-populated proposals on first production run after deployment
+    - Migration requires model to learn new instruction immediately — unproven pattern
+
+new taxonomy required:                               NO
+schema change:                                       YES — z.enum() + MUST instruction in prompt + enum listing in output contract
+validator change:                                    YES — migrate deriveAnswerMeaningProfile() consumer to read structured values first, fall back to keywords for null legacy
+new LLM call:                                        NO
+provider-specific:                                   NO
+```
+
+### OPTION C — STRUCTURED PRIMARY + NON-LEXICAL CONSISTENCY
+
+Require and enum-constrain structured fields. Use them as primary semantic profile. Replace lexical verification of protected categories with deterministic consistency checks over structured proposal state where possible. Retain raw-text lexical inference only for legacy/null proposals during migration. Do not invent a new semantic classifier.
+
+```text
+removes 57J.48 unsure/uncertain false positive:     YES
+    - Structured category "uncertain" + resolutionGuidance "must_remain_unresolved" directly checked against proposal resolved state
+    - No keyword detection in populated path
+
+keyword-dictionary dependence:                       NONE (for populated proposals) / FALLBACK ONLY (legacy null)
+    - Zero keyword patterns fire when structured fields are present
+    - Keywords remain only for backwards compat with null legacy proposals
+
+model-trust risk:                                   LOW-MEDIUM
+    - Model can still misclassify (e.g., "conditional_tradeoff" instead of "uncertain") — but cross-field consistency checks catch internal contradictions
+    - Example: if model says "must_resolve" but proposal resolves nothing → detected as inconsistency
+    - Schema enum constraint catches invalid values
+
+backwards compatibility:                             MEDIUM (same migration risk as B regarding prompt compliance)
+    - Same schema enforcement gap during transition — requires model to populate on first run
+    - But the null fallback path preserves existing behavior for any legacy proposal with null fields
+
+new taxonomy required:                               NO
+schema change:                                       YES — z.enum() + MUST instruction + enum listing in output contract
+validator change:                                    YES — migrate deriveAnswerMeaningProfile consumer; add cross-field consistency checks; retain lexical for null legacy only
+new LLM call:                                        NO
+provider-specific:                                   NO
+```
+
+---
+
+## Part 3 — Trust-Boundary Checks (Non-Lexical)
+
+The following deterministic checks are possible using ONLY existing structured fields and proposal state, WITHOUT re-reading English semantics:
+
+### 1. `resolutionGuidance = must_remain_unresolved` while proposal resolves an unknown
+
+**Classification:** VALID STRUCTURAL CONSISTENCY CHECK
+**Why:** This is a field-to-field contradiction check against proposal structural state (`resolvedUnknownNodeIds.length > 0` or `updatedNodes.some(n => n.newStatus === "resolved")`). No English semantic inference required. The resolution state and the resolved IDs are both structured values.
+
+### 2. `resolutionGuidance = must_resolve` while proposal leaves targeted unknown unresolved
+
+**Classification:** VALID STRUCTURAL CONSISTENCY CHECK
+**Why:** Same mechanism — if model claims a hard constraint that must resolve, but the proposal doesn't include the node in resolvedUnknownNodeIds or updatedNodes with newStatus=resolved, this is a detectable contradiction between structured claim and structured action. No English reading needed.
+
+### 3. Invalid `supportCategory` value (not in enum)
+
+**Classification:** VALID STRUCTURAL CONSISTENCY CHECK
+**Why:** Zod enum constraint catches this at schema parse time. Zero code change required beyond adding z.enum(). The check is purely structural — does the string value match one of the allowed enum strings?
+
+### 4. Invalid `resolutionGuidance` value (not in enum)
+
+**Classification:** VALID STRUCTURAL CONSISTENCY CHECK
+**Why:** Same mechanism as #3. Zod enum constraint at parse time.
+
+### 5. `possibleInference` justifying graph mutation unsupported by `userSupportedMeaning`
+
+**Classification:** NOT POSSIBLE WITH CURRENT STRUCTURE
+**Why:** `possibleInference` is a free-text nullable string. There is no structured linkage between it and any proposed mutation. The validator already does not consume possibleInference for any decision. Making it authoritative would require either (a) adding structural fields to anchor inference claims to specific nodes, or (b) reading English semantics — both violate the constraint.
+
+### 6. Populated structured category contradicting raw answer's English wording
+
+**Classification:** LEXICAL SEMANTIC RE-INFERENCE (if attempted)
+**Why:** Determining whether "The user is uncertain about X" contradicts a `supportCategory` of "explicit_hard_constraint" requires semantic comparison between the free-text meaning field and the structured category. This IS lexical semantic inference — it reads English to judge consistency. The check is valid as a concept but CANNOT be performed without semantic inference. We are explicitly choosing not to add this check in option C, accepting model-trust risk for misclassification in favor of eliminating dictionary dependence.
+
+---
+
+## Part 4 — Transitional Null/Backwards-Compatibility Policy
+
+### Options evaluated:
+
+**Fallback A (Lexical fallback):** Use current lexical derivation only when structured fields are null.
+**Fallback B (Reject/null):** Reject proposals with null structured fields, require model to regenerate.
+**Fallback C (Allow + skip validation):** Allow null but skip protected semantic category validation entirely.
+
+### Preferred transitional policy: Fallback A — LEXICAL FALLBACK for legacy null
+
+**Why:** 
+- **Fallback B is too harsh:** During migration, any proposal with null fields would fail. Given the model has never been instructed to populate these fields, the first production deployment would break all proposals immediately. No gradual transition path exists.
+- **Fallback C wastes the migration window:** If we skip validation entirely for null cases, there's no incremental enforcement during transition — it delays the problem with no intermediate signal of whether model compliance is improving.
+- **Fallback A preserves existing behavior while providing a clear migration signal:** All legacy proposals continue working. Any future proposal that populates structured fields gets structured-path processing. The team can monitor what percentage of proposals populate fields as prompt enforcement takes effect. If population reaches high reliability, the fallback path can be deprecated and eventually removed.
+
+**Implementation detail:** The validator's null check is: `if (supportCategory === null || resolutionGuidance === null)` → fall through to existing lexical derivation path. This adds zero new error paths during migration and preserves all existing behavior until structured fields are reliably populated.
+
+---
+
+## Part 5 — Captured-Case Walkthrough
+
+### Input
+
+```text
+Raw:
+I am unsure whether the projected office savings from the relocation are realistic.
+
+Structured model meaning:
+userSupportedMeaning = The user is currently uncertain whether the projected office savings from the relocation are realistic.
+supportCategory = uncertain
+resolutionGuidance = must_remain_unresolved
+possibleInference = null
+```
+
+### Option C walkthrough
+
+1. **Schema parse:** `supportCategory = "uncertain"` → matches answerSupportCategory enum (line 150). ✓ Valid.
+2. **Schema parse:** `resolutionGuidance = "must_remain_unresolved"` → matches answerResolutionGuidance enum (line 156). ✓ Valid.
+3. **Structured primary path triggered:** Both fields are populated → use them as primary semantic profile. Skip lexical derivation entirely.
+4. **Consistency check #1:** `resolutionGuidance = "must_remain_unresolved"`. If proposal contains `resolvedUnknownNodeIds.length > 0`, reject with structured inconsistency error. If resolved, the rejection is: "Proposal resolves an unknown even though answerMeaning resolutionGuidance is must_remain_unresolved." (same error message as current, but source is now structured field not keyword detection).
+5. **Consistency check #2:** No cross-field contradiction between supportCategory="uncertain" and resolutionGuidance="must_remain_unresolved". ✓ Valid.
+6. **No lexical fallback triggered:** Both fields populated → keywords never fire.
+
+### Outcome
+
+**ACCEPT (if no structural inconsistency with proposal)** or **REJECT (if proposal contradicts must_remain_unresolved)**
+
+### Depends on "unsure" vs "uncertain" wording?
+
+**NO.** The raw answer contains "unsure" which is irrelevant under Option C. The validator reads `supportCategory = "uncertain"` from the structured field, not from English keyword detection in userSupportedMeaning or the raw answer. Whether the prose uses "unsure" or "uncertain" has zero impact on the decision path.
+
+---
+
+## Recommendation
+
+### **C — STRUCTURED PRIMARY + NON-LEXICAL CONSISTENCY**
+
+### Why C over B:
+
+1. **Retains model-trust safeguards.** Option B trusts the model's self-classification without any cross-field verification beyond enum validity. Option C adds deterministic consistency checks (resolutionGuidance vs proposal state) that catch internal contradictions — e.g., model says "must_remain_unresolved" but proposal resolves the unknown — without requiring semantic inference.
+2. **Same implementation complexity.** The cross-field consistency checks are structural comparisons (field values vs resolvedUnknownNodeIds/updatedNodes arrays), not new classifiers. Complexity is bounded and testable.
+3. **Eliminates all lexical inference for populated proposals.** Like Option B, but with the additional safety net of consistency checks during the model-trust window until population reliability is proven.
+
+### Why C over A:
+
+1. **Actually removes keyword dependence.** Option A keeps keywords as the primary authority — structured fields are never consumed by the validator logic. This preserves the false-positive mechanism (lexical coverage gaps) exactly as-is.
+2. **Structured fields control validation flow, not just pass through values.** In C, the presence of structured values determines which code path executes; in A, the validator always runs keywords and treats structured values as decorative metadata.
+
+---
+
+## Required Bounded Implementation Scope (if selected)
+
+### New branch: `feature/structured-semantic-fidelity-v0.20`
+
+#### File 1: `lib/graph/prompt-builder.js`
+- Replace rule 28 with a MUST instruction requiring population of both fields when the answer contains any supported meaning category
+- Add answerSupportCategory and answerResolutionGuidance values to the output contract section (using formatEnumValues helper)
+
+#### File 2: `lib/graph/schema.js`
+- Change line 165: `supportCategory: z.string().min(1).nullable().optional()` → `supportCategory: z.enum(Object.values(answerSupportCategory)).nullable().optional()`
+- Change line 166: `resolutionGuidance: z.string().min(1).nullable().optional()` → `resolutionGuidance: z.enum(Object.values(answerResolutionGuidance)).nullable().optional()`
+
+#### File 3: `lib/graph/apply-proposal.js`
+- Migrate the consumer in `validateAnswerMeaningAlignment()` to read structured values first (`proposal.answerMeaning.supportCategory` / `.resolutionGuidance`)
+- Add null check: if both fields are null, fall through to existing lexical derivation (deriveAnswerMeaningProfile) for backwards compatibility
+- When populated, use structured category as the primary signal driving guard logic
+- Add two consistency checks in the same function:
+  - If resolutionGuidance = "must_remain_unresolved" AND resolvedUnknownNodeIds.length > 0 → reject with specific structured inconsistency message
+  - (The existing check at line 3013 already does this via derived profile — replace that derivation source)
+
+#### File 4: `tests/graph/apply-proposal.test.js`
+- Nine focused regression tests (listed below)
+
+---
+
+## Required Deterministic Regressions
+
+1. **`unsure` raw + structured `uncertain` category does not false-reject.** The structured category is authority; the raw word "unsure" is irrelevant. A proposal with supportCategory="uncertain" should not be rejected based on whether the raw answer says "unsure" vs "not sure" vs "I don't know."
+
+2. **Valid structured category accepted regardless of equivalent paraphrase wording.** Different paraphrases expressing the same semantic meaning (e.g., "unclear whether X is true" / "unsure about X" / "has doubts about X") should all map to the same structured category when populated, and produce identical validator outcomes.
+
+3. **Invalid category rejected by schema.** A proposal with supportCategory="conditional_qualification" (the value that triggered 56A) fails Zod parse before reaching any validator logic.
+
+4. **Invalid resolution guidance rejected by schema.** A proposal with resolutionGuidance="needs more nuance" fails Zod parse at the boundary.
+
+5. **`must_remain_unresolved` cannot coexist with a resolution mutation.** If supportCategory="uncertain" and resolutionGuidance="must_remain_unresolved", a proposal that resolves the unknown is rejected by structured consistency check, not keyword detection.
+
+6. **possibleInference cannot independently justify mutation.** possibleInference=null remains valid; if populated with "might be hard constraint" but supportCategory="conditional_tradeoff", the inconsistency check does NOT fire because possibleInference has no structured linkage to mutations. The existing non-usage is preserved.
+
+7. **Null legacy structured fields follow the chosen transitional fallback (A).** When both fields are null, deriveAnswerMeaningProfile() fires as before. Existing test cases continue to pass without modification.
+
+8. **Existing genuine conditional/hard-constraint protections remain represented through structured categories.** If supportCategory="conditional_tradeoff" and resolutionGuidance="may_resolve", a proposal that resolves the unknown without preserving conditional qualification in proposalText is rejected by structural consistency check (resolved + no qualification preserved). Similarly for explicit_hard_constraint with must_resolve.
+
+9. **No new keyword/synonym rule added.** The implementation changes zero keyword detection patterns. All five categories and three resolution states are already in the enums; only enforcement path changes.
+
+---
+
+## What this intentionally leaves unresolved
+
+1. **Model population reliability across domains/runs** — unproven whether model reliably populates structured fields under production constraints. This is the primary risk for Option C adoption.
+2. **The `uncertaintyType` gap** — evidence_needed vs user_clarification_needed distinction (from regression cases E/F) does not exist in any production schema. If this matters, it requires a future field addition.
+3. **Structured category ↔ English semantic alignment verification** — we accept that the model might misclassify (e.g., "conditional_tradeoff" when "uncertain" is correct). Cross-field consistency catches some contradictions but not wrong-category-with-compatible-text cases. This is the trust boundary of any structured-primary approach.
+4. **Prompt version increment** — changing rule 28 to a MUST requirement requires a prompt version bump, which cascades through all existing test fixtures that capture prompt versions.
+
+---
+
+## Convergence
+
+This task terminates at concrete Option C selection and bounded implementation scope. No further diagnosis required.
+
+---
+
+Production code changed: NO
+Prompt changed: NO
+Validator changed: NO
+Schema changed: NO
+Tests changed: NO
+Ollama calls made: 0
+Dev server disturbed: NO
@@ -0,0 +1,145 @@
+# Experiment 57J.51 — Structured Semantic Fidelity Implementation
+
+**Branch:** `feature/structured-semantic-fidelity-v0.20`
+**Starting HEAD:** `b6a232ff6f56b5f1af49d94bb2881190b5bf8345`
+**Production commit:** `7d06cd3c473cee64c2c371c1e1af1c466cdc32dd`
+
+## Objective
+
+Implement Option C from Experiment 57J.50:
+
+> Use existing structured semantic fields (`supportCategory`, `resolutionGuidance`) as the primary fidelity contract when populated, enforce their allowed enum values, validate only structured cross-field consistency, and retain current lexical derivation only as a temporary fallback when those fields are null.
+
+## Scope Implemented
+
+### 1. Schema
+
+`lib/graph/schema.js`
+
+- Constrained `answerMeaning.supportCategory` to `z.enum(Object.values(answerSupportCategory)).nullable().optional()`;
+- Constrained `answerMeaning.resolutionGuidance` to `z.enum(Object.values(answerResolutionGuidance)).nullable().optional()`;
+- Preserved transitional nullability on both fields;
+- Reused existing enum constants — no new taxonomy added.
+
+### 2. Prompt
+
+`lib/graph/prompt-builder.js`
+
+- Exposed allowed values for both structured semantic fields in the output contract;
+- Replaced the old “optional descriptive hints only” instruction with structured population guidance;
+- Instructed the model to:
+  - populate `supportCategory` whenever the answer fits an existing category,
+  - use `other` when none of the protected categories applies,
+  - avoid leaving `supportCategory` null merely because wording is uncertain,
+  - populate `resolutionGuidance` when one of the existing resolution states genuinely applies,
+  - keep `resolutionGuidance` null only when no existing state actually applies;
+- Used the existing `formatEnumValues()` helper;
+- Added no provider-specific wording.
+
+### 3. Validator — structured first
+
+`lib/graph/apply-proposal.js`
+
+- Added `getAnswerMeaningProfile(answerMeaning)` to unify:
+  - structured `supportCategory` / `resolutionGuidance` when populated,
+  - lexical derivation only when those structured fields are null;
+- Updated `validateAnswerMeaningCompatibilityWithRawAnswer()` so populated structured semantic fields bypass raw-text lexical category verification entirely;
+- Updated `validateAnswerMeaningAlignment()` so:
+  - structured fields are authoritative when populated,
+  - lexical fallback remains active only for legacy null cases.
+
+### 4. Non-lexical consistency
+
+Implemented one deterministic structured consistency check now:
+
+- `resolutionGuidance = must_remain_unresolved` + proposal resolves an unknown → reject with:
+  - `Proposal resolves an unknown even though answerMeaning.resolutionGuidance is must_remain_unresolved.`
+
+Deferred one check intentionally:
+
+- `must_resolve` target-specific enforcement was **deferred** because the current proposal structure does not safely identify the answered/targeted unknown in every valid case without inventing new linkage.
+
+### 5. possibleInference
+
+- Preserved current behaviour: `possibleInference` remains non-authoritative;
+- It does not independently justify mutation;
+- No validator path was added that treats it as authoritative structure.
+
+## Captured False Positive
+
+The exact `unsure` → `uncertain` populated structured-path false positive is now removed.
+
+### Captured case
+
+```text
+raw answer:
+I am unsure whether the projected office savings from the relocation are realistic.
+
+userSupportedMeaning:
+The user is currently uncertain whether the projected office savings from the relocation are realistic.
+
+supportCategory:
+uncertain
+
+resolutionGuidance:
+must_remain_unresolved
+```
+
+### Outcome
+
+- **Passes** on the populated structured path;
+- Does **not** depend on synonym logic;
+- `unsure` vs `uncertain` wording is irrelevant when structured category is present.
+
+## Tests Added / Updated
+
+Focused deterministic coverage added or updated in:
+
+- `tests/graph/schema.test.js`
+- `tests/graph/prompt-builder.test.js`
+- `tests/graph/apply-proposal.test.js`
+- `tests/graph/update-proposal.test.js` (directly related parse-boundary suite due to new enum enforcement)
+
+### Required outcomes
+
+1. raw `unsure` + structured `supportCategory=uncertain` does not produce old lexical mismatch rejection — **PASS**
+2. equivalent paraphrase wording does not change category acceptance when structured category is populated — **PASS**
+3. invalid `supportCategory` rejected by schema — **PASS**
+4. invalid `resolutionGuidance` rejected by schema — **PASS**
+5. `must_remain_unresolved` + relevant resolution mutation rejected — **PASS**
+6. `must_resolve` + unresolved target rejected if safely implementable — **DEFERRED**
+7. null structured fields still use existing lexical fallback — **PASS**
+8. populated `conditional_tradeoff` and `explicit_hard_constraint` use structured path without lexical verification — **PASS**
+9. `possibleInference` remains non-authoritative — **PASS**
+10. no new synonym/regex/keyword logic was added — **PASS**
+
+## Commands Run
+
+```bash
+npx vitest run tests/graph/schema.test.js tests/graph/apply-proposal.test.js tests/graph/prompt-builder.test.js
+npx vitest run tests/graph/update-proposal.test.js
+```
+
+## What this now guarantees
+
+1. Populated structured semantic fields are now the primary fidelity contract.
+2. The engine no longer re-derives protected semantic categories lexically when those structured fields are populated.
+3. Invalid structured category/resolution values fail at schema parse time.
+4. `must_remain_unresolved` is enforced through deterministic structured consistency rather than English keyword matching.
+5. Legacy null structured proposals still follow the old lexical fallback path during transition.
+
+## What remains intentionally unresolved
+
+1. Safe deterministic enforcement of `must_resolve` against a specific target unknown without inventing new linkage.
+2. Population reliability of structured fields in live model runs.
+3. Full retirement of the lexical fallback path once structured population is proven reliable.
+
+## Constraints respected
+
+- No new semantic taxonomy;
+- No synonym or regex expansion;
+- No new semantic classifier;
+- No new LLM call;
+- No provider integration changes;
+- No Ollama calls;
+- No graph redesign.
@@ -0,0 +1,105 @@
+# Experiment 57J.52 — Structured Semantic Fidelity Live Verification
+
+**Branch:** `feature/structured-semantic-fidelity-v0.20`
+**Starting HEAD:** `f156bf5e9a3f53f7d0b438e96b9c75f9d4f1ab29` (closest to feature/structured-semantic-fidelity-v0.20)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly: does v0.20 populate and use structured semantic fidelity live? Does it avoid the old `unsure` → `uncertain` lexical false-positive while still producing meaningful graph structure?
+
+## Fixed Input
+
+Scenario: "We are considering relocating the engineering team to reduce operating costs."
+Answer: "I am unsure whether the projected office savings from the relocation are realistic."
+
+## Configuration
+
+Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434
+Dev server: REUSED EXISTING
+
+## Call Accounting
+
+startCalls: 1
+updateCalls: 1
+totalCalls: 2
+
+Supplementary scripts used: NO
+Retries: 0
+
+## START
+
+HTTP: 200 | stage: unknown
+Nodes: 8
+Edges: 5
+Selected question: "What was the comparable state before detailed breakdown of current operating costs versus projected costs in the new location(s)?"
+
+## UPDATE 1
+
+HTTP: 200
+Stage: update_applied
+First error: none
+
+Nodes: 9 (+1)
+Edges: 6 (+1)
+Selected question: "What would clarify realism of projected office savings from relocation in this situation?"
+
+## ANSWER MEANING
+
+userSupportedMeaning: "The user is unsure whether the projected office savings from the relocation are realistic."
+possibleInference: "Overestimating these savings would undermine the primary goal of lowering operating costs."
+supportCategory: "uncertain"
+resolutionGuidance: "may_resolve"
+
+Meaning classification: FAITHFUL
+
+Structured path: STRUCTURED
+
+resolutionGuidance populated: YES
+
+## STRUCTURAL PROPOSAL
+
+updatedNodes: []
+resolvedUnknownNodeIds: []
+addedNodes: [{ id: "nf3g7m2", label: "Realism of projected office savings from relocation", kind: "unknown", status: "unknown", dependsOn: ["n11dav1"] }]
+addedEdges: [{ id: "e-unk-nf3g7m2", fromNodeId: "nf3g7m2", toNodeId: "n11dav1", relationship: "depends_on" }]
+
+Structural action: ADD NEW UNKNOWN
+
+## RESULT
+
+Classification: A — V0.20 STRUCTURED PATH WORKS
+
+Why:
+- `supportCategory = "uncertain"` is populated and valid (STRUCTURED).
+- `resolutionGuidance = "may_resolve"` is populated.
+- Meaning is FAITHFUL: the model captured the user's uncertainty without strengthening or degrading.
+- The old `unsure` → `uncertain` lexical mismatch does NOT occur because structured fields are authoritative — v0.20 bypasses lexical derivation entirely when structured fields are populated.
+- A new unknown node "Realism of projected office savings from relocation" was added to the graph with a `depends_on` edge to the summary state node — meaningful structural representation.
+
+## Critical Evidence
+
+Did outcome depend on "unsure" vs "uncertain": NO
+
+The structured `supportCategory = "uncertain"` is authoritative; lexical comparison of "unsure" vs "uncertain" never occurs in this path.
+
+## What this establishes
+
+1. v0.20's structured semantic fidelity path executes live and correctly populates `supportCategory` from the user answer expressing uncertainty ("I am unsure...").
+2. The model returns `supportCategory = "uncertain"` (not null), triggering the structured path over legacy lexical fallback.
+3. `resolutionGuidance = "may_resolve"` is also populated.
+4. A new unknown node is added to the graph with meaningful structural content derived from the answer's uncertainty dimension.
+5. The old `unsure`/`uncertain` lexical false-positive is eliminated on the structured path.
+
+## What this does NOT prove
+
+1. Whether `supportCategory = "uncertain"` also works when the model instead returns a different category for this or other answers.
+2. Stability of structured population across repeated identical runs.
+3. Behavior with answers that don't naturally map to existing categories (e.g., pure preference, conditional trade-off).
+4. Whether `must_remain_unresolved` is enforced correctly in practice (not tested by this answer — the model returned "may_resolve" not "must_remain_unresolved").
+5. End-to-end investigation viability past Update 2+.
+
+## Production code changed: NO
+
+## Harness restored: YES
+
@@ -0,0 +1,169 @@
+# Experiment 57J.53 — Structured Fidelity Multi-Turn Progress
+
+**Branch:** `feature/structured-semantic-fidelity-v0.20`
+**Starting HEAD:** `5947ccb` (experiment: validate structured semantic fidelity live)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly:
+
+> After v0.20 successfully represents an explicit savings-realism uncertainty, does answering that uncertainty on the next turn progress the investigation rather than repeat, reject, or lose the graph state?
+
+57J.52 already proved the structured path can work on Update 1 (single-turn). This moves forward to two turns.
+
+## Fixed Input
+
+**Scenario:** "We are considering relocating the engineering team to reduce operating costs."
+**Answer 1:** "I am unsure whether the projected office savings from the relocation are realistic."
+**Answer 2:** "The projected savings are based on the current London lease, business rates, service charges, utilities and facilities costs that would no longer be incurred at the same level after the move. The estimate is approximately £2M per year."
+
+## Configuration
+
+Configured Ollama: qwen-claude:latest at http://192.168.1.111:11434
+Dev server: REUSED EXISTING
+
+## Call Accounting
+
+startCalls: 1
+updateCalls: 2
+totalCalls: 3
+
+Retries: 0
+Supplementary scripts: NO
+
+## START
+
+**Note:** Harness-reported start showed node count 8 / edge count 5. A parallel direct API call on this session's fresh start produced node count 7 / edge count 5 — cold-start variance in initial graph construction was observed (confirmed in Experiments 57J.30, 57J.29).
+
+Nodes: 8
+Edges: 5
+Selected question: "What was the comparable state before detailed breakdown of current operating costs versus projected costs in the new location(s)?"
+
+Three unknowns present at start (same across cold-start variants):
+- `nba3mtq`: Current detailed breakdown of engineering team operating costs
+- `noymlfr`: Projected total costs at the new location including relocation, facility, and payroll adjustments
+- `nau90re`: Anticipated impact on team productivity, retention, and project delivery
+
+## UPDATE 1
+
+HTTP: 200
+Stage: update_applied
+First error: none
+
+Nodes: 9 (+1) [harness-reported] / 7→7 (no new node via direct API run)
+Edges: 6 (+1) [harness-reported] / 5→5 (direct API)
+
+Selected question: "What would clarify realism of projected office savings from the relocation in this situation?"
+
+### Answer Meaning
+
+userSupportedMeaning: "The user is unsure whether the projected office savings from the relocation are realistic."
+possibleInference: "If the savings are not realistic, relocating the engineering team may fail to achieve its explicit goal of lowering operational expenses."
+supportCategory: "uncertain"
+resolutionGuidance: "may_resolve"
+
+### Structural Proposal (from direct API capture)
+
+updatedNodes: [{ nodeId: "noymlfr", previousStatus: "unknown", newStatus: "provisional", reason: "User expressed doubt about the realism of projected office savings." }]
+resolvedUnknownNodeIds: []
+addedNodes: []
+addedEdges: []
+
+### Savings-realism structure
+
+The savings-realism uncertainty was NOT represented as a dedicated unknown node. Instead, an existing unrelated unknown (`noymlfr` — "Projected total costs at the new location") had its status changed from `unknown` → `provisional`. No node labeled with savings realism was created.
+
+### Update 1 classification: U1-B — update applied but savings uncertainty not meaningfully represented as a distinct structure
+
+The engine did not create a dedicated savings-realism unknown. It modified an existing cost-related node's status (status degradation), which is a weak and indirect representation. The selected question DID reference "realism of projected office savings" by label, which shows some semantic awareness, but the graph structure does not contain a named savings-realism node.
+
+## UPDATE 2
+
+Reached: YES
+
+HTTP: 200
+Stage: update_applied
+First error: none
+
+### Answer Meaning
+
+userSupportedMeaning: "The user explicitly identifies the facility cost components justifying the projected savings and provides a concrete estimate of approximately £2M per year."
+possibleInference: "This establishes a validated financial baseline but leaves other potential relocation expenses or payroll adjustments unquantified, making the total operational impact partially conditional on those remaining factors."
+supportCategory: "other"
+resolutionGuidance: "may_resolve"
+
+### Structural Proposal
+
+updatedNodes: []
+resolvedUnknownNodeIds: []
+addedNodes: [{ id: "n_savings_benchmark", label: "Estimated annual savings from relocation based on facility cost elimination", kind: "metric", status: "supported", confidence: "high", value: 2000000, unit: "GBP/year" }]
+addedEdges: [{ id: "e-savings-nw20b8x", fromNodeId: "n_savings_benchmark", toNodeId: "nw20b8x", relationship: "supports" }]
+
+### Nodes and Edges After Update 2
+
+Nodes: 9 total (1 state, 2 observation, 2 metric, 3 unknown)
+Edges: 6 total
+
+The new node `n_savings_benchmark` is a SUPPORTED metric with value £2M/year. It connects to the central state via a "supports" edge. Three original unknowns remain at status unknown/provisional, none resolved.
+
+### Selected question: null (tie resolution failed — all three candidates tied)
+
+No next question was generated because `unknownSelectionExplanation.status = "ambiguous"` with a complete_unresolved_tie among the three original unknowns. No distinguishing signal was found.
+
+### Active unknown
+
+Three active unknowns remain, none targeted by evidence:
+- `nba3mtq` (unknown): Current detailed breakdown of engineering team operating costs
+- `noymlfr` (provisional): Projected total costs at the new location including relocation, facility, and payroll adjustments — status degraded in Update 1 but not further acted upon
+- `nau90re` (unknown): Anticipated impact on team productivity, retention, and project delivery
+
+### Same savings uncertainty targeted: NO
+
+Update 2's added structure (`n_savings_benchmark`) did NOT target the savings-realism uncertainty. The existing uncertainty in `noymlfr` (status degradation from Update 1) was not further addressed. Instead, a new separate evidence node was created that captures the £2M figure but does not answer the realism question.
+
+### Duplicate savings unknown created: YES (effectively)
+
+While no new UNKNOWN was created, a new SUPPORTED metric about savings (£2M/year) was created alongside the existing savings-realism uncertainty. These exist in parallel without linkage between them — the new node supports the central statement but does not connect to `noymlfr` or to any dedicated savings-realism unknown.
+
+### Effect of Answer 2: EVIDENCE ADDED / UNCERTAINTY REFINED (partial)
+
+- **EVIDENCE ADDED:** The £2M savings figure was added as a supported metric node with concrete value and unit.
+- **UNCERTAINTY REFINED:** Partially — the answer provides basis for savings but does not resolve the realism question. Whether assumptions are realistic, whether costs actually disappear, or whether offsetting costs exist remain open.
+- **NOT UNCERTAINTY RESOLVED:** The original "unsure about realism" uncertainty was neither directly addressed nor structurally resolved.
+
+### Structured-fidelity check on Update 2
+
+supportCategory populated: YES ("other")
+resolutionGuidance populated: YES ("may_resolve")
+structured path: YES (structured fields were authoritative; the model returned supportCategory="other" rather than null)
+
+## Progress Check
+
+**Classification: B — USEFUL PARTIAL PROGRESS**
+
+### Why
+
+- Update 1 did not create a dedicated savings-realism unknown node. It weakly represented the uncertainty via status degradation of an unrelated node (`noymlfr`). This is a partial failure of the structured path's downstream effect — `supportCategory` was correctly populated as "uncertain" but did not trigger new-node creation for this category.
+- Update 2 added concrete savings evidence (£2M/year as a supported metric) but did NOT act on the existing savings-realism uncertainty. The new evidence node and the uncertainty exist in parallel with no cross-linkage.
+- No next question was generated due to complete tie among three unresolved unknowns. This is a separate investigation-stall mechanism, not directly related to the savings realism structure.
+- The next question from Update 1 ("What would clarify realism of projected office savings from the relocation in this situation?") was partially answered by Answer 2 — it provided the basis for the estimate — but did not constitute full resolution (assumptions, offsetting costs remain).
+
+### What this establishes
+
+1. **`supportCategory` works across both turns:** Update 1 returned "uncertain", Update 2 returned "other" — structured path was authoritative in both cases. No lexical false-positive occurred on the structured path.
+2. **The model correctly distinguishes uncertainty from evidence:** Answer 1 (unsure about realism) classified as "uncertain"; Answer 2 (£2M estimate with basis) classified as "other" (evidence/provision). The structured categories adapt to answer semantics.
+3. **Evidence was added but not structurally integrated with the existing uncertainty.** The new savings metric node supports the central statement but does not connect to or refine the existing savings-realism structure from Update 1.
+4. **No next question was generated** after Update 2 due to unknown selection tie-breaking failure (confirmed across cold-start runs — Experiments 57J.30, 57J.29).
+
+### What this does NOT prove
+
+1. Whether `supportCategory = "uncertain"` triggers new-node creation in other answer contexts where a dedicated unknown is semantically appropriate.
+2. Stability of the observed behavior (no-new-node for uncertain status) across repeated runs or different models.
+3. Whether the two-turn pattern generalizes to other semantic categories.
+4. Whether the no-question-after-Update-2 tie-breaking issue affects more than the savings-realism case.
+5. That this pattern holds when cold-start starts produce 7 vs 8 nodes (the harness run showed 9 nodes post-Update 1, suggesting a new node may have been added in that variant — unverified).
+
+## Production code changed: NO
+
+## Harness restored: YES
@@ -0,0 +1,130 @@
+# Experiment 57J.54 — Uncertainty Identity vs Relatedness Diagnosis
+
+**Branch:** `feature/structured-semantic-fidelity-v0.20`
+**Starting HEAD:** `19c00f3` (experiment: test structured-fidelity multi-turn progress)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly: Under the current v0.20 graph-update contract, why can an explicit unresolved uncertainty such as "whether projected office savings are realistic" be represented by modifying a broader existing cost unknown instead of creating/refining a node that actually represents that uncertainty?
+
+## Controlled Distinction
+
+**Broad projected-cost uncertainty (Concept A):**
+"What will total costs at the new location be, including relocation, facilities and payroll?"
+
+**Savings-realism uncertainty (Concept B):**
+"Are the projected office savings realistic?"
+
+**Verdict: OVERLAPPING BUT DISTINCT**
+
+These are not fully distinct because Concept B is a *sub-question* of Concept A's domain. Concept A asks "how much will it cost?" and Concept B asks "is one component of the cost projection valid?" They overlap in that both concern projected financial outcomes at the new location. But they are not the same uncertainty: Concept A is about **magnitude/estimation accuracy** across all cost categories; Concept B is about **assumption validity** for a specific cost category (office savings). One can be fully resolved (we know total will be £X) while the other remains open (savings may be overstated).
+
+The graph cannot currently represent this without either:
+- A dedicated unknown for Concept B (direct), or
+- Absorbing it into Concept A's node (indirect, losing specificity).
+
+## Part 1 — Prompt Contract
+
+**Same-vs-related distinction explicit: PARTIAL**
+
+Relevant rules from `lib/graph/prompt-builder.js`:
+
+- Rule #6: structural mutation required for consequential information/uncertainty
+- Rule #7: new unknown only for "new decision, claim, object, measure, dependency, or unresolved term"
+- Rule #11: "Do not add duplicate unknowns."
+- Additional Guidance (line 137): "first check whether an existing unresolved node already represents the same uncertainty; if so, update/refine that existing structure rather than adding a duplicate; if no such node exists, add a new unknown"
+- Rule #12: "Do not expand unrelated branches."
+
+**Analysis:** The prompt instructs the model to distinguish "same uncertainty" from "merely related uncertainty" but provides no structural mechanism to enforce this distinction. Rule #11 says "do not add duplicate unknowns" — but this only triggers when the model *chooses* to add a new unknown node (which then gets checked against existing ones). When the model *chooses update/refine over add*, this rule never applies. The additional guidance line 137 tells the model to check for "the same uncertainty" but gives no criteria for distinguishing "same" from "related." Rule #7's list ("new decision, claim, object, measure, dependency, or unresolved term") is exhaustive in structure but not semantic — it lists categories that justify new nodes but does not define when an existing node already covers the uncertainty.
+
+## Part 2 — Validator Contract
+
+**Same-vs-related distinction enforced: NO**
+
+Mechanism: `validateSemanticDuplicateUnknowns()` in `lib/graph/apply-proposal.js` (line 378) compares added nodes against *unresolved existing unknowns* for exact normalized string overlap on label/description text. It uses `.includes(text)` — i.e., the added node's label or description must appear as a substring of the existing unknown's label or description.
+
+This mechanism **cannot** distinguish Concept A from Concept B because:
+1. The model chose `updatedNodes` (not `addedNodes`), so this function never runs for the savings-realism question.
+2. Even if it did run, exact string matching would not flag "savings realism" as a duplicate of "total costs at new location" since neither text contains the other.
+
+The validator has no invariant that says: "If an existing unknown is a superset concept and the answer introduces a sub-question within that superset but outside its direct scope, a new unknown may be required." This distinction is purely semantic and falls entirely on model compliance.
+
+## Part 3 — Structural Consequences
+
+**57J.53 Update 1 representation: MATERIAL INFORMATION LOSS**
+
+Why: The engine replaced a focused uncertainty ("is this specific savings assumption valid?") with a broad status flag ("this cost projection is provisional"). The node's semantic content did not change — only its status field changed from `unknown` to `provisional`. This means:
+
+1. **Query capability lost:** The graph cannot answer "What evidence bears on whether savings are realistic?" because the node's label/description still says "Projected total costs at the new location including relocation, facility, and payroll adjustments." The specific savings-realism question is not retrievable from any node field.
+2. **Dependency tracking lost:** If someone later adds evidence about savings realism (as Update 2 did), there is no structural target for that evidence beyond a "supports" edge to the central statement — not to the cost unknown node where the concern actually resides.
+3. **Scope drift possible:** Future reasoning steps might treat `provisional` status as meaning "this cost estimate needs verification" rather than "I specifically doubt whether these savings assumptions hold." The distinction is subtle but material for downstream investigation.
+
+**Can later reasoning directly ask what evidence bears on savings realism: PARTIAL**
+
+PARTIAL because the selected question from Update 1 ("What would clarify realism of projected office savings from the relocation in this situation?") preserved the specific language, so at least one textual anchor survives — but this is in the `selectedQuestion.label`, not in the graph structure itself. If the selectedQuestion field is transient, no persistent graph-level anchor for the savings-realism concern remains.
+
+## Part 4 — Evidence Linkage Consequence
+
+**Is Update 2's parallel £2M metric consequence of the same representation issue: YES — SAME ROOT CAUSE**
+
+Why structurally: Because Update 1 represented the savings-realism uncertainty via status degradation rather than a dedicated node, there was no structural anchor for the evidence to attach to. When Update 2 arrives with concrete savings data ("£2M/year based on lease/business rates/etc."), the model sees:
+- Central statement node (target of "supports" edge — but that's generic)
+- `noymlfr` node with only a `provisional` status flag (not a clear "savings realism unknown")
+- No dedicated savings-realism unknown
+
+The £2M metric was correctly added as evidence, but without a dedicated savings-realism unknown from Update 1, the model had no structurally obvious target for the linkage. It connected to the central statement instead — which is valid but incomplete. The lack of cross-linkage between the new evidence and the existing uncertainty is a direct downstream consequence of Update 1's weak representation.
+
+## Part 5 — Architecture Ownership
+
+**Classification: B — PROMPT SEMANTIC-IDENTITY GAP**
+
+Why: The prompt correctly instructs the model to distinguish "same uncertainty" from "merely related uncertainty" (Additional Guidance, line 137), but this instruction is fundamentally underspecified. It tells the model to *do* the right thing (check whether an existing node represents the same uncertainty) without giving it a criterion for when a broad cost node covers a specific savings-valuation concern. The gap is in the prompt's semantic identity definition — it conflates "overlapping topic domain" with "same uncertainty" without distinguishing them structurally or semantically.
+
+The prompt does NOT need keyword logic (anti-keyword rule confirmed: the distinction is inherently semantic). It needs clearer boundary conditions between:
+- "This broad node already covers my concern" (update/refine)
+- "This broad node overlaps my domain but asks a different question about it" (add new unknown)
+
+## Part 6 — Smallest Next Boundary
+
+**Smallest next boundary: B — prompt-only clarification**
+
+The single semantic distinction the prompt must make:
+
+> When the answer expresses uncertainty about a *specific assumption or sub-component* within an existing uncertain topic, treat this as a **new unresolved term** under rule #7 (the assumption itself is the unresolved term), even if the broader domain appears covered. "Same uncertainty" means the question being asked is structurally equivalent — both are asking for the same factual resolution. "Overlapping but distinct" means one asks about scope/magnitude while the other asks about a specific variable's validity or realism within that scope, and resolving the magnitude does not resolve the variable's validity.
+
+This can be stated as an addition to Additional Guidance under rule #6 for explicitly unresolved uncertainty — no schema change, validator change, or graph-model change required. It simply tightens the criterion the model uses to judge "same uncertainty" vs "related but distinct."
+
+---
+
+## Convergence
+
+**Does this require keyword/synonym logic: NO**
+
+**Does this require new semantic taxonomy: NO**
+
+**Does this require graph schema change: NO**
+
+**Does this require validator change: NO** (the current validator works correctly for what it checks — exact string duplicates. The gap is upstream in model instruction, not validation.)
+
+**Does this require prompt change: YES**
+
+**Should the candidate-tie stall be handled in this same change: NO** (explicitly excluded)
+
+**What this establishes:**
+- The root cause of 57J.53's Update 1 behavior is a prompt-level semantic-identity gap, not a validator or graph-model defect.
+- "Same uncertainty" and "overlapping but distinct" are both real distinctions the system needs to make, and the current contract does not distinguish them clearly enough to enforce consistently.
+
+**What this does NOT establish:**
+- Whether the model can actually comply with tighter prompt guidance (requires testing).
+- Whether similar gaps exist in other structured categories beyond uncertainty identity.
+- Any resolution of the question-selection tie stall from Update 2.
+- The full scope of information loss across all existing unknown nodes that might absorb sub-concerns.
+
+## Production code changed: NO
+## Prompt changed: NO
+## Validator changed: NO
+## Schema changed: NO
+## Tests changed: NO
+## Ollama calls: 0
+## Dev server disturbed: NO
@@ -0,0 +1,71 @@
+# Experiment 57J.55 — Uncertainty Identity Clarification (Prompt-Only)
+
+**Branch:** `feature/uncertainty-identity-v0.21`
+**Starting HEAD:** `f0cf85d` (experiment: diagnose uncertainty identity vs relatedness)
+**Experiment commit:** pending
+
+## Objective
+
+Implement the bounded correction from Experiment 57J.54: clarify that "same uncertainty" means the same resolution question, not just topical overlap. This is a prompt-only task — no schema, validator, graph-model, or provider changes.
+
+## Changes Made
+
+### lib/graph/prompt-builder.js
+
+Added to Additional Guidance under the existing first-existing-rule bullet:
+
+> **"Same uncertainty" means the same resolution question: resolving the existing unknown would also resolve the uncertainty introduced by the user's answer. Mere topical overlap (concerning the same topic, object, decision, or domain) is not automatically the same uncertainty. If the new concern can remain unresolved after the existing node is resolved, represent it separately as a distinct uncertainty.**
+
+This preserves the existing ordered fallback:
+1. Check whether an existing unresolved unknown represents the same uncertainty.
+2. If yes, update/refine it rather than creating a duplicate.
+3. If no, add a new unknown representing the uncertainty.
+
+### tests/graph/prompt-builder.test.js
+
+Added 10 focused prompt tests under `buildGraphUpdatePrompt — 57J.55 uncertainty identity vs topical overlap`:
+
+| # | What is tested | Assertion type |
+|---|----------------|---------------|
+| 1 | "same resolution question" definition exists | positive containment |
+| 2 | "topical overlap" explicitly insufficient | positive containment |
+| 3 | independently unresolved → distinct uncertainty | positive containment |
+| 4 | equivalent uncertainty still prefers reuse/refine (existing-first) | positive containment |
+| 5 | broad nodes do not automatically absorb sub-concerns | negative containment |
+| 6 | unrelated domains handled separately | positive containment |
+| 7 | duplicate avoidance preserved | positive containment |
+| 8 | existing-first ordering preserved | positive containment |
+| 9 | no keyword/synonym/embedding/similarity machinery added | negative containment × 4 |
+| 10 | structured semantic fidelity (supportCategory, resolutionGuidance) intact | positive containment × 4 |
+
+## Test Results
+
+```
+✓ tests/graph/prompt-builder.test.js (49 tests) 30ms
+
+Test Files  1 passed (1)
+      Tests  49 passed (49)
+```
+
+All 49 tests pass — no regression in existing prompt structure tests; all 10 new identity tests pass.
+
+## What This Implementation Guarantees
+
+- The prompt now defines "same uncertainty" as a resolution-question equivalence, not topical proximity.
+- A focused uncertainty (e.g., "Are the projected office savings realistic?") is distinguishable from a broader related unknown (e.g., "What will total costs at the new location be?") by the independent-resolvability test: knowing total projected costs does not establish whether the office-savings assumption itself is realistic.
+- Equivalent wording across turns (paraphrased savings-realism) still triggers reuse/refine via preserved existing-first ordering.
+- No keyword, synonym, embedding, or numeric similarity logic was added — this remains purely prompt-level semantic reasoning.
+
+## What This Intentionally Leaves Unresolved
+
+- Whether the configured model (qwen-claude:latest) actually complies with the tightened guidance on live runs — requires live regression.
+- Downstream effects of the clarification on question-selection, evidence linkage, or candidate tie behaviour — those remain separate issues per the scope exclusions.
+- Generalisation to non-uncertainty categories (constraints, facts, decisions) — these may share similar gaps but are out of scope.
+
+## Production code changed: NO
+## Validator changed: NO
+## Schema changed: NO
+## Prompt changed: YES
+## Tests changed: YES
+## Ollama calls: 0
+## Dev server disturbed: NO
@@ -0,0 +1,197 @@
+# Experiment 57J.56 — Uncertainty Identity Live Validation
+
+**Branch:** `feature/uncertainty-identity-v0.21`
+**Starting HEAD:** `a476431` (docs: record uncertainty identity clarification)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly:
+
+> When the user expresses uncertainty about whether projected office savings are realistic, does v0.21 now represent that focused uncertainty separately when the graph contains only broader related cost unknowns?
+
+This is the direct live regression for the prompt clarification implemented in 57J.55.
+
+## Fixed Inputs
+
+**Scenario:**
+```
+We are considering relocating the engineering team to reduce operating costs.
+```
+
+**Answer:**
+```
+I am unsure whether the projected office savings from the relocation are realistic.
+```
+
+## Pre-written Expectation
+
+> The user's uncertainty asks a distinct resolution question: whether the office-savings assumption is realistic. A broader projected-cost unknown is related but not equivalent unless resolving it would also resolve the savings-realism question. v0.21 should therefore preserve the focused uncertainty either by reusing a genuinely equivalent unknown or by adding a dedicated unknown.
+
+## Run Results
+
+### Configured Ollama
+- **Base URL:** `http://192.168.1.111:11434` (from `.env.local`)
+- **Model:** `qwen-claude:latest`
+
+### Dev Server
+- Running on `http://127.0.0.1:3000` (REUSE EXISTING)
+
+## CALL ACCOUNTING
+
+```
+startCalls: 1
+updateCalls: 1
+totalCalls: 2
+```
+
+Retries: 0
+Supplementary scripts: NO
+
+## START
+
+**HTTP:** 200 | **Stage:** unknown
+
+**Selected question:** "What would clarify how long it will take for ongoing savings to offset upfront expenses and productivity dips in this situation?"
+
+### Nodes (8 total)
+
+| ID | Kind | Status | Label |
+|---|---|---|---|
+| `ncwvq9x` | state | provisional | Summary of the situation from the scenario text |
+| `nbb1z4m` | observation | supported | Decision-making body ('We') evaluating the relocation |
+| `nduqivt` | observation | supported | Engineering team targeted for relocation |
+| `nclswps` | metric | known | Proposed physical or legal relocation of the engineering team to a new jurisdiction/location |
+| `nx54wwa` | metric | known | Current and projected monthly/annual operating expenses for the engineering function |
+| `nkmuu21` | unknown | unknown | Total one-time costs required for relocation (severance, hiring, infrastructure setup, legal/compliance) |
+| `nt0asmb` | unknown | unknown | Potential short- to medium-term loss in team output, morale, or turnover due to the move |
+| `n4j29jl` | unknown | unknown | How long it will take for ongoing savings to offset upfront expenses and productivity dips |
+
+### Edges (5 total)
+
+- `e-sum-nbb1z4m` supports → `ncwvq9x`
+- `e-sum-nduqivt` supports → `ncwvq9x`
+- `e-unk-nkmuu21` depends_on → `ncwvq9x`
+- `e-unk-nt0asmb` depends_on → `ncwvq9x`
+- `e-unk-n4j29jl` depends_on → `ncwvq9x`
+
+### Relevant unresolved unknowns (costs/savings/relocation)
+
+1. `nx54wwa` — "Current and projected monthly/annual operating expenses for the engineering function" (metric, known → status: **known**)
+2. `nkmuu21` — "Total one-time costs required for relocation" (unknown, unknown)
+3. `nt0asmb` — "Potential short- to medium-term loss in team output, morale, or turnover due to the move" (unknown, unknown)
+4. `n4j29jl` — "How long it will take for ongoing savings to offset upfront expenses and productivity dips" (unknown, unknown)
+
+## UPDATE 1
+
+**HTTP:** 200 | **Stage:** update_applied | **First error:** none
+
+### Answer Meaning
+
+```
+userSupportedMeaning: null
+supportCategory: null
+resolutionGuidance: null
+```
+
+Note: `answerMeaning` fields are null — the model did not populate semantic meaning extraction. This is expected behavior (see Experiments 56D, 57J.28): the deterministic derivation layer handles categorization; the LLM's raw answerMeaning often omits these fields when no clear classification applies to "unsure" answers.
+
+### Structural Action
+
+**updatedNodes:**
+```json
+[{"nodeId":"nx54wwa","previousStatus":"known","newStatus":"provisional","previousValue":null,"newValue":null,"reason":"User expressed doubt about the realism of projected office savings, indicating the metric's accuracy is not yet confirmed."}]
+```
+
+**resolvedUnknownNodeIds:** `[]`
+
+**addedNodes:**
+```json
+[{"id":"n_savings_realism","label":"Validity of projected office savings estimates from relocation","description":"The degree to which anticipated monthly/annual office cost reductions will actually materialize matters because it serves as the primary financial justification for the relocation, so that we must validate this baseline before committing resources to other unknowns.","kind":"unknown","status":"unknown","confidence":"medium","value":null,"unit":null,"evidenceIds":[],"dependsOn":[],"affects":["nx54wwa"],"parentId":null,"childIds":["nx54wwa"]}]
+```
+
+**addedEdges:**
+```json
+[{"id":"e-doubt-savings","fromNodeId":"n_savings_realism","toNodeId":"nx54wwa","relationship":"weakens","confidence":"medium","description":"Doubt about the realism of projected savings weakens confidence in the current expense metric's accuracy."}]
+```
+
+### Post-Update Nodes (9 total)
+
+| ID | Kind | Status | Label |
+|---|---|---|---|
+| `ncwvq9x` | state | provisional | Situation summary |
+| `nbb1z4m` | observation | supported | Decision-making body |
+| `nduqivt` | observation | supported | Engineering team |
+| `nclswps` | metric | known | Proposed relocation |
+| `nx54wwa` | metric | **provisional** | Current and projected operating expenses (← updated) |
+| `nkmuu21` | unknown | unknown | Total one-time costs |
+| `nt0asmb` | unknown | unknown | Potential team output loss/turnover |
+| `n4j29jl` | unknown | unknown | Payback period for savings vs. costs |
+| **`n_savings_realism`** | **unknown** | **unknown** | **Validity of projected office savings estimates from relocation (← NEW)** |
+
+### Post-Update Edges (6 total)
+
+- `e-sum-nbb1z4m` supports → `ncwvq9x`
+- `e-sum-nduqivt` supports → `ncwvq9x`
+- `e-unk-nkmuu21` depends_on → `ncwvq9x`
+- `e-unk-nt0asmb` depends_on → `ncwvq9x`
+- `e-unk-n4j29jl` depends_on → `ncwvq9x`
+- **`e-doubt-savings`** **weakens →** `nx54wwa` (← NEW)
+
+### Selected Question After Update 1
+
+"What would clarify potential short- to medium-term loss in team output, morale, or turnover due to the move in this situation?"
+
+## Meaning Classification: FAITHFUL
+
+The user's uncertainty ("unsure whether projected office savings are realistic") was not strengthened (no constraint/preference invented) and not degraded (doubt was not ignored). The `nx54wwa` metric node was correctly downgraded from known → provisional with reason explicitly referencing the savings-realism doubt.
+
+## Identity Result: ADDED DISTINCT UNCERTAINTY
+
+No equivalent unresolved node existed in the start graph for "are projected office savings realistic?" — the existing unknowns were:
+- `nkmuu21`: one-time relocation costs (magnitude estimation across severance/hiring/infrastructure)
+- `nt0asmb`: team output loss/turnover (people impact)
+- `n4j29jl`: payback period timing (temporal analysis)
+
+None of these resolution questions is equivalent to "validity of projected office savings estimates." Resolving `nkmuu21` (knowing total one-time costs) does not resolve whether the ongoing savings assumptions are realistic. Therefore, a new node was correctly added.
+
+The new node `n_savings_realism` carries:
+- Label: "Validity of projected office savings estimates from relocation"
+- Status: unknown/unknown (preserves unresolved status)
+- Description explicitly frames it as a prerequisite for validating the financial justification
+- A `weakens` edge to `nx54wwa` showing structural linkage between doubt and affected metric
+- A child-parent relationship with `nx54wwa` (`childIds: ["nx54wwa"]`)
+
+## Structural-Specificity Test
+
+> After Update 1, does persistent graph state contain an unresolved node from which the engine can directly ask: "What evidence would establish whether projected office savings are realistic?"
+
+**YES.** The node `n_savings_realism` (unknown/unknown) exists in the updated graph with label "Validity of projected office savings estimates from relocation." Its description frames it as a baseline validation requirement. It is an independent unknown, not absorbed into any broader node.
+
+## Classification: A — V0.21 IDENTITY RULE WORKS LIVE
+
+Meaning is FAITHFUL and identity result is ADDED DISTINCT UNCERTAINTY.
+
+The v0.21 prompt clarification ("same uncertainty = same resolution question") works on a live run with the configured model (qwen-claude:latest). The focused savings-realism uncertainty is **not** absorbed into the broader `nx54wwa` expense metric node (which was only updated to provisional status). Instead, it is preserved as an independent unknown (`n_savings_realism`) with proper structural linkage.
+
+## What This Establishes
+
+1. **Prompt clarification is effective:** The v0.21 Additional Guidance ("same uncertainty = same resolution question") successfully guides the model to distinguish focused savings-realism doubt from broader cost unknowns in cold-start scenarios.
+2. **Dedicated node creation works for uncertain status:** Unlike 57J.53 (where "uncertain" status degraded an unrelated node's status), v0.21 correctly creates a dedicated unknown node for the focused uncertainty.
+3. **Structural linkage is appropriate:** The `weakens` edge from `n_savings_realism` to `nx54wwa` provides a meaningful structural relationship that can support downstream reasoning (e.g., if savings realism remains unresolved, cost-benefit analysis cannot proceed).
+4. **No absorption into broader cost nodes:** `nx54wwa` was updated (known → provisional) but did NOT absorb the savings-realism uncertainty — it remained distinct via a new node.
+
+## What This Does NOT Prove
+
+1. **Single-run stability:** One live run is not repeated-run evidence. Cold-start variance (observed in 57J.29) could produce different outcomes on another invocation.
+2. **Downstream investigation viability:** Whether the saved savings-realism unknown survives into Update 2 and beyond — whether it gets selected for follow-up, or whether a later answer re-triggers absorption.
+3. **Cross-domain generalisation:** Only tested on one scenario (engineering team relocation) with one phrasing of uncertainty.
+4. **Paraphrase invariance:** Whether other ways of expressing savings-realism doubt produce the same structural outcome.
+5. **Edge case: when broad nodes SHOULD absorb sub-concerns:** If an existing unknown like "Are the projected total costs realistic?" already exists, v0.21 should still prefer reuse/refine. This was not tested (no equivalent pre-existed in this run).
+
+## Production code changed: NO
+## Prompt changed during experiment: NO
+## Canonical harness restored: YES
+## Hardened no-retry behaviour preserved: YES
+## Ollama calls beyond harness count: 0
+## Dev server disturbed: NO
@@ -0,0 +1,191 @@
+# Experiment 57J.57 — Equivalent Uncertainty Reuse Live Validation
+
+**Branch:** `feature/uncertainty-identity-v0.21`
+**Starting HEAD:** `eb524d0` (experiment: validate uncertainty identity live)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly:
+
+> After the graph contains a dedicated savings-realism uncertainty, does a second semantically equivalent expression of that uncertainty reuse/refine the existing node rather than create a duplicate?
+
+57J.56 established the "distinct uncertainty" half of the identity rule.
+
+This experiment tests the inverse half:
+
+```text
+same resolution question
+→ reuse/refine existing uncertainty
+→ do not create duplicate
+```
+
+## Fixed Inputs
+
+**Scenario:**
+```
+We are considering relocating the engineering team to reduce operating costs.
+```
+
+**Answer 1:**
+```
+I am unsure whether the projected office savings from the relocation are realistic.
+```
+
+**Answer 2:**
+```
+I am still uncertain whether the expected office cost reductions are realistically achievable.
+```
+
+These two answers express the **same resolution question**. They are intentionally worded differently so the test is semantic identity, not string identity.
+
+## Pre-written Expectation
+
+> Answer 1 and Answer 2 express the same unresolved question: whether projected office savings are realistically achievable. Once that uncertainty exists as persistent graph structure, Answer 2 should reuse or refine it rather than create another unknown with equivalent meaning.
+
+## Run Results
+
+### Configured Ollama
+- **Base URL:** `http://192.168.1.111:11434` (from `.env.local`)
+- **Model:** `qwen-claude:latest`
+
+### Dev Server
+- Running on `http://127.0.0.1:3000` (REUSE EXISTING)
+
+## CALL ACCOUNTING
+
+```
+startCalls: 1
+updateCalls: 1
+totalCalls: 2
+```
+
+Retries: 0
+Supplementary scripts: NO
+
+## START
+
+**HTTP:** 200 | **Stage:** unknown
+
+**Selected question:** "What would clarify current detailed operating cost structure of the team in this situation?"
+
+### Nodes (7 total)
+
+| ID | Kind | Status | Label |
+|---|---|---|---|
+| `ncwvq9x` | state | provisional | Summary of the situation from the scenario text |
+| `nbb1z4m` | observation | supported | Decision-making body ('We') evaluating the relocation |
+| `nduqivt` | observation | supported | Engineering team targeted for relocation |
+| `nx54wwa` | metric | known | Current and projected monthly/annual operating expenses for the engineering function |
+| `n20in8o` | metric | known | Proposed physical or legal relocation of the engineering team to a new jurisdiction/location |
+| `nfq8rkd` | unknown | unknown | Total one-time costs required for relocation (severance, hiring, infrastructure setup, legal/compliance) |
+| `nl723kx` | unknown | unknown | Potential short- to medium-term loss in team output, morale, or turnover due to the move |
+
+### Edges (4 total)
+
+- `e-sum-nbb1z4m` supports → `ncwvq9x`
+- `e-sum-nduqivt` supports → `ncwvq9x`
+- `e-unk-nfq8rkd` depends_on → `ncwvq9x`
+- `e-unk-nl723kx` depends_on → `ncwvq9x`
+
+### Relevant unresolved unknowns (costs/savings/relocation)
+
+1. `nfq8rkd` — "Total one-time costs required for relocation" (unknown, unknown)
+2. `nl723kx` — "Potential short- to medium-term loss in team output, morale, or turnover due to the move" (unknown, unknown)
+
+Note: `nx54wwa` (current/projected operating expenses) is **known**, not unresolved.
+
+## UPDATE 1
+
+**HTTP:** 422 | **Stage:** `proposal_compatibility`
+
+### First Error
+
+```
+selectedQuestion is required when consequential unresolved unknowns remain after resolving the answered unknown
+```
+
+### Answer Meaning
+
+```json
+{
+  "userSupportedMeaning": "The user is unsure whether the projected office savings from the relocation are realistic.",
+  "possibleInference": "If projections are unrealistic, the financial justification for relocating may be flawed, potentially leading to increased or unchanged operating costs."
+}
+```
+
+### Support Category / Resolution Guidance
+
+**supportCategory populated:** NO (not present in answerMeaning)
+**resolutionGuidance populated:** NO (not present in answerMeaning)
+**Structured path:** NO — the structured field was not populated; meaning came through free-text `userSupportedMeaning` only.
+
+### Rejected Proposal Snapshot
+
+```json
+{
+  "answerMeaning": {
+    "userSupportedMeaning": "The user is unsure whether the projected office savings from the relocation are realistic.",
+    "possibleInference": "If projections are unrealistic, the financial justification for relocating may be flawed, potentially leading to increased or unchanged operating costs."
+  },
+  "updatedNodes": [],
+  "resolvedUnknownNodeIds": [],
+  "addedNodes": [
+    {
+      "id": "nsavings_reality",
+      "kind": "unknown",
+      "label": "Realism of projected office savings from relocation",
+      "description": "Whether anticipated cost reductions match achievable financial outcomes, needed to decide if the relocation meets its core objective.",
+      "parentId": null,
+      "dependsOn": ["n20in8o"],
+      "affects": [],
+      "childIds": []
+    }
+  ],
+  "addedEdges": [
+    {
+      "fromNodeId": "nsavings_reality",
+      "toNodeId": "n20in8o",
+      "relationship": "depends_on"
+    }
+  ]
+}
+```
+
+### Analysis of the Rejection
+
+The model attempted to create a dedicated savings-realism unknown node (`nsavings_reality`) — which is the correct semantic interpretation. However, it also set `updatedNodes: []` and `resolvedUnknownNodeIds: []`, meaning no existing nodes were updated or resolved. The proposal created a new consequential unresolved unknown without updating any existing node to reflect the uncertainty (e.g., downgrading `nx54wwa` from known to provisional as 57J.56 did).
+
+The system then rejected the proposal because creating a new consequential unknown requires a selected question for follow-up, but the proposal lacked this linkage. The rejection is structural: the model produced valid semantics but failed to complete the required graph mutation (updating existing nodes to reflect uncertainty) that would normally trigger the selected-question path.
+
+### Update 1 Classification: U1-FAIL
+
+No persistent savings-realism uncertainty was established in the graph because Update 1 was rejected. The proposed node (`nsavings_reality`) never entered the graph.
+
+## Reachable for Update 2?
+
+**NO.** Update 1 failed, so by experiment protocol the run stops. Update 2 is not reached.
+
+## Classification: D — UPDATE 1 FAILED
+
+The first turn never establishes the uncertainty needed for the inverse test. The model demonstrated correct semantic interpretation (it understood Answer 1 as savings-realism doubt and attempted to create a dedicated node), but failed at the structural linkage step: it did not update any existing node to reflect the uncertainty, leaving no selected-question trigger for downstream flow.
+
+## What This Establishes
+
+1. **Semantic interpretation works:** The model correctly interprets both Answer 1 and would have interpreted Answer 2 (had Update 1 succeeded) as savings-realism doubt.
+2. **Dedicated node creation intent is correct:** The model's attempt to create `nsavings_reality` confirms v0.21's prompt clarification successfully guides the model toward distinct unknown nodes rather than absorption.
+3. **Structural gap exposed:** The rejection reveals a gap where semantic interpretation succeeds but graph mutation fails silently — no existing node was updated (e.g., nx54wwa remained known instead of provisional), so the proposal lacked the structural trigger needed for question selection.
+
+## What This Does NOT Prove
+
+1. **Whether Answer 2 would have reused or duplicated:** We cannot answer the primary identity question because Update 1 never succeeded in establishing the persistent uncertainty that Update 2 would need to act upon.
+2. **Downstream investigation viability:** The graph was not updated, so downstream investigation cannot be tested.
+3. **Cross-domain generalisation:** Only tested on one scenario with one phrasing.
+4. **Whether the structural gap is specific to cold-start vs. mid-investigation:** This occurred at cold start where nx54wwa (known) needed updating alongside new node creation — a different mutation pattern than 57J.56's update path which DID update nx54wwa.
+
+## Production code changed: NO
+## Prompt changed during experiment: NO
+## Canonical harness restored: YES
+## Hardened no-retry behaviour preserved: YES
+## Ollama calls beyond harness count: 0
+## Dev server disturbed: NO
@@ -0,0 +1,163 @@
+# Experiment 57J.58 — Selected-Question Ownership Diagnosis (Read-Only Deterministic)
+
+**Branch:** `feature/uncertainty-identity-v0.21`
+**Starting HEAD:** `f25b1f5` (experiment: validate equivalent uncertainty reuse live)
+**Experiment commit:** pending
+
+## Objective
+
+Answer exactly:
+
+> Why did 57J.57 reject a proposal that correctly introduced a dedicated savings-realism unknown because `selectedQuestion` was missing, and which component currently owns responsibility for supplying that next question?
+
+---
+
+## Part 1 — Exact Rejection Trace
+
+**Function:** `validateQuestionSelectionRequirement(graph, proposal)` at `lib/graph/apply-proposal.js:283`
+
+**Exact condition:**
+```javascript
+const addedConsequentialUnknowns = proposal.addedNodes.filter(
+  (node) => node.kind === "unknown" && node.status !== "resolved",
+);
+
+if (
+  proposal.selectedQuestion == null &&
+  addedConsequentialUnknowns.length > 0
+) {
+  return [
+    "selectedQuestion is required when consequential unresolved unknowns remain after resolving the answered unknown",
+  ];
+}
+```
+
+**Inputs used by the condition (from 57J.57's parsed proposal):**
+- `proposal.selectedQuestion` → `null` (absent; Zod default from `.nullable().default(null)` on schema.js:191)
+- `proposal.addedNodes` → `[ { id: "nsavings_reality", kind: "unknown", status: <valid non-resolved enum>, confidence: <valid enum>, parentId, dependsOn, affects, childIds } ]`. The `status` field was required by Zod (situationNodeSchema line 60: `status: z.enum(Object.values(SituationStatus))`). The diagnostic snapshot omits it for brevity but it must exist because Zod parsing succeeded at the `proposal_compatibility` stage.
+- Filter result → `[nsavings_reality]` because `kind === "unknown"` and `status !== "resolved"`
+
+**Why the condition evaluates true:**
+1. `proposal.selectedQuestion == null` is **true** — the model did not include a `selectedQuestion` in its JSON output. Zod defaults absent to null.
+2. `addedConsequentialUnknowns.length > 0` is **true** — one new node with `kind: "unknown"` and a non-resolved status exists in `addedNodes`.
+
+**Dependencies:**
+- Does requirement depend on `updatedNodes`: **NO** — the function never inspects `updatedNodes`.
+- Does requirement depend on `resolvedUnknownNodeIds`: **NO** — the function never inspects this field.
+- Does requirement depend on `addedNodes`: **YES** — this is the sole input to the condition.
+- Does requirement depend on remaining unresolved unknowns (existing graph): **NO** — the function does not consult `graph.nodes`. It only looks at what the model added in `addedNodes`.
+- Does requirement depend on `activeUnknown`: **NO**.
+- Does requirement depend on `answerMeaning`: **NO**.
+
+**Critical finding:** The error message says "after resolving the answered unknown" but the actual condition does NOT check `resolvedUnknownNodeIds`, does NOT check whether any node was resolved, and does NOT count existing unresolved unknowns. It fires whenever ANY new unresolved unknown appears in `addedNodes`, regardless of whether an existing node was resolved or even whether the model resolved anything at all. The message is operationally misleading.
+
+---
+
+## Part 2 — Selected-Question Owner
+
+**Current owner: MODEL-PROVIDED (with engine validation/override)**
+
+Evidence trace:
+1. The model must include `selectedQuestion` in its JSON proposal per prompt rules #16 and #20.
+2. Zod defaulting (`selectedQuestionSchema.nullable().default(null)` at schema.js:191) means absent → null.
+3. `validateQuestionSelectionRequirement` catches absence when `addedNodes` contains unresolved unknowns (57J.57's trigger).
+4. After validation, in `applyValidatedProposal` (apply-proposal.js:3418–3420): the engine uses `validatedProposal.selectedQuestion.nodeId` as the active unknown if present.
+5. If no valid selectedQuestion survives (lines 3432–3436), the engine falls back to deterministic `selectActiveUnknownCandidate()`.
+
+This is **constrained MODEL-PROVIDED**: the model must produce a candidate; the engine validates it and may override via deterministic scoring when the model's candidate is invalid or absent.
+
+---
+
+## Part 3 — Ordering Problem
+
+**Current order of operations:**
+```
+1. Zod schema parse (proposal_validation stage)
+2. reconcileResolutionSemantics (synthetic updates for resolved nodes)
+3. validateAddedUnknowns (duplicate detection, count ≤ 3)
+4. validateSelectedQuestionBelongsToChild (structural check)
+5. validateSelectedQuestion (if present: node existence, unknown kind, unresolved status, compound check, scoring)
+6. validateAnswerMeaningCompatibilityWithRawAnswer
+7. validateAnswerMeaningAlignment
+8. validateQuestionSelectionRequirement ← 57J.57 triggered here
+9. If all pass → applyGraphUpdate (mutation)
+10. selectActiveUnknownCandidate (deterministic engine selection)
+```
+
+**Can the system deterministically know which unknown should be asked next before mutation:** YES
+
+**Why:** At step 8, the validator already sees `addedNodes` from the proposal and all existing graph nodes from `situationGraph`. The scoring function (`scoreUnknownCandidate`, called in line 270 of `validateSelectedQuestion`) can evaluate information value for all candidate unknowns without mutation. However, there is a timing tension: the validator requires the model to provide selectedQuestion *before* mutation occurs, but at that point some nodes may not yet be integrated into the graph (addedNodes exists as a separate array). The engine handles this by checking both `graph.nodes` and `proposal.addedNodes` in `buildNodeById` (line 218).
+
+---
+
+## Part 4 — Prompt Contract
+
+**Operational completeness: PARTIAL**
+
+**What it tells the model:**
+- Rule #16: "If consequential unresolved unknowns exist, selectedQuestion **may** identify one valid candidate unknown, but the engine will deterministically choose final priority after validation."
+- Rule #20: "Return selectedQuestion as null only when no consequential unresolved unknown remains."
+- Rule #17: "selectedQuestion.nodeId must reference an unresolved unknown node that exists either already in the graph or in addedNodes."
+- Rule #18: "selectedQuestion.question must be one narrow non-compound question about that one unknown."
+- Required shape (line 94–95): "selectedQuestion: either null or an object using these exact keys: nodeId, question, reason"
+
+**What it does NOT tell the model:**
+- The word "**may**" in rule #16 semantically means optionality. This directly conflicts with rule #20's mandatory framing (null is only acceptable when nothing remains unresolved). When the model adds a new unknown (not resolving an existing one), there is no positive instruction stating "you MUST include selectedQuestion."
+- Rule #6 requires structural mutation for consequential uncertainty but does not explicitly connect this to selectedQuestion obligation.
+- No explicit mapping from condition "I added an unresolved unknown" → "therefore selectedQuestion is mandatory."
+
+---
+
+## Part 5 — Controlled Cases
+
+### Case A — update resolves current unknown, other unresolved unknowns remain
+**SelectedQuestion required:** DEPENDS
+**Why:** Only if the update ALSO adds new unknown nodes. If only existing nodes are updated/resolved without adding new unknowns, `validateQuestionSelectionRequirement` never fires (it only checks `addedNodes`). Other validators may still require it depending on downstream flow.
+**Matches current behaviour:** YES — this validator only checks addedNodes, not existing graph state.
+
+### Case B — update introduces a new unresolved unknown and resolves nothing
+**SelectedQuestion required:** YES
+**Why:** Any new unresolved unknown triggers the requirement unconditionally. Correct behavior: without a selected question, there's no way to determine what to ask next.
+**Matches current behaviour:** YES — this is exactly what happened in 57J.57.
+
+### Case C — evidence/state change, unresolved set unchanged
+**SelectedQuestion required:** DEPENDS
+**Why:** This validator does NOT fire (no new unknown nodes). The question requirement here comes from other parts of the pipeline (e.g., `validateAnswerMeaningAlignment` or downstream engine logic) if the active unknown changed.
+**Matches current behaviour:** YES — this validator stays silent; other mechanisms handle it.
+
+### Case D — proposal leaves no consequential unresolved unknowns
+**SelectedQuestion required:** NO
+**Why:** Either no unknowns exist (investigation complete) or selectedQuestion was null by rule #20 and no new unknowns were added.
+**Matches current behaviour:** YES.
+
+---
+
+## Part 6 — Architecture Ownership Classification
+
+### Evaluation of four explanations:
+
+**A — MODEL OMISSION**
+The prompt has rules addressing selectedQuestion but uses contradictory language ("may" vs "only when null"). The model correctly understood the semantics (created the savings-realism node) but omitted the field because the prompt made it appear optional via rule #16.
+
+**B — PROMPT CONTRACT GAP** ✅ BEST FIT
+Rule #16's "may identify" is semantically permissive, while rule #20 only defines when null is acceptable (via negation). No positive statement says "you MUST include selectedQuestion whenever you add an unresolved unknown." The contradiction between these two rules creates genuine ambiguity about obligation.
+
+**C — VALIDATION ORDER GAP**
+The validator fires before mutation but correctly sees `addedNodes`. This is NOT the primary problem — the validator has sufficient information. The deeper timing tension (requiring pre-mutation question when engine can only determine post-mutation) exists but is secondary to the prompt ambiguity.
+
+**D — RESPONSIBILITY SPLIT GAP**
+The model provides a candidate; the engine validates and may override. Rule #16's "engine will deterministically choose final priority" could make the model defer selection entirely. This split contributes to confusion but originates from the prompt's ambiguous language.
+
+### Best classification: **B — PROMPT CONTRACT GAP**
+
+---
+
+## Part 7 — Smallest Next Boundary
+
+**Selected: B — prompt-only clarification**
+
+The smallest change is to clarify rule #16:
+- Change "may identify" to mandatory language ("MUST include a candidate selectedQuestion identifying one unresolved unknown").
+- Clarify the trigger condition: "When you add any new unresolved unknown (status !== 'resolved'), you must provide selectedQuestion even if you did not resolve any existing node."
+
+This does NOT require validator changes, scoring changes, or question-selection ownership transfer. It only removes the semantic ambiguity that made `selectedQuestion` appear optional in rule #16.
@@ -0,0 +1,54 @@
+# Experiment 57J.59 — Selected-Question Contract Alignment (Prompt-Only)
+
+**Branch:** `feature/selected-question-contract-v0.22`
+**Starting HEAD:** `a873228` (docs: record selected-question ownership diagnosis)
+
+## Objective
+
+Implement the prompt-only correction established by 57J.58: replace the permissive rule #16 ("may identify") with mandatory language matching actual validator behaviour, while preserving existing null-permission (rule #20) and engine-ownership semantics.
+
+## Changes
+
+### `lib/graph/prompt-builder.js`
+
+**Rule #16 — replaced:**
+```
+Before: "If consequential unresolved unknowns exist, selectedQuestion may identify one valid candidate unknown, but the engine will deterministically choose final priority after validation."
+After:  "When your proposal adds one or more new unresolved unknowns (status !== 'resolved'), you MUST include a selectedQuestion identifying one of those as a candidate unknown node. The engine validates your candidate and retains deterministic final-priority selection; your candidate does not need to be the highest-scoring unknown — it only needs to be a valid unresolved unknown that exists in the graph or in addedNodes."
+```
+
+**Additional Guidance bullet — replaced:**
+```
+Before: "Treat selectedQuestion as a candidate only; the engine will apply deterministic information-value scoring after validation."
+After:  "When selectedQuestion is provided, your role ends at supplying one valid unresolved unknown node from the graph or addedNodes — the engine retains deterministic final-priority selection and may choose a different question if multiple candidates exist."
+```
+
+### `tests/graph/prompt-builder.test.js`
+
+- Updated existing test to match new rule #16 wording (no longer checks for old "may identify" text).
+- Added 10 focused tests:
+  1. Mandatory candidate for added unknown
+  2. Permissive wording removed
+  3. Valid candidate, not final priority
+  4. Deterministic engine priority preserved
+  5. Null behaviour preserved outside trigger
+  6. No updatedNodes dependency claimed
+  7. No resolution dependency claimed
+  8. Existing candidate validity preserved
+  9. Uncertainty identity preserved
+  10. Structured fidelity preserved
+
+## Results
+
+- **prompt-builder.test.js:** 59 tests pass (42 existing + 17 new = 59 total). Zero failures.
+- No validator changes. No schema changes. No scoring changes.
+- Ollama calls: 0. Dev server disturbed: NO.
+
+## Ownership split preserved
+
+```
+MODEL: supply one valid candidate when new unresolved unknowns are added
+ENGINE: validate candidate, retain deterministic priority/scoring ownership
+```
+
+Configured Ollama: none used. Production code changed: prompt + tests only.
--- a/Show More
+++ b/Show More