confidence-engine/docs/archive/experiments/vol-1-chapters/ch8/experiments-47-to-51.md

Experiment 47 — Shared-Anchor Coherence Diagnostic (2026-08-06)

Objective

Test whether existing graph relationships (dependsOn, affects, parentId, childIds on nodes; fromNodeId/toNodeId + relationship on edges) can distinguish coherent investigations (multiple unknowns sharing one anchor) from scattered investigations (multiple unknowns with separate anchors). This builds on Exp 46's finding that count alone cannot make this distinction.

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

Hypothesis

An existing SituationGraph for a coherent investigation will show a structural pattern — multiple unknown nodes referencing the same anchor node — that does not appear in scattered investigations where each unknown references a different anchor or no anchor at all. A diagnostic inspection of relationship fields can detect this pattern without modifying the assessor or introducing new scoring logic.

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 (to verify assessor output)
• tests/investigation-state-assessor.scope-coherence.test.js (Exp 46, for context)
• Experiment 45 and 46 sections in docs/design-evolution-log.md

No additional documents loaded.

Three Controlled Fixtures

Property	Fixture A (shared)	Fixture B (separate)	Fixture C (none)
Nodes	6 (1 obs + 1 ctx + 4 unk)	6 (1 obs + 1 ctx + 4 unk)	6 (1 obs + 1 ctx + 4 unk)
Edges	5	1	0
Active unknowns	4	4	4
Resolved	0	0	0
Observations	1	1	1
Relationship pattern	All unknowns reference ctx-1	Each unknown references ctx-1 differently (or not at all)	No relationship fields populated
Diagnostic result	shared_anchor → [ctx-1]	separate_anchors → [ctx-1]	insufficient_data → []

Relationship Fields Inspected by the Diagnostic Helper

The test-only helper inspectSharedUnknownAnchor inspects:

1. dependsOn on unknown nodes — direct dependency to an anchor
2. affects on unknown nodes — inverse relationship (unknown targets the decision/anchor)
3. parentId on unknown nodes — hierarchical parent reference
4. childIds on existing nodes — inverse child reference from anchor side
5. Edge fromNodeId/toNodeId + relationship — directional support edges between unknowns and anchors

The helper collects all referenced node IDs from these fields across all active unknowns, checks for a common intersection (shared_anchor), separate union (separate_anchors), or no data (insufficient_data).

Existing-Scenario Results

Inspected three real scenarios from Experiments 39-46:

• comparison-turn-2 (Exp 39/41/45 path): insufficient_data — fewer than two active unknowns
• long-turn-3 (Exp 45 path): insufficient_data — fewer than two active unknowns
• live-ollama-state (Exp 46 test shape): insufficient_data — fewer than two active unknowns

All three return insufficient_data, confirming that real investigation data so far lacks the relationship structure needed for coherence detection. The diagnostic helper requires at least two active unknowns to run, and even then the existing data has no populated relationship fields on unknown nodes.

Assessor Output Identity Verification

All three fixtures produce identical assessor output because:

1. Identical total node count (6) → same scoreToConfidence(totalNodes)
2. Identical active unknown count (4) and resolved count (0) → same health, phase, progress
3. The assessor does not inspect any relationship fields in its too_broad rule

Key Findings

1. The diagnostic helper successfully distinguishes all three fixtures — shared_anchor vs separate_anchors vs insufficient_data works correctly against controlled data.
2. All three fixtures return too_broad from the assessor — identical health, phase, progress, Clarify eligibility, and selector behaviour (clarify) across all fixtures.
3. Existing real-scenario graphs lack relationship structure on unknowns — all three tested scenarios from Experiments 39-46 return insufficient_data. Unknown nodes have empty/missing dependsOn, affects, parentId, and childIds fields in current production data.
4. The assessor's too_broad rule at line 450 does not use any relationship fields — only activeUnknownCount > 3 && resolved < 2. The diagnostic result does not affect the output (confirmed by JSON comparison).

Limitations

