# Pending plan addition: SMI datalogger-intensive testing

Status: superseded
Type: evidence
Original Type: planning-note
Updated: 2026-07-24
Next Action: none
Campaign Reason: Historical or workspace-maintenance record retained independently; no separate owner-queue execution is required.
Campaign: standalone
Superseded By: work/wp/active/wp-sd-card-accelerated-endurance-evaluator-and-media-qualification.md

Date noted: 2026-07-13

The SMI firmware needs an intensive hardware-testing campaign added to its
future Tool Shed plan. SMI is the appropriate control for this work because it
actually uses the datalogger feature; the 7520708 display-test firmware does
not exercise the production datalogging workload.

There are two physical SMI setups. Their identities, hardware/probe
configurations, firmware baselines, SD cards, and intended roles are not yet
defined in this planning folder. The future plan must identify both setups and
state which tests run on each; do not treat evidence from one setup as coverage
for the other unless equivalence is explicitly established.

When the SMI plan is created, explicitly consider:

- sustained datalogger operation under a realistic production write cadence;
- a separate setup inventory and test/evidence record for each of the two SMI
  setups;
- multiple samples of candidate/replacement SD cards and required formats;
- throughput, worst write latency/stalls, integrity, FileX errors, and usable
  free-space behavior during logging;
- long-duration operation and controlled restart/recovery scenarios;
- evidence needed to approve the production card and final acceptance limits;
- whether the deferred multi-card qualification work currently referenced by
  the 7520708 plans should be relocated or superseded by the SMI campaign.

This scope is now represented as Phase 5 and as a proposed workstream in
`work/maps/map-smi-firmware-stabilization-and-qualification.md`. It still is
not an approved workpackage, checklist, test procedure, or authorization to
begin destructive/endurance testing. Create the detailed workpackage and
qualification checklist after Phase 0 identifies the two setups and the owner
approves media samples, measurements, acceptance limits, and test authority.

Update 2026-07-14: the detailed design now exists in
`work/wp/active/wp-sd-card-accelerated-endurance-evaluator-and-media-qualification.md`
with execution checklist
`work/checklists/checklist-sd-card-accelerated-endurance-evaluator.md`. This
materializes the plan but does not authorize destructive execution. Setup/media
inventory, implementation review, acceptance-limit approval, and test authority
remain explicit gates.

Decision update 2026-07-14: destructive evaluator formatting and datalogger
activity are approved when service code 472 presents a fresh, explicit warning
that all selected-card data will be permanently lost and the operator confirms
Erase/Start. See
`work/adr/adr-sd-evaluator-destructive-media-preparation.md`. Automatic format
on mount/error remains prohibited, and controller-risking power-cut tests retain
their separate approval gate.

Execution update 2026-07-14: the evaluator and semantic startup gate are now
implemented; static checks and isolated clean Debug/Release builds pass. See
`work/evidence/implementation-and-build-20260714.md`. Physical execution did
not start because the connected removable device reported No Media/zero bytes.

Connection update: the controller was subsequently connected and programmed
with the verified Release candidate. Its VEEPROM was preserved and its internal
SD interface reports READY. The installed card still requires physical
EDGE/Industrial identification before service code 472 is confirmed.

Run update: the operator identified the SanDisk Industrial 8 GB reference and
confirmed service code 472. Corrected-candidate run 07949 passed all 44,640
records, A/B checkpoint comparisons, file checks, and non-correcting FileX
integrity scans in 34 minutes 34.96 seconds. This is one candidate/Industrial
pass, not completion of old-code EDGE/Industrial discrimination, repeat runs,
host inspection, power/restart cases, candidate samples, or the real-time soak.
