# Idea Brief: Service 489 Unattended Run And USB Evidence

Status: exploring
Type: idea-brief
Updated: 2026-09-01
Next Action: settle the remaining USB-loss, certification-authority, and included-487 ordering details before promotion
Source Idea: IDEA-0001
Source Roadmap: PRM-0006

## Current Synthesis

### Idea

Extend firmware service 489 with a short guided initialization phase followed by deterministic ordered execution that is unattended between intentional intervention boundaries. The initialization phase captures the complete immutable session plan before destructive work begins, including whether to collect qualification evidence on USB and whether to include or bypass the service-487 72-hour endurance test.

When service 489 reaches the controlled-recovery boundary, service 486 durably arms the checkpoint and the process stops with an instruction to power the whole controller off and back on. After the controller has rebooted and become stable, the operator enters service 488. Service 488 validates the exact session, controller, firmware, catalog, live SD CID, checkpoint, representative-sector read, and media state. It then durably records the accepted resume, atomically consumes the entry point, and returns execution to service 489.

### Operator Initialization

Before starting the ordered run, service 489 must collect and durably record:

1. The bound controller, firmware candidate, service catalog, live SD CID, media readiness, and destructive authority.
2. Whether to run service 487:
   - `INCLUDE_487`: run the approximately 72-hour endurance leaf as part of the selected plan.
   - `BYPASS_487`: require explicit confirmation, record the bypass reason, and prevent the run from being represented as endurance-complete or certification-ready.
3. Whether to record qualification evidence to USB:
   - `USB_YES`: require a mounted, writable, standards-conforming USB Mass Storage device; verify sufficient capacity; create a unique session directory; and pass a bounded write/close/reopen/content check before destructive work starts.
   - `USB_NO`: require an explicit evidence override and preserve the distinction between technical test outcome and evidence completeness.
4. A final review of the ordered plan, inclusions, exclusions, intervention boundaries, USB destination when selected, and expected duration, followed by one final start confirmation.

The finalized plan is immutable for that session and must survive controller restart.

### USB Session Evidence

When USB evidence is selected, service 489 creates one unique session folder identified by time/run identity plus non-sensitive controller and CID suffixes. It writes artifacts into that same folder throughout the run and across the 486/488 reboot boundary. The evidence set includes:

- session plan and identity block;
- append-only event/progress stream;
- one result area per selected service;
- explicit skipped-service records and reasons;
- interruption, reboot, and resume records;
- final result with separate workflow, technical, method/performance, and evidence states;
- a manifest of artifact sizes and hashes; and
- a completion marker written only after successful finalization.

The controller's existing durable qualification journal remains execution authority. USB is an evidence destination and must not become the source of resume truth. USB handling must remain standards-based and must not introduce vendor-, model-, capacity-, serial-, timing-, or specimen-specific production behavior.

### Result Semantics

The final result must distinguish at least:

- `PASS_FULL`: all selected full-run requirements, including service 487, completed and passed; this may be certification-review-ready only if the separately defined evidence and approval gates are also satisfied.
- `PASS_FOCUSED_487_BYPASSED`: all selected focused tests passed, service 487 was intentionally bypassed, and the run is not endurance-complete or certification-ready.
- `FAIL`: a selected test reached a terminal failure.
- `INCOMPLETE`: execution or required evidence did not reach a valid terminal state.

A bypass is never reported as a pass. Firmware may produce a certification-review evidence package but does not itself grant certification or independent evidence admission.

## Decisions

- Preserve IDEA-0001's shared leaf engine and Option A authority split: firmware owns leaf execution and ordered service-489 workflow; the Pi/web qualifier remains the independent witness, evidence ingester/admission authority, and reviewer/family-disposition surface.
- Put the USB evidence question and the service-487 include/bypass question in service 489's initialization phase.
- Require explicit confirmation for `BYPASS_487`; persist the selection before destructive work and prohibit changing it mid-run.
- Pause at the service-486 controlled-recovery boundary for whole-controller power-off/on. Resume only through service 488 after the controller is stable and every identity/state check passes.
- Reuse one USB session folder across the reboot and write evidence incrementally rather than only at final completion.
- Keep the internal durable journal authoritative and preserve fail-closed, identity-bound, no-automatic-replay behavior.
- Treat this as follow-on scope. It does not retroactively change the completed PRM-0006 Work2 result or give service 487 endurance credit.

## Constraints And Non-Goals

- Powered SD-card removal or insertion remains prohibited. A qualified whole-controller interruption is the recovery mechanism.
- USB evidence support must use the broad standards-conforming USB Mass Storage class and FileX surface; it must not add specimen-specific behavior.
- Selecting `USB_NO` may bypass only USB evidence collection, not CID binding, destructive confirmation, recovery safety, or another selected leaf prerequisite.
- The current requirement captures service-487 selection and bypass semantics; it does not claim that service 487 has passed hardware endurance qualification.
- No firmware change, build, controller programming, media destruction, Pi runtime mutation, production release, or certification action is authorized by this Idea Brief.

## Open Questions

- If an initially viable USB becomes unavailable or unwritable during the run, should service 489 continue with `USB_EVIDENCE_INCOMPLETE`, pause for operator action, or fail the selected evidence requirement?
- What minimum free-space calculation and reserve must the initial USB viability check enforce for focused and 72-hour profiles?
- What exact artifact schema, timestamp source, hash/finalization rules, and optional signing mechanism make a package acceptable for certification review?
- When service 487 is included, should it execute immediately before the service-486 power-interruption boundary, or at another catalog-defined point?
- Can an authorized automated bench power controller satisfy the 486 intervention while keeping 488 as the explicit operator entry point?
- What exact A/B controller and coordinator qualification matrix is required before this follow-on behavior can receive release credit?

## Exploration Log

### 2026-09-01

- The owner requested an upfront USB choice. When selected, service 489 must confirm a viable inserted USB drive, create a unique session folder, stream qualification artifacts into it during execution, and produce a final result suitable for certification review.
- The owner selected a deliberate 486 pause: stop for whole-controller power-off/on, then expose service 488 as the stable-boot entry point that validates and consumes the resume checkpoint before service 489 continues.
- The owner required service 489 initialization to ask whether the approximately 72-hour service-487 endurance leaf should be bypassed. A bypassed run remains a focused result and cannot represent 487 as passed.
- This brief is linked follow-on discovery because IDEA-0001 and PRM-0006 are already promoted/completed provenance and PRM-0006 explicitly excluded service 487 and USB media work from Work2.