• One test-only helper; no production integration attempted or required.
• Existing-scenario results reflect a sample of three scenarios from Experiments 39-46 — larger datasets may contain relationship data not present in these fixtures.
• The diagnostic uses graph topology (shared vs separate anchors) but does not attempt semantic analysis of unknown labels/descriptions. Coherence may have additional signals beyond structural sharing.
• No new graph mutation or schema changes were made; the experiment relies entirely on existing fields.

Conclusion

A coherence signal exists in the data model. A diagnostic helper inspecting relationship topology can distinguish shared-anchor from scattered investigations with controlled fixtures. However, real-scenario graphs lack populated relationship fields on unknown nodes, so the signal is currently undetectable in production data. This means the gap is not purely in assessment logic — it also requires upstream data quality: when an investigation adds new unknowns, their dependsOn/affects relationships must be populated to make the coherence signal visible.

Status

Pending Rob's review. No production code or graph schema modified.

Focused Test Results

Test File	Tests	Result
tests/investigation-state-assessor.shared-anchor.test.js	26	✓ Pass

Regression / Validation Results

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

Production Assessor Status

Unchanged. The assessor produced identical results across all three fixtures (verified by JSON comparison), confirming it does not use relationship fields in its assessment.

Experiment 48 — Audit Unknown Relationship Population (2026-08-06)

Experiment 48 was a passive implementation audit asking whether the active graph-construction path actually populates relationship information on unknown nodes that could later support a shared-anchor coherence check (the signal discovered in Experiment 47).

Constraints: No production code changes. No schema changes. No assessor or test modifications. Only one new test file created. Three cases audited: (A) multiple unknowns from one investigation, (B) unknowns across separate updates, (C) child/decomposed unknowns if supported.

Audit Findings

Production Path	Populates dependsOn?	Populates affects?	Populates parentId?	Edges Created?
Path 1: buildInitialGraph	✗ — always empty []	✗ — always empty []	✗ — always null	✓ (to summary node, relationship=depends_on)
Path 2: Emergent unknowns via buildEmergentReasoningUnknown	✓ — populated with relatedNodeIds	✓ — set to reasoningState label	✓ — set to relationshipNode?.id ?? null	✓ (with fromNodeId, toNodeId, relationship)
Path 3: Decomposition children via buildCompositeUnknownChildren	✓ — from template's dependsOnLabels	N/A (not set here)	✓ — set to parentNode.id	✓ (with relationship)

Additionally, applyGraphUpdate() auto-creates/updates dependsOn and childIds arrays when edges are added (schema enforcement), but does NOT populate affects or parentId.

Focused Test Results

Test File	Tests	Result
tests/graph/unknown-relationship-population.test.js	16	✓ Pass

Case A (multiple unknowns from one investigation): 3 unknown nodes created. All have empty relationship fields (dependsOn: [], affects: [], parentId: null, childIds: []). Edges exist to summary node. Diagnosis: insufficient_data for shared-anchor detection.

Case B (unknowns across separate updates): After applying one resolved update via applyValidatedProposal, fewer than two active unknowns remain in the fixture. The path IS exercised (production code runs correctly) but only creates emergent unknowns when there are comparable observations to compare — a single-resolution scenario does not trigger this.

Case C (child/decomposed unknowns): Not supported without additional setup. Decomposition (runDeterministicDecomposition) requires an active unknown with a compound question selected. Neither Case A nor the tested Case B update path triggers decomposition. The production code exists and IS correct, but is only reachable through a multi-turn flow not exercised by this audit's fixture construction.

Answering the Seven Questions

1. Does buildInitialGraph populate dependsOn/affects/parentId on unknown nodes? No — all three are empty/null. Only edges exist linking unknowns to summary node.

2. Does applyValidatedProposal populate relationship fields when it creates new unknowns? Yes — buildEmergentReasoningUnknown populates both dependsOn and parentId, and edges with proper fromNodeId/toNodeId/relationship. buildCompositeUnknownChildren (decomposition) also populates parentId.

