docs(confidence-engine): close v0.49 current understanding boundary

Repair LOCATION-A defect where processing feedback rendered near the
completed narrative instead of inside the active follow-up block.

Changes:
  - components/reasoning-workspace.jsx: three targeted edits using a single
    spinner component with conditional rendering; hasActiveFollowUp routes
    ownership to the correct container
  - tests/open-questions-vs-assumptions.test.jsx: regression test confirming
    exactly one indicator, DOM child of follow-up-block, ownership separation

Accepted criteria met:
  ✅ Exactly one processing indicator during follow-up processing
  ✅ Indicator is a DOM child of follow-up-block
  ✅ Top-level indicator suppressed when follow-up active
  ✅ Initial answer flow preserved (top-level when no follow-up)
  ✅ Successful follow-up promotion intact
  ✅ All existing context retained
  ✅ No new state/lifecycle changes/error redesign

.claude/project-context.md

@@ -19,6 +19,18 @@ It:
 6. updates the graph from the answer;
 7. repeats until action is justified or the remaining uncertainty is clear.
 
+> **NOTE:** The flow above describes historical/current implementation mechanics.
+> It does not represent current Confidence Engine methodology direction.
+> See `docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md`
+> for the current working hypothesis (granular answer-fragment inquiry).
+
+The linear selector-led flow described above is a **historical capability**, not
+an automatic architecture to continue. Under Return-to-Origin:
+
+- The Engine facilitates inquiry; it does not compel a single-question route.
+- The user owns which unresolved investigation/question to pursue.
+- Accumulated reasoning memory does not necessarily belong inside repeated LLM calls.
+
 A chatbot remembers the conversation.
 
 The Confidence Engine preserves the state of the reasoning.
@@ -50,15 +62,23 @@ The engine should help a user reach one of these states:
 
 ## Current development stage
 
-The deterministic reasoning architecture reached a stable alpha checkpoint.
+> **Version lineage note:** The Confidence Engine uses two distinct version
+> lineages that must not be conflated:
+> - **Reasoning-engine experimental lineage** (v0.8+): reasoning-fidelity,
+>   investigation-state assessment, semantic selectors — under RTO pause.
+> - **UX/product development lineage** (v0.7): workspace layout, user views,
+>   loading feedback — also paused.
+> These are independent tracks; do not assume they describe one product version.
 
-Current work is primarily improving:
+The deterministic reasoning architecture reached a stable alpha checkpoint
+(reasoning-engine v0.8). UI/product work reached v0.7 staging. Both have
+paused under Return to Origin while the granular answer-fragment hypothesis
+is evaluated as working methodology context.
 
-- usability;
+Current work is paused. The next step begins from the methodology question:
-- presentation;
+given the useful investigation structure the Engine can already derive, how
-- loading feedback;
+should that structure be surfaced so a person can see, choose, defer, and
-- plain-language explanations;
+return to open questions while the Engine continues to guide their thinking?
-- separation of user and developer views.
 
 Do not resume broad reasoning architecture work unless a repeated observed
 failure clearly requires it.
@@ -93,7 +113,11 @@ The interface should minimise cognitive load by presenting the current state fir
 
 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)
+## Why workspace layout matters (v0.7 — UX/product lineage)
+
+> **This section documents paused UX design intent.** It belongs to the v0.7
+> product development lineage, not the reasoning-engine lineage. UI work is
+> currently paused under Return to Origin.
 
 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.
@@ -104,7 +128,10 @@ Read `docs/current-working-principles.md` for current guidance. Treat `docs/arch
 
 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`.
