# Evidence: SD qualification lifecycle synchronization

Status: complete
Type: evidence
Updated: 2026-07-26
Next Action: none; use the synchronized policy for candidate intake and fixture workflow review
Parent: work/wp/completed/wp-synchronize-sd-qualification-lifecycle-across-firmware-and-qualifier.md

## Scope

Synchronize the accepted remote card-model qualification lifecycle with the
firmware workspace's controller, safety, evidence, candidate, and release
planning surfaces. No controller programming, J-Link mutation, physical-media
operation, formatting, fault injection, or power interruption occurred.

Remote authority inspected and updated:

`jong@srv-rpi00.local:~/dev/sd_qualification`

## Synchronized policy

- Begin each campaign with at least two fresh expendable specimens.
- The current SMI profile assigns one initial counted sample to Controller A
  and one to Controller B.
- Require at least two counted complete passes, all assigned campaign
  coverage, immutable terminal evidence, and reviewer approval.
- Add a third or later specimen only for a recorded replacement,
  investigation, inconclusive, infrastructure-damaged, or
  additional-coverage reason.
- Never let later passes outvote a confirmed media-family failure.
- Block approval for unresolved firmware, controller, method, automation,
  evidence, infrastructure, or safety failures.
- Create a new immutable campaign for requalification or a changed release
  scope.
- Run the read-only CID-pinned full-address scrub before destructive
  authorization or HPT initialization and repeat it after the campaign.

## Local planning result

- GIGASTONE's two ordered cards may form its initial A/B pair if both pass
  intake.
- A one-card Lexar order requires one additional matching card, not two.
- KEXIN begins with an A/B pair; remaining cards stay fresh until justified.
- Minimum first-family endurance is one concurrent `72-hour / 3-day` A/B wave
  rather than two waves for a fixed three-card population.
- The estimated minimum initial-release duration is `6–8 days` after the
  initial pair is available, down from `9–11 days`, assuming no added sample or
  investigation is required.

## Remote implementation and deployment

- Remote commit: `8c2e7e0` (`Enforce adaptive A/B qualification lifecycle`).
- Django system check: PASS.
- Migration drift check: PASS.
- Fixture tests: PASS, `22/22`.
- Logical backup:
  `/backups/sd-qualifier-20260726T185503Z.dump`.
- Disposable restore check: PASS.
- Applied migration:
  `qualification.0004_qualification_policy_enforcement`.
- Application image:
  `sha256:1905814f65ee978179e5c0c30689eb4ffe23343f685fdf8ac7b212c22b1952f2`.
- Public health: PASS, HTTP `200`, database ready, `fixture_only: true`.
- Active commands before/after deployment: `0` / `0`.
- Active notifications before/after deployment: `0` / `0`.

## Local verification

| Check | Result |
| --- | --- |
| `script/check-sd-qualification-lifecycle-policy.ps1` | PASS, `16/16` |
| Integrated `script/check-hpt-commissioning.ps1` | PASS, `95/95`, including lifecycle `16/16` |
| Tool Shed stale-path check | PASS in both workspaces before closeout move |
| Tool Shed work-state review | PASS; both workspaces reconciled before closeout move |
| Cross-workspace active-policy scan | PASS; no active fixed-three rule or stale pre-implementation qualifier claim |
