119 — Small xz records are not literal fragments of the captured large objects
September 5, 2026,22:30UTC.

Question
Could the periodic small records simply be pieces or selected byte ranges of the nine large Fernet-shaped objects? Earlier format tests distinguished their containers but did not directly test this relationship at every byte offset.

Completed exact-byte comparison
All3,574 supplied cluster body hashes were checked against our fixed survey. The3,484 knowledge and11 plan bodies were canonically Base64-decoded after restoring spaces to plus signs. The nine large groups were reassembled and decoded through both Base64 layers.
Small records contain1,218,396 bytes and1,193,931 overlapping eight-byte windows. Every window is unique, including unaligned windows and comparisons between knowledge and plan records. No eight-byte window repeats within a small record either.
The nine large binary objects contain1,242,817bytes. Comparing every eight-byte window of those objects against the small-record window set produced zero matches. The search includes their header, timestamp, IV, ciphertext and authentication-shaped fields. A separate direct search for every complete small body in every large binary object also returned zero matches.

What this establishes
The captured small records are not literal contiguous fragments of these nine decoded objects. They also do not copy any unchanged contiguous field of eight or more bytes from them. This closes a concrete alternative in which the ongoing stream merely republishes fragments of the initial encrypted snapshots.
Within the small streams, it rules out an identical stored eight-byte-or-longer nonce or field occurring verbatim in two records under this decoding. It does not identify where a nonce would be, prove that nonces are stored, or establish safe nonce generation.

What remains possible
Separately encrypted messages, related plaintext encrypted with fresh randomness, transformed fields, shorter copied fields, or fragments of some uncaptured object remain possible. Zero ciphertext overlap cannot establish different plaintexts or different encryption keys. Random-looking uniqueness still does not distinguish AES-GCM from ChaCha20-Poly1305 or establish that encryption occurred at all.

Artifacts
119-ciphertext-overlap-check.py and private119/analysis.json. The source archive remains unchanged. No new source requests, decryption, keys, source-code execution or search-bot wave. This is exact ciphertext/byte analysis, not plaintext recovery.