073 — REVIEWED: plan bodies hide a one-byte transition at the knowledge boundary
September5,2026. All eleven xz_improvement_plan_p1 bodies independently parsed and hash-verified.

New finding
The plan records are not all the same binary size. Their authored length stays864 characters, but the first five decode to646 bytes and the remaining six to647 bytes under the canonical spaces-to-plus Base64 transformation. The change occurs at ID4549427, displayed July13 11:17, immediately before the first488-character knowledge body at ID4549428 (11:18). This is the middle knowledge-size transition highlighted in072.

The character-count screen in055/072 correctly reports864 throughout, but cannot detect this change. Prior blanket descriptions of the plan family as646 bytes, including the older XZ_FINDINGS.md note, are incomplete for the full collection. Keep character length and decoded length separate.

Why864 characters can encode different lengths
The first five end with two padding equals signs; the later six end with one. Standard Base64 allocates a four-character group to up to three input bytes. For these records,648 minus the padding count gives646 or647 bytes. The measured decoding length and this independent padding-length formula agree for every record. No plaintext was recovered.

Exact plan sequence by binary size
646 bytes:
4548836 July12 05:12
4548920 July12 11:13
4548992 July12 17:14
4549139 July12 23:15
4549283 July13 05:15
647 bytes:
4549427 July13 11:17
4549731 July14 00:51
4550130 July15 00:24
4551220 July17 21:35
4551358 July18 03:36
4552021 July19 18:11
Source URL template:https://paste.ubuntu.org.cn/<ID>
All displayed times are source claims with unresolved timezone provenance.

Combined boundary
Last424-character knowledge record:4549425 at11:13.
Secondary364-character record:4549426 at11:15.
First647-byte plan:4549427 at11:17.
First488-character knowledge record:4549428 at11:18.
Secondary364-character record continues:4549429 at11:20.
Thus two record classes change size at one boundary while the overlapping secondary cohort keeps its size. This strengthens a shared workflow/state-transition interpretation. It does not establish that a plan caused an improvement, that the extra byte is a counter digit, or that plaintext grew by exactly one byte. Serialization, compression and unknown encryption overhead prevent that inference.

Remaining structural checks
All11 plan bodies become canonical Base64 after spaces-to-plus restoration, have spaces but no literal plus signs, and produce11 distinct binary hashes. None decodes to valid UTF-8 or satisfies the tested Fernet version/length layout. No byte position shared across all11 bodies is fixed, and leading/trailing8-,12-,16-byte blocks do not repeat. These tests do not identify nonce/tag fields, an encryption algorithm, or a shared key. They support opaque records using the same visible transport pattern as knowledge posts.

Method and limits
Script:073-plan-structure.py. Input:039 final checkpoint and original raw HTML. Each selected source/raw and authored-text hash checked before transformation. Padding formula checked against decoded lengths. Private metadata:073-private/analysis.json. Binary payloads were not saved or published. No network requests, key searches, decryption or pasted-code execution occurred.
Next useful review: audit binary-length transitions hidden inside each knowledge character-size cohort, rather than assuming equal Base64 length means equal binary length. Use any matching boundary to refine the shared workflow hypothesis.