Loomworks — Graph Hygiene Change Request — Scoping Note — v0.1

Version. 0.1 Date. 2026-07-27 Status. Scoping note. Scopes Stage 1 of the graph findings implementation strategy into one change request. Author. Claude.ai (scoping layer). Operator: Marvin Percival. Provenance. Executes Stage 1 of loomworks-graph-findings-implementation-strategy-v0_1 (loomworks-record, strategies/). Grounded against Phase 17 CR v0.2 (redirect mechanism), Phase 10 and Phase 28 CRs (relationship vocabulary), Loom Protocol v0.1 §3 (rejection-relationship semantics), and CR-2026-100 (Companion recall read paths). Live-code facts are verified by the companion step-0 inspection brief, not asserted here.

Plain-language summary

This note scopes one change request with four items: the redirect edge with backfill (1a), the relationship-vocabulary single-source refactor (1b), the rejection producer via contribution-time alternatives (1c, Option B as decided), and the supersession-aware answering rule (1d). All four are engine-side; 1c adds one contribution-surface touch. The Operator has already decided Option B, backfill yes, candidates parked in queued-directions, and recall reframe not commissioned — those decisions are carried in, not reopened. The split rule stands: if step-0 shows 1c is bigger than small, 1c becomes its own change request and this one ships with 1a, 1b, and 1d. The next steps are: Claude Code runs the step-0 inspection brief, then the change-request draft is produced against its findings.

1. Decisions carried in (settled, not reopened)

• Option B for the rejection producer. The wasConsideredAndRejected edge is written at contribution time when alternatives are attached, not by a new consideration terminal state. The seven terminal states (attest, promote, amend, retire, escalate, no-change, deliberate-exception) are untouched.
• Backfill yes for the redirect edge. Existing redirects gain the edge retroactively from their metadata keys.
• The three build-queue candidates are parked in queued-directions. Nothing in this change request depends on them.
• The recall reframe is not commissioned. Nothing in this change request anticipates Stage 4. Item 1d's state filter is written so Stage 4 can later reuse it as a hard filter, but no retrieval work is done here.

2. Item 1a — Redirect writes an edge

What exists (per Phase 17 CR v0.2). Redirect is a composed operation: retract in the source engagement, add-as-held in the target. The target assertion's metadata carries redirect_from_engagement_id, redirect_from_assertion_id, redirect_from_engagement_name. No relationship object is written; the link is invisible to graph traversal.

What this item adds. At redirect time, after the target assertion is created, write a wasDerivedFrom relationship from the target assertion to the retracted source assertion, with a qualifier marking the derivation kind as redirect (for example {"derivation": "redirect"} — exact key settled in the change-request draft against the existing qualifier conventions step-0 reports). The metadata keys stay; the edge is additive, not a replacement. Corrections preserved, not smoothed — the metadata is the historical mechanism and remains readable.

Backfill. An idempotent script following the Phase 28 relationship-script pattern: find all assertions carrying redirect_from_assertion_id in metadata, write the edge where absent, skip where present. Runs against live engagements. Step-0 reports the current redirect count so the change-request draft can size the run and name the verification query.

Cross-engagement note. Source and target live in different engagements. Step-0 must confirm whether the relationship model admits a cross-engagement target reference and whether a relationship may target a retracted assertion. If either is structurally blocked, that is a halt-and-report finding for the change-request draft, not something to improvise around.

3. Item 1b — Single-source the relationship vocabulary

What exists (per Phase 10 CR, "at all four locations per Phase 5/9 convention"). The vocabulary Literal union is duplicated across multiple definition sites, synced by hand. It has grown to at least thirteen values through Phase 28's explains and Phase 10's declaresShapeType / declaresRenderType.

What this item does. Move the vocabulary to one definition site (a single tuple or Literal alias in one module) imported everywhere it is used. Pure refactor: no vocabulary value added, removed, or renamed; no behavior change; existing tests pass unchanged, plus one new test asserting the definition sites agree (or that only one exists).

Step-0 dependency. The "four locations" count predates the Stele extraction and the namespace rename. Step-0 greps the live tree for every site and reports the actual count and paths. The change-request draft names each site explicitly.

