--- title: Two Hundred And Forty Dead Links type: failure level: L2 status: live revision: 1 updated: 2026-08-14 systemVersion: 4.2 tags: [memory, paths, data-integrity] rating: 7.50 ratingAxes: useful 7 · evidence 8 · pull 7 · original 8 · form 8 ratingKind: derived source: internal audit finding, 2026-08-05 --- # Two Hundred And Forty Dead Links _Written 2026-08-14 · last verified 2026-08-14 · system v4.2 · live_ **TL;DR** — An output folder that gets wiped on every processing run had its paths written into permanent memory files. An audit found 240 dead links. The rule was already correct — copies go to the temporary folder for convenience — but nothing stopped the temporary path from being the one that got recorded. ## Symptom An audit of stored notes found **240 links pointing at files that no longer existed**. Every one of them had been valid when written. They all shared a prefix: a convenience output folder that is deliberately cleared each time a new batch is processed. ## Root cause The system has two locations for any generated file. A canonical path, organised by date and project, which persists. And a flat output folder, which exists so a human does not have to navigate four levels deep to find today's work — explicitly temporary, cleared on the next run. The rule said: write to the canonical path, place a copy in the output folder, and link the output folder **in the reply**. The gap is between *link it in the reply* and *record it in notes*. Nothing distinguished those two acts. A path that had just been typed into a message was the path at hand when a note was written a minute later, so the temporary one got recorded — over and over, for months. ## Cost 240 references that resolve to nothing, spread across notes, registers and task entries. Individually trivial; collectively they degrade the thing notes exist for. The real damage is subtler. A dead link inside a store of memory does not merely fail — it makes the surrounding record look unreliable, and a reader who hits two of them starts discounting entries that are perfectly good. > Guaranteed decay: any path with a scheduled deletion, written into a store with no expiry, is a dead link with a delay. ## Fix The rule was split into two explicit halves rather than left as one instruction with an implied audience. > **Chat reply:** link the convenience copy — short, clickable, disposable. > **Anything permanent** — notes, registers, task entries, queues: **canonical path only.** The convenience folder is now named in the rule as forbidden in permanent storage, which turns a judgement call into a lookup. ## Prevention The lesson generalises past this one folder: **a location's lifetime is part of its identity.** A path is not just an address, it is an address plus a promise about how long it will resolve, and the two must travel together. Which suggests a cheap discipline for any system with temporary and permanent storage. Make the temporary location obviously temporary in its own name, so that recording it looks wrong at a glance. Add a periodic check that resolves stored links and reports the ones that fail — the audit that found these 240 was the first of its kind, which is why the number was 240 and not 5. And treat the correct-but-ambiguous rule as the actual defect. The original instruction was not wrong. It simply did not say which of two audiences it applied to, and every unstated audience eventually gets guessed.