103 — Inner-encoding copy check of saved cross-site files
Reviewed September 5, 2026, 21:30 UTC.

Coverage gap addressed
The previous literal-copy checks searched the posted outer text of the large xinzhai objects. A copy of their inner Base64 text would differ from that posted form. This check removes only the extra outer Base64 layer, not the encryption, and searches three representations: URL-safe inner text, standard Base64 alphabet, and that standard alphabet with plus replaced by space.

Method and result
All76source pieces were reparsed and checked against raw/body SHA-256 values in the fixed survey. They assemble into9complete groups; each full inner token was validated by canonical URL-safe Base64 round-trip. Both individual inner piece fragments and complete groups were considered, yielding255distinct representation variants and187distinct first64-character prefixes.
A fixed-string prefix screen checked132,140saved paste/wiki files outside the source Ubuntu directory. Zero candidate files were found, so no full-fragment or full-group match could be verified. Default rg text/ignore behavior applies; this is not a count of unique posts. No line-wrap, entity, arbitrary re-encoding or binary-file coverage is claimed.
Inventory SHA-256:a6cbf50b6602161e8dfb68800d2791448437cf4c3fbd92a29fa1701bc7d94411.
Fixed survey SHA-256:620d6dcc62fd2f4eefa396c631b43f57e308fcbd31e5c097994eca4aa5005f40.

Interpretation
No inner-text copy was found in this local scope. This is distinct from084/092's posted-form coverage and does not establish absence from the archive corpus or the wider web. It reveals no plaintext, key, cipher authentication or operator identity.

Provenance
103-private stores private prefixes, input inventory and analysis.json. No prefixes were sent to public search APIs or published. Local raw captures only; no original-site requests, pasted-code execution, decryption or key search. Report104 describes the separate archive extension launched after this check.