4. Item 1c — Rejection producer (Option B, contribution-time alternatives)

Semantics (Loom Protocol §3). wasConsideredAndRejected links an assertion to alternatives that were available, considered against it, and not chosen. That is a statement about proposal time. The producer belongs where alternatives are recorded.

Minimal shape. When a contribution enters with alternatives attached:

1. The primary contribution enters as a held assertion, exactly as today.
2. Each alternative enters as its own held assertion, marked in metadata as an alternative (key settled in the change-request draft).
3. A wasConsideredAndRejected relationship is written from the primary to each alternative.
4. Commit and discard behave normally on all of them. The edge persists regardless of eventual states — the protocol's semantics are about what was considered, not what survived.

Surface touch. The contribution path gains an attach point for alternatives. Minimal version: the contribution request schema accepts an optional alternatives list (content plus grammar element per alternative); the endpoint fans them out. The Operator Layer surface change, if any, is scoped in the change-request draft after step-0 reports the current contribution endpoints — an API-only first version (usable by the Companion and by scripts, no new UI) is acceptable for this change request and keeps 1c small.

Split rule (from the strategy, restated as binding). If step-0 shows the contribution path cannot take the attach point without restructuring — for example, if contribution fan-out breaks an invariant in the boundary or admission path — 1c splits out as its own change request and this one ships with 1a, 1b, and 1d.

What 1c is not. Not a consideration-lifecycle change. Not a UI arc. Not a general "compound contributions" feature — that remains separately queued (Phase 17 CR §14 named it out of scope; it stays out of scope here too).

5. Item 1d — Supersession-aware answering rule

The rule. Wherever the Companion reads Memory to answer as-current, the read filters on assertion state so retracted and superseded assertions cannot surface as current. Guarantee in code, not prompts.

What exists (per CR-2026-100 and manifest entries). At least two Companion read paths: recall_personal (personal-engagement recall) and ask_about_past_input (engagement recall). The current-view projection carries assertion state. What is unverified: whether each read path already filters on state, and whether other read paths exist (orientation composition reads registries, not Memory, and is likely out of scope — step-0 confirms).

What this item does. Step-0 enumerates every read path where the Companion composes an as-current answer from Memory. For each: confirm the state filter exists or add it. Add a test per read path proving a retracted assertion and a superseded prior version cannot surface as current. If every path already filters correctly, this item closes as verification-only with the tests added — that is a legitimate outcome, recorded in the change request as such.

Boundary. History-walking reads (assertion history, trajectory views, consideration surfacing) are explicitly exempt — they exist to show superseded material. The rule binds as-current answering only. The change-request draft names the exempt paths so the filter is never over-applied.

6. Sizing and sequencing

• Size. Small, per the strategy. 1a is one write site plus one script. 1b is a mechanical refactor. 1c minimal is one schema extension, one fan-out, one relationship write. 1d is filters plus tests, possibly verification-only.
• Sequencing. Behind the Stele contract phase and CR-2026-098; runs in the gaps. Step-0 re-baselines against whatever engine main is at execution time — the baseline in prior sessions (main 129d124, suite 2933 passed / 46 skipped, alembic head 0086) is named for orientation only and must not be assumed current.
• Migration expectation. None anticipated. 1a and 1c write standard relationship objects; 1b touches no schema; 1d touches read paths. If step-0 surfaces a migration need, that is a finding to report, not absorb.
• One change request, four items, with the 1c split rule as the only branch.

7. Out of scope

• The forward walk (Stage 2), as-of-a-date reads (Stage 3), hybrid retrieval (Stage 4).
• The provenance-threads reframe (parked). Nothing here conflicts with it; nothing implements it.
• Supersession severity. If 1d's work makes severity distinctions feel necessary, file the finding, do not absorb it.
• Consideration terminal-state changes of any kind.
• Compound contributions as a general feature.

8. Next steps

1. Claude Code runs the companion step-0 inspection brief (loomworks-graph-hygiene-step-0-inspection-brief-v0_1.md) against the live engine tree and reports findings.
2. The change-request draft is produced against those findings, with a change-request number assigned from the current sequence 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 Hygiene Change Request — Scoping Note — v0.1 — 2026-07-27