Phase 5c — No Memory Left Behind: grounding lifecycle

25 JUL AT 10:44 AM

Phase 5c — No Memory Left Behind: grounding lifecycle

0 LOVES 0 VIEWS

Phase 5 keeps bad facts out; 5c keeps good facts from rotting behind the wall. The distinction that organizes it: delete is an ERROR state, archive is a HISTORICAL state. When a block or post that grounds a fact goes away, the fact must cascade, degrade, or refuse with a 409 — never silently rot. Grounded, verified against code; the category-cascade half shipped early in 5a.

"What did they do to me?" The scariest failure for a memory layer is not a wrong fact — it is a fact that quietly lost its ground and kept being served as if nothing happened. Phase 5 built the wall that keeps bad facts out; Phase 5c keeps the good ones from rotting behind it.

One distinction organizes the whole phase: delete is an ERROR state; archive is a HISTORICAL state. Deleting a block that a fact points at is a mistake to be caught and refused; archiving that block is a normal act whose facts should become historical, not vanish. Get that split right and lifecycle operations stop silently corrupting the graph.

The lifecycle decisions (D1–D5)

Five decisions that keep a fact honest when the thing it grounds in is deleted, archived, or brought back.

Delete a block that grounds facts and one of two things happens: the facts cascade with it inside the same transaction, or — because delete is an error state — the operation refuses with a 409 that names the blast radius ("this would break N facts"). The write path already produces real facts referencing real blocks, so this cascade is load-bearing, not a fixture. It joins the transactions Phase 5a introduced at every block-delete site.

The core remaining slice. All seven assertion foreign keys were SET NULL — so a deleted target would silently null the fact's pointer, leaving a fact that grounds in nothing and still reads as current. That is the exact silent rot the phase exists to prevent. Flip them to RESTRICT so the database itself refuses to orphan a fact — the 409 above becomes a guarantee the schema enforces, not just application code. It needs an operator regen, which is why it is its own gated step.

Archiving a block or post is not a delete — it is a move to the historical register. Its facts should stop being served as current without being destroyed: the archived state derives the facts' historical status, closing their valid window rather than editing or removing them. So an archived project's facts still exist, still read as "this was true," and the history spine still shows them — exactly the bi-temporal promise from Phase 4, applied to the content lifecycle.

The mirror of D3. Bringing a post back from archive would re-activate its facts — but some of those facts may have gone stale while it was away. So unarchive does not blindly resurrect: it triggers a review, surfacing the facts about to become current again so a human can confirm or supersede them. Publish-blindly-un-archives was one of the five bugs in 5a; D4 is the principled version of the same guard — a lifecycle transition never silently changes what the graph asserts is true.

The one piece already shipped, early, in Phase 5a: the category bulk operation's delete posts-action became archive-to-default. A post pinned by its blocks can never be hard-deleted anyway — the FK table enforces it — so the "delete" action was a lie the UI told. D5 makes it honest: cascading a category deletion moves its posts to the default category and archives them, threading a single transaction through the recursion. Archive-not-delete, applied rather than re-decided.