Proving a database disposable
Calling a database a cache does not make it safe to delete. The claim depends on where its facts came from and whether those sources still exist.
Python Spice moved replayable Serve observations into a separate projection store. Durable team and directive authority stayed elsewhere. A corrupt, missing, or incompatible projection could then be discarded without discarding the decisions it was displaying.
A rebuild populated a fresh staging database first. Readers could retain the previous servable generation while that work ran. Only after population finished did the implementation copy the complete family’s rows into the published database inside one transaction, together with its generation and status.
That is an atomic row publication, not a filesystem rename of the live database. A failed staging callback never copied partial rows into the live family. The status remained explicitly stale if older data was still servable, or unavailable if there was no usable prior generation.
The integration tests seed authority and observation data, discard the projection, rebuild it, and compare the resulting combined view. Rebuilding must not reinterpret durable decisions as though they were merely observations that could be recreated from whatever transcript happens to remain.
Retention matters. Transcript-derived activity can be rebuilt from retained transcript bytes; deleting the source limits what any rebuild can recover.
The separation made failure handling simpler because the ownership was specific. This file could be recreated. The files carrying authority could not be treated the same way.