# Decision Matrix: Remaining qualification authorization

Status: decided
Result: decided; owner approved the bounded qualification matrix
Type: decision-matrix
Updated: 2026-08-02
Next Action: this firmware workspace prepares the reviewed immutable SMI candidate bundle, controller-test contracts, and handoff manifest; after readiness, the srv-rpi00.local qualification app coordinates every Controller A/B test, while physical receipt/handling remains operator work
Campaign: 005-complete-sd-qualifier-gate2-release-plan-acceptance
Parent: work/maps/map-smi-firmware-stabilization-and-qualification.md
Canonical Truth: docs/firmware-update-validation-and-recovery.md and docs/sd-card-operation-and-recovery.md

## Decision

The owner approved this matrix on 2026-07-25 by directing adoption of the
recommended remaining qualification plan. It identifies required, accepted,
waived, and deferred cases; assigns controller and expendable-card roles;
defines conditional destructive authority and recovery requirements; and fixes
the minimum engineering endurance sample count and acceptance limits.

This is planning and operation-specific authorization for the cases marked
`AUTHORIZED` once every listed entry gate is satisfied. It does not assert that
the gates have run or passed. It never authorizes powered SD-card removal or
insertion, which is unsupported and prohibited.

## Execution ownership and readiness

Authorization in this decision is not an assertion that the execution system is
ready. The work is divided across these boundaries:

- this Windows firmware workspace owns source, the exact managed build,
  artifact hashes, firmware diagnostics, host/model/static checks, controller
  test contracts, bundle publication, returned-result review, and release
  disposition; it does not coordinate tests that execute on Controllers A/B;
- `jong@srv-rpi00.local:~/dev/sd_qualification` owns the live SD qualification
  registry, exact-bundle campaign instances, all physical-controller
  orchestration using SMI firmware—including Controller B code-review
  negative/recovery and calibration-preservation cases—generated evidence,
  failure disposition, and reviewer-approved result manifests;
- the separate HPT Lab Power Control service on `srv-rpi00.local` owns the
  G-PWR interface and operations; the qualifier is a gated client of that
  service, not its replacement;
- the operator owns physical receipt, labels, photographs, and all SD-card
  removal, insertion, or replacement while controller power is off.

The Pi qualifier is `NOT READY` for the remaining physical campaigns until its
standalone appliance foundation, live-controller adapter, authorized read-only
A/B identity, stop/recovery, and evidence-path gates pass. The workspaces
exchange immutable firmware bundles and reviewed result manifests through
GitHub; the operator is never used as a cross-workspace data relay.

## Qualification disposition

