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;
• Evaluates whether remaining uncertainty justifies action;
• 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 presented across three distinct routes:

/                              → Portfolio (investigator notebook index)
/investigations/{id}           → Investigation (working case / pages)
/investigations/{id}/report   → Investigation Report (readable derived summary)

Portfolio: Shows the persisted investigation collection. Actions on each card: View report, Continue investigation, Restart investigation. Below the cards: + Create new investigation (allocates durable ID via crypto.randomUUID() + navigates to /investigations/{id}). Restart is confirmation-gated and preserves container while clearing reasoning/Report state.

Investigation: Contains ScenarioForm + ReasoningWorkspace. Handles graph reasoning, focused investigation turns, Done/Re-open semantics, Current Understanding synthesis. Report presentation is NOT part of this route — owned by the dedicated Report page.

Report: Renders persisted investigationReport snapshot. Generation is on-demand (exactly one /api/cases/overview call on first visit; zero on subsequent visits). The Report is a derived artefact, not canonical reasoning evidence.

The user controls which question to investigate, when to say Done for now, whether Current Understanding is sufficient, whether to reopen work, and when to review the Report. The engine facilitates — it does not steer or prioritise.

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 — remains an available capability (graph-backed question generation for selected nodes);
• 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.

NOTE on investigation ownership: The user currently owns which unresolved investigation/question to pursue. Selector-led compulsory next-question optimisation is paused under Return-to-Origin. Semantic-selector replacement is also paused. Question formulation remains available as a capability but its output is not automatically enforced as the user's required next step.

Route architecture (v0.55)

Three distinct routes, each with clear ownership:

Route	Owner	Presentation
Portfolio (/)	Portfolio page + storage	List of Investigation summaries; no Report presentation
Investigation (/investigations/{id})	ScenarioForm + ReasoningWorkspace	Focused investigation turn cycle
Report (/investigations/{id}/report)	Report page (standalone)	Persisted derived artefact; on-demand generation

Key invariants: ReasoningWorkspace no longer owns Report presentation. The Report is a distinct route/page, not an internal state of the Investigation.

Persistence and report lifecycle

• Multi-Investigation collection via localStorage (key prefix confidence-engine-investigation:<durable-id>). Legacy singleton path retained for backward compatibility (unused by current product).
• saveInvestigation() / loadInvestigation() are the canonical storage seams.
• listInvestigations() returns lightweight summaries for Portfolio rendering.
• Report generation: first visit → one synthesis call + persist; subsequent visits → zero calls, renders persisted snapshot.
• Restart is destructive and confirmation-gated (dialog → explicit second confirmation → clearInvestigation()).

Reasoning-engine vs UX/product version lineage

The Confidence Engine tracks two independent version lineages:

• Reasoning-engine experimental lineage (v0.8+): reasoning-fidelity, investigation-state assessment, semantic selectors — under RTO pause.
• UX/product development lineage (v0.55+): Portfolio / Investigation / Report route separation, persisted report lifecycle, confirmation-gated restart, focused-presentation ownership, empty Done semantics. Do not conflate these lineages as describing one product version.

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

Not yet implemented (product capabilities)

Multi-investigation storage and portfolio are structurally complete in v0.60. Deferred feature work beyond MVP scope:

• Search, tag, archive, group behaviour within Portfolio
• Export/copy of Reports to Jira or external document

Multi-investigation identity is durable (uuidv4). Legacy singleton compatibility remains internally (unused by current product). Report freshness / versioning after investigation changes uses generatedFromRevision vs investigationRevision.

Methodological 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/current-handoff.md (current state + methodology anchor), then docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md (methodology continuity)
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/README.md → relevant chapter

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.

UX/product development reached v0.55: Portfolio / Investigation / Report route separation, persisted report lifecycle (first visit = one synthesis; subsequent visits = zero), confirmation-gated restart, focused-presentation ownership per question, empty Done + Re-open semantics, zero-Open-Questions milestone. All verified via targeted Vitest and live Playwright.

First document to read: docs/current-handoff.md (methodology continuity + current state), then docs/current-project-state.md, then docs/project-knowledge-inventory.md. Consult .claude/architecture-guardrails.md before any code changes. The full experiment history remains available in docs/design-evolution/README.md but is no longer default reading — load only when a specific question requires it.

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

Durable methodology principles (2026-08-19)

The following principles have been durably codified in docs/current-working-principles.md as Axiomatic Principles A1–A12. They are now the authoritative methodological baseline for all future work:

Classification	Principle
METHODOLOGY PRINCIPLE	A1 — Delivery-platform independence (methodology ≠ software)
METHODOLOGY PRINCIPLE	A2 — The Engine facilitates; the user directs investigation
METHODOLOGY PRINCIPLE	A3 — Meaning over prescribed vocabulary; no domain/language dictionaries
METHODOLOGY PRINCIPLE	A4 — Semantic interpretation as a facilitation capability (LLM optional)
METHODOLOGY PRINCIPLE	A5 — Deterministic code for structure/integrity only, not semantic judgment
METHODOLOGY PRINCIPLE	A6 — Investigation is non-linear; user moves between branches
METHODOLOGY PRINCIPLE	A7 — Background assistance must not redirect the user's current work
METHODOLOGY PRINCIPLE	A8 — Closure is user-owned and may be provisional (no mandatory thresholds)
METHODOLOGY PRINCIPLE	A9 — Graph-like reasoning structure does not mandate graph UI
METHODOLOGY PRINCIPLE	A10 — Progressive disclosure mirrors progressive reasoning
METHODOLOGY PRINCIPLE	A11 — Multilingual portability follows from meaning-based (not vocabulary-based) design
METHODOLOGY PRINCIPLE	A12 — Latency is an implementation trade-off, not a methodological constraint
IMPLEMENTATION HYPOTHESIS	Hybrid deterministic/semantic fast path (not selected; guardrail applies)

New work must not contradict these axioms without explicit methodological review. See docs/current-working-principles.md §0 for full wording and classification discipline.

Carry-forward from Phase 1B audit evidence

The following material learnings are carried forward as durable context for safe later archival of experiment families:

• Proposition phrasing materially influences deterministic scoring (57-series / 60B.100): Even when underlying meaning is equivalent, the specific wording or lexical form of a proposition can change deterministic scoring outcomes. Phrase/keyword-driven semantic priority is therefore brittle and must not be treated as paraphrase-invariant.

• Decision-sufficiency reasoning is passive capability: Decision-sufficiency reasoning exists as a passive/experimental capability rather than current user-facing routing authority. (Already documented in §3 Passive experimental capabilities.)

• Ownership survives rejection: User-selected/active investigation ownership must survive substantive ties and question-formulation rejection. (Already documented in docs/current-handoff.md.)

RTO learning from Experiments 14–17

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: 85204f96aca7e4b350fe8db73150bf0683ebeefe (experiment: checkpoint borderline relationship control)

Current experimental context

The durable methodology principles (A1–A12 above) should be loaded before continuing experiments. For detailed current operational state, read docs/current-handoff.md first.