Skip to content

Controlled Software Risk Analysis

Status: Frozen-baseline risk analysis approved for IDE submission Version: 1.53 Owner: BionicLoop engineering
Prepared by: BionicLoop engineering Approval reference: Edward R. Damiano, PhD, residual-risk acceptance and final software-package approval, controlled email dated 2026-09-07 EDT Baseline freeze SHA: 91c0e98a9bc9429a0486bebdebffc7d8dbbe300e Scope: BionicLoop investigational closed-loop app (Dexcom G7 + OmniPod DASH + Algo2015) Last updated: 2026-09-08

Revision History

Version Date Author Summary of Changes
0.1 2026-03-25 Engineering Initial controlled draft baseline
0.9 2026-04-06 BionicLoop engineering Added controlled-document metadata and refined software-only cybersecurity boundary language for RA-009.
0.91 2026-04-07 BionicLoop engineering Tightened residual-risk wording for local telemetry exposure, investigational clinical gating, and reconnect-fallback behavior to match the current baseline and remaining freeze-time evidence posture
0.92 2026-04-08 BionicLoop engineering Added masked-fallback maintenance and restore guardrail wording for the masked offline-fallback design
0.93 2026-04-08 BionicLoop engineering Clarified masked-fallback deferred-maintenance and recoverable-restore controls for the implemented design
0.94 2026-04-14 BionicLoop engineering Added reconciliation-required blocked-state controls after offline mask expiry for the masked-fallback design
0.95 2026-04-14 BionicLoop engineering Added reconnect restore/disarm retry and explicit fresh re-arm controls for pending masked-fallback recovery
0.96 2026-04-14 BionicLoop engineering Updated masked-fallback recovery risk controls to describe same-session unreconciled resume as the current feasibility path after successful restore
0.97 2026-04-15 BionicLoop engineering Added pod total-delivery baseline and modeled-vs-pump-reported fallback review controls for the masked-fallback design
0.98 2026-04-15 BionicLoop engineering Added confirmed/corrected basal-only reconnect replay controls, persisted replay-plan state, and replay-detail review visibility for the masked-fallback design
0.99 2026-06-02 BionicLoop engineering Updated masked-fallback controls to pump-delta missed-step algorithm replay and added repeated no-active-pod critical alert controls
1.00 2026-06-06 BionicLoop engineering Added same-pod continuity as a replay authorization control and formalized explicit-operator-only algorithm session lifecycle
1.01 2026-06-08 BionicLoop engineering Added schedule-weighted replay allocation controls and zero-weight no-replay behavior for credible same-pod pump delta
1.02 2026-06-11 BionicLoop engineering Clarified that fallback replay is bounded to confirmed fallback-active missed slots and excludes pre-activation disconnected gaps
1.03 2026-06-12 BionicLoop engineering Added generalized issued-dose attribution controls for interrupted automatic bolus commands and different/new-pod no-replay disposition
1.04 2026-06-13 BionicLoop engineering Hardened issued-dose risk controls for non-credible delivered-unit evidence, old-pod delivery input scrubbing, and automatic resume blocking
1.05 2026-06-15 BionicLoop engineering Updated different/new-pod issued-dose control to assume delivered without blocking replacement-pod dosing; documented possible 4-hour adaptation-forget control pending team signoff
1.06 2026-06-17 BionicLoop engineering Added explicit meal-progress pod-replacement escape that records assumed-delivered evidence before clearing trapped UI state
1.061 2026-06-18 BionicLoop engineering Added retired/expired/no-active-pod fallback recovery control that uses assumed modeled fallback exposure when connected pump evidence is no longer recoverable. (Renumbered 2026-07-09: this row previously duplicated version 1.06.)
1.07 2026-07-08 BionicLoop engineering Added verification-backed liveness bound for the accepted issued-dose skip-and-wait/no-boundary-cancel policy.
1.08 2026-07-10 BionicLoop engineering RA-014 control hardened after a field-observed dual-instance isolation defect: the safety-track instance shared the C++ process-global state, halving buffer-time safety windows (observed 34-min forced open-loop vs designed 60); resolved with symbol-isolated per-instance algorithm copies and isolation regression tests. Connected-outage zero-insulin window recorded as ANOM-003 pending clinical policy.
1.09 2026-07-10 BionicLoop engineering Independent review: added the qualitative risk-scoring framework (severity/probability scales, risk matrix, acceptability criteria) and per-row S×P ratings; added RA-018 (connected-outage zero-insulin window, ANOM-003) and the overall residual-risk/benefit-risk conclusion; controls restated as shipped behavior (feasibility-work phrasing retired); RA-011 forced-open control aligned to the informational-first/fingerstick copy; RA-015 pending freeze decision moved to the acceptance notes; RA-005 residual resolved to Low; RA-014 linked to SRS-ALG-008. Header version corrected (1.07 -> 1.09; the 1.08 row landed without a header bump).
1.10 2026-07-13 BionicLoop engineering RA-018 acceptance note updated with the received clinical policy answer (2-hour fingerstick cadence with conditional hourly escalation, no maximum-offline hard stop); residual stays provisional pending sponsor-approved design, implementation, and verification.
1.11 2026-07-14 BionicLoop engineering RA-018: dropout-clock characterization complete (fingerstick restarts the full 60-minute window - real-C++ pins) and the backup-basal bridge design clinically approved (Camille Powe, MD, 2026-07-14); residual stays provisional pending implementation and verification.
1.12 2026-07-14 BionicLoop engineering RA-018 controls updated to the implemented fingerstick-supported CGM-outage dosing behavior (schedule, tiered alerts, countdown, backup-basal bridge, no-stop rationale) with residual re-stated (implemented + unit-verified; formal and physical evidence pending); RA-017 verification links gain TV-PUMP-010 (pump-command watchdog implemented).
1.13 2026-07-14 BionicLoop engineering RA-013 controls extended per clinical IFU-review feedback: first-launch Standard/120/75%/40 defaults (never rewriting persisted values) and the New Participant Reset participant-data wipe for reused phones (also supports the RA-009 local-data posture between participants).
1.14 2026-07-14 BionicLoop engineering Independent review alignment: RA-017 controls corrected to the implemented assumed-delivered-per-clinical-policy disposition (stale no-guess/hold wording removed; the future 4-hour adaptation mitigation moved from controls to the acceptance notes per Method) and gains SRS-PUMP-011 + the pump-command watchdog control; RA-013 armed-case wording aligned to the guided stop-then-reset flow with SRS-CLIN-013/014 and TV-CLIN-014/015 links; RA-018 gains SRS-OUTAGE-001..006 + TV-OUTAGE-001..003 links and the OS-notification-permission control gap (in-app surfacing identified as a gap); RA-014 residual rationale made explicit (harm-vs-occurrence basis after the dual-instance isolation incident, provisional); Residual Probability Rationale section added; severity-scale confidentiality note added; RA-019 added (unintended New Participant Reset); Overall Residual Risk Conclusion rewritten to enumerate the provisional rows and retire the already-made ANOM-003 clinical-disposition condition.
1.15 2026-07-16 BionicLoop engineering RA-020 added (discovered in live field data during a sponsor outage drill): backup basal delivered during a connected CGM-outage window is not counted by the algorithm - error direction is toward extra insulin, bounded by fallback rate × outage duration. Interim control shipped same day (release windows quantified on the engaged fallback event at re-arm: duration + modeled schedule exposure, resumed_without_reconciliation); planned control is algorithm-side accounting (differential replay and simulated-outage verification), blocking for any human-use build. This field test carried no exposure risk (saline, no participants).
1.16 2026-07-17 BionicLoop engineering RA-021 added (coverage review, 2026-07-17): subject weight was the one dose-scaling clinical input with no plausibility bounds before the algorithm. Mitigated same day: SRS-CLIN-015 save-gate range 50-500 lbs, store top-clamp, and 20-230 kg algorithm last rail (TV-CLIN-016). Range flagged for sponsor confirmation.
1.17 2026-07-17 BionicLoop engineering RA-009 re-scored High to Low (sponsor-approved closure package): file sharing removed, CSV sealed to the gated share with complete protection + backup exclusion, spool protected, redundancy role replaced by SRS-LOG-012 provable delivery with BionicScout completeness visibility. The freeze export-posture condition is resolved: decided, not deferred.
1.18 2026-07-17 BionicLoop engineering Coverage review made the RA-020 mechanism statement precise by naming phantom assumed-delivered mode-2 asks and uncounted backup basal, with drill-1 net-direction evidence and recorded-sequence differential quantification. Extended RA-019 controls for the SRS-CLIN-014 v1.41 telemetry drain guard with a pre-confirmation final flush, undelivered-count consent line, best-effort telemetry.outbox.discarded marker before erasure, and sequence-continuity-preserving erasure.
1.19 2026-07-18 BionicLoop engineering RA-020 controls extended (sponsor-directed, 2026-07-18 field incident): the accounting control is implemented, and pod-away gap reconciliation within a released window is recorded as replay-based (time-positioned schedule-weighted rows via the standard bounded fallback replay; baseline re-anchor; exactly-once accumulation) rather than a single reconnect-step chunk - the chunk positions the whole gap delta at the pre-gap request step, and the measured real-C++ divergence (Algo2015OutageGapPodAwayReplayCharacterizationTests) is cited in the controls cell.
1.20 2026-07-18 BionicLoop engineering RA-020 controls corrected from the independent safety review of the gap-replay work: row shares restated as 0.01 U-quantized largest-remainder allocation with engine-ledger conservation pinned against the real C++ on the field and overnight shapes (fractional shares had inflated the C++ ledger +0.03 U / +0.14 U; sponsor sign-off flagged for the quantized-time-positioning policy); the credit context now persists inside the replay plan, closing the force-quit-at-mid-pass-save double-count (reviewer probe fed 0.29999 U for a physical 0.15 U; now conserved exactly); measured chunk-vs-replay numbers refreshed for the quantized lane (0.1235 vs 0.0811 U reconnect IOB, two 0.05 U batches freed earlier, residual gap bounded by dosed divergence).
1.21 2026-07-18 BionicLoop engineering Documentation truth-sync: RA-020 is restated as an implemented control rather than a planned control; residual closure remains conditional on sponsor sign-off for the 0.01 U quantized time-positioning policy, the exact hardware re-drill, independent safety-review completion, merge designation, and formal-lane execution. RA-009 acceptance and the overall residual-risk conclusion are aligned to the sponsor-approved 2026-07-17 closed posture, including implemented protection/backup exclusion for enumerated Algo2015 diagnostics.
1.22 2026-07-19 BionicLoop engineering RA-004/011/012 controls aligned to exact-step pending-fingerstick meal execution and same-severity pump-signal precedence: combined BG + meal is real-C++-characterized and dual-track pinned; stale/invalid/pump-unavailable negative paths remain blocked; signal loss cannot be masked by a newer check-BG prompt.
1.23 2026-07-20 BionicLoop engineering RA-010/011/012/018 controls aligned to the spatially separate exact-value Manual BG review and the shared Home gold emphasis for direct check-BG, due-soon, and overdue fingerstick requests.
1.24 2026-07-21 BionicLoop engineering RA-017 issued-dose completion evidence hardened after review against the 2026-07-08 cancel/relaunch incident: a zero DASH bolusNotDelivered register cannot overwrite persisted partial-delivery evidence; only explicitly persisted in-progress-capped provenance can authorize a higher settled observation. Canceled and legacy-unclassified partials remain authoritative, with regression coverage at the adapter, runtime, and persistence boundaries.
1.25 2026-07-21 BionicLoop engineering RA-004 control closes the borrowed-step forced-open race: the last qualifying glucose step is persisted, prospective meal availability blocks the characterized 13th blind step, and the coordinator repeats the check before accepted-meal persistence. Fresh CGM and valid exact-step BG remain the only glucose exceptions; rejection creates no meal/algorithm/pump action and gives explicit no-delivery feedback.
1.26 2026-07-22 BionicLoop engineering RA-004 participant guidance corrected for connected busy pumps: active .delivering status now produces wait-for-delivery guidance even when attribution is pending; reconnect guidance remains for idle unresolved delivery. The blocking control and dosing behavior are unchanged.
1.27 2026-07-24 BionicLoop engineering Added RA-022 for an incorrect, absent, stale, or safety-profile-mixed Temporary Target, with persisted absolute expiry, execution-time primary resolution, permanent-target safety/fallback separation, explicit activation gates, UI/notification visibility, reset handling, and app-to-Scout telemetry controls.
1.28 2026-07-30 BionicLoop engineering Extended RA-010/RA-011 controls for relocating the existing suspend/resume action to Exercise and Insulin Delivery, removing the duplicate Pod Settings action, preserving manual-resume reminders and disabled unsafe states, and routing suspend-alert actions to the control.
1.29 2026-07-30 BionicLoop engineering Extended RA-010 controls so Manual BG and Meal Announcement remain persistently visible in the Home bottom safe area while variable-length status, alert, and chart content scrolls.
1.30 2026-07-30 BionicLoop engineering Extended RA-011 controls so an ended suspension reminder provides a direct serialized resume action and escalates to a fresh safety-critical alert/notification after 15 minutes if insulin remains suspended.
1.31 2026-07-30 BionicLoop engineering Extended RA-004/RA-017 controls for suspended-meal rejection before algorithm execution and matching-only cleanup of definitively blocked bolus metadata so DASH status reconstruction cannot fabricate and repeatedly feed an undelivered meal dose.
1.32 2026-07-30 BionicLoop engineering Added RA-023 for stale old-sensor binding and wrong-nearby-sensor adoption, controlled by explicit persistent replacement mode, staleness non-adoption, authenticated discovery, participant guidance, durably deduplicated telemetry, and required multi-device physical validation.
1.33 2026-07-31 BionicLoop engineering Extended RA-015 controls so interruption guidance cannot retain a stale CGM diagnosis when suspension or fallback recovery actually blocked stepping; blocker state now follows the latest unresolved outcome and clears after successful live execution. Extended RA-019 reset controls so asynchronous G7 persistence/telemetry completion cannot recreate outgoing-participant state.
1.34 2026-08-06 BionicLoop engineering Extended RA-008 auditability controls so Recent Dose Steps identifies valid fingerstick input, displays its exact value, and preserves concurrent CGM evidence.
1.35 2026-08-11 BionicLoop engineering Extended RA-014 controls after field telemetry identified a host mapping defect that omitted concurrent basal insulin from meal-step commands and caused explicit Algo2015 reconciliation rejection.
1.36 2026-08-11 BionicLoop engineering Aligned RA-013 with the implemented clinical-configuration boundary (staff initial setup only while configuration is unset; offline unlock for all later access/edits) and removed obsolete development labels from the implemented RA-020 control.
1.37 2026-08-13 BionicLoop engineering Extended RA-009 controls after field telemetry backlog amplification: update-safe incremental spool migration, retained-evidence-first recovery, aggregate chatter-drop reporting, transition-only notification telemetry, and passive backlog visibility; no score change.
1.38 2026-08-17 BionicLoop engineering Strengthened RA-009 controls with an uncapped retained-clinical SQLite ledger, durable-enqueue/network separation, retry liveness, bounded batch recovery with single-route fallback, and complete protected active-session step evidence; no score change.
1.39 2026-08-20 BionicLoop engineering Extended RA-012 controls so pending fingerstick BG is visibly distinct from completed algorithm use, with persisted submission time, evidence-only fill, and same-target deduplication; no score change.
1.40 2026-08-20 BionicLoop engineering Added RA-024 for wrong-session or internally inconsistent legacy Algo2015 recovery export; extended RA-009 local-data controls to the clinical-gated protected ZIP staging/share path.
1.41 2026-08-20 BionicLoop engineering Revised RA-009/024 controls for the combined CSV/Algo2015 ZIP shared through Recent Dose Steps; exact missing epochs now produce CSV-only output and competing Settings presentations were removed.
1.42 2026-08-20 BionicLoop engineering Extended RA-015 controls so a proven fresh idle Pod refresh replaces stale reconnect guidance without waking the algorithm, while stale/non-idle/no-Pod evidence cannot falsely claim recovery; no score change.
1.43 2026-08-20 BionicLoop engineering Extended RA-010 controls with point-only CGM chart rendering so discrete sensor samples are not visually interpolated by a connector line or area fill; no score change.
1.44 2026-08-21 BionicLoop engineering Bound the controlled risk analysis to the immutable 2026-08-21 software freeze; clarified that engineering execution is complete while sponsor approval and residual-risk acceptance remain pending. No hazard, control, score, or product behavior changed.
1.45 2026-08-21 BionicLoop engineering Synchronized current row conclusions and overall benefit-risk status to the exact-freeze execution report. STP-ALG-001 passed behaviorally with ALG-DEV-SA-006; app/SIM/scoped-security execution completed with the identified UI and cybersecurity deviations still open. Superseded candidate states remain in this revision history. No hazard, control, score, or product behavior changed.
1.46 2026-08-25 BionicLoop engineering Recorded Camille Powe, MD's 2026-08-21 written clinical confirmation of 0.01 U schedule-weighted allocation with total conservation, RES-004 fallback activation when CGM freshness cannot be established, and the 50...500 lb participant weight-entry range with the 20...230 kg algorithm rail. Clinical policy confirmation is closed; organizational residual-risk acceptance and retained physical-claim decisions remain sponsor decisions. No hazard, control, score, or product behavior changed.
1.47 2026-08-25 BionicLoop engineering Added the exact-freeze 6/6 algorithm linkage companion and corrected 44/44 serial UI companion, closing ALG-DEV-SA-006, AUTO-DEV-001, and AUTO-DEV-002. Original execution records remain unchanged. No hazard, control, score, or product behavior changed.
1.48 2026-08-27 BionicLoop engineering Recorded clinical approval of the first-step Dexcom requirement, non-synthesized CGM-gap handling, investigational Clinical Settings access, supportive Scout role and official study sources, physical-use and human-factors claim boundaries, and protocol correction for the distinct fingerstick mode. No hazard, control, residual score, product behavior, or formal result changed.
1.49 2026-08-27 BionicLoop engineering Replaced internal development labels, test-device shorthand, obsolete package language, and an unselected future-mitigation note with reviewer-neutral current-state descriptions. No hazard, control, score, or product behavior changed.
1.50 2026-08-28 BionicLoop engineering Corrected the residual risk-level labels for RA-020, RA-021, and RA-022 from Low to Medium so they match the controlled S3×P1 matrix cell. Severity, probability, controls, verification, and product behavior are unchanged; residual-risk acceptance remains an approval action.
1.51 2026-09-03 BionicLoop engineering Proposed deferring the RA-023 controlled multi-device G7 bench exercise from submission assembly until before first participant deployment, subject to dated Sponsor/Clinical approval and a no-participant-deployment condition until testing and final disposition are complete. Clarified that the app has no authoritative Dexcom handoff identity and that authenticated acquisition alone does not identify the intended participant sensor. No hazard, control, severity, probability, residual score, product behavior, or verification result changed.
1.52 2026-09-03 BionicLoop engineering Recorded the Build 843 RA-023 adversarial review: CGM-screen reentry can replace the persisted acquisition manager; concurrent candidates lack an atomic single-winner adoption gate; post-connection comparison is detection rather than a gate on first-reading use; and device-lifecycle replacement may begin without planned physical isolation. Expanded D06 pre-deployment disposition and test conditions. No product source, formal test result, or existing risk score changed; final residual-risk acceptance remains open.
1.53 2026-09-03 Software Developer Added the required RA-023 probability discriminator and sponsor sub-decision, removed deferred BG controls from the active RA-012 claim, and aligned the residual rationale with the supportive-Scout boundary. The provisional score is unchanged pending D06.

