# HPT Export Terminal Authority Evidence — 2026-07-27

Status: partial pass; operator UI and controlled failure/retry remain open

## Exact Candidate

- Debug S-record SHA-256:
  `3F498F6C473CAC39B2C09D5EA4083C4C5F87BEC50B5195705054051F312A7C81`
- Debug ELF SHA-256:
  `D46452927DBD832DB536560B505CF185266C70A526E541F2F659C01683DCD7CA`
- `gHptExportStatus` size: `0x100`
- Static gates: HPT customer export `30/30`, operator warning truth
  `17/17`, code-review mitigations `15/15`
- Isolated clean e2 Debug build: PASS

The S-record was programmed and verified on Controller B first and Controller A
second. Both targets were reset and run after programming.

## Controller B

- Assembly: `1751219`
- J-Link: `69660123`
- Protocol/card status: `6` (`RAW_HPT`)
- CID-valid status: `1`
- Representative-sector-read status: `0` (success)
- Manufacturer/MID: SanDisk/WD, `0x03`
- OEM/application ID: `SD`
- Product/revision: `SS08G`, `8.0`
- Serial/manufacturing date: `2540634245`, `2024-05`
- Raw CID: `035344535330384780976F0085018507`
- HPT state/status: ready, success
- System errors: `0`

Electronic export request `1`, file `AUTHB.csv`, completed as:

- State/reason: `PUBLISHED` / none
- USB phase/status/first failure: `COMPLETE` / `0` / `0`
- Published/complete: `1` / `1`
- Records selected: `2819`
- Snapshot/requested-range gaps: `0` / `0`
- USB writes/bytes: `1` / `131064`
- USB buffer capacity: `131072`
- Total/USB elapsed: `5.00 s` / `1.43 s`

## Controller A

- Assembly: `1751136`
- J-Link: `69664082`
- Protocol/card status: `6` (`RAW_HPT`)
- CID-valid status: `1`
- Representative-sector-read status: `0` (success)
- Manufacturer/MID: SanDisk/WD, `0x03`
- OEM/application ID: `SD`
- Product/revision: `SS08G`, `8.0`
- Serial/manufacturing date: `2540634244`, `2024-05`
- Raw CID: `035344535330384780976F0084018559`
- HPT state/status: ready, success
- System errors: `0`
- Graph cache: ready, `720` records retrieved

Electronic export request `1`, file `AUTHA.csv`, completed as:

- State/reason: `PUBLISHED` / none
- USB phase/status/first failure: `COMPLETE` / `0` / `0`
- Published/complete: `1` / `1`
- Requested range: `301739760` through `301916007`
- Actual range: `301739760` through `301915998`
- Records selected: `2855`
- Snapshot/requested-range gaps: `0` / `0`
- USB writes/bytes: `1` / `131027`
- USB buffer capacity: `131072`
- Total/USB elapsed: `4.04 s` / `0.38 s`

## Proven Boundary

The target captures prove that each request has a nonzero identity and that a
successful USB publication reaches matching `PUBLISHED`, `COMPLETE`, and
`FX_SUCCESS` terminal state on both controllers. Static and build evidence
prove the HMI consumes only a matching request and maps matching publication to
success even if shared generic progress contains an older terminal value.

The electronic trigger bypasses the physical HMI export button. It therefore
does not prove the displayed Success message. The USB files were not moved or
mounted on the qualification host, so their completion markers and record
counts have not been independently inspected. No approved non-destructive USB
fault-injection mechanism was found; a controlled failure/reinsertion/retry
test remains open.

## Controller B Physical-HMI Failure

The owner initiated request `2` from Controller B's HMI using the original USB
stick. The HMI displayed `USB write error`. The immediately captured
request-specific status confirms that this was a real publication failure, not
stale generic progress:

- Export state/reason: `FAILED` / USB publication failure
- USB phase: `TEMP_DELETE`
- USB status: `92` (`0x5C`, USBX `UX_TRANSFER_TIMEOUT`)
- First USB failure status: `92`
- Published/complete: `0` / `1`
- USB write calls/bytes: `0` / `0`
- USB elapsed time: `36.44 s`
- HPT records selected before publication: `2840`
- Snapshot/requested-range gaps: `0` / `0`

The paired identity capture remained healthy: RAW HPT, valid CID,
representative read success, HPT ready/success, zero system errors, zero lost
or mismatched HPT records, and raw CID
`035344535330384780976F0085018507`. This localizes the observed failure to the
USB operation before the first CSV write; it is not an SD-card read failure.