| Case | Disposition | Assignment and boundary |
| --- | --- | --- |
| Automated malformed-update corpus | `ACCEPTED` | Existing automated corpus remains required evidence; do not repeat merely to create output. |
| Representative-target malformed, truncated, oversized, wrong-product, and bad-CRC update rejection | `REQUIRED / AUTHORIZED` | Controller B `1751219`, J-Link `69660123`; rejection must occur before QSPI erase/program. |
| Injected update timeout/storage failure | `REQUIRED / AUTHORIZED` | Controller B first; existing RAM-only/diagnostic injection only, with no persistent injected state or frozen-image mutation. |
| Injected HPT and USB create/write/flush/close/verify/rename failures | `REQUIRED / AUTHORIZED` | Both controllers through existing diagnostic hooks. Physical card removal is not a substitute. |
| No-card boot and card replacement | `REQUIRED / AUTHORIZED` | Both controllers; power off before any card removal/insertion, reboot, and repeat CID/media classification. |
| Powered SD-card removal/insertion | `PROHIBITED / N/A` | Unsupported and expected to damage or corrupt the card; never execute. |
| HPT destructive initialization | `REQUIRED / AUTHORIZED` | Only inventoried expendable samples assigned to the active family campaign, after baseline CID and full-address scrub. |
| Named HPT power interruptions | `REQUIRED / AUTHORIZED` | Controller A fault sample through G-PWR-A and Controller B fault sample through G-PWR-B; cover record write, commit, segment seal, reclaim activation, and retirement snapshot. |
| Firmware-update power interruption | `REQUIRED / CONDITIONALLY AUTHORIZED` | Controller B only after its configuration/calibration backup, known-good program recovery image, probe recovery, and safe non-heating state are captured and verified. |
| Controller A firmware-update power interruption | `DEFERRED` | Execute only if Controller B exposes a failure or a hardware-variant-specific path requires A coverage. |
| Corrupt/degraded-media behavior | `REQUIRED / AUTHORIZED` | Prefer deterministic injected/model cases. Physical cases use only a designated expendable fault sample and may not repair or auto-format it. |
| General visual/audio/touchscreen review | `ACCEPTED` | The completed A/B review stands; do not repeat it. |
| Unique Format/export failure messages | `ACCEPTED BY EQUIVALENCE 2026-08-11` | Deterministic mapping, current regression/build evidence, an actual target `EXPORT_CAPACITY` terminal result, accepted common progress-screen navigation, and the absence of an admitted qualifier injection profile close presentation-only review without bypassing the remote execution owner. See `work/evidence/hpt-operator-failure-message-closeout-20260811.md`. |
| Existing healthy-media A/B baseline | `ACCEPTED` | Retain the passing CID-linked full-address scrub and integrated HPT evidence; do not repeat without a material identity/state change. |
| Initial release card campaign | `REQUIRED / AUTHORIZED AFTER FAULT GATE` | Begin with two new expendable samples from one retail family, one on A and one on B. Two complete counted passes approve that family and the byte-identical frozen firmware for release together only when all assigned A/B coverage is complete and no unresolved family or systemic failure exists. |
| Additional retail-card families | `POST-RELEASE ROLLING QUALIFICATION` | Qualify one adaptive two-or-more-sample family at a time using the unchanged released firmware and add each passing model to the approved-card pool without delaying the initial release. |
| Third or later sample / statistical lifetime claim | `CONDITIONAL / SEPARATE` | Add a sample only for a recorded replacement, investigation, inconclusive, infrastructure-damaged, additional-coverage, material-substitution, or separately approved reliability reason. Adaptive engineering compatibility is not a statistical lifetime claim. |
| Power-rail/signal-integrity instrumentation | `DEFERRED` | Activate if failures cluster on one controller. |
| Additional workload-causation investigation | `DEFERRED` | Activate if failures cluster under accelerated activity across controllers. |
| Field rollout | `REQUIRED / NOT YET AUTHORIZED` | One recoverable pilot after the fault matrix and first adaptive family campaign passes; broader deployment requires pilot verification and rollback readiness. Later card families do not block this release. |

## Controller roles and retained cards

| Role | Controller | Probe | Card policy |
| --- | --- | --- | --- |
| Firmware negative/recovery representative | B, assembly `1751219`, hardware variant `1` | J-Link `69660123`, `srv-rpi00:19121` | Keep installed CID `035344535330384780976F0085018507` as a non-destructive reference; use expendable media where update flow needs media. |
| HPT fault/endurance lead | A, assembly `1751136`, hardware variant `0` | J-Link `69664082`, `srv-rpi00:19120` | Keep installed CID `035344535330384780976F0084018559` as a non-destructive reference. |
| Cross-controller HPT coverage | B, assembly `1751219`, hardware variant `1` | J-Link `69660123`, `srv-rpi00:19121` | Use assigned expendable samples only after B recovery baselines are complete. |

The owner identifies both currently installed `SS08G` cards as SanDisk EDGE
8 GB cards. Their controller-reported identities and raw CIDs are recorded in
`work/inventories/inventory-sd-card-qualification-candidates.md`. Neither
installed card is expendable. The retired failed FAT32 card is a distinct
specimen and is not eligible for testing.

## Expendable-card allocation

Three provisional retail candidates are ordered and recorded in
`work/inventories/inventory-sd-card-qualification-candidates.md`: a KEXIN 8 GB
10-pack, a GIGASTONE 8 GB 2-pack, and a Lexar High-Performance microSDHC 300x
8 GB listing model `LSDMI8GBBNL300A`. Physical receipt, exact
model/package/lot, label photographs, decoded CID, and raw CID remain pending.
The KEXIN pack is the preferred Family 1 lead because it can supply the initial
pair plus fresh adaptive replacements or investigation specimens; that
assignment is not final until physical intake passes. The two-card GIGASTONE
pack can supply an initial A/B pair if both cards have consistent commercial
identity and pass intake. The Lexar screenshot does not expose order quantity;
if it represents one physical card, that family needs one more matching sample
before its initial campaign. Reserve these roles now:

