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.