Method

This risk analysis follows a qualitative process consistent with ISO 14971 concepts, scoped to the investigational software baseline. Each hazard is tracked with:

  • RA-ID
  • hazard statement
  • initial (pre-control) risk level with severity × probability rating
  • controls (implemented behavior only; pending or planned work is never listed as a control)
  • linked requirements (SRS-*)
  • linked verification (TV-* / manual protocol IDs)
  • residual (post-control) risk level with severity × probability rating

Severity scale

Rating Name Definition (harm to the study participant)
S3 Critical Could cause severe hypoglycemia, or hyperglycemia/DKA requiring medical intervention (incorrect, missing, or unaccounted insulin delivery; missed safety-critical alert)
S2 Serious Could cause reversible or temporary harm, delayed therapy, or loss of the data/oversight needed to protect the participant
S1 Minor Nuisance or inconvenience with no plausible path to participant harm

Confidentiality/data-exposure harms (RA-009, RA-013, RA-019) are rated on this same participant-harm scale through their downstream effect (S2: loss of the data or oversight needed to protect the participant); no separate confidentiality severity dimension is maintained at this investigational scale.

Probability scale (qualitative, per study exposure)

Rating Name Definition
P3 Frequent Expected to occur routinely during the study in the absence of controls
P2 Occasional Plausible during the study; precipitating conditions have been observed in development or field use
P1 Improbable Not expected during the study with controls in place; requires multiple independent failures or deliberate misuse

