PR-7: Exact recall from another machine's store

In plain language: One machine searched another machine's crystal and pulled back 20 of 20 files byte-exact by address, signed by the other machine, in about 1 ms each on a home LAN.

The full receipt follows, as written: method, every limit and incident, and the SHA-256 of every input and output file. File locations are shown by file name only.

Built 2026-10-05T03:20Z by a W005 build helper (Claude, seat BM07) on M0. Live run 2026-10-05T02:53:00Z to 02:53:04Z (2026-10-04 21:53 Central). The Founder's word for the node, relayed by W005: "Use M2 for the cross-node test." Token figures marked cl100k use tiktoken cl100k_base; figures marked "chars/4" are estimates. STAGED: this file belongs at RECEIPT_PR_7_CROSS_NODE_EXACT_RECALL.md, but the controls claim on that folder was refused (BM0 "Prime Radiant build (XO)" holds PRIME_RADIANT and is live). Nothing was written there.

What was proven, in plain language

M0 searched a crystal that M2 built from 20 files that exist only on M2. The search returned pointers (celpanes), and M0 then fetched each file by its address over the LAN. 20 of 20 came back byte-exact (sha256). Every address was in a list that M2 signed with its own Ed25519 key, and the signature verified on M0. All 6 negative controls were refused or came back empty. Median fetch: 1.18 ms on the LAN.

The line that is safe to publish: one machine searched another machine's crystal and pulled back 20 of 20 files byte-exact by address, signed by the other machine, in about 1 ms each on a home LAN.

Condition (the caveat wins)

This is an exact fetch by address after a search on an exact topic word. It is not paraphrase search and it is not reasoning.
The test used one pair of machines (M0 M0, M2 M2) on one home LAN, with 20 small files (385 to 399 bytes), in one run.
The service was written for this run with Node built-ins only. It is not the Conduit, not MnemosyneC, and not the Founder's Conduit (its port was not touched).
The M2 key was generated on M2 for this test. It is not the enrolled peer identity 7317b20248c782fe, whose key lives under MnemosyneC safeStorage and cannot be read by plain Node. The manifest names the enrolled id only as a registry label.

Nodes and seals

item	value
asking node	M0, host M0, M0
answering node	M2, host M2, M2
node id (sha256 of M2 public key, first 16 hex)	`m2-62a0786d9de5df37`
crystal id (sha256 of canonical record list)	`8668154b0883ddc22ebb518994734c27e684a7181af40d53a7c53ec99385f1cc`
set seal (sha256 of the 20 sorted addresses)	`746b7532efd68bbd8492345186b6394b24dce3ea8d919511a5efac7f7c1a8202` signed; recomputed on M0 from the fetched bytes: same
build time (on M2)	2026-10-05T02:53:00.701Z
public key (SPKI, base64)	`MCowBQYDK2VwAyEAuo12nEFLkTv5du7Ag8QZF7V7QFDJiq4+Nt7fW097KKc=` (M0 received it twice, out of band over WinRM and in the LAN manifest, and the two match)
signature (Ed25519, base64)	`gUMxEru3uKrSZJiEu5fqEyQ17gef+OlxKf/bj7rdZHvtM3jB7OLH7oLlpADUDyyfmSEBSIMr+fVyG/fXvTJ4AA==`; verified on M0: TRUE; a copy with one field changed: REJECTED
private key	stays on M2 at `node_ed25519_priv.pem`; M0 never read, hashed or copied it

The 20 queries (Shiver then Frenzy)

In a Shiver, M0 asks M2's crystal for a topic word and gets back celpanes only. In a Frenzy, M0 asks for the record by the DOC_<sha12> short form in the celpane and gets back the bytes. A fetch counts as byte-exact when the sha256 of the received bytes starts with the short form, appears in the signed address list, and the file size matches the celpane.

