confidence-engine/docs/current-project-state.md

Current Project State — Confidence Engine

Created by Experiment 27. This document is the starting point for any fresh session working on the Confidence Engine. Read this first, then follow the routing table below to task-specific references.

1. What the Confidence Engine Is

The Confidence Engine helps people decide whether they have enough justified confidence to act on a complicated problem — one step at a time.

It does not simply answer the user's question. It:

• Reconstructs the situation;
• Separates observations, assumptions, relationships and unknowns;
• Builds a structured reasoning graph;
• Selects the most useful unresolved uncertainty;
• Asks one simple question;
• Updates the graph from the answer;
• Repeats until action is justified or the remaining uncertainty is clear.

The user may already know the answer but needs confidence to act, may need to identify who to ask, may need to find where to look, or may need to determine how to test a claim. The engine carries the complexity of reasoning so the user does not have to manage graph theory, node IDs, internal enums, schemas, prompt versions or provider details.

2. Current Product Experience

The product direction is a facilitated investigation, not a chatbot and not a form.

• A conversation lane guides the user through one question at a time;
• A shared workspace (situation, understanding, investigation map, history) presents the current state alongside the active question;
• A graph is used as the machine representation of reasoning, translated into human-readable narrative for the user view;
• Developer and debug views remain available but are intentionally separate.

UI work is currently paused. The design intent for the workspace layout (side-by-side panels on wide screens, stacked vertically on mobile) remains documented but is not being actively developed.

3. Current Engine Capabilities

Active capabilities

These are what currently affect the working engine:

• Deterministic reasoning pipeline from scenario reconstruction through graph update, propagation and confidence/completeness calculation;
• Unknown selection using atomicity and answerability checks;
• Question formulation within a selected reasoning pattern;
• Scenario API (analyseScenario / updateCase);
• Investigation turn cycle orchestration;
• Reasoning-fidelity v0.8 (completed): user-supported meaning cannot silently outrun the raw answer at the mutation boundary; evidence-resolvable uncertainty and user-owned ambiguity are routed differently at question formulation. A–F regression boundaries closed for this pass. See docs/current-handoff.md for closeout details.

Passive experimental capabilities

The following were built during Experiments 18–25B. They are isolated diagnostic layers with no active integration into the user-facing investigation:

• Investigation-state assessment (phase and progress classification);
• Behaviour selection from assessed state — passively evaluated in Experiments 39–41; all five behaviours reachable but Acknowledge dominates (71% on real data); Exp 41 recommends Variant B (Acknowledge exclusions via phase/progress/health gates) as the cleaner approach;
• Decision condition status evaluation;
• Question-to-condition relevance scoring;
• Evidence direction classification (support, contradict, inform);
• Evidence scope detection (direct_match, different_timeframe, subject_mismatch, partial_match, cannot_determine);
• Scope-aware condition status using phrase matching.

These passive classifiers do not yet control the user-facing investigation. They record signals for future use when integrated into the active reasoning path.

4. What Experiments 20–25B Established

• A decision's importance requires a destination — you cannot assess whether something matters without knowing what you are deciding between.
• Decision conditions explain what would make a decision justified; they are not the same as unresolved unknowns.
• Resolving a question does not automatically establish the condition that question might inform — there is a distinct gap between answering and establishing.
• Evidence can support, contradict or merely inform a condition depending on subject, timeframe and claim type alignment.
• Direction alone (support/contradict/inform) is insufficient without checking whether evidence and condition share subject, claim type and timeframe.
• Present-state evidence does not automatically settle future-feasibility conditions; scope detection must check both inputs independently.
• Keyword and phrase matching remains provisional experimental scaffolding — it is narrow, targeted and replaceable, not a finished language-understanding system.

5. What Remains Unresolved

• How free language will be interpreted reliably without keyword scaffolding;
• Whether structured LLM interpretation should eventually replace current phrase-based detection;
• Whether passive classifiers generalise across domains or remain fixture-specific;
• How and when passive reasoning signals should enter the active turn cycle;
• Whether current architectural documents (v0.6-reasoning-architecture.md, etc.) still accurately match implementation after experiments 15–25B.

6. Work Currently Paused

• Engine experiments advanced through Experiment 43 (Clarify readiness diagnostic confirming zero Clarify eligibility across all real fixtures; orienting-based rule identified as dead code; too_broad trigger validly narrow but untested in fixtures).
• UI experiments are paused;
• Knowledge-management experiments are complete (confirmed by Experiment 38 cold-start validation);
• Nothing historical has been deleted or archived yet.

7. Context Loading Guide

When you need	Read this
Returning after a break	First: docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md (methodology continuity), then docs/current-handoff.md
Where we are now	docs/current-project-state.md (this file)
Current principles and reasoning guidance	docs/current-working-principles.md
What to keep from code changes during UX work	.claude/architecture-guardrails.md
Product direction and stage	.claude/project-context.md
Task-specific or historical references	docs/project-knowledge-inventory.md
Broader architectural intent	docs/architectural-principles.md (task-specific only)
Task-specific routing by work type	docs/task-context-packs.md (four minimal packs + common rules)
Historical evidence or a named experiment	docs/design-evolution-log.md (the named section only)

Do not read the full design-evolution log unless a specific experiment is required. Use the inventory to locate task-specific context, then load only what you need.

Historical documents are retained under docs/archive/ and should be opened only when a named past decision, release or experiment requires them.

8. Return-to-Work Summary

Engine experiments advanced through Experiment 43, which diagnosed Clarify's absence across all real fixtures (zero eligibility in 10 turns). The orienting-based Clarify rule is dead code — the assessor never produces phase=orienting. The too_broad trigger is validly narrow but untested by any fixture. Summarise and Pause remain operational from Exp 42. Behaviour Selection remains passive and isolated. Open decision: whether to fix the orienting dead-code path or accept it as intentional design, and whether to widen or tighten the too_broad threshold with dedicated fixtures. No active tests rerun as part of documentation closure.

First document to read: docs/current-project-state.md. Then consult .claude/architecture-guardrails.md before any code changes and docs/project-knowledge-inventory.md for task-specific references. The full experiment history remains available in docs/design-evolution-log.md but is no longer default reading.

Verification Marker

Implementation status last checked against source: Experiment 43. The current-state document was verified as accurate by focused code inspection of API routes, orchestrator imports/calls, and cross-module traces for all passive classifiers. No corrections were required.

10. Post-v0.8 Methodology Learning

Since the handoff document was written, further learning has emerged from Return-to-Origin work (RTO.14–17):

What proved useful: An LLM can retain prior focused knowledge, revise uncertainty, and carry coherent reasoning across turns inside a single investigation.

What was exposed: Pushing that approach further reproduced the original cumulative-state reconstruction pattern at a lower scope (focused-investigation state + new answer → LLM rewrites focused state). This is the same structural assumption we challenged at the global-graph level — just compressed.

Current working hypothesis (not yet architecture): The natural reasoning unit is one question → one answer → one interpretation/capture. Each accepted answer produces a small evidence-bearing reasoning fragment, remembered outside the LLM call. The larger investigation understanding emerges from composing those fragments over time. Only directly relevant prior knowledge needs to be supplied when qualifying a specific earlier fragment.

Next experiment direction: Test independent user-chosen question/answer deconstruction without accumulated focused state being passed between LLM calls. See docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md for full context.

Branch: feature/decision-closure-ownership-v0.47 Current HEAD: e1b54e4 (experiment: checkpoint granular answer fragment apparatus)