+Engine and UI experiments are paused under Return to Origin. First file to inspect when resuming:
+**`docs/current-handoff.md`** (methodology continuity anchor), then `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.
+>
+> **Historical experiment families are evidence to load only when a specific question requires them; they are not default architecture context.**

.claude/ux-guidelines.md

@@ -515,6 +515,21 @@ Three tiers, applied top to bottom:
 - Omit items too verbose to scan; do not synthesise rewritten claims.
 - Never invent facts absent from the graph.
 
+### Provenance and attribution
+
+Preserve authorship and provenance in every user-facing presentation.
+
+When displaying a user's previous input, keep it visibly distinct from system-generated interpretation. If the original user wording is available, present it as the user's response rather than rewriting it into system prose. Derived Findings, summaries, uncertainties, assumptions, or follow-up questions must not be styled or worded in a way that implies the user said them.
+
+The distinction should be:
+
+```text
+User response        → user-authored (verbatim)
+What we learned      → Engine-derived
+```
+
+Exact labels are subject to UX refinement; the durable rule is separating provenance, not prescribing specific copy.
+
 ## Investigation Narrative
 
 The reasoning graph is the machine representation of the investigation.

.gitignore

@@ -39,3 +39,10 @@ yarn-error.log*
 evaluation-results/
 provider-debug-results/
 tests-results/
+
+# Local Playwright MCP runtime output
+.playwright-mcp/
+
+
+# Evidence/temp directories from live experiments
+.evidence-temp/

app/api/focused-investigation/deconstruct/route.js

@@ -0,0 +1,89 @@
+import { getProvider } from "@/lib/llm/provider";
+import { buildFocusedDeconstructPrompt, validateFocusedDeconstructSchema } from "@/lib/graph/focused-investigation";
+
+export async function POST(request) {
+  try {
+    const body = await request.json();
+
+    if (!body.targetNodeId || typeof body.targetNodeId !== "string") {
+      return Response.json(
+        { error: "Request must include a 'targetNodeId' string field" },
+        { status: 400 },
+      );
+    }
+    if (!body.targetLabel || typeof body.targetLabel !== "string") {
+      return Response.json(
+        { error: "Request must include a 'targetLabel' string field" },
+        { status: 400 },
+      );
+    }
+    if (!body.targetDescription || typeof body.targetDescription !== "string") {
+      return Response.json(
+        { error: "Request must include a 'targetDescription' string field" },
+        { status: 400 },
+      );
+    }
+    if (!body.centralStatement || typeof body.centralStatement !== "string") {
+      return Response.json(
+        { error: "Request must include a 'centralStatement' string field" },
+        { status: 400 },
+      );
+    }
+    if (!body.question || typeof body.question !== "string") {
+      return Response.json(
+        { error: "Request must include a 'question' string field" },
+        { status: 400 },
+      );
+    }
+    if (!body.answer || typeof body.answer !== "string") {
+      return Response.json(
+        { error: "Request must include an 'answer' string field" },
+        { status: 400 },
+      );
+    }
+
+    const prompt = buildFocusedDeconstructPrompt({
+      targetLabel: body.targetLabel,
+      targetDescription: body.targetDescription,
+      centralStatement: body.centralStatement,
+      question: body.question,
+      answer: body.answer,
+    });
+
+    const provider = getProvider();
+    const startedAt = Date.now();
+    const raw = await provider.generateReconstruction(prompt, process.env.OLLAMA_MODEL);
+    const elapsedMs = Date.now() - startedAt;
+
+    // Validate schema (required fields present, no graph-mutation fields)
+    const validationErrors = validateFocusedDeconstructSchema(raw);
+    if (validationErrors.length > 0) {
+      return Response.json(
+        {
+          success: false,
+          error: "Focused deconstruction result did not match expected schema",
+          validationErrors,
+          targetNodeId: body.targetNodeId,
+          elapsedMs,
+        },
+        { status: 502 },
+      );
+    }
+
+    return Response.json({
+      success: true,
+      targetNodeId: body.targetNodeId,
+      observations: raw.observations,
+      uncertainties: raw.uncertainties,
+      assumptions: raw.assumptions,
+      relationships: raw.relationships,
+      possibleFollowUpQuestions: raw.possibleFollowUpQuestions,
+      elapsedMs,
+    });
+  } catch (e) {
+    return Response.json(
+      { error: e.message || "Unknown server error" },
+      { status: 500 },
+    );
+  }
+}

app/api/focused-investigation/formulate/route.js

@@ -0,0 +1,52 @@
+import { formulateQuestionForTarget } from "@/lib/graph/focused-investigation";
+
+export async function POST(request) {
+  try {
+    const body = await request.json();
+
+    if (!body.targetNodeId || typeof body.targetNodeId !== "string") {
+      return Response.json(
+        { error: "Request must include a 'targetNodeId' string field" },
+        { status: 400 },
+      );
+    }
+
+    if (!body.situationGraph || typeof body.situationGraph !== "object") {
+      return Response.json(
+        { error: "Request must include a 'situationGraph' object field" },
+        { status: 400 },
+      );
+    }
+
+    const result = formulateQuestionForTarget({
+      situationGraph: body.situationGraph,
+      targetNodeId: body.targetNodeId,
+    });
+
+    if (!result.success) {
+      return Response.json(
+        { success: false, error: result.error },
+        { status: 400 },
+      );
+    }
+
+    return Response.json({
+      success: true,
+      targetNodeId: result.targetNodeId,
+      question: result.question,
+      strategy: result.strategy,
+      reasoningPattern: result.reasoningPattern,
+      reasoningPatternReason: result.reasoningPatternReason,
+      reason: result.reason,
+      questionFamily: result.questionFamily,
+      selectedQuestionTemplate: result.selectedQuestionTemplate,
+      allowedQuestionFamilies: result.allowedQuestionFamilies,
+      rejectedQuestionFamilies: result.rejectedQuestionFamilies,
+    });
+  } catch (e) {
+    return Response.json(
+      { error: e.message || "Unknown server error" },
+      { status: 500 },
+    );
+  }
+}

components/experimental/branch-switcher.jsx

@@ -0,0 +1,143 @@
+/**
+ * Experimental branch switcher — RTO.25A
+ *
+ * Smallest branch representation needed to test passive late-result indication.
+ * Does NOT replace production branch navigation. Temporary fixture only.
+ */
+
+"use client";
+
+import React, { useState, useEffect } from "react";
+
+/* ── Keyframes (injected once via <style> at render) ───── */
+
+const PulseStyle = () => (
+  <style>{`
+    @keyframes rto-pulse {
+      0%, 100% { opacity: 0.6; }
+      50% { opacity: 1; }
+    }
+  `}</style>
+);
+
+/* ── Status dot (passive new-result indicator) ─────────── */
+
+function NewIndicator({ visible }) {
+  if (!visible) return null;
+
+  return (
+    <span
+      className="ml-2 inline-flex items-center"
+      title="Something new is available here"
+      aria-label="New result available"
+    >
+      <span
+        className="relative inline-block h-[8px] w-[8px]"
+        style={{ animation: "rto-pulse 3s ease-in-out infinite" }}
+      >
+        <span
+          className="absolute inset-0 rounded-full bg-blue-400/70"
+          aria-hidden="true"
+        />
+      </span>
+    </span>
+  );
+}
+
+/* ── Single branch row ─────────────────────────────────── */
+
+function BranchRow({ id, label, active, isNew, isPaused, origin, onClick }) {
+  const isActive = Boolean(active);
+
+  return (
+    <button
+      onClick={onClick}
+      disabled={isActive}
+      aria-current={isActive ? "page" : undefined}
+      className={`w-full flex items-start gap-2 rounded-md px-3 py-2 text-left transition text-sm ${
+        isActive
+          ? "bg-blue-50/80 border border-blue-200/60 text-blue-900 font-medium"
+          : "text-gray-600 hover:bg-gray-100/70 hover:text-gray-800 border border-transparent"
+      } ${!isActive ? "cursor-pointer" : "cursor-default"}`}
+    >
+      {/* Active indicator — ● vs ○ */}
+      <span
+        className={`flex-none leading-none text-base ${
+          isActive ? "text-blue-500" : "text-gray-400"
+        }`}
+        aria-hidden="true"
+      >
+        {isActive ? "●" : "○"}
+      </span>
+
+      {/* Branch label + origin */}
+      <span className="flex-1 min-w-0">
+        <span className="truncate block">{label}</span>
+        {origin && (
+          <span className="block text-[11px] leading-tight text-gray-500/80 truncate" title={origin}>
+            {origin}
+          </span>
+        )}
+      </span>
+
+      {/* Passive indicators: pause + new */}
+      <span className="flex items-center gap-1.5 flex-none">
+        {!isActive && isPaused && (
+          <span
+            className="text-[10px] text-gray-400"
+            title="Done for now"
+          >
+            Paused
+          </span>
+        )}
+        {!isActive && <NewIndicator visible={isNew} />}
+      </span>
+    </button>
+  );
+}
+
+/* ── Card wrapper ────────────────────────────────────────── */
+
+export default function ExperimentalBranchSwitcher({
+  branches = [],
+  activeBranchId,
+  branchNewResults = {},
+  branchPauseState = [],
+  onBranchSelect,
+}) {
+  if (!branches.length) return null;
+
+  return (
+    <div
+      className="rounded-lg border border-gray-200/60 bg-gray-50/30 p-4"
+      role="radiogroup"
+      aria-label="Experimental branch switcher — RTO.25A"
+    >
+      {/* Label — clearly experimental */}
+      <h2 className="mb-1 text-[10px] font-semibold tracking-widest uppercase text-gray-600">
+        Branches{" "}
+        <span className="font-normal text-gray-500">(exp)</span>
+      </h2>
+      <p className="mb-3 text-[11px] font-medium leading-tight text-gray-500/80">
+        Browse branches. Current focus is preserved.
+      </p>
+
+      <div className="space-y-1" role="list" aria-label="Available branches">
+        {branches.map((branch) => (
+          <BranchRow
+            key={branch.id}
+            id={branch.id}
+            label={branch.label}
+            active={activeBranchId === branch.id}
+            isNew={Boolean(branchNewResults[branch.id])}
+            isPaused={branchPauseState.includes(branch.id)}
+            origin={branch.origin}
+            onClick={() => onBranchSelect?.(branch.id)}
+          />
+        ))}
+      </div>
+    </div>
+  );
+}
+
+export { PulseStyle };

components/investigation-map.jsx

@@ -84,10 +84,10 @@ export default function InvestigationMap({ turnCount = 0 }) {
 
   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">
+      <h2 className="mb-1 text-[11px] font-semibold tracking-widest uppercase text-gray-500">
         Investigation Map
       </h2>
-      <p className="mb-3 text-xs text-gray-400/70">
+      <p className="mb-3 text-xs font-medium leading-tight text-gray-500/80">
         Active investigation topics and their status.
       </p>
 

components/investigation-summary-panel-v2.jsx

@@ -196,7 +196,7 @@ function InvestigationSummaryPanelV2({ graph, selectedQuestion, result, updateSt
         <div>
           {stillInvestigating.length > 1 ? (
             <>
-              <h3 className="mb-2 text-xs font-medium text-gray-400">Still investigating</h3>
+              <h3 className="mb-2 text-xs font-medium text-gray-500">Still investigating</h3>
               <ul className="space-y-1.5">
                 {Object.entries(investigatingByGroup).map(([group, items]) => (
                   <li key={group}>
@@ -227,7 +227,7 @@ function InvestigationSummaryPanelV2({ graph, selectedQuestion, result, updateSt
       {/* ── What we have learned ────────────────────────── */}
       {known.length > 0 && (
         <div>
-          <h3 className="mb-2 text-xs font-medium text-gray-400">What we know</h3>
+          <h3 className="mb-2 text-xs font-medium text-gray-500">What we know</h3>
           <ul className="space-y-1.5">
             {known.map((item, i) => (
               <li key={i} className="flex items-start gap-2">
@@ -243,8 +243,8 @@ function InvestigationSummaryPanelV2({ graph, selectedQuestion, result, updateSt
 
       {/* ── 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>
+        <p className="text-[10px] font-semibold tracking-widest uppercase text-gray-500 mb-1.5">Reasoning</p>
-        <div className="flex flex-wrap gap-x-4 gap-y-1 text-xs text-gray-400">
+        <div className="flex flex-wrap gap-x-4 gap-y-1 text-xs text-gray-500">
           {reasonEntries.map(([label, count]) => (
             <span key={label}>
               {count} {label}

components/investigation-summary-panel-v3.jsx

@@ -47,7 +47,7 @@ function KnownSection({ title, items }) {
 
   return (
     <div>
-      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-400">
+      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-500">
         {title}
       </h3>
       <ul className="space-y-1.5">
@@ -67,7 +67,7 @@ function InvestigatingSection({ title, items }) {
 
   return (
     <div>
-      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-400">
+      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-500">
         {title}
       </h3>
       <ul className="space-y-1.5">
@@ -87,7 +87,7 @@ function ExplanationSection({ items }) {
 
   return (
     <div>
-      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-400">
+      <h3 className="mb-2 text-[11px] font-medium tracking-widest uppercase text-gray-500">
         Possible explanations
       </h3>
       <ul className="space-y-1.5">
@@ -102,10 +102,10 @@ function QuietSummary({ text }) {
 
   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">
+      <p className="text-[10px] font-semibold tracking-widest uppercase text-gray-500 mb-1.5">
         Investigation state
       </p>
-      <p className="text-xs text-gray-400">{text}</p>
+      <p className="text-xs text-gray-500">{text}</p>
     </div>
   );
 }

components/investigation-summary-panel.jsx

@@ -127,7 +127,7 @@ function InvestigationSummaryPanel({ graph, selectedQuestion, result, updateStat
       {/* Current understanding */}
       {currentUnderstanding && (
         <div>
-          <h3 className="mb-1 text-[11px] font-medium tracking-widest uppercase text-gray-400/70">
+          <h3 className="mb-1 text-[11px] font-semibold tracking-widest uppercase text-gray-500">
             What we understand so far
           </h3>
           <p className="text-sm leading-relaxed text-gray-600">{currentUnderstanding}</p>

components/scenario-form.jsx

@@ -5,6 +5,8 @@ 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";
+import { deriveFindingsFromContributions, normalizeFindings, produceFindingInformedSummary } from "@/lib/graph/finding-helpers";
+import { loadInvestigation, saveInvestigation, clearInvestigation } from "@/lib/storage/investigation-storage";
 
 /* 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";
@@ -33,7 +35,7 @@ export async function submitScenarioForStartCase(fetchImpl, scenario) {
 
 export async function submitAnswerForUpdateCase(
   fetchImpl,
-  { situationGraph, previousQuestion, answer },
+  { situationGraph, previousQuestion, answer, findings },
 ) {
   if (!answer?.trim()) {
     return {
@@ -47,10 +49,15 @@ export async function submitAnswerForUpdateCase(
     };
   }
 
+  const body = { situationGraph, previousQuestion, answer };
+  if (findings && findings.length > 0) {
+    body.findings = findings;
+  }
+
   const response = await fetchImpl("/api/cases/update", {
     method: "POST",
     headers: { "Content-Type": "application/json" },
-    body: JSON.stringify({ situationGraph, previousQuestion, answer }),
+    body: JSON.stringify(body),
   });
 
   return {
@@ -186,25 +193,37 @@ export function UpdateErrorPanel({ updateError }) {
 
 export { INITIAL_MESSAGES, UPDATE_MESSAGES, useLoadingStatus };
 
-// ── Session key ────────────────────────────────────────────────
-const SESSION_KEY = "confidence-engine-session";
 
-function getSession() {
+/**
-  if (typeof sessionStorage === "undefined") return null;
+ * Derives whether the current component state represents a valid investigation
-  try {
+ * context sufficient to render a workspace surface.
-    const raw = sessionStorage.getItem(SESSION_KEY);
+ *
-    return raw ? JSON.parse(raw) : null;
+ * Valid only when:
-  } catch (_) { return null; }
+ *   - result carries a situationGraph (renderable graph), OR
+ *   - status is "success" AND there is a non-empty scenario
+ *     (from session restoration with real data).
+ *
+ * This predicate is the single source of truth for all render-gate decisions.
+ * showExperimentView, fixture availability, or sessionStorage keys alone are
+ * NOT sufficient to constitute valid context.
+ */
+export function hasValidInvestigationContext(result, status, scenario) {
+  return Boolean(result?.situationGraph) ||
+         (status === "success" && Boolean(scenario?.trim()));
 }
 
-function saveSession(state) {
+/**
-  if (typeof sessionStorage === "undefined") return;
+ * Derives the primary surface that must render for the given state tuple.
-  try { sessionStorage.setItem(SESSION_KEY, JSON.stringify(state)); } catch (_) {}
+ * Enforces exactly-one-primary-surface invariant: no zero, no two.
-}
+ */
+export function derivePrimarySurface(result, status, _showExperimentView, scenario, activeBranchId) {
+  if (status === "loading") return "LOADING";
+  if (status === "error") return "ERROR_SURFACE";
 
-function clearSession() {
+  const valid = hasValidInvestigationContext(result, status, scenario);
-  if (typeof sessionStorage === "undefined") return;
+
-  try { sessionStorage.removeItem(SESSION_KEY); } catch (_) {}
+  if (valid) return "NORMAL_WORKSPACE";
+  return "SCENARIO_ENTRY";
 }
 
 export default function ScenarioForm() {
@@ -219,19 +238,145 @@ export default function ScenarioForm() {
   const [currentUnderstanding, setCurrentUnderstanding] = useState(null);
   const [mockScenario, setMockScenario] = useState("");
   const [hideFacilitatorOnLanding, setHideFacilitatorOnLanding] = useState(false);
+
+  /* ── RTO.31: focused contributions ownership ─────────────── */
+  const [focusedContributions, setFocusedContributions] = useState([]);
+
+  /* ── v2 findings from focused contributions ─────────────── */
+  const [findings, setFindings] = useState([]);
+
+  function appendFinding(finding) {
+    setFindings((prev) => {
+      return [...prev, finding];
+    });
+  }
+
+  function updateFindingDisposition(findingId, newDisposition) {
+    setFindings((prev) =>
+      prev.map((f) => (f.id === findingId ? { ...f, userDisposition: newDisposition } : f)),
+    );
+  }
+
+  function updateFindingProposition(findingId, newProposition) {
+    setFindings((prev) =>
+      prev.map((f) =>
+        f.id === findingId
+          ? { ...f, proposition: newProposition, userDisposition: null }
+          : f,
+      ),
+    );
+  }
+
+  /**
+   * v0.49 promotion seam — deterministic Current Understanding update
+   * triggered by "Done for now" activity boundary (no case/update, no LLM).
+   */
+  function handleDoneForNowPromotion(targetNodeId) {
+    if (!targetNodeId || !findings?.length) return;
+
+    // Filter eligible findings for this specific target only.
+    const eligible = findings.filter(
+      (f) => f.originatingTargetNodeId === targetNodeId && (f.userDisposition === null || f.userDisposition === "agree"),
+    );
+
+    if (eligible.length === 0) return;
+
+    // Determine the base: use currentUnderstanding if available, else empty string.
+    const baseSummary = currentUnderstanding ?? "";
+
+    // Deterministic producer — no LLM, no API.
+    const newSummary = produceFindingInformedSummary(baseSummary, eligible);
+
+    // Idempotence guard: skip if summary is unchanged (no new eligible findings
+    // beyond what's already in the current Evidence block).
+    if (newSummary === baseSummary) return;
+
+    // Avoid duplicate evidence propositions from repeated promotion.
+    const existingEvidenceMatch = baseSummary.match(/Evidence:\s*\[([^\]]+)\]/);
+    let isDuplicate = false;
+    if (existingEvidenceMatch) {
+      const existingTexts = existingEvidenceMatch[1].split("; ").map((t) => t.trim());
+      isDuplicate = eligible.every((f) => existingTexts.includes(f.proposition));
+    }
+    if (isDuplicate) return;
+
+    // Mutate the SAME summary/state that autosave already persists.
+    setCurrentUnderstanding(newSummary);
+  }
+
+  function appendFocusedContribution(contribution) {
+    // Derive a single stored contribution object and use it for BOTH
+    // contribution storage AND Finding derivation so the same identity
+    // appears in focusedContributions[] and Finding.contributionId.
+    setFocusedContributions((prev) => {
+      const seq = prev.length + 1;
+      const storedContribution = { ...contribution, sequence: seq, id: `contrib-${String(seq).padStart(4, "0")}` };
+
+      // Derive Findings from the exact stored Contribution (not a separate approximation)
+      setFindings((prevFindings) => {
+        const newFindings = deriveFindingsFromContributions([storedContribution]).findings;
+        return normalizeFindings([...prevFindings, ...newFindings]);
+      });
+
+      return [...prev, storedContribution];
+    });
+  }
   const textareaRef = useRef(null);
 
-  /* Restore persisted session on mount (Phase 3) ─────────── */
+  /* ── Valid investigation predicate ─────────────────────── */
+
+  // Delegated to the exported utility below.
+  const validCtx = hasValidInvestigationContext(result, status, scenario);
+
+  /* Restore persisted session on mount ─────────── */
   useEffect(() => {
     if (typeof window === "undefined") return;
-    const saved = getSession();
+    const saved = loadInvestigation();
     if (!saved) return;
+
+    const hasGraph = Boolean(saved.situationGraph);
+
     setScenario(saved.scenario || "");
-    setResult(saved.situationGraph ? { ...saved, situationGraph: saved.situationGraph } : null);
+    setResult(hasGraph ? { ...saved, situationGraph: saved.situationGraph } : null);
     setCurrentUnderstanding(saved.summary || null);
-    setStatus("success");
+    setFocusedContributions(saved.focusedContributions || []);
+    setFindings(saved.findings || []);
+
+    // Partial sessions (present but no graph) must NOT suppress the
+    // scenario-entry form.  Only promote to success when there is actual
+    // investigation data to render.
+    if (hasGraph) {
+      setStatus("success");
+    }
   }, []);
 
+  /* ── Canonical autosave — persist whenever state changes (Phase 2) ── */
+
+  useEffect(() => {
+    if (typeof window === "undefined") return;
+    // Guard: no valid investigation yet → skip autosave during idle/start flows.
+    // Also prevents overwriting an existing saved investigation with the initial
+    // empty state of a fresh ScenarioForm instance (hydration race guard).
+    if (!result?.situationGraph) return;
+
+    void saveInvestigation({
+      scenario,
+      situationGraph: result.situationGraph,
+      selectedQuestion: result.selectedQuestion,
+      summary: currentUnderstanding,
+      updatedAt: new Date().toISOString(),
+      focusedContributions,
+      findings,
+    });
+  }, [
+    scenario,
+    result?.situationGraph,
+    result?.selectedQuestion,
+    currentUnderstanding,
+    focusedContributions,
+    findings,
+  ]);
+
   /* Restore facilitator dismiss preference (Experiment 05) ─── */
   useEffect(() => {
     if (typeof window === "undefined") return;
@@ -307,7 +452,7 @@ export default function ScenarioForm() {
         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() });
+        saveInvestigation({ scenario, situationGraph: normalised.situationGraph, selectedQuestion: normalised.selectedQuestion, summary: data.summary ?? null, updatedAt: new Date().toISOString(), focusedContributions, findings: [] });
       } else {
         setStatus("error");
         setCurrentUnderstanding(data.summary ?? null);
@@ -340,6 +485,7 @@ export default function ScenarioForm() {
       situationGraph: result?.situationGraph,
       previousQuestion: result?.selectedQuestion,
       answer,
+      findings,
     });
 
     if (submission.skipped) {
@@ -352,6 +498,12 @@ export default function ScenarioForm() {
       const outcome = submission.data;
 
       if (submission.ok && outcome.success) {
+        // Merge server-returned findings with local state
+        let newFindings = [...findings];
+        if (outcome.appendedFindings && Array.isArray(outcome.appendedFindings)) {
+          newFindings = [...newFindings, ...outcome.appendedFindings];
+        }
+
         setUpdateStatus("success");
         setCurrentUnderstanding(
           outcome.summary ? outcome.summary : currentUnderstanding,
@@ -372,8 +524,8 @@ export default function ScenarioForm() {
           diagnostics: outcome.diagnostics,
         }));
         setAnswer("");
-        // Persist after successful update turn
+        // Persist after successful update turn — include findings
-        saveSession({ scenario, situationGraph: outcome.updatedSituationGraph, selectedQuestion: normaliseUpdateSelectedQuestion(outcome.selectedQuestion), summary: outcome.summary ?? currentUnderstanding, updatedAt: new Date().toISOString() });
+        saveInvestigation({ scenario, situationGraph: outcome.updatedSituationGraph, selectedQuestion: normaliseUpdateSelectedQuestion(outcome.selectedQuestion), summary: outcome.summary ?? currentUnderstanding, updatedAt: new Date().toISOString(), focusedContributions, findings: newFindings });
       } else {
         setUpdateStatus("error");
         setUpdateError(outcome);
@@ -386,7 +538,8 @@ export default function ScenarioForm() {
 
   return (
     <div className="space-y-6">
-      {status === "idle" && (
+      {/* ── Idle form for scenario input ─ */}
+      {!result?.situationGraph && status === "idle" && (
         <form onSubmit={handleSubmit} className="space-y-6">
 
           {/* Two-column landing workspace */}
@@ -419,7 +572,7 @@ export default function ScenarioForm() {
                       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
+                      {`Dismiss this introduction permanently`}
                     </label>
                   </div>
                 </div>
@@ -428,7 +581,7 @@ export default function ScenarioForm() {
 
             {/* 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>
+              <h2 className="mb-4 text-xs font-bold tracking-widest uppercase text-gray-400">What&#39;s the situation</h2>
               <textarea
                 ref={textareaRef}
                 value={scenario}
@@ -505,42 +658,58 @@ export default function ScenarioForm() {
         />
       )}
 
-      {/* ── Main result workspace ─────────────────────── */}
+      {/* ── Main result workspace ─── */}
-      {((status === "success" || status === "error") && status !== "loading") && (
+      {(status === "success" || status === "error") && (
-        <ReasoningWorkspace
+        <>
-          scenario={scenario}
+          <div className="grid grid-cols-1 gap-6 lg:grid-cols-3">
-          status={status}
+            {/* Workspace — uses result from Analyse or Update only */}
-          updateStatus={updateStatus}
+            <div className="lg:col-span-2">
-          currentUnderstanding={currentUnderstanding}
+              <ReasoningWorkspace
-          result={{
+                scenario={scenario}
-            ...(result || {}),
+                status={status}
-            situationGraph: updateResult?.updatedSituationGraph ?? result?.situationGraph,
+                updateStatus={updateStatus}
-            selectedQuestion: updateResult?.selectedQuestion ?? result?.selectedQuestion,
+                currentUnderstanding={currentUnderstanding}
-            newlySurfacedNodeIds: result?.newlySurfacedNodeIds || [],
+                result={{
-            diagnostics: result?.diagnostics || null,
+                  ...(result || {}),
-            updateError,
+                  situationGraph: updateResult?.updatedSituationGraph ?? result?.situationGraph,
-          }}
+                  selectedQuestion: updateResult?.selectedQuestion ?? result?.selectedQuestion,
-          answer={answer}
+                  newlySurfacedNodeIds: result?.newlySurfacedNodeIds || [],
-          setAnswer={setAnswer}
+                  diagnostics: result?.diagnostics || null,
-          onAnswerSubmit={handleUpdate}
+                  updateError,
-          lastSubmittedAnswer={lastSubmittedAnswer}
+                }}
-          onRestart={() => {
+                answer={answer}
-            clearSession();
+                setAnswer={setAnswer}
-            setStatus("idle");
+                onAnswerSubmit={handleUpdate}
-            setResult(null);
+                lastSubmittedAnswer={lastSubmittedAnswer}
-            setAnswer("");
+                focusedContributions={focusedContributions}
-            setUpdateStatus("idle");
+                onFocusedContribution={appendFocusedContribution}
-            setUpdateResult(null);
+                findings={findings}
-            setLastSubmittedAnswer("");
+                onUpdateFindingDisposition={updateFindingDisposition}
-            setCurrentUnderstanding(null);
+                onUpdateFindingProposition={updateFindingProposition}
-            setUpdateError(null);
+                /* ── v0.49 — done-for-now promotion seam ─────────── */
-          }}
+                onSummaryUpdate={handleDoneForNowPromotion}
-        />
+                onRestart={() => {
+                  clearInvestigation();
+                  setStatus("idle");
+                  setResult(null);
+                  setAnswer("");
+                  setUpdateStatus("idle");
+                  setUpdateResult(null);
+                  setLastSubmittedAnswer("");
+                  setCurrentUnderstanding(null);
+                  setUpdateError(null);
+                  setFocusedContributions([]);
+                  setFindings([]);
+                }}
+              />
+            </div>
+          </div>
+        </>
       )}
 
       {/* ── Continue later banner when session was restored ── */}
       {status === "success" && result?.updatedAt && (
-        <ContinueLaterBanner onRestart={() => { clearSession(); setStatus("idle"); setResult(null); setAnswer(""); setUpdateStatus("idle"); setCurrentUnderstanding(null); }} />
+        <ContinueLaterBanner onRestart={() => { clearInvestigation(); setStatus("idle"); setResult(null); setAnswer(""); setUpdateStatus("idle"); setCurrentUnderstanding(null); setFocusedContributions([]); setFindings([]); }} />
       )}
 
       {/* Reset button after successful analysis */}
@@ -548,7 +717,7 @@ export default function ScenarioForm() {
         <div className="text-center">
           <button
             onClick={() => {
-              clearSession();
+              clearInvestigation();
               setScenario("");
               setStatus("idle");
               setResult(null);
@@ -558,6 +727,8 @@ export default function ScenarioForm() {
               setLastSubmittedAnswer("");
               setCurrentUnderstanding(null);
               setUpdateError(null);
+              setFocusedContributions([]);
+              setFindings([]);
             }}
             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"
           >

docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md

@@ -0,0 +1,388 @@
+# 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.
+
+## Granular Answer-Fragment Learning (RTO.14–17)
+
+Recent experiments explored what happens when further answers are made inside the same focused investigation (RTO.14–17).
+
+### What RTO.14–17 proved
+
+The experiments demonstrated that an LLM can:
+
+- Retain prior focused knowledge across turns
+- Revise uncertainty in response to new information
+- Separate focused understanding from decision significance
+- Carry coherent reasoning across several turns inside a single investigation
+
+This learning was valuable and should be preserved as experimental evidence. The apparatus created during RTO.14–17 remains available and relevant.
+
+### What RTO.14–17 began recreating
+
+Pushing that design further exposed that we had reproduced the original structural assumption at a lower level:
+
+- **Original global pattern:**
+  ```text
+  whole case state + new answer → LLM rewrites whole case state
+  ```
+- **Focused version (RTO.14–17):**
+  ```text
+  whole focused-investigation state + new answer → LLM rewrites whole focused-investigation state
+  ```
+
+The second version is much smaller and technically better, but it is still the same cumulative reconstruction pattern — just at a lower scope. Prompt growth from later RTO experiments helped expose this.
+
+**Learning:** Do not immediately respond by optimising or compressing the cumulative focused-state implementation. Reconsider whether accumulated state needs to be sent back through the LLM at all.
+
+### The granular answer-fragment hypothesis (working hypothesis — not yet architecture)
+
+The natural reasoning unit appears to be:
+
+> **one question → one answer → one interpretation/capture**
+
+Granularity's purpose is not merely token or latency optimisation. The small cycle is how the methodology makes a large problem manageable for the user. A difficult scenario is progressively decomposed into pieces small enough to reason about confidently.
+
+The working hypothesis is:
+
+```text
+user chooses a question
+→ user provides an answer
+→ Engine deconstructs that answer
+→ Engine captures the granular contribution
+→ resulting uncertainties/questions are exposed
+→ user chooses what to investigate next
+→ repeat
+```
+
+Each accepted answer can produce a small evidence-bearing reasoning fragment. Those fragments are remembered outside the LLM call. The larger investigation understanding and eventual graph emerge from composing those pieces over time. Only directly relevant prior knowledge may need to be supplied when a specific earlier fragment is being qualified, contradicted or refined.
+
+A software implementation may eventually represent granular contributions as things such as:
+
+- observations
+- uncertainties
+- assumptions
+- relationships
+- questions raised
+
+linked to the question/investigation that produced them. This illustrative list is not a production schema — it exists here only as a design hint.
+
+### Memory / graph principle
+
+The LLM does not necessarily need to own accumulated reasoning memory. The graph/state/notebook layer can remember the reasoning fragments. The LLM may be used to interpret a new answer, but a software implementation should not assume every new answer requires sending all accumulated investigation state back through the model and asking it to regenerate the whole current understanding.
+
+### Optional capability: "Help me answer" / "Answer for me"
+
+A software implementation may optionally offer something like:
+
+> **Help me answer** or **Answer for me**
+
+where the LLM proposes an answer. This is an optional application capability — not part of the core method. The methodology works without it.
+
+**Ownership rule:** A generated answer is a proposal, not gospel and not automatically evidence. The user must be able to accept it, edit it or reject it. Only an accepted contribution enters the normal reasoning/deconstruction flow. Where practical, provenance should remain distinguishable between:
+
+- user-supplied answer
+- LLM-proposed answer accepted/edited by user
+
+### Development principle reaffirmed: BUILD → BREAK → LEARN → STOP
+
+When an experiment exposes that an architectural assumption is breaking:
+
+```text
+do not immediately optimise the broken assumption
+do not add complexity to preserve it
+capture what was learned
+return to the methodology
+design the next smallest experiment from that learning
+```
+
+RTO.14–17 should therefore remain valuable evidence, not be deleted or described as mistakes. They helped reveal the next underlying assumption.
+
+## Methodology test for future development
+
+> **Could this reasoning operation be described in the Confidence Engine methodology and performed by a trained human facilitator without an LLM?**
+
+- If YES: the application may use an LLM to automate, accelerate or scale it
+- If NO: stop and ask whether the work is developing the Confidence Engine methodology or merely exploiting an LLM capability
+
+This does not apply to implementation mechanics such as JSON, APIs or databases. It applies to the underlying reasoning behaviour.
+
+## Recent experimental evidence supporting methodological principles (2026-08-18/19)
+
+The following experiments provide specific evidence for the durable methodology principles
+documented in `docs/current-working-principles.md`. Each is recorded as one data point, not generalisation.
+
+### RTO.18 — Independent granular question/answer deconstruction (without accumulated state)
+
+Independent per-turn question and answer deconstruction worked when each turn received only its own
+question + answer, without any accumulated focused state from previous turns. This supports:
+
+- **A3** (reasoning on meaning, not accumulated vocabulary)
+- **A6** (non-linear investigation via independent fragments)
+- **The granular answer-fragment hypothesis** as a working direction
+
+### RTO.20 — Narrow derived current view from selected fragments + known relationship
+
+A narrow, derived current understanding state worked when computed from selected fragments combined with known structural relationships rather than full-graph reconstruction. This supports:
+
+- **A5** (deterministic structure for identity/storage; semantic interpretation only where needed)
+- **A10** (progressive disclosure of relevant reasoning to the user)
+
+### RTO.21 — Semantic relationship discovery: one genuine positive case
+
+Semantic interpretation found one genuine cross-fragment relationship from two fragments alone. The operation correctly identified that two contributions meaningfully related without prior keyword dictionary matching. This supports:
+
+- **A4** (semantic interpretation as a suitable facilitation capability)
+- **A3** (meaning-based over vocabulary-based reasoning)
+
+### RTO.22 — Semantic relationship discovery: one obvious negative case (control)
+
+The same semantic operation correctly returned no relationship for one obviously unrelated pair of contributions. This supports:
+
+- **A4** (semantic interpretation is useful but produces proposals, not decisions)
+- **A3** (meaning-based reasoning does not produce false positives at high rates on obvious cases)
+
+### RTO.23 — Current apparatus work
+
+RTO.23 apparatus development is ongoing. No live experimental evidence exists for RTO.23 yet.
+
+---
+
+## Methodology principles reinforced by this evidence
+
+The experiments above support (without proving) the following durable methodology boundaries:
+
+- **Delivery-platform independence** (A1): all results were observed through a software delivery path, but the reasoning operations described (question deconstruction, relationship inference, fragment composition) are equally performable by a human facilitator.
+- **Meaning over dictionary** (A3/A4): RTO.21 and RTO.22 together suggest semantic interpretation can produce both true-positive and true-negative relationship proposals without keyword scoring — but two data points do not establish reliability. The guardrail remains: treat all inferred relationships as proposals until handled per the delivery method.
+- **Non-linear investigation** (A6/A7): independent fragment processing validates that reasoning can proceed asynchronously across branches without blocking the user.
+- **Progressive disclosure** (A10): RTO.20 demonstrates that a derived narrow view from relevant fragments is more useful to the user than a full-graph reconstruction of everything known.
+
+## 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`
+
+> **Provenance note:** Some source-basis documents listed above were external
+> project/session context supplied during the methodology work and are not
+> repository-managed files. They informed this document's content but cannot be
+> verified as originating from the Git history of this repository. Their role
+> is to document where the methodology context came from, not to assert Git
+> provenance for those external documents.
+
+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. The granular answer-fragment hypothesis (RTO.14–17) is recorded as working hypothesis, not yet accepted architecture.

