docs: clarify Confidence Engine context authority

.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;
+Current work is paused. The next step begins from the methodology question:
-- presentation;
+given the useful investigation structure the Engine can already derive, how
-- loading feedback;
+should that structure be surfaced so a person can see, choose, defer, and
-- plain-language explanations;
+return to open questions while the Engine continues to guide their thinking?
-- separation of user and developer views.
 
 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.**

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.

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.

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.

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.