Risk level matrix

P1 Improbable P2 Occasional P3 Frequent
S3 Critical Medium High High
S2 Serious Low Medium High
S1 Minor Low Low Medium

Acceptability criteria

  • High residual risk is not acceptable by default: it requires further risk control, or documented explicit acceptance with rationale recorded in this document and confirmed at freeze designation.
  • Medium residual risk is acceptable when the listed controls are implemented and linked to passing verification.
  • Low residual risk is acceptable.

Register entries are shown as Level (S×Py). Initial ratings assume no software controls; residual ratings assume the listed controls with their linked verification. Probability rates the occurrence of harm (hazard occurrence and failure of the remaining safeguards), not merely of the triggering condition.

Risk Register

RA-ID Hazard Initial Risk Key Controls SRS Links Verification Links Residual Risk
RA-001 Loop step not executed on expected cadence due to iOS wake variability High (S3×P3) CGM-triggered doWork, bounded wake-cause policy, cadence anchor, skip logic, stale-state visibility SRS-RUN-001, SRS-RUN-002, SRS-RUN-003, SRS-UI-001 TV-RUN-001, TV-RUN-002, TV-RUN-003 Medium (S3×P1)
RA-002 Invalid CGM values used as real glucose input High (S3×P2) Out-of-range sanitize to unavailable (-1), step-0 gate, degraded-step safety policy, explicit blocked-state messaging SRS-CGM-001, SRS-CGM-002, SRS-CGM-003, SRS-CGM-004 TV-CGM-001, TV-CGM-002, TV-CGM-003, TV-CGM-004 Medium (S3×P1)
RA-003 Pump unavailable causes incorrect delivery behavior High (S3×P2) Degraded algorithm input with unavailable pump fields, command block on unavailable pump, auto-refresh delivery-state convergence, and closed-loop-only command exposure (no manual bolus path). The masked offline-fallback subsystem adds layered guardrails: maintenance arm/refresh is gated to active algorithm sessions with a newly completed successful step, newly computed first-arm fallback is attempted before the same step's pump command so step 0 bolus delivery cannot outrun fallback schedule programming and masking, pre-command first-arm maintenance skips unavailable/unknown refreshed pump status instead of bypassing normal pump-command classification, pre-execution arm/renew/refresh maintenance requires a fresh idle pump-status refresh and defers without pod mutation when status is unavailable/unknown/delivering or refresh fails, disruptive schedule writes are blocked during active bolus / unsafe / unknown pump-delivery states, an already-active 0 U/hr mask enters renewal in the final 20 minutes of its 30 minute window and blocked renewals are treated as deferred while the current mask is still active, clean first-arm blocks leave fallback unarmed but do not automatically suppress the normal step command or retry again in the same cycle, any remask failure after possible schedule mutation or mask replacement, including late post-schedule pump blocks and existing-mask renewal failures, persists reconciliation-required recovery and blocks normal command flow, the mask may be allowed to expire only when successful loop stepping stalls or deferred maintenance runs out of remaining mask time so fallback insulin can autonomously resume, offline mask expiry now persists reconciliation-required recovery state instead of allowing ordinary authoritative live stepping to continue, reconnect/start/foreground now retry connected restore/disarm while that recovery remains pending, confirmed/corrected basal-only reconnect evidence now drives no-command missed-step primary/secondary algorithm replay only for missed delivery slots overlapping confirmed fallback-active time using CGM=-1 and per-step pump-delivery allocations only from credible pump-reported delivered insulin with proven same-pod continuity, disconnected missed slots before offline fallback activation are left missing rather than replayed as synthetic delivery rows, replay allocation weights those pump-reported units by the persisted programmed fallback schedule rather than by a scalar guess, positive pump delta with missing/zero schedule weight suppresses replay, invalid/not-required/stale pending replay plans are cleared after trace emission rather than retried against later wakes, ambiguous/new-pod/unknown-identity/history-discontinuous reconnect evidence remains explicitly marked as unreconciled/no-replay for operator review instead of being treated as authoritative reconciliation, and retired/expired/no-active old-pod recovery may use persisted schedule-modeled exposure as assumed delivered with explicit assumed-delivered labeling when pump-counter evidence is no longer recoverable. Broader ambiguous/non-basal reconstruction is explicitly deferred from this baseline (see the scope and deferred-items register). SRS-PUMP-001, SRS-PUMP-002, SRS-PUMP-005, SRS-PUMP-006, SRS-PUMP-007, SRS-PUMP-008, SRS-PUMP-009, SRS-RUN-006 TV-PUMP-001, TV-PUMP-002, TV-PUMP-005, TV-PUMP-006, TV-PUMP-007, TV-PUMP-008, TV-RUN-008 Medium (S3×P1)
RA-004 Meal announce accepted while pump not safe/ready High (S3×P2) Meal announce pump-ready gating requires an active Pod with known idle delivery state; unavailable-reason messaging distinguishes delivering, suspended, signal-loss, and reconciliation states. A live .delivering status presents wait-for-delivery guidance; .suspended presents resume-before-meal guidance; idle unresolved attribution retains reconnect guidance. The app persists the algorithm step that consumed the last qualifying glucose and blocks a borrowed/due meal step that would cross the characterized 12-step blind tolerance, both in UI preflight and again in the coordinator before meal persistence. Fresh CGM or a valid pending manual BG assigned to the exact prospective meal step may permit that step so glucose and meal share the input; stale, future, invalid, pump-unavailable, signal-loss, suspension, and reconciliation states remain blocked. A suspension rejection performs no meal persistence, algorithm execution, cadence advancement, pump command, or delivered-dose chart entry; pump-confirmed resume revalidates availability without waiting for a loop step. SRS-MEAL-001, SRS-MEAL-002, SRS-MEAL-003, SRS-MEAL-004, SRS-MEAL-005 TV-MEAL-001, TV-MEAL-002, TV-MEAL-003, TV-MEAL-004, TV-MEAL-005, TV-MEAL-006 Medium (S3×P1)
RA-005 Dose quantization mismatch with DASH minimum deliverable dose Medium (S2×P2) Algorithm constants + command quantization validation + telemetry reconciliation SRS-PUMP-003, SRS-LOG-001 TV-PUMP-003, TV-LOG-001 Low (S2×P1)
RA-006 App relaunch/reset causes state mismatch and unsafe cadence High (S3×P2) Persisted runtime/algorithm/device-manager state, explicit full reset semantics, explicit-operator-only algorithm start/stop/reset/session replacement, and for the masked offline-fallback subsystem additional persisted maintenance state capturing original programmed basal schedule, current fallback schedule/rate, safety target, connected pod identity plus total-delivery baseline/timestamp, maintenance timestamps, restore-failed or reconciliation-required recovery context, and any pending pump-delta reconciliation state so refresh/disarm decisions, reconnect/start/foreground restore retry, post-expiry blocked-state recovery, confirmed/corrected missed-step algorithm replay, and ambiguous logging-only resume remain reconstructible across app/session boundaries without silently creating a new session SRS-STATE-001, SRS-STATE-002, SRS-STATE-003, SRS-STATE-004, SRS-STATE-005 TV-STATE-001, TV-STATE-002, TV-STATE-003, TV-STATE-004, TV-STATE-005 Medium (S3×P1)
RA-007 Home pod status stale despite reconnect Medium (S2×P2) Connection-driven refresh path, observer wiring SRS-PUMP-004 TV-PUMP-004 Low (S2×P1)
RA-008 Missing auditability of algorithm inputs/outputs/commands High (S2×P3) Per-step telemetry capture and traceability mapping. Recent Dose Steps derives a visible fingerstick marker and exact manual BG value from the persisted algorithm input and retains concurrent CGM evidence, avoiding ambiguity about which glucose inputs the step used. The masked offline-fallback subsystem extends operator review coverage with explicit fallback lifecycle events (armed, maintenance deferred, mask renewed, schedule checked unchanged, schedule refreshed, mask expired offline, disarmed, restore/remask failed) carrying fallback rate, source, safety target, duration, reconciliation status, pod-continuity result, failure detail, modeled fallback delivery, pump-reported delivered insulin delta when the reconnect baseline is proven same-pod and available, persisted fallback schedule metadata, schedule-weighted pump-delta reconciliation detail when confirmed/corrected reconnect recovery occurs, explicit assumed-delivered status when retired/expired/no-active pod recovery uses modeled fallback exposure because pump evidence is unrecoverable, replay rows only for reconciled or assumed fallback-active missed slots, and no-replay reason when replay cannot be safely allocated. Pre-activation disconnected gaps remain absent from replay telemetry rather than being represented as delivered-insulin rows. SRS-LOG-001, SRS-LOG-002, SRS-LOG-009 TV-LOG-001, TV-LOG-002, TV-LOG-009 Medium (S2×P2)
RA-009 Investigational telemetry artifacts stored or exported locally are accessed outside intended site/operator controls High (S2×P3, pre-mitigation) Closed-posture controls (2026-07-17, sponsor-approved): OS file sharing removed (UIFileSharingEnabled/LSSupportsOpeningDocumentsInPlace absent, pinned by test); CSV export sealed to Application Support with complete file protection, backup exclusion, and legacy Documents cleanup; telemetry spool protected until-first-unlock + backup-excluded; enumerated C++-created Algo2015 diagnostics receive complete-until-first-unlock protection and backup exclusion while remaining unavailable through Files sharing; the combined recovery export snapshots the CSV and matching/current enumerated algorithm session into a complete-protected, backup-excluded temporary directory, shares only through the clinical-gated Recent Dose Steps ShareLink, and removes temporary data when that view closes; the CSV's silent-redundancy role is replaced by provable delivery (SRS-LOG-012 sequence-numbered envelopes) with per-subject completeness and stale-gap alerts on BionicScout, so loss is evident before any reset. Residual boundary: applying attributes to C++-created diagnostics is best-effort after app enumeration and requires freeze-build inspection. SRS-SEC-001, SRS-SEC-002, SRS-LOG-012, SRS-LOG-015 TV-SEC-001, TV-LOG-012, TV-LOG-015 Low (S2×P1; export posture decided - no ungated local access in any baseline)
RA-010 User workflow errors (profile, meal UI, status interpretation, stale/unreliable CGM value interpretation, incorrect device date/time leading to misleading recency context) Medium (S2×P2) Explicit UI states, spatially separate exact-value Manual BG review, persistent bottom-safe-area Manual BG and Meal Announcement actions while variable-length Home content scrolls, startup-cancel paths, background-auto-cancel for meal composer, stale/unreliable-CGM display masking (-- and no trend arrow after 11 minutes or when hasReliableGlucose == false), boundary CGM rendering (LOW/HIGH), stepped CGM chart scaling (300/350/400) with discrete point-only samples rather than a visually interpolated connector/area, UTC clock-drift checks with actionable warning (>10 min skew, 24-hour warning rate limit), and SOP-driven usability checks. The existing Pod suspend/resume command is directly available on the less-prominent Exercise and Insulin Delivery screen and omitted from normal Pod Settings to prevent duplicate control locations; the action is disabled without a usable Pod or during suspension-state transitions, and reminder copy states that insulin remains suspended until manual resume. SRS-UI-001, SRS-UI-002, SRS-UI-003, SRS-UI-004, SRS-UI-005, SRS-UI-006, SRS-UI-007, SRS-UI-008, SRS-CLIN-016, SRS-VAL-001, SRS-LOG-006 TV-UI-001, TV-UI-002, TV-UI-003, TV-UI-004, TV-UI-005, TV-UI-007, TV-UI-008, TV-UI-009, TV-UI-010, TV-CLIN-017, TV-LOG-006 Medium (S2×P2)
RA-011 Critical device/runtime alerts are missed, delayed, or masked by lower-severity messages High (S3×P2) Multi-source alert normalization; severity-first precedence; a narrow same-severity rank that keeps Pod signal loss above a newer check-BG prompt while leaving every safety-critical alert above both; debounce/coalescing rules; repeated no-active-pod notification attempts; explicit ack/clear policy; protocol-aligned wording; suspend reminders explicitly state that insulin remains suspended until manual resume, offer the existing resume command directly on the active alert with duplicate-command suppression and retryable failure, remain until pump-confirmed recovery, route notification taps to Settings > Exercise and Insulin Delivery, and escalate with a fresh safety-critical alert/notification after 15 minutes still suspended; direct check-BG, due-soon, and overdue requests visibly emphasize the Home BG-entry control, with haptic feedback for Algo2015 checkBG; and Algo2015 forced-open-loop command-block alerting (informational-first, safety-critical escalation after 3 consecutive blocked steps, fingerstick-BG remedy instruction with sensor-check/study-team guidance; no reset demand) SRS-ALERT-001, SRS-ALERT-002, SRS-ALERT-003, SRS-ALERT-004, SRS-ALERT-005, SRS-ALERT-006, SRS-ALERT-011, SRS-ALERT-017, SRS-ALERT-018, SRS-ALERT-019, SRS-CLIN-016 TV-ALERT-001, TV-ALERT-002, TV-ALERT-003, TV-ALERT-004, TV-ALERT-005, TV-ALERT-009, TV-ALERT-010, TV-ALERT-016, TV-ALERT-017, TV-ALERT-018, TV-CLIN-017 Medium (S3×P1)
RA-012 Manual BG entry is stale, invalid, duplicated, misapplied to wrong step, or executed while loop is off, causing incorrect algorithm input or user confusion High (S3×P2) Dedicated bgCheck policy with single pending candidate, immediate-next-step-only validity, replace-on-new submit semantics, explicit stale/duplicate guards, loop-armed gating, accepted manual BG range 20...600 mg/dL, spatially separate exact-value review that cannot be bypassed by repeated taps on the entry action, source-tagged telemetry, and explicit user feedback for rejected BG actions. Home renders accepted persisted pending BG as an unfilled marker at submission time and fills it only from completed algorithm-input evidence; original-time retention and same-target deduplication prevent a consumed value from moving or appearing twice, while pending-state disappearance is never treated as proof of use. When a meal is accepted for that exact pending target step, the same BG and meal inputs are delivered to both primary and safety algorithms and the BG candidate is consumed once only after the shared step succeeds. SRS-BG-001, SRS-BG-002, SRS-BG-003, SRS-BG-004, SRS-BG-005, SRS-BG-006, SRS-BG-007, SRS-BG-009, SRS-BG-010, SRS-BG-011, SRS-BG-012, SRS-BG-013 TV-BG-001, TV-BG-002, TV-BG-003, TV-BG-004, TV-BG-005, TV-BG-006, TV-BG-008, TV-BG-009, TV-BG-010, TV-BG-011, TV-BG-012, TV-BG-013, TV-MEAL-002 Medium (S3×P1)
RA-013 Clinical settings misconfiguration or unauthorized access leads to unsafe algorithm/session configuration (target/upfront/TMAX/subject/weight/start-reset controls) High (S3×P2) Dedicated staff initial-configuration surface available only while no usable subject configuration exists, followed by a clinician-gated settings surface; subject-scoped offline clinical unlock verifier; validated app-side material installation/refresh into Keychain-backed per-subject verifier material/local state; single-use monotonic counter burn before unlock; accepted-counter preservation across material refresh; active-unlock clearing on material refresh; local unlock expiration/manual lock with storage-failure visibility; malformed/non-ASCII/reused/wrong-subject/beyond-lookahead/unsupported-version rejection; no production master secret in app source; strict selector bounds/step validation; lbs->kg normalization; persisted defaults/migration; clinician-controlled participant target-access profile (Pregnancy / Standard); required approval capture before participant target changes; profile-bounded clinician target options with nearest-allowed normalization on profile switch; and unchanged start/reset behavior semantics under relocated controls. First-launch defaults follow clinical direction 2026-07-14 (Standard profile, 120 mg/dL, 75% meal upfront, 40-minute TMAX for Fiasp), never rewrite persisted values, and can be saved without an unlock only until the first usable configuration is committed; every later access/edit requires the offline unlock. An unlock-gated, dual-confirmed New Participant Reset wipes all participant-scoped data (including subject-scoped unlock material and telemetry) and signs out before a reused phone reaches the next participant; the reset is refused while a pod is active, and when a session is armed the control offers a guided stop-then-reset flow (explicit session stop, then the erase confirmation) rather than a silent stop or an unexplained refusal. This remains an investigational single-device clinical unlock control and is not a full production role-based authorization system. SRS-CLIN-001, SRS-CLIN-002, SRS-CLIN-003, SRS-CLIN-004, SRS-CLIN-005, SRS-CLIN-006, SRS-CLIN-007, SRS-CLIN-008, SRS-CLIN-009, SRS-CLIN-010, SRS-CLIN-011, SRS-CLIN-012, SRS-CLIN-013, SRS-CLIN-014, SRS-VAL-001, SRS-LOG-008 TV-CLIN-001, TV-CLIN-002, TV-CLIN-003, TV-CLIN-004, TV-CLIN-005, TV-CLIN-006, TV-CLIN-007, TV-CLIN-008, TV-CLIN-009, TV-CLIN-010, TV-CLIN-011, TV-CLIN-012, TV-CLIN-013, TV-CLIN-014, TV-CLIN-015, TV-LOG-008 Medium (S3×P1; accepted investigational residual; production authorization hardening deferred)
RA-014 Algorithm logic regression or latent C++/host-interface defects remain undetected due to insufficient structural/deterministic test coverage, leading to incorrect dosing recommendations under specific input sequences High (S3×P2) Dedicated Algo2015 structural-coverage campaign, deterministic golden-vector replay suite, bridge-contract edge-case testing, persistence/restart continuity testing, mandatory static-analysis lane on formal runs, and risk-based conditional MISRA closure (report+deviations or explicit N/A rationale) with IDE-traceable STR evidence packaging; symbol-isolated per-instance algorithm copies so the safety/fallback track shares no C++ global state with the primary (dual-instance isolation correction, 2026-07-10; isolation tests pin the buffer clock, the 60-minute dropout window, and CGM-history density); and a reference-host contract regression proving every pump recommendation includes the exact bolus + basal + meal output total and that matching feedback produces accepted I reconciliation rather than ~I rejection SRS-ALG-001, SRS-ALG-002, SRS-ALG-003, SRS-ALG-004, SRS-ALG-005, SRS-ALG-006, SRS-ALG-007, SRS-ALG-008, SRS-ALG-009 TV-ALG-001, TV-ALG-002, TV-ALG-003, TV-ALG-004, TV-ALG-005, TV-ALG-006, TV-ALG-007, TV-ALG-008, TV-ALG-009, TV-ALG-010, TV-ALG-011, TV-ALG-012 Medium (S3×P1; both identified mechanisms are eliminated and regression-pinned. Exact-freeze STP-ALG-001 passed behaviorally; the 6/6 linkage companion closes ALG-DEV-SA-006.)
RA-015 The armed loop stops achieving timely successful steps and scheduled dosing recommendations may remain unserved without actionable user escalation, or inaccurate blocker guidance directs the participant toward an unrelated recovery action High (S3×P2) Current baseline monitors successful-step continuity rather than CGM receipt alone: while armed, the app computes a 15-minute interruption deadline from the most recent successful step (or session start / first-step wait state if none exists yet), raises ALERT-ALGORITHM-STEPPING-INTERRUPTED with local notification when that deadline is missed, preserves Home status visibility, and clears interruption state on the next successful step or loop disarm/reset. Blocker-specific guidance is derived from the latest unresolved runtime outcome or authoritative pump-native state rather than broad CGM lifecycle alerts; explicit suspension outranks fallback recovery, fallback recovery replaces stale CGM/pump-status detail, successful live execution clears persisted diagnosis, and Home suppresses the redundant interruption banner while the stronger suspend-ended alert is active without removing Alert Center/telemetry evidence. After a pump-status-unavailable attempt, only a newer idle status for an active Pod replaces reconnect guidance with communication-restored/waiting-for-glucose copy; the status refresh does not wake the algorithm or issue a command, stale/non-idle/no-Pod evidence cannot claim recovery, and a later unknown status restores unavailable guidance. Runtime also permits guarded reconnect-based fallback execution after the first anchored step exists using the current due step only without re-anchoring or backlog replay. SRS-CGM-005, SRS-RUN-004, SRS-RUN-005, SRS-ALERT-013, SRS-ALERT-014, SRS-UI-001, SRS-UI-002 TV-CGM-005, TV-RUN-004, TV-RUN-005, TV-RUN-006, TV-RUN-007, TV-ALERT-012, TV-ALERT-013, TV-UI-001 Medium (S3×P1); exact-freeze AUTO and SIM execution passed, clinical confirmation of RES-004 is recorded, and residual risk is accepted under D07. No separate physical recovery claim is made.
RA-016 Meal announce is duplicated, silently lost, or ambiguously applied because submit/outcome state is not durable across relaunch, comms interruption, or competing triggers High (S3×P2) Implemented baseline now persists pending meal-request state plus correlated meal flow_id across relaunch, blocks duplicate meal entry while the intended execution step remains unresolved, defers Home success messaging/telemetry until runtime/coordinator result is known, blocks repeat meal entry with explicit operator guidance when command outcome is uncertain until reconciliation or session reset/disarm, rejects competing-trigger slot conflicts with explicit retry guidance instead of silently reassigning meal intent to a later borrowed step, provides an explicit user-confirmed pod-replacement escape for unconfirmed old-pod meal delivery after timeout or known pod unavailability, and emits accepted / resolved telemetry closure when the request is accepted, reconciles after uncertainty, or is cleared by session reset. Loop command telemetry preserves uncertain-vs-blocked semantics for cloud reconstruction. SRS-MEAL-007, SRS-MEAL-008, SRS-MEAL-009, SRS-MEAL-010, SRS-MEAL-012, SRS-LOG-007, SRS-UI-002 TV-MEAL-008, TV-MEAL-009, TV-MEAL-010, TV-MEAL-011, TV-MEAL-013, TV-LOG-007 Medium (S3×P1); exact-freeze AUTO and SIM/pod-simulation execution passed. Residual risk is accepted under D07; no separate physical meal-lifecycle claim is made
RA-017 Automatic bolus delivery is interrupted or unreconciled, causing the primary/secondary algorithms to miss delivered insulin or issue additional insulin before prior delivery is safely dispositioned High (S3×P2) Runtime now persists issued-dose attribution for any applied or uncertain automatic bolus command, including meal, correction, mixed, and basal micro-dose commands. Active delivery blocks live step advancement. The accepted no-boundary-cancel policy is bounded by fresh DASH delivery-state convergence: supported automatic bolus sizes complete before the next 5-minute step under connected status, and disconnect/expiry/no-active-pod paths leave the active-delivery skip path by reporting unavailable/unknown status rather than .delivering. Matching same-request same-pod pump evidence replays missed primary/secondary steps with CGM=-1, actual delivered insulin injected only at the first missed attribution step, no catch-up commands, and monotonic/non-duplicating coordination with fallback replay; if the first eligible attribution step is the live due step, persisted evidence is fed into that live step without synthetic replay rows. When a same-pod reconnect pump-total delta spans both an in-flight issued dose and fallback basal exposure, runtime partitions the known pending issued-dose request from that pump total only when the request, pod identity, completion timing, and residual fallback exposure are credible; the residual is used for fallback replay and the raw pump total remains telemetry/operator-review evidence. While the pod still reports active delivery or unknown status, or no post-request pump-status refresh exists yet, the attribution remains pending and live advancement is skipped. Once a fresh settled post-request pump status exists and the original pod has not been proven replaced, absent, mismatched, non-credible (delivered units outside 0...requested), or missing-identity delivery evidence resolves as assumed delivered per clinical policy: the requested units are recorded as the assumed delivered amount, fed into the first eligible attribution step by replay or live-step input, labeled assumed - never confirmed - in UI/telemetry, and meal-linked assumed doses schedule a meal-adaptation exclusion so algorithm meal learning does not adapt on assumed evidence. Assuming the requested amount is the conservative direction for insulin-on-board accounting (under-crediting would risk re-dosing insulin that may already have been delivered) and preserves dosing liveness. Non-credible pump-total partition still refuses to guess the fallback split: ambiguous raw pump total is not displayed or persisted as actual fallback residual delivery. If a different/new pod appears before reconciliation, runtime records that disposition, preserves the same algorithm session, assumes the issued dose was delivered, feeds that assumed amount into the first eligible attribution step by replay or live-step input, clears the old-pod pending attribution after consumption, scrubs unrelated replacement-pod lastDelivery from the resumed live algorithm input, and does not block later insulin-adding automatic commands solely because the original pod cannot be reconciled. If the operator explicitly confirms pod replacement from an unresolved meal-progress modal after the old pod is unavailable or timed out, runtime records user_abandoned_unavailable_pod, stores assumed-delivered evidence, clears only meal-progress UI state, and leaves attribution for replay/live-step consumption; missing original pod identity is accepted only for this assumed-delivered path when step, units, delivered bounds, and non-active pump state match. Every pump command and status await is additionally bounded by an app-level 120-second watchdog that fails the command as uncertain (or the status read as blocked) instead of stalling the serialized loop work pass; late or duplicate transport completions after the watchdog fires are ignored safely (SRS-PUMP-011). SRS-PUMP-010, SRS-PUMP-011, SRS-MEAL-012, SRS-STATE-004, SRS-STATE-005, SRS-LOG-001 TV-PUMP-009, TV-MEAL-013, TV-STATE-004, TV-STATE-005, TV-LOG-001, TV-PUMP-010 Medium (S3×P1); exact-freeze AUTO and SIM/pod-simulation execution passed. Residual risk is accepted under D07; no separate physical canceled-partial/reconciliation claim is made
RA-018 Sustained loss of connected CGM data drives the algorithm to forced open-loop: automated commands are blocked and the pod's programmed basal remains masked at 0 U/hr, producing a zero-insulin window that persists until fingerstick BG entry or CGM recovery (field-observed 2026-07-10: 95 minutes) High (S3×P2) Algorithm-native dropout tolerance delivers an exponentially tapering micro-dose for the designed 60-minute window before forcing open loop; per-instance algorithm isolation restores and regression-pins that full window (dual-instance isolation correction); escalating alert pair (informational at the first blocked step, safety-critical after 3 consecutive blocked steps) instructs the fingerstick-BG remedy; a manual fingerstick BG re-closes the loop; per-step telemetry records the blocked window for study oversight. fingerstick-supported CGM-outage dosing controls implemented 2026-07-14 under SRS-OUTAGE-001..006 and SDD-OUTAGE-001: persisted BG-due schedule (120-minute cadence, 60 when the measured value is >200/<80 mg/dL), tiered pre-scheduled alerts (due-soon actionable, backup-basal informational, overdue safety-critical), Home countdown plus gold BG-entry emphasis for due-soon and overdue requests, backup-basal bridge (active mask cancel on connected forced-open, renewal suppression while released, pre-command re-arm on re-close, conservative failure paths), replay-based reconciliation of bridged exposure, and no maximum-outage stop (deliberate, clinically owned divergence from the iLet cutoffs; short study, close monitoring, escalating alerts, remote telemetry). The due-soon/overdue tiers are OS notifications and depend on user-granted notification permission: notification permission is requested once at app startup (priming); iOS silently drops the pre-scheduled tiers when permission is denied or later revoked and this baseline has no in-app permission-state indicator (gap; tracked as an identified future enhancement). Since 2026-07-16 every scheduled-notification telemetry event carries the OS authorization_status and an unauthorized schedule logs a cloud warning, so a denied-permission phone is visible to study monitoring even though not yet surfaced in-app - the in-app alert stack and Home countdown remain active regardless of permission, and the IFU setup instructions require confirming notifications are enabled during provisioning (information-for-safety control). SRS-ALERT-019, SRS-RUN-007, SRS-ALG-008, SRS-OUTAGE-001, SRS-OUTAGE-002, SRS-OUTAGE-003, SRS-OUTAGE-004, SRS-OUTAGE-005, SRS-OUTAGE-006 TV-ALERT-018, TV-ALG-004, TV-OUTAGE-001, TV-OUTAGE-002, TV-OUTAGE-003 Medium (S3×P1); exact-freeze AUTO and SIM execution passed, residual risk is accepted under D07, and no separate physical outage claim is made.
RA-019 New Participant Reset is invoked unintentionally (wrong reset chosen, or its device-wipe scope misunderstood), erasing participant-scoped data mid-study: clinical configuration, local step telemetry and CSV export, the not-yet-uploaded cloud outbox queue, alert history, stored device-manager state, and the subject-scoped unlock material including burned counters; or asynchronous device work recreates outgoing-participant state after the wipe Medium (S2×P2) Reset is reachable only inside unlocked Clinical Settings (clinical-unlock gating); distinct side-by-side labeling (Same-Participant Reset vs New Participant Reset); refusal while a pod is active; guided stop-then-reset when a session is armed (no silent session stop); explicit destructive confirmation naming the erased data; telemetry drain guard: a final upload flush before the erase confirmation, an explicit consent line stating how many telemetry records remain undelivered and that resetting discards them permanently, a best-effort telemetry.outbox.discarded marker posted before the erasure, and sequence-continuity-preserving erasure so any discarded records stay server-detectable as a BionicScout gap (no more silent local-queue loss); CGM reset teardown cancels acquisition work and invalidates persistence callbacks/in-flight markers before deleting raw manager state, preventing late completion from recreating the prior participant's replacement episode; sign-out after the wipe makes the effect immediately visible; previously uploaded telemetry persists server-side in BionicScout (only local copies and the local queue are erased); dosing safety is unaffected because the reset never executes with an active pod or an armed session SRS-CLIN-014 TV-CLIN-015 Low (S2×P1)
RA-020 Backup basal delivered during a connected CGM-outage window is not counted by the algorithm (discovered 2026-07-16 in live field data): while the bridge is released, the pod runs its programmed fallback schedule; without reconciliation, subsequent dosing can skew toward extra insulin, partly offset by blocked mode-2 asks that the C++ carries as assumed delivery Medium (S3×P2, pre-mitigation, human-use framing) Interim telemetry control shipped 2026-07-16: every release window is quantified at mask re-arm. The frozen baseline contains the implemented accounting control: connected released steps credit live per-step using echoed asks plus identity-guarded pod deltas; a pod-away gap is reconciled by historical, schedule-weighted replay rather than one reconnect chunk. Shares are allocated in 0.01 U quanta by largest remainder so the C++ booked total equals the measured delta. The replay plan persists measured delta, re-anchor counter/identity, and first-row echo ask so a force-quit neither loses nor double-counts delivery. Real-C++ characterization, recorded-sequence differential, and simulated outage scenarios passed the exact-freeze SIM lane. SRS-OUTAGE-006 TV-OUTAGE-002 Medium with implemented frozen-baseline control (S3×P1); clinical confirmation of 0.01 U quantized time positioning is recorded. Residual risk is accepted under D07; no separate physical outage claim is made
RA-021 An implausible subject weight (units fat-finger, migration defect, or absurd entry) reaches the dosing algorithm and scales every computed dose - weight was the one clinical input with no plausibility bound before the C++ (found by the 2026-07-17 algorithm test coverage review; all other clinical settings were double-bounded and double-tested) Medium (S3×P2, pre-mitigation) Save gate: configurations with weight outside 50...500 lbs are not usable for arming (SRS-CLIN-015; entry is clinical-unlock-gated); store top-clamp at 500 lbs bounds runaway scale for legacy-persisted values without ever raising a lower entry (0 stays unset and keeps first-launch setup gated; sub-plausible positives stay visible but unusable); algorithm last rail clamps consumed weight into 20...230 kg where the low clamp under-doses (safe direction) and the clamped value is telemetry-visible; range clinically confirmed 2026-08-21 SRS-CLIN-015 TV-CLIN-016 Medium (S3×P1)
RA-022 A Pregnancy Temporary Target is applied with the wrong value or interval, fails to apply when selected, persists beyond its intended end, or contaminates the safety-controller/fallback profile. The resulting primary dosing may be less or more aggressive than intended during activity, or an inappropriate temporary target may survive relaunch/profile/session/participant transitions. High (S3×P2, pre-mitigation) The participant must explicitly select one of two bounded targets and one of four bounded durations; activation is Pregnancy-only and requires an armed session, active Pod, and no pending fallback recovery. The subject-bound state persists an absolute expiry before UI success, is resolved independently for every algorithm row's execution time, and the first row at/after expiry returns to the permanent target without relying on notification delivery. Replacement/end/profile/session/reset dispositions are deterministic; New Participant Reset removes all state. The override is injected only through the primary set-point resolver; the safety target, q5 profile, and programmed four-rate backup schedule remain derived from the permanent Pregnancy configuration, as clinically selected 2026-07-24. Home/Settings show target and end time, a local expiration notification is scheduled, and lifecycle plus per-step telemetry distinguish activation from observed algorithm use in BionicScout. SRS-CLIN-016, SRS-LOG-013, SRS-RUN-007 TV-CLIN-017, TV-LOG-013 Medium (S3×P1); exact-freeze AUTO execution passed. Residual risk is accepted under D07; no separate physical/live-telemetry claim is made
RA-023 The app remains bound to an ended G7 and never acquires its replacement, or releases the correct binding and adopts a nearby participant's G7, causing unavailable or wrong-person glucose to influence automated dosing. High (S3×P2) Settings exposes a manual replacement action; ordinary BLE search and reading staleness never clear the bound identity. Replacement intent and prior identity are synchronously offered to app storage before the lower BLE binding is released; direct manager reconstruction preserves that state; repeated manager callbacks do not restart the timer; and adoption requires authenticated glucose discovery with activation evidence. A ten-minute in-app alert directs completion in the Dexcom app and retry from Settings, and stable stall/adoption event identities reduce duplicate Scout evidence. Device-reported sensor failure/session end and remote disconnect during pending authentication may also start replacement; routine disconnect does not. The current integration has no authoritative intended-sensor handoff identity. The September 3 adversarial review found that reopening CGM setup during active replacement can install a fresh manager and reset episode evidence, multiple already-queued candidate callbacks have no atomic single-winner gate, automatic triggers may begin without planned physical isolation, and the IFU's post-connection comparison does not gate first-reading use by an armed runtime. No wrong-sensor adoption was observed in the supporting field event. SRS-CGM-006, SRS-ALERT-020, SRS-LOG-014 TV-CGM-006, TV-ALERT-019, TV-LOG-014 Medium (S3×P1), accepted for IDE submission under D06 and D07. The controlled multi-device exercise and final deployment disposition remain required before first participant deployment.
RA-024 A combined recovery export pairs the retained step CSV with Algo2015 files from the wrong run or captures a changing file inconsistently, causing investigators to reconstruct an incorrect session when primary telemetry has a gap. Medium (S2×P2) Timestamped log/data files are grouped by parsed epoch and the fixed matrix joins only the epoch it names. The active C++ real-T0 inspection epoch selects only an exact group; an unavailable exact group produces CSV-only output, while absent inspection state permits only the newest valid grouped epoch. CSV and algorithm sources are each copied to their observed start size before ZIP creation; ZIP input is staged snapshots rather than live paths; CRC/size and byte-exact extraction are regression-tested. The Settings modal/picker path was removed, eliminating its repeated concurrent-presentation failures. The feature is read-only and cannot change dosing or algorithm output. SRS-LOG-015, SRS-SEC-001 TV-LOG-015 Low (S2×P1); exact-freeze AUTO and scoped SEC execution passed, and residual risk is accepted under D07. No separate physical share/open claim is made.

