confidence-engine/docs/current-implementation-verification.md

# Current Implementation Verification

> Experiment 28 — Focused code inspection of `feature/user-workspace-ux-v0.7`.

## 1. Verification Method

Inspected the following runtime entry points and imports:

**API routes (entry points):**
- `app/api/cases/start/route.js` → calls `startCase` from orchestrator;
- `app/api/cases/update/route.js` → calls `updateCase` from orchestrator;
- `app/api/analyse/route.js` → calls `analyseScenario` from analysis.js (reconstruction only).

**Orchestrator imports** (`lib/graph/orchestrator.js`, lines 6–32):
- `analyseScenario` (reconstruction, not engine);
- `buildInitialGraph`, `describeGraph` (graph builder);
- `applyValidatedProposal`, `determineGraphBackedQuestion` (apply-proposal);
- `assessInvestigationState` (imported, but result only placed in diagnostics field);
- `buildReasoningState`, `formulateQuestion`, `formulateTieResolutionQuestion` (question-formulator);
- `parseGraphUpdateProposal`;
- `explainUnknownSelection`, `selectActiveUnknownCandidate`, `validateGraphReferences` (utils).

**Cross-module traces:**
- `grep -R "selectBehaviour"` — no callers outside its own module;
- `grep -R "assessDecisionConditionStatus\|scoreQuestionDecisionRelevance\|assessQuestionImportance"` — no callers outside decision-condition-status.js, question-decision-relevance.js, and question-importance.js respectively;
- `import` statements in all JS files under lib/ and app/ were inspected for references to passive classifier modules.

Evidence is based on actual imports, call sites, and return-object placement found in source.

## 2. Active Capabilities

### 2a. Scenario Reconstruction (analyseScenario)
- **Purpose:** LLM-based scenario analysis producing situation graph; first step of a new case.
- **Implementation:** `lib/analysis.js` → calls provider, parses response, validates against Zod schemas.
- **Evidence:** Called from `app/api/analyse/route.js` and imported by orchestrator's startCase flow via `buildInitialGraph`.

### 2b. Reasoning Graph Updates (startCase / updateCase)
- **Purpose:** Builds initial situation graph from analysis; applies user answers to graph nodes, updates status/confidence/completeness, runs propagation.
- **Implementation:** `lib/graph/orchestrator.js` — `startCase()` (line 376 calls `buildInitialGraph`, line 402 calls `determineGraphBackedQuestion`); `updateCaseWithDependencies()` (line 622 calls `applyValidatedProposal`).
- **Evidence:** Orchestrator functions are called from `app/api/cases/start/route.js` and `app/api/cases/update/route.js`. `applyValidatedProposal` is the runtime caller for graph mutation; propagation, confidence cap, and completeness update happen within apply-proposal.js.

### 2c. Unknown Selection (atomicity + answerability)
- **Purpose:** Selects the next unresolved node to investigate based on atomicity and answerability criteria.
- **Implementation:** `selectActiveUnknownCandidate` in `lib/graph/utils.js`; called from orchestrator's updateCase flow via `determineGraphBackedQuestion`.
- **Evidence:** Imported at line 30 of orchestrator.js; used in the active investigation turn cycle within `updateCaseWithDependencies()`.

### 2d. Question Formulation
- **Purpose:** Generates a single user-facing question from the selected unknown node and reasoning pattern.
- **Implementation:** `formulateQuestion`, `formulateTieResolutionQuestion` in `lib/graph/question-formulator.js`.
- **Evidence:** Imported at lines 23–26 of orchestrator.js; called from `determineGraphBackedQuestion` within the active updateCase path.

### 2e. Investigation Turn Cycle Orchestration
- **Purpose:** Coordinates the full turn: unknown selection → question formulation → user answer → graph update → propagation → next unknown.
- **Implementation:** `lib/graph/orchestrator.js` — the complete `updateCaseWithDependencies()` function (line 581–919) and `startCase` flow (line 370–566).
- **Evidence:** Both functions are exposed as public entry points and called from their respective API routes. This is the active runtime heart of the engine.

## 3. Passive or Isolated Capabilities

### 3a. Investigation-State Assessment
- **Implementation:** `lib/assessment/investigation-state-assessor.js`.
- **Called by:** `lib/graph/orchestrator.js` at lines 552, 904, 1013 (three call sites in startCase and updateCase).
- **Where result goes:** Placed into the `assessment` field of the diagnostics object returned to the client. It is **not** used to control any engine decision or behaviour path.
- **Classification: diagnostic_only.**

### 3b. Behaviour Selection
- **Implementation:** `lib/behaviour-selection/behaviour-selector.js`.
- **Called by:** None. No import or call found in any file under lib/ or app/.
- **Why not active:** Entirely isolated — no caller exists anywhere in the repository.

### 3c. Question Importance Assessment
- **Implementation:** `lib/graph/question-importance.js` (line 106: `assessQuestionImportance`).
- **Called by:** None. No import found outside its own module.
- **Why not active:** Isolated — not called by runtime, diagnostics, or any other module.

### 3d. Question Relevance to Decision Conditions
- **Implementation:** `lib/graph/question-decision-relevance.js` (line 65: `assessQuestionRelevanceToDecision`).
- **Called by:** None. No import found outside its own module.
- **Why not active:** Isolated — same status as question-importance.js.

### 3e. Decision Condition Status Evaluation
- **Implementation:** `lib/graph/decision-condition-status.js`. Exports `assessDecisionConditionStatus` (line 105). Imports and uses `assessEvidenceDirection` and `assessEvidenceConditionScope`.
- **Called by:** None. No import found in any other module.
- **Why not active:** Isolated at the file level — it exists as a self-contained module with no external callers.

### 3f. Evidence Direction Classification
- **Implementation:** `lib/graph/evidence-direction.js` (line 134: `assessEvidenceDirection`).
- **Called by:** Only from `decision-condition-status.js` (internal dependency). No external caller.
- **Why not active:** Isolated — only consumed by decision-condition-status.js, which itself has no callers.

### 3g. Evidence Scope Detection
- **Implementation:** `lib/graph/evidence-condition-scope.js` (line 100: `assessEvidenceConditionScope`).
- **Called by:** Only from `decision-condition-status.js` (internal dependency). No external caller.
- **Why not active:** Isolated — only consumed by decision-condition-status.js, which itself has no callers.

### 3h. Scope-Aware Condition Status (composite)
- **Implementation:** Same as 3e — the composite `assessDecisionConditionStatus` combines evidence direction and scope detection.
- **Classification: isolated.** No external caller.

## 4. Differences From the Current-State Document

**None found.** The current-state document's classification of active capabilities (reconstruction, graph updates, unknown selection, question formulation, turn orchestration) matches what the code shows as genuinely active in the runtime path. Its classification of passive experimental capabilities (investigation-state assessment, behaviour selection, decision-condition status, question-to-condition relevance, evidence direction, evidence scope, scope-aware condition status) also matches — all remain either diagnostic_only or isolated with no external callers.

## 5. Unresolved From Code Inspection

- The runtime output shape of `assessInvestigationState` and which assessment values it produces cannot be fully assessed without reading the assessor's internal logic (per constraints). However, its **classification** as diagnostic_only is established by tracing: imported → called at 3 sites → result placed in a diagnostics field → no if/switch/ternary branches check its output.
- Whether `startCase` and `updateCase` API routes are the only callers of the orchestrator cannot be confirmed without searching outside this repository (e.g., external clients). The assessment is limited to code within the repo.

## Verification Marker

Implementation status last checked against source: Experiment 28.