diff --git a/.claude/project-context.md b/.claude/project-context.md index a21f8c2..5e339b1 100644 --- a/.claude/project-context.md +++ b/.claude/project-context.md @@ -19,6 +19,18 @@ It: 6. updates the graph from the answer; 7. repeats until action is justified or the remaining uncertainty is clear. +> **NOTE:** The flow above describes historical/current implementation mechanics. +> It does not represent current Confidence Engine methodology direction. +> See `docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md` +> for the current working hypothesis (granular answer-fragment inquiry). + +The linear selector-led flow described above is a **historical capability**, not +an automatic architecture to continue. Under Return-to-Origin: + +- The Engine facilitates inquiry; it does not compel a single-question route. +- The user owns which unresolved investigation/question to pursue. +- Accumulated reasoning memory does not necessarily belong inside repeated LLM calls. + A chatbot remembers the conversation. The Confidence Engine preserves the state of the reasoning. @@ -50,15 +62,23 @@ The engine should help a user reach one of these states: ## Current development stage -The deterministic reasoning architecture reached a stable alpha checkpoint. +> **Version lineage note:** The Confidence Engine uses two distinct version +> lineages that must not be conflated: +> - **Reasoning-engine experimental lineage** (v0.8+): reasoning-fidelity, +> investigation-state assessment, semantic selectors — under RTO pause. +> - **UX/product development lineage** (v0.7): workspace layout, user views, +> loading feedback — also paused. +> These are independent tracks; do not assume they describe one product version. -Current work is primarily improving: +The deterministic reasoning architecture reached a stable alpha checkpoint +(reasoning-engine v0.8). UI/product work reached v0.7 staging. Both have +paused under Return to Origin while the granular answer-fragment hypothesis +is evaluated as working methodology context. -- usability; -- presentation; -- loading feedback; -- plain-language explanations; -- separation of user and developer views. +Current work is paused. The next step begins from the methodology question: +given the useful investigation structure the Engine can already derive, how +should that structure be surfaced so a person can see, choose, defer, and +return to open questions while the Engine continues to guide their thinking? Do not resume broad reasoning architecture work unless a repeated observed failure clearly requires it. @@ -93,7 +113,11 @@ The interface should minimise cognitive load by presenting the current state fir The engine may contain hundreds of reasoning nodes; the user should only see the information required to take the next meaningful action. -## Why workspace layout matters (v0.7) +## Why workspace layout matters (v0.7 — UX/product lineage) + +> **This section documents paused UX design intent.** It belongs to the v0.7 +> product development lineage, not the reasoning-engine lineage. UI work is +> currently paused under Return to Origin. This phase optimises for simultaneous visibility instead of sequential scrolling. Related panels — Understanding alongside Investigation Map, Situation alongside History — can appear side-by-side on wide screens while mobile continues to stack everything vertically. The reasoning engine is completely unaware of these changes; only the presentation layer is affected. @@ -104,7 +128,10 @@ Read `docs/current-working-principles.md` for current guidance. Treat `docs/arch For UI mock work, read `docs/ui-mock-reference.md`. Do not load `docs/archive/deferred-ux-backlog.md` unless a named past UX idea is being reviewed. -Engine and UI experiments are paused. First file to inspect when resuming: -`docs/current-project-state.md`, then `docs/project-knowledge-inventory.md`. + +Engine and UI experiments are paused under Return to Origin. First file to inspect when resuming: +**`docs/current-handoff.md`** (methodology continuity anchor), then `docs/current-project-state.md`, then `docs/project-knowledge-inventory.md`. > After reading `docs/current-project-state.md`, choose the relevant minimal pack from `docs/task-context-packs.md`. Do not combine packs unless a specific task genuinely crosses boundaries. +> +> **Historical experiment families are evidence to load only when a specific question requires them; they are not default architecture context.** diff --git a/docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md b/docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md index 5b1617e..f41f126 100644 --- a/docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md +++ b/docs/Confidence_Engine_Return_to_Origin_Methodology_Context_2026-08-18.md @@ -328,4 +328,11 @@ This does not apply to implementation mechanics such as JSON, APIs or databases. - `Confidence_Engine_Project_Context_Update_2026-08-17` - `Confidence_Engine_Current_Handoff_2026-08-17` +> **Provenance note:** Some source-basis documents listed above were external +> project/session context supplied during the methodology work and are not +> repository-managed files. They informed this document's content but cannot be +> verified as originating from the Git history of this repository. Their role +> is to document where the methodology context came from, not to assert Git +> provenance for those external documents. + This context update distinguishes established project principles from current implementation learning. The workspace/user-directed investigation model is recorded as the current hypothesis to test, not as a completed replacement architecture. The granular answer-fragment hypothesis (RTO.14–17) is recorded as working hypothesis, not yet accepted architecture. \ No newline at end of file diff --git a/docs/current-project-state.md b/docs/current-project-state.md index bbae4a7..09abe69 100644 --- a/docs/current-project-state.md +++ b/docs/current-project-state.md @@ -37,11 +37,25 @@ 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; +- **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. + +### 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.7): workspace layout, user views, loading feedback — also paused. + +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: @@ -85,7 +99,7 @@ The following were built during Experiments 18–25B. They are isolated diagnost | 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` | +| 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` | @@ -103,7 +117,7 @@ Historical documents are retained under `docs/archive/` and should be opened onl 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. +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-log.md` but is no longer default reading — load only when a specific question requires it. ## Verification Marker @@ -112,6 +126,25 @@ The current-state document was verified as accurate by focused code inspection o ## 10. Post-v0.8 Methodology Learning +### 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. diff --git a/docs/investigation-state-assessment-contract.md b/docs/investigation-state-assessment-contract.md index 0bcfccf..f166723 100644 --- a/docs/investigation-state-assessment-contract.md +++ b/docs/investigation-state-assessment-contract.md @@ -1,9 +1,18 @@ # Investigation State Assessment Contract +> **Status: Passive / Experimental Implementation** +> Implemented in code during Experiments 18–25B but does not control active user-facing investigation routing. +> This document defines the data contract that was tested; the capability remains passive. +> > Architecture Experiment 18 — First Executable Slice > > This document defines the data contract for the investigation state assessment layer. It is the interface between investigation narrative (Stage 3) and behaviour selection (Stage 5). +## Implementation status + +- **Implemented in code**: Yes — first executable slice deployed (Experiment 18). +- **Active routing authority**: No — passive experimental capability isolated from user-facing investigation. + --- ## Versioning @@ -229,4 +238,4 @@ These are tracked in `reasoning-contract-backlog.md`. ## Recording Note -This contract was drafted for Experiment 18's first executable slice. It captures the minimal viable assessment object shape derived from actual repository data contracts (schema.js, orchestrator.js, facilitator-view-adapter.js). Future experiments will add dimensions and signals as the graph schema and diagnostics evolve. +This contract was drafted for Experiment 18's first executable slice. It captures the minimal viable assessment object shape derived from actual repository data contracts (schema.js, orchestrator.js, facilitator-view-adapter.js). The capability is implemented in code but remains passive/experimental — it does not control active user-facing investigation routing. Future experiments may add dimensions and signals as the graph schema and diagnostics evolve. diff --git a/docs/investigation-state-assessment.md b/docs/investigation-state-assessment.md index 09be730..9d88eea 100644 --- a/docs/investigation-state-assessment.md +++ b/docs/investigation-state-assessment.md @@ -1,8 +1,15 @@ # Investigation State Assessment — Architectural Specification -> **Status: Implemented (Experiment 18). First executable slice deployed.** +> **Status: Passive / Experimental Implementation** +> Implemented in code during Experiments 18–25B but does not control active user-facing investigation routing. +> The capability records signals for future use; it is not current authority over the investigation path. > Design evolved through experiments; implementation validates and adjusts the spec iteratively. +## Implementation status + +- **Implemented in code**: Yes — first executable slice deployed (Experiment 18). +- **Active routing authority**: No — passive experimental capability isolated from user-facing investigation. + --- ## Purpose @@ -373,4 +380,4 @@ User Each arrow is a data flow. Each layer has a single responsibility. The assessment layer does not decide, reason, present, or converse — it describes the investigation's current state through multiple analytical dimensions so that behaviour selection can act on state rather than implementation details. -This is an emerging architectural direction. It is intentionally recorded before implementation so future experiments remain aligned. +This architectural description was captured during Experiment 18 and preserved as evidence of the assessment capability's design rationale. The capability is implemented in code but remains passive/experimental — it does not control the active user-facing investigation path. Future experiments may integrate these signals or replace them; this document records the design that was tested.