RA-009 controlled clarification (v1.38): field evidence showed that a long debug-logging backlog could amplify itself after the chatter lane reached its cap. The strengthened control uses a protected SQLite ledger with no count eviction for retained clinical/runtime evidence, transactionally and repeatably imports earlier file spools, completes telemetry calls after durable commit rather than network drain, preserves independent retry scheduling, drains retained evidence before bounded chatter, and aggregates chatter-cap loss after transport progress. An additive bounded batch route improves catch-up throughput while unsupported-route fallback preserves the deployed single-event contract. A separate protected SQLite archive preserves the complete active-session step history for clinical export while Recent Dose Steps remains bounded. New Participant Reset physically recreates the outbox database and removes its sidecars while preserving only install-scoped sequence metadata; explicit algorithm-session reset securely purges the step archive. Byte-marker regressions verify that cleared participant content is absent from the affected SQLite artifacts. Notification-clear telemetry is emitted only for an actual persisted lifecycle transition, and Settings remains passive with no alert or dosing dependency. Storage exhaustion is now bounded by available protected app storage rather than an arbitrary clinical-entry count; an actual local commit failure cannot itself be reported to cloud while storage is unavailable. Working verification is TV-LOG-001/TV-LOG-012; live update-in-place recovery, Scout catch-up, post-deploy batch observation, and formal promotion remain required.

