Result: no new plaintext. The published Agrippa decoder works on its own control, but does not yield readable ASCII text from the verified Liber Primus 256-byte block in any of its three byte alignments.
Method and recovery control
Wrote a separate Python implementation from Ayal Ryger's published JavaScript. It permutes bits, separates each three-byte group into two 12-bit values, raises each to power 11 modulo 4097, and reassembles/permutates the result. The modulus is 17 times 241. No key fitting or altered constants were used.
Source: https://agrippa.english.ucsb.edu/wp-content/uploads/images/cracked-code/submissions/files/agrippa_in_action.html
The Python output matches the published JavaScript output exactly for all 9,918 bytes of the demonstration poem. It also matches Freek Wiedijk's independent 2011 memory extraction after converting its 362 Mac CR line endings to LF. The initial raw-byte comparison failed solely because of those line endings; no other normalization was applied. This verifies the decoder against external plaintext, not just a round trip of our own code.
Independent reference: https://agrippa.english.ucsb.edu/post/documents-subcategories/the-disk-and-its-code/original-text-of-gibsons-agrippa-poem-extracted-from-disk
Cicada test
Target: previously verified 256-byte base-60 block from LP2 pages 49-51. Original byte order only. SHA-256: 3b9b07d9a26e6d55c432d94d2661fdff3c2b348daed06821f2bdb23184a4b290.
The complete block is not a multiple of three bytes. Before inspecting outputs, the test was limited to the three possible byte phases. Only complete three-byte groups were decoded, with omitted edges recorded; there was no padding or inferred header.
| Start offset | Bytes decoded | Bytes omitted at start/end | ASCII text bytes | Longest ASCII text run |
|---|---|---|---|---|
| 0 | 255 | 0 / 1 | 101 (39.6%) | 4 |
| 1 | 255 | 1 / 0 | 92 (36.1%) | 5 |
| 2 | 252 | 2 / 2 | 98 (38.9%) | 5 |
ASCII text means byte values 32-126, tab, LF, or CR. None is a readable ASCII message. Output bytes are retained as hex in agrippa_results.json. No modular-result overflow was observed in the control or these targets.
Interpretation and next decision
This rejects the narrow candidate that the byte block directly decodes into ASCII prose under the published Agrippa algorithm, including simple changes of block alignment. It does not exclude binary/compressed output, a different encoding, an additional layer, a modified algorithm, or Agrippa used as a source text. None of those alternatives has been established.
The rune pages are a separate representation; this test does not assume an arbitrary rune-to-byte conversion. A historical or literary association alone does not determine such a conversion.
The next useful Agrippa investigation is textual: reconstruct the already-solved 2012 book cipher using its exact text edition and indexing convention. That provides a documented control before any attempt to reuse the poem or convention on an unsolved page. Different online editions have spacing/capitalization differences, so freely switching versions would risk manufacturing a result. No such book-cipher reconstruction was performed in this session.
Reproduction
The bundle contains agrippa_pass.py, prepare_agrippa_control.py, agrippa_source_hashes.json, agrippa_results.json, and the existing base60_verified.bin.
Run python3 prepare_agrippa_control.py, then python3 agrippa_pass.py. Preparation requires network access and Node.js; it downloads hash-pinned public sources and executes only the inspected demonstration algorithm. Full poem text and third-party source snapshots remain local research inputs and are not redistributed in the bundle.