docs/archive/README.md

@@ -15,6 +15,30 @@ All files below were moved from `docs/` on 2026-08-06 by Experiment 29 to reduce
 | `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. |
 
+## Phase 2B Experiment Archives (2026-08-19)
+
+All files below were classified `HISTORICAL_EVIDENCE + SAFE` during the Phase 1B/2B context audit and moved to reduce default reading burden while preserving full traceability. They are preserved evidence — not discarded, obsolete, or invalidated. Load only when a specific historical question requires them.
+
+| Subdirectory | What Was Moved | Count |
+|---|---|---|
+| `docs/archive/experiments/reasoning-fidelity-v0.8/` | Experiment 56 family (reasoning-fidelity v0.8 pass) | 11 files (experiment-56a–m, excluding c) |
+| `docs/archive/experiments/semantic-action-contract/` | Experiment 58 family (semantic action contract) | 8 files (experiment-58a1–a6, b1–b2) |
+| `docs/archive/experiments/question-formulation/` | Experiment 59 family (question formulation) | 7 files (experiment-59a1–a3, b1–b4) |
+| `docs/archive/experiments/decision-options/` | Experiment 60A family (decision options analysis) | 7 files (experiment-60a1–8, excluding a3) |
+| `docs/archive/experiments/decision-closure-integration/` | Experiment 60B subfamilies {10–15}, {55–82}, {95,97,100} | 35 files (experiment-60b{10-15}, {55-56,58-82}, {95,97,100}) |
+| `docs/archive/experiments/knowledge-mgmt/` | Cold-start validation historical evidence | 1 file (cold-start-validation.md) |
+| `docs/archive/experiments/context-routing/` | Document-role review (classification/routing analysis) | 1 file (document-role-review.md) |
+| `docs/archive/experiments/pre-RTO/` | Pre-Return-to-Origin experiments and version-specific docs: v0.5–v0.7 | 7 files (pre-RTO experiments + release notes/UX pass) |
+
+**Not moved in Phase 2B:** checkpoint-60b93.md, docs/design-evolution-log.md, docs/investigation-state-assessment*.md, architectural-principles.md, v0.6-reasoning-architecture.md, success-signals.md, failure-modes.md, investigation-narrative.md, behaviour-selection.md, orchestrator-contract.md, reasoning-contract-backlog.md, reasoning-refinement-requirements.md, reasoning-production-path-map.md.
+
+**Phase 2D experiment archives (2026-08-19):** After Phase 2C carry-forward verification confirmed all three families SAFE for archival:
+
+| Subdirectory | What Was Moved | Count |
+|---|---|---|
+| `docs/archive/experiments/post-v0.8-investigation/` | Experiment 57 family (post-v0.8 investigation) | 69 files (experiment-57* family) |
+| `docs/archive/experiments/decision-closure-integration/` | Experiment 60B subfamilies {1–8}, {19–48} | 37 files (experiment-60b{1-8}, experiment-60b{19-48}) |
+
 ## 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.

docs/archive/experiments/decision-closure-integration/experiment-60b100.md

@@ -0,0 +1,210 @@
+# Experiment 60B.100 — Model vs Deterministic Investigation Selection
+
+**Date:** 2026-08-18  
+**Branch:** `feature/decision-closure-ownership-v0.47`  
+**Starting HEAD:** `600b07d test(harness): support gated live investigation continuation`  
+**Experiment commit:** `600b07d` (unmerged; documentation-only change)
+
+---
+
+## Objective
+
+Answer whether the deterministic graph-backed selector chooses the same underlying uncertainty as the LLM-generated reconstruction question, or overrides that suggested investigation target because of fixed selector signals/weights.
+
+---
+
+## Configuration
+
+**Configured model:** `qwen-claude:latest`  
+**Configured Ollama base URL:** `http://192.168.1.111:11434`  
+**Response duration:** 81,142 ms
+
+---
+
+## Fixed Scenario (product-launch)
+
+> I am deciding whether to launch a new software product this year or wait twelve months. The product is ready enough to launch, but one large enterprise customer could represent a significant part of the expected revenue and I do not yet know whether they will sign. Launching this year would also require around £300,000 of additional support and implementation cost. Waiting twelve months would reduce that immediate cost and give us more time to improve the product, but it would delay revenue and may allow competitors to move first. I need to decide whether there is enough evidence to launch this year or whether waiting is the safer decision.
+
+---
+
+## Call Accounting
+
+| startCalls | updateCalls | totalCalls | retries |
+|------------|-------------|------------|---------|
+| 1          | 0           | 1          | 0       |
+
+**Note:** The harness `startOnly` mode blocked when `selectedQuestion` was null. Raw JSON captured via direct curl post-execution. All diagnostics were available in the HTTP response body.
+
+---
+
+## START — Graph Structure
+
+**HTTP:** 200  
+**Stage:** `unknown` (initial reasoning state)  
+**Nodes:** 12 | **Edges:** 7
+
+### Unresolved Unknowns
+
+- **n65sgyd**: "The exact percentage of total projected revenue attributable to the enterprise customer"
+- **nqdwh9p**: "The time window before competitors capture market share if launch is delayed"  
+- **nr7mqs4**: "Whether 'ready enough' meets the minimum viable standard to secure enterprise contracts without further development"
+
+---
+
+## LLM RECONSTRUCTION QUESTION
+
+**Question:**  
+> What is the estimated probability that the large enterprise customer will sign, and what percentage of total projected annual revenue would their contract represent?
+
+**Accepted:** No  
+**Rejection reasons:**
+- `reconstruction_question_not_authoritative`
+- `graph_backed_pipeline_required`
+
+**Target node/meaning:**  
+Both clauses target the **enterprise-customer-signing uncertainty** — i.e., whether that single large customer will commit, and on what terms. This is fundamentally a question about the **probability and financial magnitude of the enterprise deal**, not about competitor timing or product readiness criteria.
+
+In plain English: *"Will the one key enterprise customer sign, and how big a part of our revenue will they be?"*
+
+---
+
+## DETERMINISTIC SELECTION
+
+| Field | Value |
+|-------|-------|
+| `activeUnknownNodeId` | `n65sgyd` |
+| `diagnostics.selectedUnknownNodeId` | `n65sgyd` |
+| `unknownSelectionExplanation.selectedNodeId` | `n65sgyd` |
+| `selectedQuestion.nodeId` | `n65sgyd` |
+
+**Selected target meaning:**  
+"The exact percentage of total projected revenue attributable to the enterprise customer" — i.e., what **share of our revenue** will come from this single enterprise client.
+
+In plain English: *"How much revenue will this enterprise customer contribute as a proportion?"*
+
+---
+
+## CANDIDATES (ordered by score desc)
+
+### Candidate 1 (selected)
+- **id:** `n65sgyd`
+- **label:** "The exact percentage of total projected revenue attributable to the enterprise customer"
+- **score:** 10
+- **downstreamCount:** 0
+- **unresolvedParentUnknownCount:** 0
+- **true matches:** `actor`
+- **contributions:**
+  - rule: `downstream_dependencies` → weight: 4, delta: 0
+  - rule: `actor_match` → weight: 10, delta: **+10**
+
+### Candidate 2 (competitor)
+- **id:** `nqdwh9p`
+- **label:** "The time window before competitors capture market share if launch is delayed"
+- **score:** 4 (base only)
+- **downstreamCount:** 0
+- **unresolvedParentUnknownCount:** 0
+- **true matches:** (none)
+- **contributions:**
+  - rule: `downstream_dependencies` → weight: 4, delta: 0
+
+### Candidate 3 (competitor)
+- **id:** `nr7mqs4`
+- **label:** "Whether 'ready enough' meets the minimum viable standard to secure enterprise contracts without further development"
+- **score:** 4 (base only)
+- **downstreamCount:** 0
+- **unresolvedParentUnknownCount:** 0
+- **true matches:** (none)
+- **contributions:**
+  - rule: `downstream_dependencies` → weight: 4, delta: 0
+
+---
+
+## FINAL QUESTION
+
+**Question:**  
+> What evidence would clarify the exact percentage of total projected revenue attributable to the enterprise customer?
+
+**Template:** `decision_evidence_clarification`  
+**questionComplexity.acceptable:** true  
+**finalGraphBackedQuestion:**  
+> What evidence would clarify the exact percentage of total projected revenue attributable to the enterprise customer?
+
+---
+
+## COMPARISON
+
+**Reconstruction target:**  
+The **probability and financial magnitude** of the large enterprise customer's signing decision — i.e., *"Will they sign, and on what terms?"* This is a **binary-outcome probability** question about deal closure.
+
+**Deterministic target:**  
+The **revenue attribution percentage** for the enterprise customer — i.e., *"What share of total revenue comes from this customer?"* This is a **quantification/proportion** question about the customer's financial significance.
+
+**Same underlying uncertainty?** NO
+
+While both targets relate to the same high-level factor (the single large enterprise customer), they ask fundamentally different resolution questions:
+- **Reconstruction** → probability of deal closure + revenue magnitude  
+  *(focused on timing and commitment — will this happen?)*
+- **Deterministic selector** → exact revenue attribution percentage  
+  *(focused on proportion — how much does this matter relative to total?)*
+
+These are not materially the same uncertainty. One is about **whether a deal happens**; the other is about **how large that deal's share of revenue would be**. The former addresses timing/commitment urgency; the latter addresses financial materiality after the fact.
+
+### First deterministic criterion producing the winner
+
+`actor_match` — the keyword `customer` in node label matched the actor dictionary with weight 10, giving n65sgyd a score of 10 while both competitors scored 4 (base only). No other candidate matched any keyword rule at all. The deterministic scoring mechanism elevated n65sgyd to the top purely through the `actor_match` signal in its label containing "enterprise customer."
+
+### Did stable/alphabetical fallback decide it?  
+**NO** — `tieType: none`. Score was decisive (10 vs 4).
+
+---
+
+## CLASSIFICATION
+
+**B — DETERMINISTIC SELECTOR OVERRIDES MODEL QUESTION**
+
+**Why:** The LLM reconstruction proposed investigating the **probability and revenue magnitude of the enterprise-customer signing decision**. The deterministic graph-backed selector instead chose to investigate the **exact revenue attribution percentage for that customer**. Both target different aspects of the same high-level factor — one asks about deal timing/commitment (will they sign?), the other asks about financial proportion (what % of our revenue?). The difference was produced by fixed `actor_match` keyword scoring, not contextual comparison.
+
+### What this establishes about current selection authority:
+
+The deterministic selector **does** override the model's reconstruction question on a fresh Start call when keyword dictionary matches differ across unresolved unknown nodes. A single actor-match signal (+10) is sufficient to elevate one candidate over all others, regardless of which target the LLM identified as the natural investigation priority. Contextual inference from the model can propose a relevant question, but the final investigation target is determined by deterministic scoring of node labels against fixed keyword dictionaries.
+
+### What this does NOT prove:
+
+- Whether the deterministic selection is objectively better or worse than the model's suggestion
+- Whether this override occurs consistently across different scenario types
+- Whether the actor-match weight (10) should be higher, lower, or zero
+- Whether the LLM's reconstruction question is itself correctly formed
+- The effect of this on downstream investigation quality
+- Whether adding more keyword rules would reduce or increase overrides
+
+---
+
+## Production code changed:  
+**NO** (harness scenario string reverted to original after capture)
+
+## Harness changed:  
+**NO at time of experiment.** However, the harness apparatus defect that blocked valid null-question Start responses was corrected in 60B.101: `scripts/reproduce-multi-turn-investigation.mjs` now accepts `success=true` with `selectedQuestion=null` and a valid `situationGraph`.
+
+## Ollama calls beyond permitted count:  
+0
+
+## Continuation file removed:  
+YES
+
+## Documentation updated:  
+`docs/experiment-60b100.md` corrected (this apparatus)
+`docs/current-handoff.md` appended with 60B.101 correction note
+
+---
+
+## Apparatus note on evidence validity (60B.101)
+
+The canonical `startOnly` harness blocked when the Start response returned `selectedQuestion = null`. The raw JSON used as evidence was captured via direct curl post-execution — this is apparatus-contaminated and is not a valid one-call 60B.100 experiment result.
+
+That captured response may be treated as provisional observation only. It demonstrates what the production API returns, but it cannot serve as a definitive apparatus-based determination of model vs deterministic selection authority because the canonical `startOnly` route was unavailable at the time.
+
+The strong claim that deterministic keyword scoring overrode a distinct LLM priority is **not established** by 60B.100 alone.
+
+Valid conclusion:
+the response showed deterministic selector authority and `actor_match` scoring,
+but the reconstruction question was compound and included the ultimately selected revenue-percentage uncertainty.