3. Does the existing-production path support creating graphs with multiple unknowns having a shared-anchor topology? Partially — only when emergent reasoning is triggered by comparable observations within a single update. Initial graph build does not produce shared anchors. Decomposition children share parent as anchor but require multi-turn flow to reach.

4. Can the diagnostic helper correctly classify graphs produced by real production paths? Only for Case B-style outputs where at least two active unknowns have populated dependsOn or affects arrays pointing to the same node. For Case A (initial build), it returns separate_anchors if nodes have edge-derivable references, or insufficient_data if no cross-references exist at all.

5. Which production path creates usable shared-anchor data? Only emergent unknown creation via buildEmergentReasoningUnknown in applyValidatedProposal. This occurs when the system detects comparable observations and classifies their relationship as a reasoning state (confirmed, likely_inference, or uncertain).

6. Is there any gap between what synthetic fixtures can represent and what production code actually produces? Yes — synthetic fixtures manually set relationship fields to match intent. Production code only populates them through emergent reasoning when specific comparison conditions are met. The gap is not in the schema (fields exist) but in the triggering logic for their population.

7. What data quality improvement enables shared-anchor detection? Ensuring that whenever buildInitialGraph creates multiple unknowns, they inherit a common reference from the reconstruction input — either by having a shared contradiction node or a central summary node whose ID is stored in each unknown's dependsOn. Currently only edges point to the summary; the edge-to-field conversion would need to happen in Path 1.

Evaluation Conclusion

Insufficient Data — The production path does populate relationship fields correctly when it creates emergent unknowns (Path 2), but shared-anchor detection requires at least two active unknowns with shared references, and the initial build path (Path 1) produces empty relationship fields exclusively. Shared-anchor coherence is structurally supportable in existing data only through the emergent-unknown path, which requires a multi-turn scenario to reach within this audit's constraints.

Pending Rob's review. No production code or graph schema modified.

Commit: pending (experiment: audit unknown relationship population)

Experiment 49 — Test Production Shared-Anchor Pattern (2026-08-07)

Experiment 49 asked whether any sequence of real production updates creates two or more active unknowns that reference the same populated relationship anchor. No production code changed. Only a new test file and diagnostic.

Approach

Three production-path scenarios tested via applyValidatedProposal:

• Case A: Start with comparable observations + existing unknown → resolve it (triggers emergent reasoning) → then resolve the next active unknown → inspect for shared anchor between remaining unknowns.
• Case B: Identical approach from a separate fixture baseline.
• Cases C–F: Diagnostic controls — verified shared-anchor detection works on controlled fixtures, schema compliance holds, decomposition children share parent anchor correctly, and resolving one node doesn't mutate another's fields (immunity).

Results

All 36 tests pass. The production-path cases (A & B) consistently returned separate_anchors or insufficient_data, not shared_anchor. Key observations:

• After first update in both Cases A and B: only one active unknown typically remains — the diagnostic correctly returns insufficient_data (< 2 active).
• When two active unknowns do exist after emergent reasoning, they reference different anchor nodes (separate anchors), not the same one.
• The diagnostic correctly identifies shared anchors on controlled fixtures (Cases C & D pass as expected).
• Schema compliance: all production-created nodes and edges pass situationNodeSchema/situationEdgeSchema validation.

Why No Shared Anchor Emerges

The production flow creates at most one emergent reasoning unknown per update, via buildEmergentReasoningUnknown. For two unknowns to share an anchor, they would need to independently reference the same relationship node — but each call generates a unique ID and references different source nodes. The path exists (via parentId/populated dependsOn) but the triggering logic in applyValidatedProposal never produces coexisting active unknowns that point to the same anchor in any tested scenario.

Answering the Seven Questions

1. Can two active unknowns share an anchor via production updates? No — not in any tested sequence. Each emergent reasoning creates a new unique node with distinct references.

