confidence-engine/docs/archive/experiments/vol-1-chapters/ch7/experiments-42-to-46.md

Experiment 42 — Implement Narrow Acknowledge Exclusion (Variant B) (2026-08-06)

Hypothesis

Applying a narrow exclusion gate to Acknowledge — excluding it when phase is synthesising or concluding, progress is stalled, or conversation health is user_overloaded — will reduce the two identified false-Acknowledge selections (concluding → summarise, stalled → pause) without introducing any unintended behaviour changes in other tested turns.

Exact Exclusion Rule

isAcknowledgeExcluded(assessment) returns true when:

• phase.value is synthesising or concluding; OR
• progress.value is stalled; OR
• conversationHealth.value is user_overloaded.

When excluded, Acknowledge does not fire and the selector proceeds to the next priority rule. The gate qualifies the trigger; it does not replace it.

Two Changed Turns

Turn	Scenario	Phase	Progress	Health	Before	After
long-investigation t4	concluding long-investigation	concluding(high)	steady	healthy	acknowledge	summarise
contradictory-evidence t1	stalled contradictory-evidence	focusing(high)	stalled	healthy	acknowledge	pause

Five Preserved Turns

Turn	Scenario	Phase	Progress	Health	Behaviour (unchanged)
long-investigation t0	cannot_determine(low)	cannot_determine	too_narrow	continue
long-investigation t3	focusing(high)	steady	healthy	acknowledge
contradictory-evidence t0	focusing(high)	cannot_determine	healthy	acknowledge
contradictory-evidence t2	focusing(high)	steady	healthy	acknowledge
short-early t0	exploring(low)	cannot_determine	healthy	continue

Final Behaviour Distribution (7 real assessment turns)

• Acknowledge: 3
• Summarise: 1
• Pause: 1
• Continue: 2
• Clarify: 0

Integration Status

The production Behaviour Selection module (lib/behaviour-selection/behaviour-selector.js) was changed to include the isAcknowledgeExcluded() gate. However, active user-facing engine behaviour did not change because Behaviour Selection remains isolated with no runtime caller — it is exported but never imported by any code in the repository.

Clarify Status

Clarify remains unresolved and was not modified in this experiment. Its trigger conditions (health=too_broad or phase=orienting + obs<3) require states that no tested scenario produces. This remains an open question for future work.

Selector Output Shape

The selector output shape did not change. The exclusion gate returns null from selectAcknowledge, which is the existing early-return mechanism used when a rule does not match. No new fields, no restructuring of the return object.

Assessor and Fixtures

Assessor logic did not change. Fixtures did not change. Priority order did not change.

Test Results

All 151 relevant tests passed across:

• tests/behaviour-selection.test.js: 51 (no regressions)
• tests/behaviour-selection.reachability.test.js: 33 (updated for new exclusion gate)
• tests/behaviour-selection.counterfactual.test.js: 44 (from Exp 41, no changes)
• tests/behaviour-selection.real-assessment.test.js: 16 (shared fixtures intact)

Tests were not rerun as part of this documentation-only closure. The recorded result comes from the implementation commit (05d3d96).

Limitations

• Only seven real assessment turns across three scenarios were evaluated; other investigation domains may exhibit different patterns.
• health=user_overloaded is excluded by rule but never produced by any current assessor fixture — it is untested in practice.
• Clarify remains deferred because no scenario produces the narrow trigger conditions it requires.
• The selector remains isolated with no runtime caller; there is no live user-facing validation.

Result

Confirmed within the tested scenarios. Variant B correctly changes only the two intended turns and preserves all five others. No unintended side-effects were observed.

Documents Updated

• docs/design-evolution-log.md — this entry
• docs/current-handoff.md — return-to-work note replaced

Experiment 43 — Audit Clarify Readiness Signals (2026-08-06)

Hypothesis

The existing investigation-state-assessor never produces states that trigger the production Clarify rule in any tested scenario. Clarify is absent from Behaviour Selection not because of a selector defect but because no current fixture represents the genuinely unclear-scoped investigations that its triggers are designed for.

Diagnostic Test File

A focused diagnostic test was created at tests/behaviour-selection.clarify-readiness.test.js with 31 assertions auditing every turn across all existing assessor and reachability fixtures. It inspects:

• Phase value distribution (focusing, exploring, concluding, synthesising, deepening, cannot_determine)
• Conversation health values (healthy, too_narrow, too_broad, user_overloaded)
• Observation density per turn
• Clarify eligibility via the exact production rule in selectClarify

