116 lines
8.2 KiB
Markdown
116 lines
8.2 KiB
Markdown
# 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;
|
||
- 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 paused after Experiment 25B;
|
||
- UI experiments are paused;
|
||
- Knowledge-management experiments are active;
|
||
- Nothing historical has been deleted or archived yet.
|
||
|
||
## 7. Context Loading Guide
|
||
|
||
| When you need | Read this |
|
||
|---|---|
|
||
| Where we are now | `docs/current-project-state.md` (this file) |
|
||
| 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` |
|
||
| 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 are paused after Experiment 25B, which established scope-aware condition status — distinguishing direct evidence from relevant-but-different claims by checking subject, timeframe and claim type. The passive classifier layers (Exps 18–25B) remain isolated; none yet control the user-facing investigation. Current focus is knowledge management: creating a short current-state entry point so future sessions do not need to read the full experiment history.
|
||
|
||
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.
|
||
|
||
Nothing has been archived, moved or deleted. Before changing the documentation structure, review whether the new entry point reliably replaces the large log section and whether any historical documents should be formally archived.
|
||
|
||
### Return-to-Work Note (updated Experiment 29)
|
||
|
||
The current-state briefing was checked against source code via targeted code inspection of API routes, orchestrator imports/calls, and cross-module traces for each passive classifier. Five active capabilities are confirmed (reconstruction, graph updates, unknown selection, question formulation, turn orchestration). Seven passive capabilities remain classified as diagnostic_only (investigation-state assessment) or isolated (behaviour selection, decision-condition status, evidence direction, evidence scope, question importance, question relevance to decision, scope-aware condition status). No corrections to the current-state document were required. Knowledge-management experiments continue: selected historical documents have been archived to `docs/archive/`; nothing was deleted. The archive index explains where older evidence lives and when to consult it. Engine and UI experiments remain paused. First file to inspect when resuming: `docs/current-project-state.md`, then `.claude/architecture-guardrails.md` before any code changes, then `lib/graph/orchestrator.js` for engine-resumption work.
|
||
|
||
## 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:** `4661b8e` (experiment: inventory project knowledge and context needs)
|