Version. 0.1
Date. 2026-08-20
Filed under. Ruling 2, item A, Operator, 2026-08-20 — split out from the R-2 forward-gap arc as its own item, not a registry footnote. R-2 stays a forward-gap CR; this does not fold into it.
Status. Open design question. Not answered here. Filed to be posed, not resolved.
Raised by. The R-2 Step 0 trace of candidate_engagement_discarded (loomworks-foray-r2-forward-gap-scoping-note-v0_3.md; the six-entry trace), tracing engagement/candidate_discard_policy.py and engagement/candidate_discard.py.
candidate_discard_policy.py's own comments describe the mechanism directly:
> "the forward fix already deletes a discarded candidate's finding EVENTS (candidate_discard.py)... from the memory_events the candidate discard already deletes... which the discard deletes — the rows follow their source."
Candidate discard is implemented as deletion of the discarded candidate's rows in memory_events — not as a new event written about the discard. No writer for candidate_engagement_discarded exists anywhere in the codebase, and none is a near-miss the way induction_cycle/induction_cycle_recorded was: the actual mechanism removes memory rows rather than adding one, which is the opposite of what the registry entry's name assumes.
loomworks-candidate-seed-v0_14.md, § Memory, quoted directly:
> "Memory does not forget. Contributions that are corrected or superseded remain visible as part of the record. The trajectory matters — not just where the work arrived, but how it got there. A correction is a contribution. A retraction is a contribution. Both are preserved. This holds at every scope."
And, on what Memory is:
> "Memory is accumulated knowledge with provenance — everything that has been contributed, by everyone, over the life of the work."
The seed's stated shape has no deletion path. A correction is a contribution; a retraction is a contribution; both are preserved, not removed. This is stated as holding "at every scope" — the seed does not carve out an exception for candidate-stage or pre-commit material.
Either: candidate-engagement material sits outside Memory proper as the seed defines it — a staging area whose rows are not yet "contributed" in the seed's sense, so deleting them is not a retraction of a contribution and the current mechanism is correct as built.
Or: memory_events rows written for a candidate are already Memory in the seed's sense the moment they're written, and the discard path's deletion of them contradicts "Memory does not forget... this holds at every scope" — in which case the corrective shape the seed would require is a candidate_engagement_discarded event alongside the retained (not deleted) original rows, the same corrections-preserved shape every other retraction in the system already uses.
This question is not answered by this filing. It determines candidate_engagement_discarded's disposition in the anchor-priority registry (held open at loomworks-anchor-priority-registry-dispositions-v0_1.md §3 pending exactly this), and it is filed as a design question because it reaches wider than that one registry entry — it is a question about whether candidate-stage engagement material is Memory at all.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — open design question: candidate discard deletes Memory event rows — v0_1 — 2026-08-20