RA-009 / RA-024 submission-scope clarification (v1.48): clinical review on 2026-08-27 approved Scout as supportive monitoring and corroboration rather than an official study outcome or safety-report source. Official CGM outcomes come from Dexcom Clarity, insulin-delivery outcomes from the BionicLoop exported CSV, and adverse events and other safety information from staff-entered electronic case-report forms. The device-local recovery ZIP remains primary software session-reconstruction evidence for its covered interval. This clarification changes neither the controls nor the residual scores.

RA-017 controlled clarification (v1.24): DASH can report bolusNotDelivered = 0 after a canceled bolus and app relaunch. That register value alone is therefore not evidence of full completion. Durable cancellation evidence and legacy partial evidence remain authoritative; only a partial explicitly labeled as capped while delivery was still active may be raised by a later same-pod settled observation. This control prevents a canceled partial from being fabricated as a full delivered dose in algorithm input while preserving the existing conservative assumed-full policy when no reliable partial evidence exists.

RA-017 controlled clarification (v1.31): the 2026-07-30 field suspension incident showed that a locally cached 2.9 U request rejected by the Pod as suspended could be paired with bolusNotDelivered = 0, displayed as delivered, and fed to steps 21-23 because no valid issued-dose attribution existed to deduplicate it. The control now invalidates matching adapter request metadata after a definitive blocked result and strips any matching cached delivery; uncertain results retain reconciliation state. The independent idle-only meal preflight prevents the normal known-suspension path from reaching either algorithm or command construction.

