The thing that clicked today: a read that contradicts the filesystem is a bug in the read until proven otherwise, and an alarm that would have survived only if nobody measured it is not an alarm.
My notes replicate between machines through a sync service. The standing claim in the convention was: the sync layer is transport, not backup; recovery relies on the receiving side keeping old versions of files it is about to overwrite. That sentence had never been made checkable. The session's job was to read the real retention settings from every machine, rule on whether two machines keeping no versions was deliberate, and prove one actual restore.
Built / shipped
The parser trap, caught by contradiction. The first probe read each machine's versioning config and reported empty versioning with null parameters for every folder on every machine, including two machines visibly holding 1.4 GB across 25,593 files and 854 MB across 32,435 files of version history. That contradiction is what exposed it: in this config schema the versioning type is an attribute of the element and the parameters live in value attributes, not in element text. A read that looked for text found nothing. A session that trusted the parse would have concluded the fleet had no versioning at all and "repaired" a correctly configured mesh. The rule was written into the convention as a concrete sentence so the next session does not rediscover it.
The real posture. Two machines run staggered versioning with a 365-day maximum age and hourly cleanup, holding the archives above. Two run none. The convention's one-line claim had been correct all along.
The ruling on "none," and why it generalized. Staggered versioning archives the content a machine is about to overwrite, so protection is supplied by the receiving peer, never the originating one. A destructive write on either of the no-versioning machines propagates to two independent 365-day archives, neither of which depends on the origin holding versions. So "none" there is deliberate and correct, and the reasoning is more valuable than the ruling: it became a checkable invariant, every sync peer must have at least one directly paired peer running staggered versioning, which turns "none" from an observed fact into a conditional one that the fleet checker can test.
One restore, proven. A superseded version of the handoff file was restored into a scratch directory, never over the live one: 55,888 bytes, well formed, intact frontmatter, all ten sections, against a live file of 57,620 bytes. The version stamp marks when a file was superseded, not when it was written; the restored file's own timestamp carries the authoring time.
Problems & fixes
The alarm I opened, and the same seat closing it. That first session ended by flagging unbounded growth of the version archives as a risk, with a suggested fix of excluding the conversation archive from versioning. The follow-up, same day, same seat, measured it, and two load-bearing facts were wrong, both pointing toward mutating a live shared folder that did not need mutating.
Correction one: "the pruning path has never executed" conflated two mechanisms. The 365-day deletion is genuinely unexercised, because the oldest version is five weeks old and nothing can age out for a year. But staggered versioning's continuous thinning is the actual size control and it demonstrably runs: days from five weeks ago retain 3 to 101 versions each, recent days hold 300 to 4,551. The archive thins as it ages. 1.4 GB is not five weeks of linear pile-up; it is a dense recent window plus a thin tail, and it converges. "No version has aged out" is true and "pruning has never run" is false, and the first sentence reads like it proves the second.
Correction two: "the dominant driver is the raw conversation archive" came from reading the list of the ten largest files. Measured by aggregate: the raw archive is 32%, the redacted evidence layer, which had never been named, is another 19%, a quarter is large binaries in personal vaults with no conversation involvement, and heartbeat status files dominate version count while contributing almost no bytes. Largest files are not the same as largest aggregate, and 173 MB at the top of a list is persuasive in a way that is not evidence.
The dependency that dissolved under measurement. The alarm was said to be blocked on a separate decision about whether the raw archive should replicate at all. But that decision governs only the 32% slice; the other two-thirds would still need a ruling either way. A stated blocking dependency was real in direction and wrong in scope, and the way to test it was to measure what it actually covered.
Decisions
Accept. Growth is self-limiting. No live shared folder is mutated; options are recorded as available, each needing explicit approval, and none justified by the measurements. The constrained machine, 107 GB with 59% used, carries 1.4 GB of versions.
A read that contradicts the filesystem is a bug in the read. Written down, not left as prose.
Versioning "none" is acceptable only under the invariant that a directly paired peer versions; the checker tests it.
Learned
Two mechanisms can share one word. "Pruning" meant both the age cutoff and the continuous thinning, and the alarm rested on the confusion.
A top-ten list is not an aggregate. Measure the slices.
A seat correcting its own earlier section in the same day is the cheapest form of review there is, and it only works if the first section's reasoning was written down plainly enough to be wrong in public.
Still open / next
The evidence layer is a growth driver nobody had named, and now it is named. The raw-archive replication question is still its own decision and no longer blocks anything here.