Audit Scope

Source	Scenarios	Turns Inspected
investigation-state-assessor.test.js	7	7 (one per scenario)
behaviour-selection.reachability.test.js	3	3 (contradictory-evidence t0, t1, t2)
Total	10	10 real-turn assessments

Q1 — Does the assessor ever produce too_broad?

No. Zero scenarios across all test fixtures produce conversationHealth.value === "too_broad".

The too_broad trigger requires activeUnknownCount > 3 AND resolvedNodeIds.length < 2. Every existing scenario starts with exactly one active unknown (the single unresolved question the investigation is about), and the assessor never produces a state where more than three unrelated unknowns coexist without resolution.

Q2 — Does the assessor ever produce phase.value === "orienting"?

No. Zero scenarios produce orienting. The five phase values produced by the assessor are: concluding, synthesising, focusing, exploring, deepening, and cannot_determine. orienting is not a possible output of any assessor code path. It does not appear in assessPhase().

Q3 — Does orienting ever coincide with observation density < 3?

Never applicable. Since the assessor never produces orienting, this condition cannot arise in real data. The orienting-based Clarify trigger is dead code within the tested scenarios (and likely in production until a scenario change introduces orienting).

Q4 — How many turns are Clarify-eligible?

Zero of 10 turns. Both Clarify rules evaluate to false for every assessed turn:

• Rule 1 (too_broad health): false in all 10 turns
• Rule 2 (orienting + obs<3): false in all 10 turns (orienting never appears)

Q5 — What are the closest existing signals to a genuine Clarify need?

Two signals approach clarification but do not match its intent:

Signal	Turns	Meaning	Maps to Clarify?
too_narrow health	1 (long-turn-0)	Insufficient contextual evidence for a narrow investigation	No — too_narrow means "needs more data," not "scope is unclear"
exploring phase with low obs density	1 (complete-turn-0)	Early-stage investigation with sparse observations	No — this signals the start of an investigation, not scope confusion

Q6 — Signal reliability assessment for future Clarify rule design

Signal	Reliability for Clarify intent
too_narrow health	Low reliability. It reliably indicates insufficient context for question formulation but conflates "too little information" with "unclear scope." The assessor's own description: "The investigation needs more contextual evidence before the current question can be answered effectively." This is about quantity, not clarity.
exploring + low obs density	Low reliability. It reliably indicates an early-stage investigation but does not distinguish between "well-scoped investigation in early phase" and "unclear investigation needing anchoring." Both map to exploring.

Q7 — Is Clarify's absence appropriate for current fixtures?

Yes. Every existing fixture represents a well-defined, focused investigation with a clear central statement:

• "Comparing two products before purchase decision" (single question, single dimension)
• "Evaluating European market entry" (single strategic question)
• "Evaluating $2M procurement against conflicting expert advice" (single decision context)

A genuinely unclear-scoped investigation would need one of:

• A central statement so vague the system cannot classify it into any phase
• Multiple unrelated threads at startup with no clear priority anchor
• Contradictory framing where the situation itself is ambiguous

No current fixture represents these states. Clarify's absence is appropriate because the existing scenarios are genuinely well-scoped, not because the selector is broken.

Phase Distribution Across All 10 Turns

Phase	Count	Scenarios
focusing	7	comparison t0,t1,t2; long t3; contradictory t0,t1,t2
cannot_determine	1	long t0
concluding	1	long t4
exploring	1	complete t0

No synthesising, deepening, or orienting phases observed.

Production Clarify Trigger — Exact Rule Match

// selectClarify (behaviour-selector.js lines 65-83)
function selectClarify(assessment) {
  // Rule A: broad scope detected
  if (assessment.conversationHealth.value === "too_broad") return clarify;
  // Rule B: early orientation with sparse data
  if (assessment.phase.value === "orienting" && assessment.phase.evidence?.observationDensity < 3) return clarify;
  return null;
}

Rule A trigger: conversationHealth.value === "too_broad" — zero occurrences in tested scenarios. Rule B trigger: phase.value === "orienting" — never produced by assessor; dead code path.

Focused Test Results (Experiment 43)

• Total tests: 31
• Passed: 31
• Failed: 0

All diagnostics confirm zero Clarify eligibility across the complete set of real-world fixtures.

Regression / Validation Results