| Sample ID | Retail family | Controller | Campaign role |
| --- | --- | --- | --- |
| `F1-A1` | Family 1 | A | Initial counted sample; fault specimen plus endurance; all five named HPT interruptions through G-PWR-A |
| `F1-B1` | Family 1 | B | Initial counted sample; fault specimen plus endurance; all five named HPT interruptions through G-PWR-B |
| `F1-A2` | Family 1 | Unassigned until justified | Fresh reserve; add only with a recorded replacement, investigation, inconclusive, infrastructure-damaged, or additional-coverage reason |
| `F2-A1` | Family 2 | A | Initial counted post-release approved-pool sample; endurance and assigned A coverage |
| `F2-B1` | Family 2 | B | Initial counted post-release sample; fault specimen plus endurance and assigned B coverage |
| `F2-B2` | Family 2 | Unassigned until justified | Fresh reserve if obtained; add only with a reviewed adaptive-sample reason |

Family 1 is the initial-release candidate family. Family 2 does not gate the
initial firmware/card release and begins only as a rolling approved-pool
expansion. A reserve sample is not part of a campaign merely because it is
available. Each assigned role becomes destructive-test eligible only after its physical card is
labelled expendable, inventoried, CID-captured, assigned an evidence directory,
and given a copied immutable instance of
`work/checklists/checklist-hpt-media-2-autonomous-retail-card-qualification.md`.

## Destructive authority entry gate

The matrix authorizes the assigned operation only when all conditions below are
true for the exact run:

The Pi represents this approval as one immutable scope-bound human envelope
and derives a unique short-lived machine intent for each allowed state-changing
action. Read-only observation, preflight, polling, evidence capture, cleanup,
and reconciliation continue automatically and do not require another operator
response. See
`work/adr/adr-qualification-authorization-envelopes-and-machine-intents.md`.

- exact implementation commit, artifact-freeze commit, ELF/SREC hashes, and
  host-automation revision recorded;
- controller assembly, hardware variant, J-Link serial/endpoint, card sample,
  decoded CID, and raw CID match the assigned run;
- configuration/calibration backup and known-good program recovery image exist
  with verified hashes;
- J-Link acquisition, program/verify recovery, G-PWR health, stop command,
  campaign timeout, and evidence path pass preflight;
- for these exact isolated bench controllers, the standing no-heater,
  no-load, no-production connection is recorded once and replaces repeated
  heat/alarm reviews; the applicable controller power state is still verified
  electronically for each operation;
- card is explicitly labelled expendable and all existing contents are accepted
  as permanently disposable;
- baseline protocol/CID/sector status and full-address scrub pass;
- generated raw evidence is directed to the ignored generated-evidence path and
  summarized through a small manifest.

Controller B's configuration/calibration backup, exact known-good recovery
image, serial-bound J-Link recovery route, and persistent electronic
non-heating state passed on 2026-07-27. Evidence:
`work/evidence/controller-b-recovery-baseline-20260727.md`. This clears only
that baseline dependency; every destructive firmware-update interruption still
requires its exact-run identity, physical safety, stop, evidence, and
operation-specific gates.

The recovery-only non-heating snapshot is not the endurance configuration.
Normal Controller B temperature control was restored and verified across reset
at the owner's direction. Endurance and general controller qualification run
with normal controller functions enabled.

## Recovery method

1. Stop and latch the active state-changing case; never replay its target
   command. Continue bounded pre-target reconnect and read-only reconciliation
   automatically when the recorded transcript and operation identity permit it.
2. Keep the exact target, probe, card, firmware, run ID, and first failure state
   intact long enough to capture evidence.
3. Recover controller power only through the qualified G-PWR group method.
4. Use the serial-bound J-Link endpoint to verify target identity and recover
   the exact known-good program image when required.
5. Restore the hashed configuration/calibration baseline and verify redundant
   persistence, safe setpoints, zero pending save, and non-heating state.
6. Reboot, capture the complete CID block, reopen HPT, inspect the recovered
   tail/lane/quorum/retirement/error state, then append/read/export one known
   record before resuming.
7. Never repair, reformat, hot-remove, or hot-insert a failed card as part of
   automatic recovery. Preserve and disposition it first.

## Stop conditions

Stop the individual run immediately and mark it `FAIL` or `BLOCKED` on:

- controller, J-Link, firmware, card, CID, or run-profile identity mismatch;
- unsafe/heating state, uncontrolled output, smoke, excessive current, or loss
  of the emergency stop/recovery route;
- failed G-PWR/reset witness, unexpected reset, watchdog event, frozen control,
  or loss of alarms/communications/UI beyond the case limit;
- diagnostic/J-Link loss beyond the defined timeout;
- any unreadable sector, retry-recovered sector, new lane retirement, repeated
  physical-address failure, or unexplained HPT status;
- lost acknowledged record, incomplete record returned as committed,
  unexplained sequence gap, or false-success/partial customer export;
- unexpected automatic format, repair, or card identity change;
- evidence-path capacity/identity failure or missing machine-readable terminal
  result.

Do not continue other samples merely to reach the planned count after a
systemic safety, controller, firmware, or automation failure. Quarantine a
single failed sample pending disposition.

## Endurance minimum

This is an engineering compatibility qualification, not a statistical lifetime
claim.

Per sample:

- one passing CID-linked baseline full-address scrub;
- explicit HPT media 2.0 initialization;
- at least `72` continuous wall-clock hours;
- at least `3` complete HPT wrap/reclaim cycles;
- concurrent normal logging, event bursts, chart reads, USB exports,
  configuration saves, communications traffic, and control monitoring;
- scheduled interruption cases on `F1-A1` and `F1-B1` for the initial-release
  family, then on the assigned fault specimen for each later family;
- one passing CID-linked post-campaign full-address scrub;
- final retained-window readback, chart rebuild, customer export, HPT state, and
  machine-readable terminal disposition.

Family approval requires at least two counted samples to pass, complete
assigned A/B campaign coverage, disposition of every failed, blocked,
excluded, or inconclusive sample, and reviewer sign-off. A confirmed
media-family failure rejects that family from production approval until
investigated and explicitly requalified; later passing samples cannot outvote
it. A failure that implicates firmware, controller hardware, automation,
evidence, safety, or a shared qualification method blocks release or pool
expansion globally until resolved.

## Acceptance limits

A card/controller run passes only with:

- `100%` of physical sectors accounted for in both scrubs;
- `0` unreadable sectors, retry-recovered sectors, CID changes, or identity
  mismatches;
- `0` new lane retirements or repeated physical-address failures;
- `0` lost acknowledged records, committed incomplete records, unexplained
  sequence gaps, queue drops, or silent/partial successful exports;
- `0` watchdog resets, control deadline failures, uncontrolled outputs, or loss
  of required chamber-control services;
- successful reopen, append, readback, chart rebuild, and export after every
  planned interruption;
- no automatic format or repair and no powered SD-card removal/insertion;
- every required checkpoint and terminal result present with evidence links.

## Recommendation

Execute in this order:

1. Complete Controller B recovery baselines. `COMPLETE 2026-07-27`; see
   `work/evidence/controller-b-recovery-baseline-20260727.md`.
2. **Operator / Pi qualifier, gated:** receive the initial A/B Family-1 pair;
   keep later matching cards fresh and unassigned, and do not create a campaign
   until the Pi qualifier readiness gates pass.
3. **Pi qualifier, gated:** inventory the pair and capture baselines, CID
   identities, full-address scrubs, assignments, and immutable campaign
   directories.
4. **Pi qualifier, gated:** import the exact SMI bundle and coordinate the
   authorized representative Controller B firmware-update negative/recovery,
   code-review injection, and calibration-preservation cases on target.
5. **Firmware workspace:** review the returned evidence and correct firmware or
   test contracts as required; do not operate either controller from here.
6. **Operator / Pi qualifier, gated:** run power-off no-card/replacement boot
   classification; physical card handling remains operator work with controller
   power off.
7. **Pi qualifier plus power service, gated:** run `F1-A1` and `F1-B1` through
   the named G-PWR interruption matrix after both services pass their gates.
8. **Firmware workspace:** unique failure-message review is `COMPLETE
   2026-08-11` by the presentation-only evidence-equivalence disposition in
   `work/evidence/hpt-operator-failure-message-closeout-20260811.md`.
9. **Pi qualifier, gated:** run the initial two-sample A/B Family-1 endurance
   campaign.
10. **Pi qualifier, gated:** complete Family-1 post-campaign qualification and
    publish the reviewed immutable result manifest.
