Skip to content

STP-HW-001 Hardware Verification Protocol

Status: Final draft prepared for handoff (pending review)
Version: 0.9
Owner: BionicLoop engineering
Prepared by: BionicLoop engineering Reviewer: ____
Approver: ____
Decision date: ____
Effective date: ____
Baseline freeze SHA: ____
Last updated: 2026-04-06 15:20 EDT

Revision History

Version Date Author Summary of Changes
0.1 2026-03-27 Engineering Initial hardware verification protocol draft
0.9 2026-04-06 BionicLoop engineering Added handoff-ready document-control metadata for the software package

1. Purpose

Define the protocol for real-device verification on the trial-baseline phone and live peripherals.

2. Scope

This protocol covers hardware/system behavior that cannot be closed credibly with simulator or deterministic simulation evidence alone.

Primary coverage includes:

  • TV-RUN-007
  • TV-CGM-005
  • TV-PUMP-004
  • TV-PUMP-005
  • TV-STATE-003
  • hardware/system portions of:
  • TV-MEAL-010
  • TV-MEAL-011
  • TV-ALERT-012
  • TV-ALERT-013

3. Submission Baseline Hardware

  • Phone: iPhone 17e
  • CGM: Dexcom G7
  • Pump: Omnipod DASH

If another device is used for exploratory work, it must not be substituted for the formal trial-baseline evidence without explicit deviation approval.

4. References

5. Roles

  • Author: BionicLoop engineering
  • Executor: engineering / QA / clinical test operator
  • Reviewer: quality / design assurance
  • Approver: submission-quality owner

6. Prerequisites

  • Configured iPhone 17e with study build
  • Paired/active Dexcom G7 and Omnipod DASH
  • Device logging capture method available
  • Alert/notification permissions configured
  • Known app version, iOS version, and git SHA recorded

7. Core Hardware Scenarios

7.1 Restore / Relaunch / Reconnect

  1. Launch app with active paired devices.
  2. Force app relaunch and verify:
  3. pump and CGM managers restore cleanly
  4. no forced re-pairing
  5. Home cards reflect true state
  6. Trigger disconnect/reconnect cycles and verify recovery behavior.

7.2 Cadence / Wake / Continuity

  1. Run overnight or extended cadence observation.
  2. Verify anchored step continuity across natural wake gaps.
  3. Verify reset creates a fresh session.

7.3 BG and Reconnect Fallback

  1. Verify manual BG-driven stepping when CGM wake is absent.
  2. Verify BG-driven stepping when CGM wake exists but CGM is unusable.
  3. Verify reconnect fallback:
  4. only after first anchored step
  5. only after approved CGM-age gate
  6. current due step only
  7. no duplicate same-slot execution
  8. CGM regains priority when data resumes

7.4 Interruption Alerting

  1. Verify Algorithm Stepping Interrupted threshold timing.
  2. Verify blocker-specific content under live conditions.
  3. Verify clear-on-recovery and clear-on-disarm/reset.

7.5 Cloud-Log Evidence Workflow

If development-support cloud logging is used for a hardware run:

  1. Start an Integration Log Session in Home Settings before the scenario begins.
  2. Record the displayed test_run_id and UTC start time.
  3. Stop the session immediately after the scenario ends.
  4. Include the resulting test_run_id and UTC window in the STR package so the reviewer can retrieve the matching CloudWatch slice reproducibly.

8. Pass / Fail Criteria

  • Pass when required hardware scenarios behave as specified on the iPhone 17e baseline with complete evidence capture.
  • Fail when cadence, restore, fallback, or alert behavior diverges or evidence is incomplete.

9. Evidence to Capture

  • device model / iOS version / app build / git SHA
  • peripheral identifiers and session context as allowed
  • console logs
  • screenshots / screen recordings
  • timestamps for scenario start/end and observed events
  • if development-support cloud logging is used, also record:
  • test_run_id
  • UTC start/end
  • selected upload threshold
  • explicit note that the session was started before execution and stopped after execution
  • STR target path:
  • Docs/Quality/Evidence/Formal/STR-HW-001/<run-label>/

10. Traceability

TV-* ID Hardware Topic
TV-RUN-007 Reconnect fallback on live hardware
TV-CGM-005 Step-interruption detection on live device
TV-PUMP-004 Home pod-card live transition behavior
TV-PUMP-005 Delivery-state clear via live refresh
TV-STATE-003 Pump/CGM relaunch persistence without re-pair