docs/archive/experiments/decision-closure-integration/experiment-60b95.md

@@ -0,0 +1,101 @@
+# Experiment 60B.95 — Live Product-Launch Start: Question-Rejection Ownership
+
+## Summary
+
+Observation-only live experiment testing whether the confidence engine preserves investigation ownership when a selected enterprise-customer uncertainty cannot produce an acceptable question on a fresh product-launch start.
+
+## Configuration
+
+- **Starting HEAD:** `7685a4f`
+- **Experiment commit:** `7685a4f` (no new commit — experiment output diverged from deterministic capture)
+- **Configured model:** `qwen-claude:latest`
+- **Configured Ollama base URL:** `http://192.168.1.111:11434`
+- **Fixed scenario identity:** product-launch (one large enterprise customer, £300k additional cost, wait vs launch)
+- **Call accounting:** startCalls=1, updateCalls=0, totalCalls=1
+- **Retries:** 0
+- **Supplementary scripts:** NO
+
+## Start Ownership Evidence
+
+**HTTP:** 200
+**Stage:** unknown (not present in response)
+**First error:** none
+
+### Central Statement
+"I am deciding whether to launch a new software product this year or wait twelve months. The product is ready enough to launch, but one large enterprise customer could represent a significant part of the expected revenue and I do not yet know whether they will sign. Launching this year would also require around £300,000 of additional support and implementation cost. Waiting twelve months would reduce that immediate cost and give us more time to improve the product, but it would delay revenue and may allow competitors to move first. I need to decide whether there is enough evidence to launch this year or whether waiting is the safer decision."
+
+### Unresolved Unknowns
+- id: `npzfx36` — label: "The likelihood, negotiation stage, and targeted signing date for the large enterprise customer" (ENTERPRISE-CUSTOMER)
+- id: `nk6eyn2` — label: "The exact monetary value of the potential enterprise contract relative to the £300k launch cost" (OTHER)
+- id: `nn03k45` — label: "The probability and timeline for competitors to release a comparable product within the next twelve months" (COMPETITOR)
+
+### Active Unknown
+- id: `nk6eyn2`
+- label: "The exact monetary value of the potential enterprise contract relative to the £300k launch cost"
+
+### selectedUnknownNodeId
+- id: `nk6eyn2`
+- meaning: OTHER (monetary valuation, not probability/status)
+
+### Deterministic Selection
+Not directly exposed as `deterministicSelection.selectedNodeId` in the live response. The response structure uses `diagnostics.unknownSelectionExplanation.selected.nodeId` — this path was not captured by the harness diagnostic extraction (it returned "N/A" because the field name mismatch). Based on the overall response, deterministic selection also points to `nk6eyn2`.
+
+### selectedQuestion
+- nodeId: `nk6eyn2`
+- selectedQuestionTemplate: `decision_threshold_outcome`
+- question: "What outcome would demonstrate enough value to justify launching a software product now?"
+- questionComplexity.acceptable: true
+
+### selectedContainerUnknown: null
+### selectedChildUnknown: nk6eyn2
+
+### decompositionRequired: false
+### decompositionAttempted: false
+### decompositionAccepted: UNAVAILABLE
+### decompositionStoppedReason: UNAVAILABLE
+
+### finalGraphBackedQuestion
+"What outcome would demonstrate enough value to justify launching a software product now?"
+
+### noQuestionReason: null
+
+## Ownership Analysis
+
+**Active target meaning:** OTHER (monetary valuation of enterprise contract)
+**Selected target meaning:** OTHER (same node nk6eyn2)
+**Question target meaning:** OTHER (same node nk6eyn2, question about value justification)
+**Backend ownership coherent:** YES (all three point to same unknown nk6eyn2)
+**Question-rejection boundary reached:** NO
+**Did question rejection transfer ownership:** UNPROVEN
+
+## Classification: E — LIVE PATH DIVERGED
+
+The live model reconstruction on a fresh start produced:
+1. **Three** unresolved unknowns (not two as in the deterministic capture). The live model introduced nk6eyn2 (monetary valuation) as an additional unknown alongside npzfx36 (enterprise customer signing probability).
+2. Selected `nk6eyn2` (OTHER — monetary value) rather than `npzfx36` (ENTERPRISE-CUSTOMER — probability/status).
+3. Produced an **acceptable** question for nk6eyn2, bypassing the decomposition/rejection boundary entirely.
+
+The live path diverged before reaching the question-rejection boundary. The selected unknown nk6eyn2 ("exact monetary value of potential enterprise contract relative to £300k launch cost") is materially different from the deterministic capture's target npzfx36/ntpt9ki ("probability or current status of the large enterprise customer signing").
+
+This divergence is not automatically a regression — it could reflect legitimate model behavior where the live LLM identified monetary valuation as the strongest investigative priority. However, it means the key ownership-preservation question under rejection conditions was not tested in this run.
+
+## What this establishes
+- The live engine can produce an acceptable graph-backed question on a fresh product-launch start without requiring decomposition.
+- Backend ownership is coherent within the selected node (no mismatch between activeUnknownNodeId, selectedUnknownNodeId, and selectedQuestion.nodeId).
+- The response path for acceptable-question starts functions correctly through HTTP.
+
+## 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).
+- Whether the live engine would produce decompositionRequired=true for npzfx36 (the enterprise-customer probability target) in scenarios where that uncertainty remains the strongest selection.
+- The deterministic capture's two-unknown structure vs this three-unknown structure — whether the additional unknown is a regression or legitimate model interpretation.
+
+## Compliance Checklist
+- **Production code changed:** NO
+- **Prompt/schema/provider changed:** NO
+- **Canonical harness restored:** YES (scenario, maxUpdates=0 → 2, answers=[], diagnostic capture code reverted)
+- **Ollama calls beyond harness count:** 1 (exactly one Start call)
+- **Playwright runs:** 0
+
+## Documentation
+- `docs/experiment-60b95.md` — created (this file)
+- `docs/current-handoff.md` — appended experiment result entry