#	topic	address (sha256)	bytes	Shiver ms	Frenzy ms	celpane tok cl100k	fetch tok cl100k	byte-exact
1	orchard	24ffc0e522a2cb33e0df731477019032e2dc5d3f6709d0bf39892f4adb11c6d6	394	1.515	1.553	51	96	yes
2	lantern	69a5829954f1db524c8e309e27d546cc4c804dd8b0d997da21a4138a29a8df5f	393	1.169	1.429	50	102	yes
3	harbor	8ce60e74312aa49eb202389cd3656e71765a388d6505a0f73c75a2aed6c6ee00	392	0.881	1.397	50	96	yes
4	quarry	f778b3586d44a4495847c69d9220f3c298520f438a0fdb6159791c3aaa43c9ad	391	0.905	1.343	48	96	yes
5	meadow	07eae696fffb8e9d4e95597e5f47e746e04151efa8fba405b4c00446d422d499	396	1.041	1.212	50	99	yes
6	glacier	099395155e1cddea83c1d8b0e0d3942dacaef3c77afedd499be2da50d6a4593b	388	0.611	1.133	48	97	yes
7	bakery	f5c42aa0eddb5ce801d22e1961b30e5423ffe8a08e69b9b42b1e59ac0181e040	391	0.858	1.076	50	95	yes
8	compass	37524d0c89f2ddf02a6b1213b72bf857700a81017ed1bfdf34721ae83c191496	395	0.731	1.069	50	93	yes
9	falcon	fafc8432e8dcdb7896ac1829af0445eb07f8efe8b71e8b25c388fda3568c1a2f	392	0.766	1.161	49	100	yes
10	tundra	8a88c3925b8bc65a47eafb66fd153dfb534c5815232fd200099d7064f98b4f3b	391	0.707	1.069	52	102	yes
11	violin	afb99b7e7061faadc265a4426e36e9cef8162d51f957abe7672b22a69e4e5d8f	391	0.688	0.937	50	96	yes
12	canyon	7222381477728ef2cab3cf3a970ba29f5ac73bda05811fe556ab7c008e96ada4	399	0.670	1.130	47	94	yes
13	beehive	c12c48e24e2a8863872dd1f841296bc079b7176ecec04212d46cd86e80ca36cf	399	0.738	1.091	53	101	yes
14	lighthouse	768b22a6bd0722017f15391d91d81c48b1c73737ea3b5a1a5f2b9a09b679c0e7	396	0.754	1.151	50	102	yes
15	saddle	2aa17d940386e80272a8369409e481bab8a24a52b64faa44c7138914612c7892	385	0.631	1.264	48	99	yes
16	pottery	6421ef6a1b601d4be777cef61b29fc48e0b0323249dba3623085442410f589a3	391	0.762	1.320	50	97	yes
17	monsoon	38ddf1733673c924f9f562919b248bbe2bf2df22a959fa52e7da639eb3342aaa	397	0.588	1.191	48	96	yes
18	anvil	e38973e1d3d7a41630c7cd7092bc21660bc876bb1d4e969d5d5985c0c6f1899b	396	0.879	1.289	51	96	yes
19	prairie	57793d60630327fe6a438140b7f96424e62ce2f320c9d8d9a424db0d2456b8bb	389	0.735	1.228	49	99	yes
20	telescope	66d3b37cfe99b7dc81a513bfccf350fac97dfd60516db9266be1d5859cbe1cee	397	0.864	1.065	50	99	yes

Totals. All 20 Shiver queries returned exactly 1 celpane each. All 20 Frenzy fetches were byte-exact, with 0 misses. In all 20 files, the file's own topic: line matched the word asked.

measure	min	median	p95	max
Shiver round trip, ms (new TCP connection each)	0.588	0.758	1.169	1.515
Frenzy round trip, ms	0.937	1.176	1.429	1.553
celpane tokens, cl100k	47	50	52	53
celpane tokens, chars/4	27	28	29	30
fetched file tokens, cl100k	93	97	102	102
short address `DOC_<sha12>`, cl100k	6	9	10	11

