117 — User-supplied xz archive corroborates the captured dataset
September 5, 2026.

Archive supplied by the user:
/home/sophia/search/investigation/china/uploads/xz-ubuntu-cn-2026-09-05.tar.gz
SHA-256:4a202ecd9dbe3dfcc40c1dac00984573cdffb38102e9d4ba4e04ce09b9a9105c
Size9,911,019bytes;3,920tar members;46,186,588 uncompressed member bytes.

Verified comparison
All3,574 xinzhai/xz records in bodies.jsonl have the same IDs as our fixed survey. Every authored-body SHA-256, author label, language tag, character count and displayed timestamp agrees with our saved metadata. No new cluster record or changed authored text was found.
The archive's eight saved versioned tokens, v5.2/v52/v60/v61/v70/v71/v72/v73, are byte-identical to reassembly from their corresponding multipart bodies. All eight match the supplied manifest's SHA-256 values.
Its investigators-mirror/posts.jsonl is byte-identical to our public1,142-post export. That embedded mirror is a copy of our publication, not independent cross-site agent activity.
Private117/fast-comparison.json records these checks. No decrypted plaintext or operator-identifying artifact appears in the supplied materials reviewed here.

Corrections to the accompanying README
1. There are nine large groups in the authored bodies, including the initial unversioned xinzhai group. The saved-token directory contains eight. v52 is not the first structurally compatible token: [REDACTED] initial and v5.2 groups precede it.
2. Fernet-layout compatibility does not authenticate a token or identify Python's cryptography package as its producer. Header timestamps support UTC+8 as a hypothesis; without authentication or independent clock provenance, they do not prove the offset.
3. Entropy, distinct bodies and random-looking pairwise XOR do not establish a specific cipher, cryptographic security or a fresh nonce per message. Small-record plaintext lengths cannot be recovered without knowing the encoding/encryption construction and overhead.
4. Canonical space-to-plus decoding of all3,484 knowledge records gives sizes93–428bytes, not429. Exact sizes/counts match our earlier full review:93(178),226(143),271(71),316(358),319(300),352(146),364(239),374(1153),397(605),428(291).
5. Plus-to-space damage remains a plausible transport explanation, not a demonstrated defect of the site's current form. Our085 review found ordinary multipart submission; no original submitted bytes are available.
6. The eleven plan posts have already been structurally reviewed in073: first five decode to646bytes and last six to647, despite all being864characters long.

Value and limits
This is useful corroboration of dataset transcription and multipart assembly, with convenient preassembled tokens. It strengthens confidence that the existing captured dataset was read consistently. It does not add decrypted contents, independent historical posting dates, a client implementation, or evidence establishing an agent swarm or its operator.

The supplied archive remains private and unchanged. The comparison read cluster data directly from tar members without bulk extraction or code execution. The full archive-HTML-to-JSONL consistency pass completed at22:21:02UTC: all3,574 cluster pages agree with their authored text records, with zero mismatches. All eight saved snapshots also have consecutive part numbering and consistent manifest lengths. Private117/comparison.json records the completed audit. Non-cluster pages, including the previously excluded source ID, were not opened for content review. No contacts in the README were messaged.