Loomworks — Graph Stage 2 (Forward Walk / Dependents) — Scoping Note — v0.1

Version. 0.1 Date. 2026-07-27 Status. Scoping note. Scopes Stage 2 of the graph findings implementation strategy into one change request. Author. Claude.ai (scoping layer). Operator: Marvin Percival. Provenance. Executes Stage 2 of loomworks-graph-findings-implementation-strategy-v0_1 (loomworks-record, strategies/). Grounded against Phase 9 (shape events, shape_events_view), Phase 10 CR v0.1 (the GIN-index-on-JSONB precedent at render_events_view.render_content), the Operator-authority principle (the machine surfaces and signals; the Operator approves — carried from the seed and restated at CR-2026-154's D-1/D-3 pattern), and CR-2026-154 itself (the immediately prior stage, closed, tagged graph-hygiene-v0_1). Live-code facts — exact field names, index state, existing endpoint conventions — are to be verified by a companion step-0 inspection brief, not asserted here.

Plain-language summary

Stage 2 is the forward walk: given an assertion, find what was built from it. This note scopes one change request with two items. Item 2a is a query — find every shape event whose selected_memory_refs includes a given assertion, indexed so it doesn't scan every shape in the engagement — exposed as a dependents endpoint. Item 2b is a signal — when an assertion is superseded or retracted, the response says how many things were built from it, so the Operator finds out at the moment of the decision rather than discovering it later. Neither item does anything automatically to those dependent shapes; nothing gets invalidated, blocked, or changed. The strategy already settles that the signal is a signal, not an action — this note holds that line and asks step-0 to confirm the two things needed to build it: the exact shape of selected_memory_refs in the live schema, and where the supersede/retract responses live so 2b has somewhere to attach.

1. Decisions carried in (settled, not reopened)

• Signal, never automatic action (from the strategy and the seed's Operator-authority principle). Finding dependents never blocks a supersede or retract, never invalidates a shape, never changes any state. The Operator sees what depends on an assertion and decides what to do about it, if anything.
• Shape events only, not the full graph (from the strategy §5). Stage 2 scopes to the specific case of shape events selecting assertions via selected_memory_refs. It does not walk wasDerivedFrom, wasConsideredAndRejected, or any other relationship-vocabulary edge, and it does not walk forward from render events. Those are separately out of scope (§5).
• No dependency on Stage 1's redirect-edge or vocabulary work. CR-2026-154 closed cleanly and nothing in this item touches the relationship table Stage 1 worked in. Confirmed independence, not merely assumed — step-0 verifies selected_memory_refs is a shape-event field, not a relationship object, so the two stages don't share a write path.

2. Item 2a — Indexed dependents query and endpoint

What exists (per the Phase 9/10 pattern). Shape events carry selected_memory_refs — version-pinned MemoryRefs the shaping agent selected when producing the shape (Phase 33 CR names this field on the shape-event response schema; Phase 10's render_events_view already carries a GIN index on a JSONB column, render_content, as the in-tree precedent for indexing JSONB this way). No query today asks the inverse question: given an assertion, which shapes selected it.

What this item adds. A containment query against selected_memory_refs, indexed (GIN, following the Phase 10 precedent, on shape_events_view or the equivalent projection — step-0 confirms which view carries the field), exposed as GET /engagements/{eid}/assertions/{aid}/dependents (route shape settled in the change-request draft against the live routing conventions). Returns the shape events whose selected_memory_refs contains a ref matching the given assertion.

Version-matching semantics — the one real design decision in this item. A MemoryRef pins {id, version}. Does "dependents" mean shapes that selected this exact version, or shapes that selected this assertion at any version? The two questions matter differently: version-exact tells you what would break if this specific version's content changed; any-version tells you every shape ever built from this assertion's lineage. Recommendation for the change-request draft: any-version match on id, with the matched version surfaced per result — because the case this item exists to serve (2b, below) is exactly "an old version was just superseded; who selected the old version?", which an exact-version-only match would answer correctly but a match that silently ignored version would not. Step-0 confirms whether id-only containment is a clean query shape against the live JSONB structure or whether it needs a computed/generated column to index efficiently.

Cross-engagement note. Shape events are produced within an engagement and (per Phase 33/38 convention) select from that same engagement's Memory. Step-0 confirms selected_memory_refs never crosses engagement boundaries — if it can, that is a design question for the change-request draft, not something to improvise around (the same posture CR-2026-154 took toward the redirect edge's cross-engagement reference).

3. Item 2b — Supersede/retract surfaces the signal

What exists. The seven terminal states include retire (retract) and presumably a supersession path (the exact terminal-state name and route are step-0's job to confirm — the scoping note does not assume "supersede" is itself a terminal state distinct from a new version's attest). Today, superseding or retracting an assertion returns success with no visibility into what was built from it.

What this item adds. The supersede/retract response gains a dependents summary — at minimum a count, and the change-request draft decides (against step-0's findings on response-schema conventions, e.g. Phase 33's activity-observability pattern) whether to include the full list inline or point to the item 2a endpoint. This is the one attach point in this item; it is additive to an existing response, not a new state machine.

What this item is not. Not a block. Not a warning dialog. Not a required confirmation step. Not a change to any terminal state's semantics. The Operator retracts or supersedes exactly as today; the response now tells them more.

Dashboard integration — explicitly deferred, named so the boundary is visible. Phase 39's needs_you pattern is the natural home for "an assertion you retracted has dependents" as a standing item, not just a point-in-time response field. This note does not commission that integration — it is real but separable work, and folding it in risks the same shape the strategy warned against for Stage 2 generally: scope creep from "signal" toward "workflow." If the Operator wants it, it is a small follow-on CR against 2b's summary field, not an addition to this one.

4. Sizing and sequencing

• Size. Medium, per the strategy §5, one change request. 2a is one indexed query plus one endpoint. 2b is one response-schema addition at the supersede/retract route(s) plus a call to 2a's query.
• Sequencing. No blockers. Stage 1 (CR-2026-154) is closed and does not gate this. The engine suite's standing gate carries forward unchanged: no new failures; the Stele router-mount failure remains waived per its own front note, unrelated to this surface.
• Migration expectation. Likely one — the GIN index itself, if selected_memory_refs isn't already indexed on the view step-0 identifies. No new tables, no new event kinds, no schema change to the JSONB payload shape. If step-0 surfaces anything larger, that is a finding to report, not absorb.
• Split rule. None anticipated — 2a and 2b are small enough and sequential enough (2b calls 2a's query) that splitting would add coordination overhead without a clear boundary to split on. If step-0 finds the supersede/retract route to be in the middle of other active work (unlikely, but Stage 1's discipline says check rather than assume), that becomes a halt-and-report finding for the change-request draft.

5. Out of scope

• Stages 3 (as-of-a-date reads) and 4 (hybrid retrieval).
• Walking any relationship-vocabulary edge (wasDerivedFrom, wasConsideredAndRejected, etc.) — that graph already exists per Stage 1's work; walking it forward is a different, larger piece the strategy does not fold into Stage 2.
• Forward walk from render events (what was rendered from a given shape) — a natural sibling question, not this item's scope. If wanted, it is symmetric follow-on work against render_events_view rather than an extension of 2a.
• Any automatic action on dependents: no invalidation, no blocking, no forced re-confirmation.
• needs_you dashboard integration (§3, named as deferred, not designed against).
• Supersession severity — if 2b's dependents count surfaces a case where "how bad is this dependency" feels like it needs a severity distinction, file the finding; do not absorb it here (the same posture Stage 1 took on its own supersession-severity question).

6. Next steps

1. Claude Code runs a companion step-0 inspection brief against the live engine tree: confirms selected_memory_refs' live field name and containing view/table, confirms existing GIN index state, confirms the supersede/retract route(s) and their current response schemas, and confirms the cross-engagement question in §2.
2. The change-request draft is produced against those findings, in a fresh chat per the standing two-role discipline, with a change-request number assigned from the current sequence in loomworks-record at drafting time.
3. Standard loop from there: Operator review, Claude Code execution, halt-before-push.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Graph Stage 2 (Forward Walk / Dependents) — Scoping Note — v0.1 — 2026-07-27