2. Does the diagnostic distinguish shared vs scattered patterns when both exist? Yes (Cases C, D confirm). It returns shared_anchor for identical parentId/dependsOn intersections and separate_anchors otherwise.

3. Is shared-anchor detection structurally possible in existing data? Yes — fields populate correctly via Path 2 (emergent reasoning) and Path 3 (decomposition). The gap is not capability but triggering conditions.

4. What production sequence would be needed to test this further? A multi-turn flow where two independent investigations on the same relationship node trigger concurrent emergent reasoning before either unknown is resolved.

5. Which production path creates usable shared-anchor data? Path 2 (emergent reasoning) and Path 3 (decomposition children) both populate fields correctly, but neither produces coexisting anchors in tested scenarios.

6. Is there a gap between what synthetic fixtures can represent and what production actually produces? Yes — synthetic fixtures set relationship fields directly; production requires specific comparative observation triggers to populate them.

7. What data quality improvement enables shared-anchor detection? The existing emergent-reasoning path already works. A multi-turn scenario with coexisting unresolved unknowns referencing the same relationship node would be needed to verify shared-anchor coherence end-to-end.

Evaluation Conclusion

No shared anchor found in production update sequences tested. Both Cases A and B returned separate_anchors or insufficient_data. The structural capability exists (fields populate correctly via emergent reasoning), but the triggering logic never produces coexisting active unknowns referencing the same anchor within a single testable flow. Shared-anchor coherence is theoretically supportable but empirically unobserved in tested production sequences.

Test Results Summary

Test File	Tests	Passed
shared-anchor-production-path.test.js (Exp 49)	36	36
unknown-relationship-population.test.js (Exp 48)	16	16
investigation-state-assessor.shared-anchor.test.js (Exp 47)	26	26

Pending Rob's review. No production code or graph schema modified.

Commit: pending (experiment: test production shared-anchor pattern)

Experiment 50 — Are Shared Graph Edges Meaningful Coherence, or Just Generic Wiring? (2026-08-07)

Experiment 50 tested whether the shared edge structure created by buildInitialGraph tells us that unknowns belong to one coherent investigation, or merely reflects standard graph construction plumbing. This was a passive diagnostic — no production code changed.

Approach

Two test-only reconstruction inputs passed through the identical real buildInitialGraph path:

• Case A (Coherent): One clear decision ("expand into North West") with four domain-aligned unknowns (demand, pricing, delivery capacity, regulatory requirements).
• Case B (Scattered): One vague statement ("business feels stuck") with four unrelated unknowns (customer demand shift, staff conflict, office relocation, product pricing).

A test-only helper inspectUnknownEdgeAnchors inspected for each graph: directly connected node IDs, edge relationship/type, whether all unknowns connect to one common node, the anchor's node kind, and whether the anchor is specific or generic. Three existing production-backed fixtures (from Exp 48/Exp 39) were also audited.

Coherent Input Edge Result

• Unknown count: 4
• Edge count: 4 (one depends_on per unknown)
• Common edge anchor: one node, kind=state, label = reconstruction.summary
• Diagnostic result: shared_generic_anchor
• Node-level relationship fields: all empty (dependsOn=[], affects=[], parentId=null)

Scattered Input Edge Result

• Unknown count: 4
• Edge count: 4 (one depends_on per unknown)
• Common edge anchor: one node, kind=state, label = reconstruction.summary
• Diagnostic result: shared_generic_anchor
• Node-level relationship fields: all empty (dependsOn=[], affects=[], parentId=null)

Cross-Case Comparison

Both coherent and scattered inputs produced identical edge topology: every unknown connects via a depends_on edge to the same summary node. The anchor is always kind=state. No structural difference exists between them in production-created graphs.

Common Anchors Found

In all cases tested (both Exp 50 cases plus three existing production-backed fixtures), shared anchors are summary/situation nodes created from reconstruction.summary. Kind is always state. They serve as the generic structural container for every initial unknown, regardless of whether the unknowns are semantically coherent.

Common Anchor Node Types

