# Project Map: HPT2 qualification

Status: approved
Type: project-map
Updated: 2026-08-27
Next Action: develop an exact Program Roadmap proposal
Campaign: standalone
Campaign Reason: This map defines the HPT2 Qualification Project above the campaign layer; campaigns require a later, separately approved milestone plan.
Canonical Truth: docs/hpt-triple-circular-media-contract.md and docs/sd-card-operation-and-recovery.md
Source Idea Brief: work/ideas/idea-hpt2-qualification.md

## Purpose

Coordinate the HPT2 Qualification Project from the current synthesis in
`work/ideas/idea-hpt2-qualification.md`, with
`work/spikes/spike-hpt2-service-life-retrieval-performance-requirements.md`
preserved as its technical discovery source.
The project must prove that HPT2 can log, retrieve, graph, export, reopen, and
recover correctly and fast enough through supported service-life conditions.

This map is the PRM Plan Cycle output and project navigation surface. It
settles the proposed direction without approving the Program Roadmap,
campaign plan, implementation, or qualification execution.

## Plan Cycle

State: approved by owner on 2026-08-27

- Smallest valuable outcome: prove a truthful, bounded HPT2 service-life claim
  for logging, charts, exports, open, and recovery.
- Direction: measure the current maximum-relevant baseline before selecting
  direct seek, a recovery checkpoint, both, or neither.
- KISS structure: preserve the three completed milestones and add one final
  evidence-gated retained-history milestone with no more than five pass
  conditions.
- Visible unknowns: quantitative budgets, the minimum sufficient target
  matrix, required physical wrap/interruption depth, instrumentation boundary,
  and USB-evidence equivalence.
- Approval boundary: the owner approved this project-map direction on
  2026-08-27. Program Roadmap and campaign-plan approval remain separate
  exact-token gates.

## Core Qualification Claim

At the approved minimum and maximum supported geometries and representative
service-life states, HPT2:

- preserves correct production logging and essential-controller responsiveness;
- serves the newest 30 days for charts and no more than the newest 90 days for
  customer export;
- meets separately approved timing budgets for charts, exports, normal open,
  recovery, cancellation, and append interference; and
- avoids work that silently scales with unrelated years of retained history,
  except for an explicit, bounded fail-closed full-recovery scan.

## KISS Completion Policy

Only these conditions may expand or block the current milestone cycle:

1. a safety hazard;
2. proven data corruption or loss contrary to the approved contract; or
3. failure of the milestone's one explicit contribution to the core
   qualification claim.

All other findings must either narrow the supported claim or become later
work. Each milestone has one outcome and no more than five pass conditions.
Only one milestone cycle and, later, one campaign should be active at a time.

## Visual Map

```mermaid
flowchart LR
  M1[M1: Contract and baseline] --> M2[M2: Bound the expensive paths]
  M2 --> M3[M3: Qualify and close the claim]
  M3 --> M4[M4: Prove retained-history independence]
```

## Milestone Cycles

| Cycle | One outcome | Completion emphasis | Depends On |
| --- | --- | --- | --- |
| M1 | Approve a measurable HPT2 qualification contract and reproduce the current baseline. | Budgets, geometry, workload, correctness, and work counters are explicit. | none |
| M2 | Make every core path meet the approved bounded-work contract in deterministic tests. | Correctness retained; linear or days-long scans are resolved or explicitly limited to fail-closed recovery. | M1 |
| M3 | Prove and durably record the supported core claim on representative physical targets and service-life states. | Maximum geometry, wrap/reclaim, concurrency, interruption, recovery, CID identity, durable evidence, and truthful claim closeout. | M2 |
| M4 | Prove database-size independence with the smallest useful physical ladder. | Clean 100-day, 13-calendar-month, and two-year Controller A stores; identical newest-90-day export content; fail fast at each stage. | M3 |

## Binding Safety And Evidence Rules

- SD-card removal, insertion, or replacement requires controller power off.
  Powered hot swapping is prohibited.
- Every formal SD/controller evidence run includes the complete required CID
  identity block at baseline and after relevant replacement, power-off
  reinsertion, initialization, or reboot.
- Missing, slow, or failed storage must not block essential control,
  monitoring, alarms, UI, USB, or communications.
- No startup, retry, or recovery path may automatically initialize or format
  media.
- USB absence may be operator-overridden for execution without creating an
  HPT2 test failure. Such a run receives no formal qualification credit unless
  an approved equivalent evidence path captured the complete result.
- Technical result, evidence completeness, operator interruption, and test
  method or automation failure remain separate outcomes.

## Scope Boundaries

Included:

- HPT2 logging, chart, export, open, recovery, wrap, reclaim, cancellation,
  degradation, and concurrent-access performance;
- correctness and controller responsiveness while those paths run;
- algorithmic-work instrumentation needed to detect avoidable scaling; and
- reproducible host/model and physical-target qualification evidence.

Excluded unless a core claim or safety/data-integrity contradiction requires
it:

- qualification of a particular SD-card family or specimen;
- exposure of customer history older than 90 days;
- proof of physical NAND wear leveling or remaining flash life;
- broad USB device qualification beyond the existing standards-based product
  contract; and
- SD supply-chain, ECO, deployment, or release execution.

## Workstreams

| Workstream | Status | Lead Artifact | Depends On | Next Action |
| --- | --- | --- | --- | --- |
| Requirements and baseline | complete | work/evidence/hpt2-m1-contract-and-baseline-20260827.md | none | none |
| Bounded implementation | complete | work/evidence/hpt2-m2-bounded-core-paths-20260827.md | M1 | none |
| Physical qualification and claim closeout | complete | work/evidence/hpt2-m3-target-performance-20260827.md | M2 | preserve as completed evidence |
| Staged retained-history proof | proposed | Program Roadmap M4 | M3 | approve and execute the three-stage fail-fast campaign |

## Current Navigation

You are here:

- The Idea Brief is `promoted` and preserved as this Plan Cycle's discovery
  provenance.
- M1 through M3 and the graph-reconstruction remediation are completed history.
- The owner replaced the one-shot M4 experiment with one three-stage KISS
  ladder: 100 days, 13 calendar months, then two years.
- Each stage uses a clean chronological store with identical newest-90-day
  content, the exact final Release candidate, one graph reconstruction, and
  one full 90-day customer export. Failure stops the ladder.

Do next:

- [x] Preserve completed M1-M3 evidence and the exact final candidate.
- [x] Settle the three-stage retained-history direction.
- [ ] Approve Program Roadmap revision 5 and materialize only its M4 campaign.
- [ ] Execute stage 1 before preparing either larger fixture.

Avoid for now:

- creating more than one replacement campaign;
- incrementally appending older timestamps to an already current store;
- continuing to a larger fixture after a failed stage; and
- reopening wrap/reclaim, Controller B, retail-card, ECO, release, rollout, or
  unrelated abandoned SD-qualification work.

## Related Artifacts

- Discovery source: `work/ideas/idea-hpt2-qualification.md`
- Requirements spike: `work/spikes/spike-hpt2-service-life-retrieval-performance-requirements.md`
- Current Program Roadmap proposal: `work/roadmaps/roadmap-hpt2-qualification-r5.md`
- Parent firmware map: `work/maps/map-smi-firmware-stabilization-and-qualification.md`
- Current media contract: `docs/hpt-triple-circular-media-contract.md`
- Current operation and recovery contract: `docs/sd-card-operation-and-recovery.md`
- Work index: `work/index.md`