Residual Risk Acceptance Notes

  • RA-009: Sponsor-approved closure landed 2026-07-17. OS file sharing is absent, CSV export is sealed to the clinical-gated share path with complete protection and backup exclusion, and telemetry completeness is observable through SRS-LOG-012 sequence numbering. No separate sponsor export-posture decision remains open for the IDE baseline.
  • RA-013: Offline single-use Clinical Settings unlock is accepted as an investigational single-device control; broader production authorization/role-based access remains deferred unless explicitly pulled into scope.
  • RA-005: Residual resolved to Low (previously recorded ambiguously as Low/Medium): dose quantization is validated at command construction and reconciled in telemetry (TV-PUMP-003, TV-LOG-001).
  • RA-015: Exact-freeze automated and simulation execution covered the implemented reconnect/fallback gate. Clinical written confirmation of RES-004 is recorded in IDE_Clinical_Policy_Confirmation_2026-08-21.md. Residual risk is accepted under D07; no separate physical reconnect/background claim is made.
  • RA-018: The connected-outage zero-insulin window past the 60-minute dropout tolerance is tracked as ANOM-003. The clinically approved fingerstick-supported CGM-outage dosing design (2-hour fingerstick cadence, hourly when BG >200/<80; backup-basal bridge; no maximum-outage stop) is IMPLEMENTED as of 2026-07-14. Exact-freeze automated, algorithm, and simulation execution is complete, and residual risk is accepted under D07; no separate physical-device claim is made.
  • RA-014, RA-015, RA-016, and RA-017: Exact-freeze execution evidence is mapped in the canonical RTM. ALG-DEV-SA-006 is closed by companion evidence. Physical hardware claims remain deferred unless signed operator evidence is completed and accepted.
  • RA-018 (notification permission): the due-soon/overdue outage tiers are pre-scheduled OS notifications and do not fire if the participant has denied notification permission; no in-app permission surfacing exists in this baseline (2026-07-14 audit finding). The in-app alert stack and Home countdown are permission-independent, and the IFU setup checklist requires enabling notifications at provisioning. Accepted for the investigational study given provisioning verification and close study-team monitoring; in-app permission surfacing is an identified future enhancement.
  • RA-023: No Dexcom-app handoff identity is exposed by the current integration. The accepted no-handoff design uses explicit replacement acquisition followed by authenticated first-sensor discovery and trained verification. Under D06, the listed multi-device bench test is deferred from submission assembly until before first participant deployment. The provisional S3×P1 rating is accepted for submission; the exercise result controls final deployment disposition.