Test File	Tests	Result	Notes
tests/behaviour-selection.clarify-readiness.test.js	31	✓ Pass	New diagnostic file — no regression possible
tests/behaviour-selection.test.js	51	✓ Pass	Zero regressions from any prior experiments
tests/behaviour-selection.reachability.test.js	33	✓ Pass	Clarify still eligible in 0 real turns; synthetically reachable
tests/investigation-state-assessor.test.js	51	✓ Pass	Assessor behavior unchanged

Limitations

• The audit covers all existing test fixtures but not every possible investigation domain. Different problem domains (legal disputes, medical triage, multi-party procurement) may produce different assessor states.
• too_broad requires very specific conditions (>3 active unknowns with <2 resolved) that no current fixture exercises. A fixture designed specifically to trigger it would validate the health classifier path.
• The orienting phase was never produced by any assessor code path in the entire test suite, suggesting a design gap: either orienting was removed from the assessor without updating the selector, or it was never implemented as an active phase value.

Conclusion

Clarify is absent from Behaviour Selection because no current scenario genuinely needs clarification — not because of a selector defect. The two production rules are well-formed but their trigger conditions (too_broad health and orienting phase) represent states that the assessor either cannot produce (orienting) or does not produce in any tested fixture (too_broad).

Two distinct issues identified:

1. Dead code path: The orienting-based Clarify rule never activates because the assessor produces six phase values but none is orienting. This is a design inconsistency worth correcting — either add orienting as a real phase or remove that rule from the selector.
2. Narrow trigger threshold: The too_broad condition (activeUnknownCount > 3 AND resolvedNodeIds < 2) is validly narrow but never exercised by any fixture. If Clarify should fire earlier in investigations, the threshold should be relaxed; if it should only fire for genuinely lost investigations, it should stay as-is and a dedicated fixture should validate it.

Documents Updated

• docs/design-evolution-log.md — this entry
• docs/current-handoff.md — return-to-work note replaced

Experiment 44 — Assessor Against Unclear Starting Point (2026-08-06)

Objective

Create one deliberately unclear investigation fixture and test whether the existing Investigation State Assessor produces any signal that justifies Clarify.

Hypothesis

A deliberately unclear starting scenario may expose one of three outcomes:

1. The assessor already produces too_broad.
2. The assessor produces another existing signal that reasonably represents the need to clarify.
3. The assessor has no suitable signal for unclear framing.

Fixture Description

File: tests/investigation-state-assessor.unclear-start.test.js (test-only, not imported anywhere else)

The fixture represents:

• A vague central statement that admits uncertainty: "The business feels stuck. Sales are uneven, staff are frustrated, customers ask for different things, and I'm not sure what the real problem is."
• Five competing unknown threads (customer demand, staff capacity, product direction, pricing, operations) with no priority anchor
• Only one observation (the only concrete data point)
• Zero resolved evidence nodes
• No selected question (no established direction)
• All existing graph fields only (id, label, description, kind, status, confidence, evidenceIds, dependsOn, affects, childIds)
• Five kind: "unknown" nodes and one kind: "observation" node

Returned Assessment Signals

Signal	Value	Confidence
Phase	cannot_determine	low
Phase signals	"Insufficient data for phase classification"	—
Progress	cannot_determine	low
Progress signals	"Insufficient data for progress assessment"	—
Conversation health	too_broad	medium
Health signals	"5 active unknowns with fewer than 2 resolved items"; "Investigation may be spreading too thin"	—

Detailed evidence:

• Phase evidence: resolvedNodeCount=0, activeUnknownCount=5, observationDensity=1, evidenceDepth="shallow"
• Progress evidence: turnCount=0, recentResolutionsLastTurn=0
• Health evidence: activeUnknownCount=5, resolvedNodeRatio=null, hasActiveQuestion=false

Clarify Eligibility

Clarify became eligible via Rule A. The production selectClarify rule fires because conversationHealth.value === "too_broad".

The production selector (selectBehaviour) returned:

• behaviour: "clarify"
• confidence: "high"
• reason: "Conversation health is too broad — investigation may be spreading too thin. Narrow focus through a specific clarification question."

Interpretation

Classification: assessor_recognises_unclear_start

The assessor produced too_broad from the unclear-start fixture, which directly maps to Clarify's intent (genuinely unclear scope requiring anchoring). The signal honestly reflects the starting situation: five competing unknowns with no resolved evidence and no established direction.

What the Assessor Recognised

1. Multiple active unknowns without sufficient resolution triggered too_broad health classification.
2. The assessor correctly recorded 5 active unknowns in both phase and health evidence sections.
3. Observation density (1) was correctly reported as shallow.
4. Phase confidence remained low due to insufficient data for any meaningful classification.

