# 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.

### 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 are at Experiment 40 (behaviour reachability diagnostic — no rule changes).
- 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 | `docs/current-handoff.md` (first file) |
| 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 to Experiment 41, which compared two passive alternatives for reducing Acknowledge dominance. Variant B (Acknowledge exclusions via phase/progress/health gates) is recommended over Variant A (priority reordering with false-positive side effects). Both variants converge on the same two genuine changes: `concluding → summarise` and `stalled → pause`. No production code changed.

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 28.
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.

**Branch:** `feature/user-workspace-ux-v0.7`
**Latest known commit before this experiment:** `544573a` (experiment: validate cross-boundary context routing, Exp 37)