Residual Probability Rationale

Seventeen register rows carry a Medium (S3×P1) residual. That is a consequence of the scale, not a default: S3 reflects that each of those hazards, unmitigated, has a plausible path to incorrect or unaccounted insulin delivery or a missed safety-critical alert, and P1 is claimed only where the listed controls are implemented and linked to passing verification and the residual path to harm requires multiple independent failures. Per-row discriminators an auditor should expect:

  • RA-001 initial P3 (iOS wake variability occurs routinely absent controls) versus RA-018 initial P2 (a sustained multi-hour connected CGM outage was observed once in field use): the triggers have different base rates and are deliberately rated differently.
  • RA-010 initial equals residual (S2×P2): UI-state controls bound the consequence and improve detectability, but occasional workflow slips remain expected with any UI (human-factors floor). The row is acceptable at Medium under the criteria; it is not driven to P1.
  • RA-008 residual lands P2, not P1: telemetry gaps remain plausible (storage pressure, upload interruption) even with always-on capture; S2 severity bounds the row at Medium.
  • RA-014 residual P1 is claimed under the documented probability definition (occurrence of harm, not of the triggering defect): The dual-instance isolation incident demonstrated the independent safeguard layer containing a real latent-defect escape without participant harm. Exact-freeze behavioral verification and the linkage companion passed; residual risk is accepted under D07.
  • RA-023 residual P1 is claimed provisionally because ordinary staleness cannot release the bound sensor, replacement requires an explicit or defined device-lifecycle trigger, and adoption requires authenticated glucose discovery with trained post-connection verification. A path to wrong-person dosing therefore requires a replacement episode, a nearby non-intended candidate, failure of the intended-device workflow, and failure of the trained verification control. Supporting verification is incomplete for CGM-screen reentry, concurrent candidates, automatic-trigger isolation, and first-reading use. D06 and D07 accept S3×P1 for submission, subject to the controlled exercise and final deployment disposition before first participant deployment.
  • Rows whose controls eliminate the hazard mechanism (RA-002 sanitization, RA-005 quantization validation, RA-007 refresh wiring) reach P1/Low directly; rows whose controls interpose barriers (RA-003, RA-004, RA-006, RA-011, RA-012, RA-013, RA-015, RA-016, RA-017) claim P1 because harm additionally requires the in-app escalating-alert control to fail during a short, closely monitored study.

Overall Residual Risk Conclusion (Benefit-Risk)

With the listed controls implemented and linked to verification, no register row carries a High residual; RA-009 is closed at Low under the sponsor-approved sealed-export and provable-delivery posture. Exact-freeze execution is complete: STP-ALG-001 passed behaviorally and its 6/6 linkage companion closes ALG-DEV-SA-006; STP-AUTO-001 completed and its corrected 44/44 UI companion closes AUTO-DEV-001 and AUTO-DEV-002; STP-SIM-001 passed; and TV-SEC-001 passed 68/68 scoped controls. All 24 IDE-scope risk-analysis rows have execution evidence mapped. The anticipated benefit of investigational closed-loop dosing justifies the documented residual risks. Final benefit-risk acceptance is recorded under D07; the accepted D06 multi-G7 exercise remains a predeployment condition.