11. **Pi qualifier then firmware workspace:** disposition every remote failure,
    then accept or reject the returned result manifest locally.
12. **Firmware workspace:** approve the first production family and disposition upstream HPT adoption
    and legacy cleanup.
13. Run one recoverable pilot rollout and observation period.
14. Release the byte-identical frozen firmware and approved Family-1 card
    model together through a one-unit staged rollout.
15. **Pi qualifier, gated:** qualify Family 2, and each later family, as a post-release rolling
    two-or-more-sample campaign; add only passing families to the approved-card
    pool.
16. Activate the deferred temperature-profile work only after the initial
    release workpackages close.
17. Activate the deferred sensor-validity/RTD work in its approved order.

## Estimated execution time

These are planning estimates, not pass criteria. `Elapsed` includes automated
runtime, observation, and procurement where stated. `Hands-on` is expected
engineering/operator effort. Estimates assume both controllers remain
available, automation works as qualified, and no failure requires redesign.

| Order | Task | Estimated elapsed | Estimated hands-on |
| --- | --- | --- | --- |
| 1 | Complete Controller B configuration/calibration backup, program-recovery image, J-Link recovery, and safe-state baselines | `1–2 hours` | `1–2 hours` |
| 2 | Operator receives/labels/photographs the initial A/B pair; Pi app inventories it and preserves later cards as fresh reserves | `1–10 business days` procurement plus `1 hour` intake | `1 hour` |
| 3 | Pi app coordinates two baseline CID blocks, full-address scrubs, assignments, immutable campaign instances, and evidence directories | `1–2 hours` using A/B in parallel; `2–4 hours` serially | `1–2 hours` |
| 4 | Pi app coordinates Controller B malformed-update, injected update-failure, recovery, and conditional update-interruption qualification using the exact SMI bundle | `4–8 hours` | `3–6 hours` |
| 5 | Pi app coordinates injected HPT/USB failure qualification on A and B | `3–6 hours` | `2–4 hours` |
| 6 | Pi app coordinates power-off no-card and replacement/reboot classification on A and B; operator performs powered-off card handling | `1–2 hours` | `1–2 hours` |
| 7 | Pi app coordinates the five named HPT G-PWR interruptions on `F1-A1` and `F1-B1` through the separate power service | `8–16 hours` | `4–8 hours` |
| 8 | Review only unique Format/export failure messages | `COMPLETE` | `COMPLETE` |
| 9 | Run first-family initial-pair workload-based endurance and three wraps per sample | Duration follows measured workload completion with A and B in parallel | `3–6 hours` campaign setup/monitoring |
| 10 | Run two post-campaign CID captures, full scrubs, retained-window readback, charts, exports, and terminal dispositions | `1–3 hours` with A/B in parallel | `1–3 hours` |
| 11 | Review results and disposition every failure | `2–8 hours` if all pass; add `0.5–3 business days` per substantive failure | same as elapsed for investigation |
| 12 | Approve the first production family and disposition upstream HPT adoption and legacy cleanup | `4–8 hours` | `4–8 hours` |
| 13 | Run one recoverable pilot rollout and observation period | `1–3 business days` | `2–4 hours` |
| 14 | Release the frozen firmware and first approved card family together: final regression, evidence index, accepted risks, production restoration, docs, and workpackage closeout | `4–8 hours` | `4–8 hours` |
| 15 | Qualify each additional adaptive two-or-more-sample card family and add it to the approved pool | about `4–6 calendar days` when the initial A/B pair passes; longer when an added sample or investigation is required | `4–8 hours` per all-pass initial pair |
| 16 | Deferred temperature-profile recovery and steady-state regulation workpackage | provisional `5–10 engineering days` after activation | `3–7 engineering days` |
| 17 | Deferred temperature-sensor validity and RTD recovery workpackage | provisional `10–20 engineering days` after activation | `7–15 engineering days` |

There is no minimum calendar duration derived from endurance. Initial-release
duration follows measured workload completion, plus baseline/fault work and
post-campaign analysis, pilot, and release closeout. Each additional all-pass
initial pair follows the same workload-based rule and expands the approved-card
pool without delaying the initial release. A failed,
inconclusive, or infrastructure-damaged sample, unavailable controller,
procurement delay, or firmware correction extends the estimate and may require
an added specimen, candidate refreeze, or regression.
