# Verification of clean C and X experiments — 2026-09-27

Independently parsed the binary dumps and recorded kernel/boot properties in:

- `.local-artifacts/009-v4-clean-c-20260927T190738Z/`
- `.local-artifacts/009-v4-x-persist-20260927T191143Z/`

The clean C test removes the earlier X/latch confounder: T2 has a zero failure
zone and a fresh v4 #29 boot; T3 reports kernel_panic on an intermediate v4 boot;
T4 is combo4 #16. No complete failure record is present after C. The intermediate
boot prevents localization of loss to the panic itself versus later boot stages.

The X test demonstrates that all eight complete 55-byte X records survive the
normal recovery to combo4 unchanged. It does not include the panic transition
of the C test, so it is a recovery control rather than the same full sequence.

Precision correction: T3 and T4 are NOT identical binary dumps. Their first 128
bytes match, but 7,213 bytes differ across 4 MiB, including six bytes in the first
1 KiB. Likewise X2 and X3 have 79 differing bytes, despite their complete X
records surviving intact. These differences do not negate X persistence, but
avoid describing entire zones or dumps as identical. Their cause is not yet
established.

Next diagnostic should check a full C record (primary and mirrors, expected
event/id/caller/terminator) immediately after its writer and before panic.
The success/failure result must be observable independently of the storage
whose survival is under test. A print to a console that cannot be retrieved, or
another flag only in the same alt region, would repeat the observability problem.
A control-only two-phase arm/readback/trigger protocol can expose the record
and status through adb before deliberately entering panic; document the changed
timing and validate the actual immediate path subsequently. Keep normal FORTIFY
failure behavior intact.

This establishes a narrower investigation: the writer plus normal recovery can
work; a clean panic experiment still loses or fails to produce the record.
Selective AES overwrite and a safe alternative offset remain unproven.

## Follow-up: two-phase arm/readback/panic (same evening)

Artifact:
`.local-artifacts/009-v4-twophase-x-then-c-20260927T191809Z/`

Using existing v4 (no rebuild): SysRq-x → **adb dump confirms** eight
complete `AXPDIAG1,X` records → SysRq-c (latch no-ops C write; panic runs)
→ intermediate v4 (`kernel_panic`) → combo4.

Result: pre-verified X is **absent at P3 and P4**. Independent channel was
adb, not alt-only flags. Timing caveat: adb RTT between arm and panic; type
X not C. Narrow reading: fail-zone content verified before panic does not
survive this panic/reboot path; soft recover without panic still preserves X.