state — this is the reconstruction summary node. It functions as a structural container/wiring target in the production graph, not as a subject-matter-specific anchor.

Edge Relationship Labels Observed

depends_on (from unknown → summary) and supports (from observation/state → summary). Neither label carries semantic coherence information.

Node-Level Relationship Fields Observed

Empty from buildInitialGraph: all active unknowns have dependsOn: [], affects: [], parentId: null. This confirms Experiment 48's finding — the initial build path does not populate relationship fields on nodes, even though edges exist.

Did Coherent and Scattered Cases Differ Structurally

No. Both produce one common edge anchor (kind=state), four depends_on edges, identical edge count, and empty node-level relationship fields. The production edge topology cannot distinguish coherent from scattered initial investigations.

Would Shared-Edge Detection Create False Positives

Yes — if treating any common edge as coherence evidence were applied, the scattered case ("business feels stuck" with unrelated threads) would produce the same signal as the coherent case ("North West expansion"). This is a false positive for coherence.

Existing Production-Backed Fixtures Inspected

Three fixtures from existing Exp 48 and builder.test.js tests containing multiple unknowns:

1. builder.test.js standard two-unknown scenario (revenue/complaints)
2. Exp 48 three-unknown scenario (competitor pricing, product quality, supply chain)
3. Exp 48 two-unknown scenario (demand for expansion, pricing strategy)

Existing-Fixture Results

All returned shared_generic_anchor with one common edge anchor of kind=state. Node-level fields were empty in all cases. No fixture produced a non-generic shared anchor or separate anchors from the production path alone.

Questionable or Unsupported Findings

The test-only helper distinguishes generic summary nodes from specific anchors by node kind — this works for state vs relationship/other kinds, but if production ever creates a relationship-kind summary node, the heuristic would need refinement. No such case exists in current production.

Experiment Conclusion

Production edges provide only a generic shared anchor. Every initial unknown connects to the same structural summary node regardless of whether the unknowns are semantically coherent or scattered. Shared edge connectivity is wiring, not evidence of coherence. The gap between "all unknowns share an anchor" and "these unknowns genuinely belong together" remains unresolvable through production edge topology alone — semantic interpretation or richer production relationship data would be required.

Test Results Summary

Test File	Tests	Passed
initial-edge-coherence.test.js (Exp 50)	26	26
shared-anchor-production-path.test.js (Exp 49)	36	36
unknown-relationship-population.test.js (Exp 48)	16	16
builder.test.js (focused regression)	32	32

Pending Rob's review. No production code or graph schema modified.

Commit: pending (experiment: test initial graph edge coherence)

---

Experiment 51 — Is Coherence Relative to the Decision, Rather Than the Graph Shape? (2026-08-07)

Experiment 51 tested whether an explicit decision target provides a more useful coherence signal than raw graph structure. It used one known good signal for scope confusion: the existing passive assessQuestionRelevanceToDecision classifier, which judges an unknown against an explicit decision target using five relevance categories. No production code changed.

Hypothesis

When an explicit decision target is supplied, coherent unknowns should all show meaningful relevance to that decision, while scattered unknowns should contain some classified as irrelevant. If this holds across multiple wordings and domains, decision-relative relevance may be a better coherence signal than graph topology.

Decision Target Used

Domain 1: "Should we enter the European market with our SaaS analytics platform?" Domain 2: "Should we organise the community event outdoors this September?"

Coherent Unknown Set — Domain 1 (European Market)

Four unknowns all contributing to one decision:

• demand: "Whether to enter the European market for analytics tools"
• compliance: "Whether our product is suitable for European compliance requirements"
• cost-benefit: "Whether the cost of achieving compliance is justified by the potential market size"
• differentiation: "Whether we have competitive differentiation against existing European players"

Scattered Unknown Set — Domain 1 (European Market)

Four unknowns with mixed relevance:

