# Cycle γ D4 — graph traversal: PASS (already verified) + O(N²) build finding + cycle closure

**Date**: 2026-06-10 (final closure of the cycle γ multi-hop arc)
**Status**: D4 **does NOT run the MuSiQue multi-hop graph measurement**.
A pre-build investigation split the question into three, and the answer
re-routed the work: graph *function* is already verified (250+ unit
tests); graph *multi-hop-QA score* is Path-D over-investment; graph
*scalability* surfaced a real O(N²) finding. The multi-hop arc is closed;
graph-as-a-quality-axis belongs to the moat track (R1), not MuSiQue.

---

## 1. The three questions (the user's framing)

The D4 pre-registration assumed "graph traversal for multi-hop" was one
question. It is three, and they have different answers:

| Question | Status | Disposition |
|---|---|---|
| **① Does the graph layer work correctly?** (function) | **Already verified** — 250+ graph/entity unit tests + D4 smoke | No new measurement needed |
| **② Does graph lift the MuSiQue multi-hop *score*?** | Path-D (not the moat) + O(N²) build cost | **PASS** |
| **③ Graph build scalability** | New finding: O(N²), 8.6s→63s/para | **Record** |

## 2. Why each

### ① Graph function is already covered
Unit tests: entity alias/anchor/overlap/type/name (~85), graph
snapshot/typed_filter/path/explorer/traversal/visual (~164) = **250+
tests**. D4 smoke confirmed live entity extraction on MuSiQue prose:
"Steve Hillage … album Green … partner Miquette Giraudy" → entities
{Steve Hillage, Green, Miquette Giraudy} + relations (PRODUCES,
partner). The hop-2 entity (spouse) — what dense retrieval missed — is
captured. **The graph builds correct entities/relations.** The question
"does the graph work" is already answered yes.

### ② MuSiQue multi-hop score is the wrong vehicle
Measuring "does graph raise the MuSiQue gold-in-answer" requires building
the full graph (500 paras). It is:
- **Path-D over-investment**: multi-hop QA score is not JAMES's moat
  (`feedback_path_d_james_not_specialty_verifier`); the moat is
  replayable audit.
- **Cost-infeasible** (see ③).
So D4 does not run it. The six prior measurements already established the
multi-hop wall (unsupervised supporting selection); whether graph cracks
the *score* is a specialty-benchmark question JAMES doesn't need to win.

### ③ Graph build is O(N²) — a real finding
The build was mistakenly killed as a "hang"; it was in fact progressing
(299 entities built) but **slowing per paragraph: 8.6s → 63s**. Cause:
entity-overlap resolution (`[RESOLVE] N files updated, M relations
resolved`) scans accumulating entities each insert — superlinear. 500
paragraphs would take **hours**, not the ~71 min the single-paragraph
smoke implied.

This is the valuable, non-obvious result: **JAMES's graph build does not
scale linearly to large corpora.** Unit tests (tiny fixtures) cannot
catch it. And because the graph underpins the moat (replayable audit
reconstructs from the graph), this O(N²) build cost is a **real
constraint on the moat at data scale** — exactly the kind of thing the
moat-axis work (R1) must account for.

---

## 3. Where graph-as-a-quality-axis actually belongs — the moat (R1)

The user's instinct ("graph quality should be a JAMES quality axis") is
right; the *vehicle* is wrong. graph quality's home is **not** MuSiQue
multi-hop QA but the **replayable-audit moat**:

> JAMES's replayable audit reconstructs state from the graph. **Graph
> correctness ⇒ audit correctness.** So graph fidelity is an *input* to
> the moat axis (Replay Fidelity / Provenance Coverage, review R1), not a
> multi-hop-QA score.

When R1 (self-axis benchmark) is built, graph-reconstruction fidelity +
the O(N²) build scalability both feed it naturally. That is the right
place to measure "is the graph good", with the moat as the frame.

---

## 4. Cycle γ multi-hop arc — FINAL closure

Seven probes total (R0 / breadth / oracle / D1 / D1b / D2 / D3) + the D4
graph investigation. The arc is exhausted and closed:

- **retrieval is sufficient** (retrieve top-8 supporting recall 0.76)
- **the wall is unsupervised supporting-paragraph selection** (oracle
  72% knows gold; no real method exceeds 12%)
- **graph is the literature's answer** but: function already verified,
  score is not the moat, build is O(N²). Not pursued as a MuSiQue score.
- **the moat (replayable audit), not multi-hop QA, is JAMES's axis** —
  and graph fidelity feeds it.

**v0.5 reframing (final)**: "improve multi-hop" is not a JAMES roadmap
item. JAMES retrieval is fine; multi-hop QA is a known-hard specialty
axis; graph belongs to the moat. The next productive work is the moat
(R1) or platform hygiene (R3/R4), per the 3-track options.

---

## 5. Artifacts

| Purpose | Path |
|---|---|
| D4 pre-registration (graph traversal — not run) | `docs/research/cycle-gamma-d4-graph-traversal-preregistration-2026-06-10.md` |
| Graph build script (reusable, but O(N²) at scale) | `scripts/research/cycle_gamma_musique_graph_build.py` |
| Multi-hop arc closure (D2) | `docs/handovers/v0.4-cycle-gamma-retrieval-arc-closure-synth-is-the-lever-2026-06-10.md` |
| Multi-hop arc definitive closure (D3) | `docs/handovers/v0.4-cycle-gamma-multihop-arc-definitive-closure-2026-06-10.md` |

### Carry-forward
- partial graph (299 entities) removed from `cycle_gamma_musique_ans`;
  vector store kept (the multi-hop JSONs remain reproducible).
- graph build script preserved — reusable for a *small* fixture or once
  the O(N²) overlap resolution is addressed.
- **O(N²) graph build is a flagged constraint for the moat (R1)** — when
  replayable-audit-at-scale is measured, build cost must be in the frame.
- Process note: a build was killed as a "hang" when it was progressing
  (row-granularity logging hid per-paragraph progress). Future long
  builds: log per-paragraph, not per-row.
- Path D held: graph measured as a one-shot existing-layer check, never
  opened into multi-hop-QA tuning.