The next test is replacement-USB insertion followed by a fresh physical-HMI
request. Its request ID must differ from `2`, and success must reach
`PUBLISHED`/`COMPLETE` with zero USB status.

## Controller B Replacement-Drive Retry

The owner replaced the failed USB stick and repeated the physical-HMI export.
The HMI reported success. The captured fresh request `3` reported:

- Export state/reason: `PUBLISHED` / none
- USB phase/status/first failure: `COMPLETE` / `0` / `0`
- Published/complete: `1` / `1`
- USB write calls/bytes: `1` / `131064`
- USB buffer capacity: `131072`
- Total/USB elapsed time: `3.95 s` / `0.37 s`
- Records selected: `2844`
- Snapshot/requested-range gaps: `0` / `0`

Request `3` cannot be satisfied by request `2`'s terminal state, so the HMI
correctly consumed the fresh firmware result. Host inspection below shows that
the result was nevertheless not durable on the replacement filesystem; the
end-to-end retry therefore does not pass.

## Failed USB Stick Host Inspection

The original failed stick was subsequently inserted in the Windows
qualification host and inspected without repair:

- Drive/label/filesystem: `H:` / `B-CTRL` / FAT32
- Device: `USB DISK 2.0`, reported serial `000000000000`
- Capacity/free: `2009071616` / `1999085568` bytes
- Windows device status: online and nominally healthy
- Volume serial: `7401-C58E`
- Root contained a zero-byte `HPTE.TMP` dated at the failed request, along with
  prior CSV, IMX, WAV, and text artifacts.
- Read-only CHKDSK found filesystem errors and `393216` bytes in three
  recoverable lost-chain files. It made no repair because `/F` was not used.

The stick's filesystem corruption agrees with the repeatable USB timeout and
distinguishes it from the healthy Controller B SD/HPT source. Preserve needed
files before any repair. Do not return this stick to qualification service
without backup followed by repair/reformat and a separate validation pass.

## Replacement USB Stick Host Inspection

The replacement stick was inserted into the Windows qualification host as
`I:` and inspected without repair:

- Label/filesystem: `B-CTRL-2` / FAT32
- Capacity/free: `31021137920` / `31020941312` bytes
- Volume serial: `C0A9-CB4B`
- Root contents: system directory and a zero-byte `HPTE.TMP`; no completed CSV
- Read-only CHKDSK: filesystem errors and one recoverable lost chain of
  `128 KB`

The lost-chain size is consistent with request `3`'s single `131064`-byte USB
write. Thus FileX/USBX returned success through close, media flush, rename, and
final flush, but the host-visible FAT filesystem contains neither the final
directory entry nor an intact temporary file after removal. The firmware/HMI
success is not sufficient end-to-end publication proof.

Do not repair either stick until evidence needs are resolved. The next
firmware investigation must determine whether USB device write caching,
controller-side media-removal handling, or publication/flush sequencing allows
Success before FAT metadata and file data are physically durable.

## Device-Synchronized Candidate — Mounted Verification

Controller B was programmed and verified with candidate S-record
`5DC8FED4C10A241B531A23FC26DC3D566AD7D4AD0CD5E66A3182FFEF31DF1A06`.
This candidate replaces USBX's no-op FileX flush with SCSI SYNCHRONIZE CACHE
and requires post-rename reopen, exact-size comparison, and completion-tail
readback before `PUBLISHED`.

The owner ran a physical-HMI export and left the Success screen and USB media
in place. J-Link captured:

- Request/state/phase: `1` / `PUBLISHED` / `COMPLETE` (`11`)
- USB status/first failure: `0` / `0`
- Published/complete: `1` / `1`
- Records selected: `2862`
- Snapshot/requested-range gaps: `0` / `0`
- File writes/bytes: `1` / `131064`
- USB mounted: `1`
- System errors: `0`

Because this image cannot reach `COMPLETE` until the renamed file is reopened,
its size equals `131064`, and its tail matches
`Export completion: COMPLETE; records published: 2862`, this confirms the CSV
exists and is internally complete as observed through Controller B. Removal
and independent host inspection remain required for physical durability proof.

### Host result: failed

After removal, the same device appeared as `L:` / `B-CTRL-3`, but the host saw
only a zero-byte `HPTE.TMP` and no final CSV. Read-only CHKDSK found filesystem
errors and one recoverable `128 KB` lost chain. The device therefore
acknowledged SYNCHRONIZE CACHE and served the renamed file through its cache,
yet still lost the file and rename metadata at physical removal.