Example celpane (a pointer only, with no file content): DOC_24ffc0e522a2 | node M2 m2-62a0786d9de5df37 | crystal 8668154b0883 | topic: orchard | 394 B | f01_orchard.txt. 3 of the 20 celpanes come to 51 to 53 cl100k tokens, just over the 10 to 50 target, because hex characters tokenize poorly.

Negative controls (6 of 6 correct)

control	asked	result
random sha256, never existed	322583a0969974ae2dbdeb442dccbeef8c69cacdd6626d0ad29aa9301b10cafd	404 not found
random sha256, never existed	ee852af2e80509e5aaa2c5f41fb40ef20f7282795c2409fad101185799668c46	404 not found
a real M0 file address (PR-2 run file), not on M2	44dbb71b8e88c3ef09b1f8894c11a67b9b10427aa3e024f24e87b2dd503418e2	404 not found
short form not in the crystal	DOC_000000000000	404 not found
Shiver for a topic not in the crystal	q=zzqx-not-a-topic	200, 0 hits
a valid address with the wrong token	24ffc0e5...c6d6	403 forbidden

Absence on M0 (the files could not have come from M0)

Each file carries a 128-bit random nonce made on M2 by crypto.randomBytes. The build output sent to M0 over WinRM carried no addresses (only the node id, crystal id, seal, public key and count). M0 learned the addresses only through Shiver.
Prime Radiant index: the 20 addresses were checked against every sha256 column of pr_documents.db, pr_downloads.db, pr_vault.db, pr_layers.db, pr_extract.db and fp_crystals.db (11 columns, opened read-only). Result: 0 hits.
Disk: a scan of the first machine's user folder saw 14,154,183 files. It hashed all 54,693 files whose size equals one of the 20 sizes and found 0 byte matches (1,312.5 s). Fetched bytes were held in memory only and never written on M0.

What left M2 (every byte on the wire)

M2's server log and M0's client log each hold 47 requests. Every request came from M0; no other address reached the service.

verb	requests	status	body bytes	header bytes
manifest (signed, with the 20 addresses and public key)	1	200	2,004	129
shiver (celpanes; 20 queries + 1 negative)	21	200	2,796	2,687
frenzy (the 20 answered files)	20	200	7,863	2,720
frenzy miss	4	404	84	536
refused, wrong token	1	403	21	134
total	47		12,768	6,206

M2's body plus header bytes (18,974) equal the bytes M0's sockets received (18,974). Every Frenzy body's sha256 is one of the 20 answered addresses (20 distinct). The sorted list of body hashes on M2 equals the list on M0. The private key, crystal.json and the other files in the folder never crossed the LAN service. Separately, the WinRM control channel carried the two scripts to M2, the build summary to M0, and the token to the service. Afterwards it brought the wire log and a hash listing back to M0.

What this does and does not show

It shows that one node can be searched by another and give back exact bytes by address, with the answering node's signature checked on the asking side. That is the Founder's goal: "I need to prove it by searching the crystal of another node."
It does not show paraphrase or meaning search (topic words were exact), recall without a search term, scale (20 tiny files), recall over the internet (the WAN), or more than two machines.
Each file is about 97 tokens, so the pointer (about 50 tokens) is half the size of the file. The point of this test is exact recall across nodes, not token savings. For savings at scale, see PR-2 and the 5.32B receipt.
It does not use the product transport (Conduit P2P connectors, Thorax, or MnemosyneC peer routes). Related prior work, in the other direction: X029-007 (2026-09-16), where M2 searched and pulled 190 signed cards from M0 through peer_node.cjs (D-BP223-BM0-X029-007-MESH-CARDS-M2_REPORT.md); and RECEIPT_BP223_FIRST_300_MMLU_PRO_100_AND_M2_RECALL.md, where M2 ran cards shipped from M0 locally. PR-7 is the first record of M0 searching a crystal that M2 built from files that exist only on M2.
Latency is from one run on a home LAN. It includes opening a new TCP connection for each request.

Changes on M2, and cleanup