What the Assessor Failed to Recognise

1. orienting phase: Still not produced by the assessor. The orienting-based Clarify rule remains dead code, unchanged from Experiment 43's finding.
2. Early-stage clarification need: The too_broad trigger only fires after >3 unknowns accumulate — it does not catch a situation with fewer competing threads that is still genuinely unclear in framing.

Limitations

• Only one fixture was tested. Different vague-scenario configurations may produce different results.
• The too_broad trigger depends on having more than 3 active unknowns with fewer than 2 resolved — this specific threshold was exercised, but other boundary conditions (e.g., exactly 4 unknowns, or 5 unknowns with 1 resolved) were not tested.
• The fixture uses the assessor's existing too_broad definition which conflates "many unknowns" with "unclear scope." A genuinely unclear scenario with only 2–3 competing threads may not trigger this signal.

Status

Pending Rob's review. Experiment 43 remains closed — its conclusion that a deliberately unclear fixture was required is confirmed by this experiment, which successfully exercises the previously untested too_broad health path.

Focused Test Results

Test File	Tests	Result
tests/investigation-state-assessor.unclear-start.test.js	23	✓ Pass

Regression / Validation Results

Test File	Tests	Result	Notes
tests/behaviour-selection.clarify-readiness.test.js	31	✓ Pass	Zero regressions
tests/investigation-state-assessor.test.js	51	✓ Pass	Zero regressions
tests/behaviour-selection.test.js	51	✓ Pass	Zero regressions

Production Assessor Status

Unchanged. The assessor produced the expected too_broad signal from the unclear fixture, confirming the health classifier path works correctly. No code was modified.

Closure

Experiment 44 is closed. Conclusion: the assessor recognises an extreme unclear start; too_broad and Clarify are reachable; the useful boundary remained unknown.

---

Experiment 45 — Where Does "Too Broad" Begin? (2026-08-06)

Objective

Test how the existing assessor's too_broad threshold behaves as an unclear starting scenario grows from two competing unknowns to five, all with identical base inputs. Passive boundary experiment only — no production code changes.

Hypothesis

Active unknowns	Expected health
2	not too_broad
3	not too_broad
4	too_broad
5	too_broad

Fixture-Control Method

One test-only fixture builder creates the same vague starting situation varying only the number of competing unknowns:

• Same central statement; same single observation; zero resolved items (base); no selected question; no active direction; same node shapes and confidence values.
• Only the count of kind: "unknown" nodes differs.

Results: Two Through Five Active Unknowns

Active unknowns	Health	Confidence	Phase	Progress	Clarify eligible	Selector
2	cannot_determine	low	cannot_determine (low)	cannot_determine (low)	No	continue (low)
3	cannot_determine	low	cannot_determine (low)	cannot_determine (low)	No	continue (low)
4	too_broad	medium	cannot_determine (low)	cannot_determine (low)	Yes	clarify (high)
5	too_broad	medium	cannot_determine (low)	cannot_determined (low)	Yes	clarify (high)

Results: Four Unknowns + Resolved Items

Active unknowns	Resolved	Health	Confidence	Clarify eligible
4	0	too_broad	medium	Yes
4	1	too_broad	medium	Yes
4	2	cannot_determine	low	No

Human-Sense Review

• Two competing threads: Still appears ambiguous rather than clearly manageable. The assessor returns cannot_determine, not healthy. This is honest — two unknowns with one observation and no question genuinely leave the state unclear.
• Three competing threads: Appears ambiguous or already confused. The assessor still returns cannot_determine. This feels correct — three competing threads with minimal context is genuinely uncertain, not healthy.
• Four competing threads: Appears genuinely too broad. The transition from three (uncertain) to four (too_broad) feels believable — a real investigator would start losing focus at this point.
• Five competing threads: Clearly justifies clarification. Matches Experiment 44's result; no surprise.
• Transition between three and four: Understandable. Three threads with one observation is "not enough to decide"; four adds the tipping point where the spread becomes problematic.
• Confidence language: too_broad confidence is medium for both four and five unknowns. The signals are specific ("4 active unknowns with fewer than 2 resolved items"), so medium confidence is honest — it does not overstate certainty.

Boundary Classification