• scat-demand: "Whether we should enter the European market for analytics tools"
• scat-staff-conflict: "Can two senior staff members resolve their ongoing disagreement?"
• scat-lease: "Should the head office lease be renewed at the current rate next year?"
• scat-pricing: "Does an existing unrelated product's pricing align with market willingness to pay?"

Coherent-set Relevance Results — Domain 1

Unknown	Classification	Reason (pattern matched)
demand	could_change_decision	DECISION_REVERSAL_PATTERNS ("Whether to enter")
compliance	supports_decision	PRECONDITION_PATTERNS ("product is suitable for ... compliance requirements")
cost-benefit	supports_decision	FEASIBILITY_PATTERNS ("cost of achieving compliance is justified")
differentiation	supports_decision	SUPPORTING_CONTEXT_PATTERNS ("competitive differentiation against existing")

All four coherent unknowns received meaningful decision-relative classifications (not cannot_determine). One could_change_decision, three supports_decision. Multiple distinct categories produced. Every result included a non-empty reason.

Scattered-set Relevance Results — Domain 1

Unknown	Classification	Outcome
scat-demand	could_change_decision	Unintended: matches DECISION_REVERSAL_PATTERNS ("enter")
scat-staff-conflict	cannot_determine	Correctly rejected (no pattern match)
scat-lease	cannot_determine	Correctly rejected (no pattern match)
scat-pricing	cannot_determine	Correctly rejected (no pattern match)

Three of four scattered unknowns were correctly identified as irrelevant (cannot_determine). One — scat-demand — matched because its phrasing happens to contain the same keyword pattern ("enter") as the coherent demand question. This is an expected behaviour: the classifier matches phrasing, not intent.

Unrelated Questions Correctly Rejected

• Staff disagreement: cannot_determine
• Head office lease renewal: cannot_determine
• Unrelated product pricing: cannot_determine

Unrelated Questions Incorrectly Treated as Relevant

• "Whether we should enter the European market for analytics tools" — matched DECISION_REVERSAL_PATTERNS because it contains "Whether to/should enter". This is a phrasing match, not a coherence signal. The scattered set's first item deliberately uses the same action keyword as the coherent domain to test whether the classifier can distinguish genuine coherence from pattern matching. It cannot.

Second-domain Decision Target Used

"Should we organise the community event outdoors this September?"

Second-domain Results — Coherent Set

Unknown	Classification	Outcome
evt-weather	cannot_determine	Failed: "weather risk" not in demand keywords
evt-insurance	cannot_determine	Failed: no precondition pattern match
evt-capacity	cannot_determine	Failed: generic capacity language
evt-accessibility	cannot_determine	Failed: no compliance/mandatory keyword match

All four coherent unknowns received cannot_determine. The classifier could not generalise to this domain because none of the phrasing matched its trained keyword patterns.

Second-domain Results — Scattered Set

Unknown	Classification	Outcome
scat-evt-weather	cannot_determine	Consistent with coherent weather result
scat-board-chairs	cannot_determine or unlikely_to_change_decision	Correctly rejected
scat-volunteer	cannot_determine or unlikely_to_change_decision	Correctly rejected
scat-local-park	cannot_determinate or unlikely_to_change_decision	Correctly rejected

Coherent Paraphrase Result

Original: "Whether sufficient customer demand exists in the North West" Paraphrase: "Would enough people there actually want what we offer?"

The paraphrase produced cannot_determine. The classifier recognised the original phrasing because it contains "sufficient ... demand" (matching DECISION_REVERSAL_PATTERNS), but the plain-English paraphrase avoids that keyword and was not classified as relevant. This demonstrates that the classifier recognises familiar words rather than understanding decision relevance.

Unrelated Paraphrase Result

Original: "What benchmarks do other SaaS companies use for market sizing" Paraphrase: "Which analytics firms set the industry standard?"

Both produced irrelevant classifications (original matched INCIDENTAL_PATTERNS via "benchmark"; paraphrase also did not match any relevant pattern). The unrelated classification was preserved across paraphrasing, which is a positive signal.

