docs: clarify Confidence Engine context authority

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.