Transition	Classification	Rationale
2→3	believable	Both remain cannot_determine; the gap between "manageable" and "confused" genuinely sits around here
3→4	believable	Four competing threads with no resolution is a believable tipping point for losing focus
Resolution threshold (<2 resolved)	believable	The binary boundary (1 stays too_broad, 2 clears it) aligns with the design intent of "sufficient context to narrow"

Usefulness of Active-Unknown Count as a Proxy

Active-unknown count acts as a useful but coarse proxy for scope confusion. It works because:

1. In the tested scenarios, more unknowns directly correlates with genuine ambiguity.
2. The resolved-item gate prevents premature too_broad flags on investigations making progress.
3. It avoids subjective measurement of "how confused is the user."

However, it cannot distinguish between:

• Four unknowns about one decision (genuinely broad) versus four unknowns across a multi-decision comparison (expected).
• A well-formed investigation with natural branching versus an unfocused investigation losing its way.

Questionable or Unsupported Findings

1. Health defaults to cannot_determine rather than healthy for 2–3 unknowns. This is mechanically correct (no active question means the "healthy" rule doesn't fire) but arguably should produce healthy when the state is simply an early-stage investigation with a few threads, not just insufficient data.
2. The experiment uses synthetic boundary fixtures. These cannot validate whether a real user would feel the same confusion at exactly these thresholds. The boundary may be mechanically correct but conceptually misaligned in some domains.
3. All unknowns share identical labels and confidence values. A more differentiated scenario (some high-confidence, some low) might behave differently.

Experiment Conclusion

Current boundary is mechanically clear but conceptually uncertain.

The threshold sits exactly between three and four active unknowns. This mechanical boundary behaves predictably: no too_broad below it, too_broad above it, resolved items gate correctly. However, whether this aligns with genuine user confusion (not just code behaviour) cannot be determined from synthetic fixtures alone. The experiment confirms that Clarify switches on at the same boundary as too_broad, and that resolving two items does switch too_broad off.

Limitations

• Synthetic fixture only; no real-user validation possible from this experiment.
• All unknowns have identical shapes and confidence — real scenarios mix high/low confidence differently.
• Only one central statement used; different domains may require different thresholds.
• Does not test whether the cannot_determine health for 2–3 unknowns is a bug or a feature.

Status

Pending Rob's review. No production behaviour changed. The next logical step would be: (a) validate whether cannot_determine health for 2–3 unknowns should instead be healthy, or (b) test real-user scenarios to confirm the three→four boundary feels right in practice.

Focused Test Results

Test File	Tests	Result
tests/investigation-state-assessor.too-broad-boundary.test.js	32	✓ Pass

Regression / Validation Results

Test File	Tests	Result	Notes
tests/investigation-state-assessor.unclear-start.test.js	23	✓ Pass	Zero regressions
tests/behaviour-selection.clarify-readiness.test.js	31	✓ Pass	Zero regressions
tests/investigation-state-assessor.test.js	51	✓ Pass	Zero regressions
tests/behaviour-selection.test.js	51	✓ Pass	Zero regressions

Production Assessor Status

Unchanged. No code was modified. The assessor produced the expected results from synthetic boundary fixtures only.

---

Experiment 45 — Closure

The threshold is mechanically clear; active-unknown count is a coarse proxy; semantic coherence remained untested.

---

Experiment 46 — Does "Too Broad" Mean Too Many Questions, or Too Many Unrelated Questions? (2026-08-06)

Objective

Test whether the current too_broad assessment can distinguish between:

• several questions that all support one clear investigation; and
• several questions that belong to competing, unrelated lines of enquiry.

This is a passive diagnostic experiment. No production code changes.

Hypothesis

Two fixtures with the same number of active unknowns may receive the same too_broad result even when one is coherent and the other is genuinely scattered. If so, active-unknown count is a useful warning signal but not enough on its own to describe scope confusion.

Context Pack Used

Engine Experiment Work pack (Pack 1). Documents loaded:

• docs/current-project-state.md, docs/current-working-principles.md, .claude/architecture-guardrails.md, docs/current-implementation-verification.md
• lib/assessment/investigation-state-assessor.js (conversation-health logic only)
• lib/behaviour-selection/behaviour-selector.js (Clarify rule only)
• tests/investigation-state-assessor.too-broad-boundary.test.js
• tests/investigation-state-assessor.unclear-start.test.js
• Experiment 45 section in docs/design-evolution-log.md

No additional documents loaded.

Controlled Structural Variables

Both fixtures share identical structural properties:

• 4 active unknown nodes
• 0 resolved nodes
• 1 observation node (status=known, confidence=medium)
• No selected question
• No active direction / central decision node
• Zero edges (no dependency or relationship data)
• Total node count: 5
• Identical node shapes and confidence values

Coherent Fixture Summary

Central topic: "Should we launch the new service in the North West?"

Four unknowns all contributing to one decision:

1. Whether customer demand exists in the North West region
2. What price point the North West market would accept
3. Whether delivery infrastructure can support the North West region
4. Whether regulatory requirements allow operation in the North West

All four are legitimate, related questions about a single investigation. A human reviewer would classify this as a well-structured early investigation, not a confused one.

Scattered Fixture Summary

Central topic: "The business feels stuck and I do not know where to begin."

Four unknowns from competing, unrelated threads:

1. Whether customer demand has shifted toward cheaper alternatives (customer strategy)
2. Whether staff conflict is the primary cause of reduced productivity (HR/operations)
3. Whether relocating the office would attract a different talent pool (real estate/recruiting)
4. Whether product pricing is aligned with competitor offerings (product/marketing)

Each unknown belongs to a separate domain of enquiry. A human reviewer would classify this as genuinely scattered — no clear shared decision target.

Assessor and Selector Results

Dimension	Coherent Fixture	Scattered Fixture
Phase	cannot_determine (low)	cannot_determine (low)
Progress	cannot_determine (low)	cannot_determine (low)
Health	too_broad (medium)	too_broad (medium)
Active unknown count	4	4
Resolved count	0	0
Clarify eligible	Yes	Yes
Selector behaviour	clarify (high)	clarify (high)

Key Findings

1. Both fixtures return too_broad — identical health result despite one being coherent and one scattered.
2. Clarify becomes eligible in both via Rule A (health === too_broad). Identical eligibility.
3. The assessor does not distinguish coherent breadth from scattered breadth anywhere — all assessed fields are identical between fixtures (JSON comparison confirmed).
4. Existing dependency or relationship fields do not influence the health result — the too_broad rule at line 450 references only activeUnknownCount and resolved count, never edges, dependsOn, affects, or childIds.
5. Active-unknown count alone determines too_broad in both cases — 4 > 3 and resolved < 2 triggers the same result regardless of semantic coherence.

Human-Sense Review

• Coherent fixture: too_broad is questionable. Four unknowns contributing to one decision is breadth, not confusion. The label conflates "many questions" with "scattered focus."
• Scattered fixture: too_broad is believable. Four unrelated threads genuinely represent scope confusion. The label matches plain-English intuition.

Was Coherence Detected?

No. The assessor produces identical results for both fixtures. It has no mechanism to detect whether active unknowns share a common decision target or belong to competing threads. Only the count (4) and resolution status (0) matter.

Limitations

• Two synthetic fixtures; cannot validate against real-user scenarios or real-domain nuance.
• Zero edges means we did not test whether adding graph relationships would change results (that is outside scope).
• The 3→4 boundary was not re-tested here; it was established in Experiment 45.
• Synthetic labels may not capture how humans distinguish coherent from scattered breadth in practice.

Conclusion

Count is useful but cannot distinguish coherence. Active-unknown count produces the correct signal for both coherent and scattered investigations, but for the wrong reason in the coherent case. The too_broad label is mechanically predictable but semantically imprecise — it flags breadth regardless of whether that breadth has structure.

Questionable or Unsupported Findings

1. Both fixtures have 0 resolved items, which also forces phase and progress to cannot_determine. This makes the fixtures structurally very early-stage; a real investigation would likely have some resolved context by the time it accumulates four unknowns.
2. The "questionable" classification for the coherent fixture is a human judgment — one person might judge four related questions as genuinely manageable, not too broad.

Status

Closed. Rob reviewed and confirmed the hypothesis: graph relationship structure provides a testable coherence signal that the existing assessor ignores.

Focused Test Results

Test File	Tests	Result
tests/investigation-state-assessor.scope-coherence.test.js	47	✓ Pass

Regression / Validation Results

Test File	Tests	Result	Notes
tests/investigation-state-assessor.too-broad-boundary.test.js	32	✓ Pass	Zero regressions
tests/investigation-state-assessor.unclear-start.test.js	23	✓ Pass	Zero regressions
tests/investigation-state-assessor.test.js	51	✓ Pass	Zero regressions
tests/behaviour-selection.test.js	51	✓ Pass	Zero regressions

Production Assessor Status

Unchanged. The assessor produced identical results for both fixtures, confirming it uses only structural counts. No code was modified.