Settles §9 item 2. The question looked hard because two different things were being conflated. ⛔ EVICTING A MIRRORED BYTE IS NOT A DELETION. SOCIAL-MODEL §6.5 requires retention to tombstone rather than silently drop — but that is about an author retaining their OWN records, where absence in a replicated log is ambiguous and the signer's forward-only gate stalls on a pointer whose bytes vanished. A mirror holds someone else's record: the pointer is not ours to tombstone, and dropping the bytes returns that record to UNRESOLVED, which is a state the system already reports honestly and already recovers from. It is reversible. ⇒ Retention of your own records is a LOG question. Retention of a mirror is a CACHE question. That distinction is the whole answer. browse held until the peek ends, evicted with it — including at restart follow held until you unfollow, evicted only under budget, oldest first interaction held while the subject exists, evicted last, and it is smallest browse answers the question node.js leaves open beside peek(): "the BYTES stay on disk until something collects them; that is a separate question." follow gets no clock — following IS the decision to keep, so only a budget evicts. Order: browse, then followed oldest-first, then interactions. Never a record you authored; that is your log, not a mirror. ★ The budget is the ONE number that differs per device, which is why this had to be settled before packaging an APK: a handset cannot hold what an always-on box can, and the mirror fetches eagerly on every append with no reader. One number, not a separate architecture for phones. ⚠ Eviction costs availability and nothing measures it: drop the only second copy of a record whose author is offline and it is unreadable for everyone. The right policy would prefer records with many known holders; we do not track holders. Stated, not solved. evictContent(hash) and compactIndex(opts) already exist. Nothing calls either. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>