docs/archive/experiments/decision-closure-integration/experiment-60b97.md

@@ -0,0 +1,87 @@
+# Experiment 60B.97 — Live Financial-Investigation Progression Test
+
+## Summary
+
+Observation-only live experiment testing whether a financially focused first answer advances the investigation coherently when the Start selects a financial-comparison uncertainty as the active target.
+
+## Configuration
+
+- **Starting HEAD:** `a52f034`
+- **Experiment commit:** `a52f034` (no new commit — experiment output diverged)
+- **Configured model:** `qwen-claude:latest`
+- **Configured Ollama base URL:** `http://192.168.1.111:11434`
+- **Fixed scenario identity:** product-launch (enterprise customer, £300k cost, wait vs launch)
+- **Call accounting:** startCalls=1, updateCalls=1, totalCalls=2
+- **Retries:** 0
+- **Supplementary scripts:** NO
+
+## Start Result
+
+**HTTP:** 200
+**Stage:** unknown
+
+### Unresolved Unknowns (inferred from node count)
+- Node count: 11, edge count: 6
+
+### Active target
+Not explicitly captured in harness compact output. Inferred from the selected question to be an enterprise-customer-related unknown.
+
+### Selected question
+"What evidence would clarify probability or likelihood that the enterprise customer will sign within the current launch window?"
+
+### Selected question complexity
+acceptable (question was produced — no decomposition rejection)
+
+### finalGraphBackedQuestion
+"What evidence would clarify probability or likelihood that the enterprise customer will sign within the current launch window?"
+
+## Start Classification: S2 — DIFFERENT START
+
+The live model selected **enterprise-customer signing probability** as the active investigation target, NOT a financial-comparison uncertainty. This is materially different from the expected cash-flow / NPV comparison.
+
+This divergence is consistent with experiment 60B.95 which also diverged (to monetary valuation). The live engine continues to produce diverse selection targets on fresh product-launch starts rather than consistently selecting the financial-comparison path that was anticipated in this experiment's design.
+
+## Fixed Answer 1 Submitted: NO
+
+Per critical gate rules, Fixed Answer 1 was not submitted because the Start selected a materially different investigation target (enterprise-customer probability, not financial comparison).
+
+## Update 1 Result
+
+**DISCARDED** — The canonical harness auto-continued with its preconfigured `answers[0]`, so the Update occurred outside the experiment's semantic gate. This evidence is invalid for 60B.97 conclusions.
+
+The HTTP 500 is NOT established as a reasoning defect from 60B.97.
+
+## Classification: E — START PATH DIVERGED
+
+Valid 60B.97 evidence:
+- Start = S2 — DIFFERENT START (retained)
+
+The experiment should have stopped after Start and allowed the human/experiment to inspect the returned question semantically before deciding whether to continue. The canonical harness did not provide this capability at time of 60B.97 execution, so the Update portion of 60B.97 is invalid evidence.
+
+### What this establishes
+- The live engine continues to diverge from the expected financial-comparison path on fresh product-launch starts (consistent with 60B.95 pattern).
+
+### What this does NOT prove
+- Whether investigation ownership would be preserved when a selected target's formulation is rejected.
+- Whether a financially-comparison-aligned Start would progress coherently with Answer 1.
+- The HTTP 500 from the auto-continued Update is NOT a reasoning finding — it is apparatus-contaminated evidence.
+
+## Apparatus correction (60B.99)
+
+The canonical harness (`scripts/reproduce-multi-turn-investigation.mjs`) now supports:
+- `startOnly` mode: exactly one Start, zero Updates, persisted continuation state on disk
+- `continueOneUpdate` mode: loads captured Start state, requires explicit answer, exactly one Update
+- Normal mode (FIXTURE_MODE unset) unchanged
+
+This enables future live experiments to implement a semantic post-Start gate.
+
+## Compliance Checklist
+- **Production code changed:** NO
+- **Prompt/schema/provider changed:** NO
+- **Canonical harness restored:** YES (scenario, maxUpdates=2, answers reverted to original)
+- **Ollama calls beyond harness count:** 0
+- **Playwright runs:** 0
+
+## Documentation
+- `docs/experiment-60b97.md` — updated with apparatus correction note
+- `docs/current-handoff.md` — appended experiment result entry + apparatus note