experiment: verify current project state against implementation

docs/design-evolution-log.md

@@ -1638,7 +1638,68 @@ Once the information architecture and visual hierarchy stabilise we will investi
 
 This should be treated as a future UX experiment rather than an accessibility feature.
 
-## Backlog — Investigation Narrative (Potential Future Work)
+## Experiment 28 — Verify Current Project State Against Implementation
+
+**Status:** Pending Rob's review
+
+### Hypothesis
+
+A focused code inspection can verify or correct the current-state document without requiring a fresh session to read the full experiment log. If the document is accurate, it can safely become the normal project entry point.
+
+### Source Areas Inspected
+
+- `docs/current-project-state.md` — entire file;
+- `.claude/architecture-guardrails.md` — entire file;
+- `docs/project-knowledge-inventory.md` — Current Working Context and Task-Specific References sections;
+- `app/api/*/route.js` — all API entry points (analyse, cases/start, cases/update, health);
+- `lib/graph/orchestrator.js` — imports (lines 6–32) and runtime calls at lines 376, 402, 552, 581, 622, 826, 904, 1013;
+- `lib/graph/*.js` — grep for imports of passive classifier modules (decision-condition-status, evidence-direction, evidence-condition-scope, question-decision-relevance, question-importance);
+- `lib/behaviour-selection/behaviour-selector.js` — cross-module import check;
+- `lib/assessment/investigation-state-assessor.js` — caller trace in orchestrator.
+
+### Active / Passive Findings
+
+**Active capabilities confirmed:**
+1. Scenario reconstruction (analyseScenario) — API entry at app/api/analyse/route.js → lib/analysis.js.
+2. Reasoning graph updates (startCase / updateCase) — API entries at app/api/cases/{start,update}/route.js → orchestrator.js → apply-proposal.js. Propagation, confidence cap, completeness calculated in apply-proposal.
+3. Unknown selection (atomicity + answerability) — selectActiveUnknownCandidate imported and called from orchestrator's determineGraphBackedQuestion within the active updateCase path.
+4. Question formulation — formulateQuestion / formulateTieResolutionQuestion imported and called from the active turn cycle.
+5. Turn orchestration — orchestrator.js updateCaseWithDependencies() is the active engine heart, coordinating unknown→question→answer→graph-update→propagation→next-unknown.
+
+**Passive or isolated capabilities confirmed:**
+1. Investigation-state assessment (assessInvestigationState) — called at 3 sites in orchestrator but result only placed into a diagnostics field; not used for any control-flow decision. Classification: **diagnostic_only**.
+2. Behaviour selection (selectBehaviour) — exported from behaviour-selector.js; no callers anywhere in the repo. Classification: **isolated**.
+3. Question importance, question relevance to decision, evidence direction, evidence scope, scope-aware condition status — each exists as a standalone module or file with zero external callers. Evidence direction and scope are imported only by decision-condition-status.js, which itself has no callers.
+
+### Corrections Made
+
+None. The current-state document's active/passive classification is accurate as-is. Added verification marker to docs/current-project-state.md.
+
+### Practical Context-Test Result
+
+**Task:** A developer proposes connecting Behaviour Selection directly to the next user-facing response. Is it active today? What boundary exists? Which files would need inspection before future integration?
+
+**Briefing:**
+1. **Active today?** No. `selectBehaviour` is exported from `lib/behaviour-selection/behaviour-selector.js` but has zero callers anywhere in the repository. It is not active, diagnostic, or accessible through any API.
+2. **Current boundary:** Behaviour Selection and Investigation-State Assessment exist as separate modules that were never wired into the orchestrator's turn cycle. The orchestrator returns an `assessment` field to clients but does not pass assessment results into its own decision logic. There is no data path from state assessment → behaviour selection → question/response.
+3. **Files to inspect before integration:** `lib/graph/orchestrator.js` (where the insertion point would be — between unknown selection and question formulation, or after propagation); `lib/assessment/investigation-state-assessor.js` (to understand what the assessment contract outputs); `lib/behaviour-selection/behaviour-selector.js` (to understand what behaviours it can produce); `docs/investigation-state-assessment-contract.md` and `docs/behaviour-selection.md` for the documented interfaces; `app/api/cases/update/route.js` to determine whether behaviour output would appear in the API response or remain internal.
+4. **Context sufficient?** Yes — the three-file set (current-project-state, verification file, guardrails) plus targeted code inspection of the modules above provides sufficient context for a designer to assess integration scope without reopening the full history.
+5. **Verdict:** Integration is feasible as a future experiment. The primary risk is that behaviour selection has no documented input contract from the assessment layer — these were built in parallel without an agreed handoff shape.
+
+### Unresolved Questions
+
+- Whether the assessment output from `assessInvestigationState` matches the documented `investigation-state-assessment-contract.md` (requires reading the assessor's internal logic, excluded per constraints).
+- Whether external API clients (not in this repo) call the orchestrator directly, bypassing the route files.
+- The exact integration sequence: should behaviour selection read from assessment output or from the graph state directly?
+
+### Return-to-Work Note
+
+The current-state briefing was checked against source code via targeted code inspection of API routes, orchestrator imports/calls, and cross-module traces for each passive classifier. Five active capabilities are confirmed (reconstruction, graph updates, unknown selection, question formulation, turn orchestration). Seven passive capabilities remain classified as diagnostic_only (investigation-state assessment) or isolated (behaviour selection, decision-condition status, evidence direction, evidence scope, question importance, question relevance to decision, scope-aware condition status). No corrections to the current-state document were required. Knowledge-management work remains active. 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 `.claude/architecture-guardrails.md` before any code changes, then `lib/graph/orchestrator.js` for engine-resumption work.
+
+Branch: feature/user-workspace-ux-v0.7
+Commit: 61c8a3a
+
+
 
 These are observations, not implementation tasks.