One folder, CROSS_NODE_TEST_20261004, left in place. It holds files (20 files), keys (2 files), crystal.json, manifest.json, manifest.sig.json, wire_log.jsonl and the two scripts. Nothing was installed (Node v24.16.0 was already on M2).
One firewall rule, CROSS_NODE_TEST_20261004_TMP (inbound TCP on a temporary port, remote M0 only), opened at 02:53:02.42Z. The service stopped at 02:53:03.94Z.
Incident, disclosed: the orchestrator's own cleanup step failed to remove the rule because PowerShell variable names ignore case ($rule overwrote $RULE). The rule was removed by hand at 02:53:16.46Z. It was open for about 14 s in total, with nothing listening after 02:53:03.94Z.
State after cleanup: 0 rules with that name, 0 listeners on a temporary port, 0 m2_serve.js processes, and a TCP test from M0 to a temporary port fails. The script has been fixed (a versioned sibling is kept). To close the rule by hand if ever needed, run Remove-NetFirewallRule -DisplayName 'CROSS_NODE_TEST_20261004_TMP' on M2.
Before the live run, the same scripts ran once on M0 loopback in the session scratchpad, with different random files: 20 of 20 and 6 of 6. That dry run is not counted here.

Evidence (sha256)

Folder D-BP223-W005-PR7-CROSS-NODE

path	bytes	sha256	what it is
m2_gen_and_build.js	5103	3cbd6a8f2b265b13900a344f1d51cd207538f97b2a804f6b50024dd547906229	generator, crystal builder and signer (same hash on M2)
m2_serve.js	4442	ba1e20e876a3b586e44e9242aef05d69f436d18378d7a10dd8ecdd9ed8e65485	M2 fetch service (same hash on M2)
m0_client.js	9107	472d552040fcab840e58f63df10b6d32a62e89114fd0f972f3de8708b985aaff	M0 client: queries, verification, negatives, timing
m0_run_cross_node.superseded.20261005T025357Z.ps1	5650	9a4f1e7fd2c4325f4b702c853886b7dab0bc4916d821e02a20107778509e5545	orchestrator AS RUN (contains the cleanup bug)
m0_run_cross_node.ps1	5934	0ba4a4ea3f24aaba54709e6df5b442e4aeec1d5833d65ada77557a74b95b2d8a	orchestrator, fixed
m0_absence_and_wire_check.py	3816	cd631c0eb1f11d06fef58011912b4917bbde92c8e921f02204eaf2fe405cfcdc	absence and wire checks
run_live.json	31978	4514cd2513212070f61a81d109b8085cfe1559d7fab7fe668c7cca98b992ccd8	every row, negative control and request, from M0's side
m2_wire_log.jsonl	12068	a0f08b7dca395c86e9d3cf818ef9f70c1fd0b670e6ad6d263738e134518f06e4	M2 server log, copied back (same hash on M2)
checks.json		21b70f201c810a60b50dcf84d1049e1e6f49be6c155dc9af5921b210bd031a27	absence and wire results
m2_build_stdout.json	332	72631f242b8c6c2e674578b754cb37dfb94da52aa0df7b920edb8852f257ea20	what the build sent to M0 over WinRM (no addresses)
pinned_pub_out_of_band.txt	60	1fbb19cffb79122ee797ce8a0253206e1766a90ff152a0905dbdbf8152216ddc	M2 public key, received over WinRM
m2_after_cleanup.json	1263	c9fcfeac61392dd5fd8939e909aaa949e4d93bf14124c48eb1fb2fad229ca36e	M2 state after cleanup, with file hashes
orchestrator_log.txt		(see file)	timeline, including the manual cleanup line

On M2: crystal.json 84855b3dca5170cedcf280214e73b010f4cd1cbd0cbe572f883e1aaf18884cba (6682 B); manifest.json 379da05b43ee63043d43257c598cffb0c859be8c8dec1b5b5b159446408d3df9 (1924 B); manifest.sig.json a2bcd2a845a3df8d552a025e2f51e6342fdfa1346857777cfc3c272f32a4446c (166 B).

Filed. Not done. The Founder decides.