SYNCHRONIZE CACHE plus readback is insufficient for this device family. The
next candidate must issue SCSI STOP UNIT after verification and report Success
only after that removal-ready transition succeeds.

### Linux read-only analysis

`B-CTRL-3` was attached unmounted to `srv-rpi00.local` as PNY `USB 2.0 FD`,
serial `071C49DE246A1F97`, `/dev/sda1`, FAT32 UUID `3C2F-0099`.
Linux reported:

- device write cache disabled; read cache enabled; no DPO/FUA support;
- the two FAT copies differ, though each appears structurally intact;
- eight unused 16 KiB clusters form the unreferenced 131072-byte allocation;
- root entries include zero-byte `HPTE.TMP` and no final CSV;
- `fsck.fat -vn` left the filesystem unchanged;
- FAT 1 SHA-256:
  `77A41C2775B31B5E9E81AD49ECDDF16EB082804CF4E0268729050AB9F47857CE`;
- FAT 2 SHA-256:
  `612A7BC51B41A34749F0F2625178817BAEE2F1F180236E74633C9441272AB075`;
- root cluster SHA-256:
  `725EB32145A9EC94D3C1CBA64198F52E196768F31371A5F6BB42A2812B1D206F`.

This rejects device write caching as the primary explanation. The failure
boundary is inconsistent FileX/FAT metadata publication before physical
removal. Explicit STOP UNIT remains useful as a removal-ready barrier, but the
next test must begin from a repaired/reformatted filesystem and require the two
FAT copies and directory entry to remain consistent.

Raw J-Link captures are retained only under ignored `generated/` evidence
directories for Controllers A and B. This compact manifest is the versioned
summary.

## Bounded 16 KiB Write Candidate — End-to-End Pass

The repeated failed-media signature was one `131064`-byte FileX write followed
by eight orphaned 16 KiB clusters. The final candidate retained the 128 KiB
staging buffer but limited each FileX write to 16 KiB.

- S-record SHA-256:
  `486B048B65BCE801CA26DD6B4448F11B92F6B4C815DAFE082E48CBD4F170CCF9`
- ELF SHA-256:
  `FC23407A22589A91687B961C592A0C51ED8C91F0D3E556B75932145A6BE658A7`
- Controller B / J-Link: `1751219` / `69660123`
- SD CID: `035344535330384780976F0085018507`
- USB identity: PNY `USB 2.0 FD`, serial `071C49DE246A1F97`,
  label `B-CTRL-3`
- Request/state/phase: `1` / `PUBLISHED` / `COMPLETE` (`12`)
- USB status/first failure: `0` / `0`
- Records selected/published: `2902`; gaps: `0`
- File writes/bytes/max write: `9` / `146573` / `16384`
- Final readback, SYNCHRONIZE CACHE, and STOP UNIT: successful

After removal and attachment to `srv-rpi00.local`, read-only `fsck.fat -vn`
reported a clean FAT32 filesystem with two files, 10 used clusters, no
differing FAT copies, and no orphaned clusters. A read-only mount found:

- file: `SMI7_00112233_20260725t0911-20260727t1048.csv`
- size: `146573` bytes
- lines: `2920`
- SHA-256:
  `AEE558233D2242FF09DB916B1AF8501AAA1A7E7F40667FF8210604C65915F1DF`
- completion trailer:
  `Export completion: COMPLETE; records published: 2902`

This is the first complete Controller B to independent-host durability pass.
The 16 KiB FileX write bound is therefore retained as the mitigation.

### Previously failing media regression

Two additional previously corrupted sticks were clean-formatted and exercised
with the same firmware and Controller B. Both passed request-specific
COMPLETE, final readback/sync/STOP, and independent Linux read-only FAT/CSV
verification:

- `B-CTRL-2`, PNY serial `071C49DE25C08808`: request `2`, nine writes capped
  at 16 KiB, `2914` records, `147173`-byte CSV, clean FAT, CSV SHA-256
  `E9896B3B10E5E873BB434CD4C5DECA54B1D4C9623151DF827F58597E351C140A`.
- `B-CTRL`, 2 GB `USB DISK 2.0`: rebuilt with a standard MBR/FAT32 partition;
  request `3`, nine writes capped at 16 KiB, `2917` records, `147323`-byte
  CSV, clean FAT, CSV SHA-256
  `484F86946B24A0EDF1657ECEDE98A715C0F84152E9B48A6F3206494154A9F2B9`.

Together with `B-CTRL-3`, all three available USB sticks pass the bounded-write
candidate without the prior differing-FAT/orphaned-cluster signature.