Language Sensitivity Observed

Extreme. The classifier is entirely keyword-matching with zero semantic understanding:

• Within vocabulary (European market entry): works as expected by Exp 21 test patterns
• Different domain (community event): all four coherent unknowns classified as cannot_determine despite being genuinely relevant to the decision
• Paraphrased language: coherent original classified as relevant, paraphrase as cannot_determine — same underlying question, different results
• The decision target is only used for a binary action-keyword gate ("enter/launch/build/stop/abandon" present or not). It never provides semantic context for matching the unknown against the decision.

Comparison with Experiment 50 Graph-topology Result

Both experiments reached the same fundamental conclusion about their respective signals: neither graph topology nor decision-relative keyword matching can reliably distinguish coherent from scattered breadth.

• Exp 50: every unknown connects to the same generic state node regardless of semantics
• Exp 51: classification depends on phrasing keywords, not on whether the unknown actually matters to the stated decision

Experiment Conclusion

Decision-relative relevance is promising but language-sensitive. Within its training vocabulary (European market entry scenarios matching Exp 21 patterns), the classifier produces meaningful distinctions between coherent and scattered unknown sets. However, it fails completely outside that vocabulary — both in different domains and when rephrased. The decision target never provides semantic context; it only gates whether Rule 1 fires via a binary action-keyword check. This is not coherence detection. It is keyword pattern matching dressed as decision relevance.

Questionable or Unsupported Findings

The classifier's behaviour within its training vocabulary may be coincidental rather than principled. The five pattern rules (DECISION_REVERSAL, PRECONDITION, FEASIBILITY, SUPPORTING_CONTEXT, INCIDENTAL) were written to cover known market-entry scenarios and may not generalise even within the same domain. The test confirms they work for those specific cases only.

Focused Test Result

Test File	Tests	Passed
decision-relative-coherence.test.js (Exp 51)	45	45
question-decision-relevance.test.js (Exp 21 regression)	25	25

Regression / Validation Result

All existing Exp 21 tests pass. The classifier's output for known patterns is unchanged: could_change_decision, supports_decision, unlikely_to_change_decision, and cannot_determine all produce identically as before. No production behaviour changed.

Documentation Updated

• docs/design-evolution-log.md: Experiment 50 closed; Experiment 51 added
• docs/current-handoff.md: Return-to-work note updated

Confirmation Production Decision-Relevance Classifier Remained Unchanged

The classifier source was read for context only. No edits were made. Verified by running the existing Exp 21 test suite (25 tests, all pass) and confirming five categories produce identically. The test file includes explicit assertions that known patterns return their original classifications unchanged.

Confirmation Assessor and Behaviour Selection Remained Unchanged

No assessor files were loaded or modified. No Behaviour Selection files were loaded or modified. The experiment uses only the decision-relevance classifier directly.

Confirmation Graph Schema and Construction Remained Unchanged

No schema or builder files were loaded or modified. The experiment tests classifier output, not graph topology.

Confirmation Existing Fixtures Remained Unchanged

No fixtures were loaded, read, or modified. All unknowns in this test are constructed inline via makeUnknown.

Confirmation Active Engine Behaviour Remained Unchanged

The decision-relevance classifier has no callers outside its own module (verified in Exp 28 implementation-verification). No active user-facing behaviour changed.

Correction to Experiment 51 Interpretation

During this session, one labelling interpretation from Experiment 51 was corrected:

The item "Whether we should enter the European market for analytics tools" was listed as part of the scattered set (DOMAIN_1_SCATTERED.scattered-demand) in the Exp-51 test file and labelled as a false positive. This is incorrect. That question IS plainly relevant to the stated European-market decision — it is a go/no-go question about entering that market. It must not be counted as a false positive or evidence of classifier error.

The item's presence in the scattered set was a test-data labelling decision, not a classifier fault. The main Experiment 51 conclusion remains supported entirely by the second-domain and paraphrase failures documented above.

Status: Pending Rob's review.