experiment: improve semantic graph projection

Experiment 13 — Semantic Facilitator Translation

- Classify nodes by semantic role (observation, question, explanation,
  scaffolding, relationship) rather than graph kind. Scaffolding suppressed
  entirely before section routing.
- Three-tier filtering: scaffolding patterns > internal vocabulary > technical
  summary patterns. Prevents structural noise from contaminating user-facing
  sections.
- Deduplicate by normalised text — merge duplicate observations expressing the
  same finding.
- Route resolved unknowns and assumptions to known section with epistemic
  labels instead of treating them as unresolved questions.
- Prefer concrete observations (numbers, change language, temporal refs) over
  abstract labels in ranking.
- Closed Experiment 12 as confirmed. Added Experiment 13 documentation.
- Updated UX guidelines with Semantic Projection principles.
- 37 tests: filtering, classification, deduplication, ranking, framing, mock
  data integration, edge cases.

.claude/ux-guidelines.md

@@ -476,3 +476,41 @@ This section records principles for projecting graph data into human-meaningful
 
 - The same panel must remain useful during early, active and terminal investigation states.
 - Terminal state content should change its framing (e.g., "What the evidence supports" rather than "Still investigating") but not invent certainty.
+
+## Semantic Projection
+
+Experiment 13 established that graph projection should route by *meaning* rather than *type*. These are the resulting principles.
+
+### Meaning over type
+
+- Classify nodes by what they *say*, not by their kind enum. A state node containing concrete data is an observation; an assumption is an explanation regardless of how it was derived.
+- Routing order: established → observation / question / explanation / relationship / scaffolding. Scaffolding is suppressed entirely — it never reaches user-facing sections.
+
+### Suppression hierarchy
+
+Three tiers, applied top to bottom:
+
+1. **Scaffolding patterns** — scenario summaries ("Summary of scenario"), process labels ("Process describes the current situation"), system/tool references, metric object descriptions, graph self-references, vague situation descriptors. These are structural glue; the user does not need to see them.
+2. **Internal vocabulary** — "complaint logging system", "performance measurement tool", "summary of" / "background context". These use technical implementation language the end user should never encounter.
+3. **Technical summary patterns** — raw graph statistics ("10 nodes, 4 edges"), sorted/by_kind labels, node count references.
+
+### Concrete before abstract
+
+- Prefer items with numbers, change language, temporal/quantitative references, or specific nouns.
+- Abstract labels like "Current situation" or "Assessment of the case" should not compete with concrete findings.
+
+### Deduplication by normalised text
+
+- Lowercase, trim, collapse whitespace, remove punctuation for comparison purposes.
+- Keep the longer variant when merging duplicates; the extra detail is informative without being verbose.
+
+### Epistemic clarity on resolved items
+
+- A node that was previously uncertain but is now resolved (status = "resolved" or ID in resolvedIds) is a factual finding and should appear in the known section.
+- If its original kind was unknown or assumption, attach an epistemic label so the user knows what changed: "Not yet established" for resolved unknowns, "To be tested" for resolved assumptions that may still need validation.
+
+### Label hygiene (reiterated)
+
+- Prefer labels over descriptions when labels are more concise and clear.
+- Omit items too verbose to scan; do not synthesise rewritten claims.
+- Never invent facts absent from the graph.