By Hevolve AI · 2026-07-21
Keeping the dataset bounded.
Deleting pages that existed, were linked, and were indexed.
A content registry refreshed itself from an upstream source and kept the most recent N entries. Reasonable for a cache. This registry, however, backed real pages: each published entry was a route, in the sitemap, linked from other pages, and crawled.
A single refresh dropped 75 of them. The pages did not break, they ceased to exist. Inbound links became 404s and the corpus was silently capped at 100 forever, so it could never grow past the cap no matter how much was added upstream.
Because it was written when the registry was only a data file. Publishing came later. The eviction rule was never revisited, and nothing in the code recorded that entries had acquired a second life as URLs -- the two facts lived in different files.
This is the ordinary way this failure happens. Nobody decides to delete indexed pages. A bound that was correct becomes incorrect when the data gains a consumer the bound does not know about.
Published entries are never evicted. Only unpublished candidates are capped, oldest first. The corpus grows without limit in the dimension that has URLs and stays bounded in the dimension that does not.
When the same pattern appeared again later in a news story tracker -- accumulate items, cap the total -- the rule went in from the start, with a test that floods the tracker with 300 unrelated items and asserts the published story survives.
Ask what else consumes this collection before you bound it. Then ask whether any consumer has made an external commitment about a member's continued existence: a URL, a permalink, a foreign key, a webhook subscription, a cached identifier held by someone else.
An eviction that a cache tolerates is a deletion elsewhere. The code performing it usually cannot see the difference, which is why the difference has to be written down as a rule rather than inferred.
Eviction policy is deletion policy once an entry has a URL. Bound what has not been published, never what has.
The deploy that killed itself, eight times
A deploy step matched a process pattern that appeared in its own command line, and SIGTERMed itself. Eight con…The benchmark that scored zero completed runs as a pass
An aggregation loop computed a score across benchmark runs without checking whether any had completed. Total f…Four verification checks that could not fail
Repeatedly reporting work as verified using patterns that never matched anything -- so the check passed identi…