Software Requirements Specification (SRS)

Status: Frozen-baseline specification approved for IDE submission Version: 1.82 Owner: BionicLoop engineering
Prepared by: BionicLoop engineering Approval reference: Edward R. Damiano, PhD, final software-package approval, controlled email dated 2026-09-07 EDT Baseline freeze SHA: 91c0e98a9bc9429a0486bebdebffc7d8dbbe300e Scope: Closed-loop investigational runtime, device integration, and safety-critical UI behavior 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 document-control metadata and disposition fields
0.91	2026-04-08	BionicLoop engineering	Added masked offline-fallback maintenance, disarm, and fallback-review-event requirements
0.92	2026-04-08	BionicLoop engineering	Clarified 20-minute masked-fallback renewal window, deferred maintenance semantics, and recoverable restore context
0.93	2026-04-14	BionicLoop engineering	Added reconciliation-required blocked-state requirements after offline mask expiry
0.94	2026-04-14	BionicLoop engineering	Added reconnect recovery requirements for connected restore/disarm retry and explicit fresh re-arm after successful recovery
0.95	2026-04-14	BionicLoop engineering	Updated reconnect recovery behavior to auto-arm a fresh session after successful masked-fallback recovery while preserving the fallback review trail
0.96	2026-04-14	BionicLoop engineering	Updated masked-fallback feasibility recovery to preserve the existing session/cadence anchor and resume on the current due step without replay when reconnect restore succeeds
0.97	2026-04-14	BionicLoop engineering	Clarified state-persistence wording for same-session unreconciled resume after successful masked-fallback reconnect recovery
0.98	2026-04-15	BionicLoop engineering	Added pod total-delivery baseline, modeled-vs-pump-reported fallback review, and pre-step missing-fallback arm clarifications
0.99	2026-04-15	BionicLoop engineering	Added confirmed/corrected basal-only reconnect replay requirements and clarified ambiguous unreconciled-resume fallback behavior
1.00	2026-04-15	BionicLoop engineering	Added dedicated cloud fallback telemetry contract requirements for BionicScout rendering of fallback lifecycle and delivery/replay summary detail
1.01	2026-04-15	BionicLoop engineering	Clarified that confirmed/corrected reconnect replay must persist replayed internal steps into local export telemetry as distinct replay-marked rows
1.02	2026-04-27	BionicLoop engineering	Clarified that fallback replay must use pump-reported delivered-insulin delta and must not substitute modeled expected delivery when pump reconciliation is unavailable
1.03	2026-05-06	BionicLoop engineering	Added safety-track q5 nominal-basal profile persistence, four six-hour fallback-schedule generation, schedule-aware modeled exposure, and fallback profile/schedule cloud telemetry requirements
1.04	2026-06-02	BionicLoop engineering	Reframed confirmed/corrected fallback recovery as pump-delta delivery reconciliation into the live resumed step, tightened pump-evidence credibility, aligned six-hour schedule-refresh cadence, and added repeated no-active-pod critical alerting
1.05	2026-06-04	BionicLoop engineering	Aligned masked-fallback requirements with the current candidate baseline: confirmed/corrected recovery replays bounded missed primary/secondary algorithm steps with CGM=-1, per-step pump-delivery input, and no catch-up pump commands before the resumed live step
1.06	2026-06-08	BionicLoop engineering	Added schedule-weighted allocation of credible same-pod pump-delta replay across missed fallback steps and clarified zero-weight suppression / zero-delta replay behavior
1.07	2026-06-12	BionicLoop engineering	Added generalized issued-bolus attribution and no-guess replay/disposition requirements for meal, correction, and basal bolus commands interrupted by pump communication loss
1.08	2026-06-13	BionicLoop engineering	Hardened issued-dose reconciliation requirements for non-credible delivered-unit evidence, replacement-pod live-step insulin input, and automatic resume blocking during unresolved holds
1.09	2026-06-15	BionicLoop engineering	Updated different/new-pod issued-dose requirement to assumed-delivered replay/live attribution, replacement-pod command allowance, legacy hold nonblocking behavior, and deferred adaptation-forget consideration
1.10	2026-06-17	BionicLoop engineering	Added one-step algorithm/runtime cadence reconciliation before meal-step selection so loop executedStep, pump request step, and algorithm stepTime remain aligned when the algorithm bridge has already consumed the due step.
1.11	2026-06-17	BionicLoop engineering	Added explicit user-confirmed pod-replacement escape for unconfirmed meal delivery progress so the app can record assumed-delivered evidence and open pod setup without leaving the UI trapped.
1.111	2026-06-18	BionicLoop engineering	Added retired/expired/no-active-pod fallback recovery disposition: modeled fallback exposure may be recorded as assumed delivered and replayed when the original pod can no longer provide connected reconciliation evidence. (Renumbered 2026-07-10: this row previously duplicated version 1.11.)
1.12	2026-07-08	BionicLoop engineering	Added request-step-keyed single-consumption protection for reconciled issued doses plus discrepancy evidence when later pump observations disagree with already-consumed delivery.
1.13	2026-07-08	BionicLoop engineering	Added persisted issued-dose evidence restoration into the pump adapter so canceled partial boluses cannot be reconstructed as full deliveries after relaunch.
1.14	2026-07-08	BionicLoop engineering	Added one-refresh patience before reachable-pod assumed meal resolution, algorithm-visible meal-exclusion request-step persistence, and cloud/dashboard-only expired-exclusion disposal evidence.
1.15	2026-07-08	BionicLoop engineering	Documented the accepted no-boundary-cancel issued-dose liveness bound: fresh connected DASH status must converge from active bolus delivery to idle before the next 5-minute step for supported automatic bolus sizes; disconnect/expiry paths report unavailable rather than active delivery.
1.16	2026-07-08	BionicLoop engineering	Added Algo2015 forced-open-loop command block behavior with safety-critical alerting and explicit recovery guidance.
1.17	2026-07-08	BionicLoop engineering	Added masked-fallback recovery-attempt liveness: blocked ordinary wakes re-schedule reconnect recovery and triggers arriving during an in-flight attempt are requeued instead of dropped after a field-observed trigger-starvation incident.
1.18	2026-07-08	BionicLoop engineering	Bounded pump-evidence windows to measurement time, degraded stale-baseline amount-fitting deltas to corrected pump-anchored replay, narrowed unreconciled resume to genuinely unusable evidence, and required a safety-critical operator alert when an unreconciled resume may drop nonzero fallback insulin after a field-observed 0.10 U disposal incident.
1.19	2026-07-08	BionicLoop engineering	Added single-flight FIFO loop work passes with start-time state loads and monotonic same-anchor step-base persistence so a stale pass cannot regress the persisted base beneath the algorithm counter and trip a false drift block after a relaunch race.
1.20	2026-07-08	BionicLoop engineering	Sponsor decision: replaced the step-mismatch dosing block and manual-reset demand with automatic realignment - the algorithm counter is adopted as the step base without re-anchoring, dosing resumes when wall clock reaches it under fallback basal coverage, and an informational auto-clearing note states the resume window. Added SRS-RUN-007 session-continuity requirement (no automatic session kills, ever).
1.21	2026-07-08	BionicLoop engineering	Fallback replay plans carry their authorizing reconciliation status so the post-recovery re-arm event cannot mask them into disposal; alert telemetry carries disposal source codes; and forced open-loop is presented as a self-clearing CGM-dropout pause with informational-first alerting and persistent-only advisory escalation.
1.22	2026-07-08	BionicLoop engineering	Fallback replay pump tuples echo the algorithm's own prior-row ask as unitsRequested (first row keeps the schedule-share proxy): the Algo2015 reconcile gate matches requested-vs-remembered within one mechanical step (0.01 U), so the previous schedule-share proxy silently skipped delivered-insulin corrections whenever the rounded share diverged from the algorithm's rounded ask - characterized against the real C++ across 0.3-2.0 U/hr.
1.23	2026-07-08	BionicLoop engineering	Sponsor design: an issued dose interrupted before fallback activation replays as a pure confirm row on the dead-gap step plus zero-delivery echo sentinels, then fallback rows - replacing the merged-first-fallback-row convention whose ask+share requested side silently failed the 0.01 U reconcile gate (21:08 EDT field incident: 0.05 U confirmation and first 0.02 U share dropped by the C++). No-room overlap keeps the merge with the requested side echoing the ask exactly; the share credits as over-delivery at the request-step position (accepted policy, bounded to one slot share).
1.151	2026-07-08	BionicLoop engineering	Added Algo2015 checkBG fingerstick prompt behavior with dedupe, haptic feedback, BG-button emphasis, and stale-relaunch suppression. (Renumbered 2026-07-10: this row previously duplicated version 1.15.)
1.24	2026-07-09	BionicLoop engineering	Sponsor-approved Home alert presentation rescope (SRS-ALERT-011): severity-prioritized stack with expansion replaces the vertical carousel, and a root-cause suppression matrix hides generic alerts a specific active alert already explains - Home surface only, never safety-critical, Alert Center always complete.
1.25	2026-07-09	BionicLoop engineering	Sponsor UX decision (SRS-MEAL-006): revalidating an open meal composer re-arms in place on a stale observed step when fresh availability allows, and renders blocked messaging inline with selections preserved - the composer is no longer dismissed and replaced by a second sheet mid-composition. Submit-time blocking unchanged.
1.26	2026-07-09	BionicLoop engineering	Sponsor field finding (SRS-ALERT-011): when root-cause suppression hides active alerts, the Home stack shall show the hidden related-alert count with a direct Alert Center affordance - the bell badge and Home surface may never silently disagree.
1.27	2026-07-10	BionicLoop engineering	Consolidated SRS-ALERT-019 forced-open behavior; aligned SRS-BG-006 with the implemented step-scoped staleness bound and SRS-SEC-001 with the investigational export posture under RA-009; corrected duplicate revision numbers; retired obsolete feasibility wording; and added SRS-ALG-008 algorithm-instance isolation.
1.28	2026-07-14	BionicLoop engineering	Added the clinically approved SRS-OUTAGE-001..006 CGM-outage family, SRS-PUMP-011 pump-command watchdog, and an SRS-ALERT-019 supersession note while the backup-basal bridge is released.
1.29	2026-07-14	BionicLoop engineering	Clinical IFU-review feedback (Camille Powe): SRS-CLIN-013 first-launch defaults (Standard profile, 120 mg/dL target, 75% meal upfront, 40-minute TMAX for Fiasp; defaults never rewrite persisted values) and SRS-CLIN-014 New Participant Reset for reused phones (full participant-scoped wipe + sign-out, refused while armed or pod active), distinct from the same-participant algorithm reset.
1.30	2026-07-14	BionicLoop engineering	Sponsor device-pass feedback: SRS-CLIN-013 amended (empty-store loads return first-launch defaults without persisting - fixes post-reset resurrection of legacy-era defaults; per-mode wizard target defaults Standard 120 / Pregnancy 110; mode shown in the review summary) and SRS-CLIN-014 amended (armed sessions get a guided stop-then-reset flow instead of a refusal).
1.31	2026-07-14	BionicLoop engineering	Aligned SRS-PUMP-010 with the implemented assumed-delivered clinical-policy disposition for unresolved, mismatched, non-credible, or missing-identity issued-dose evidence once a fresh settled post-request pump status exists; scoped SRS-CLIN-012 to Clinical Settings profile changes outside first-launch setup; aligned reset terminology with the shipped Same-Participant Reset label.
1.32	2026-07-15	BionicLoop engineering	SRS-LOG-010 added: build-designated cloud-log profile (Info.plist-baked level/end-date/label; launch-established integration logging session, one run ID per device per profile window, inert past the end date, no participant-facing controls) supporting field integration-evidence collection.
1.33	2026-07-16	BionicLoop engineering	Sponsor-directed logging-config consolidation: SRS-LOG-011 added (server-issued remote logging config fetched at launch/foreground; session > remote > default precedence; BionicScout admin-issued only) and SRS-LOG-004 superseded to no-in-app-control (the debug-build threshold and integration-session Settings controls are removed; study logging is profile- or server-configured).
1.34	2026-07-16	BionicLoop engineering	SRS-LOG-011 amended (sponsor UX direction): periodic re-fetch (nominal 30-minute interval) added to the launch/foreground triggers so long-running phones pick up dashboard changes without a relaunch, and Settings shall show the effective logging state as read-only status text (level, expiry, source: study session / study team / default) with no controls.
1.35	2026-07-16	BionicLoop engineering	Sponsor direction ("just use the cloud session"): SRS-LOG-010 superseded pre-ship - the build-baked profile and the entire on-phone integration-session layer are removed; SRS-LOG-011 amended to the sole-lever posture (threshold = active server config else default; legacy session storage ignored) and gains the threshold-exempt remote_logging_config_applied/_cleared cloud markers on change; SRS-LOG-004 reference updated.
1.36	2026-07-16	BionicLoop engineering	SRS-UI-009 added (sponsor request): server-configurable investigational badge - default NOT FOR HUMAN USE when unset (fail-safe), admin-set text (presets or arbitrary, <= 60 chars), explicit blank shows no badge; fetched on the shared SRS-LOG-011 cadence; mirrored on the BionicScout dashboard chrome.
1.37	2026-07-16	BionicLoop engineering	SRS-OUTAGE-002 amended (field catch, sponsor-reported): "CGM outage is active" precisely defined for the countdown surface - blind executed step AND (algorithm offline mode openLoopMode == 2 OR fingerstick-fed step OR BG-run in progress via the persisted schedule's last qualifying source). An isolated blind step with the dropout clock intact (relaunch/wake firing ahead of a healthy sensor's reading) is explicitly not an outage - the prior implementation showed a false fingerstick countdown for ~10 minutes after relaunch.
1.38	2026-07-16	BionicLoop engineering	SRS-OUTAGE-006 amended after a live field discovery: release windows shall be quantified on the engaged fallback event at re-arm; the connected-case algorithm-accounting gap was recorded as a known deviation pending the differentially characterized resolution.
1.39	2026-07-17	BionicLoop engineering	SRS-CLIN-015 added after coverage review: plausible weight-entry range 50-500 lbs gates usable clinical configuration; persisted weight is bounded at 500 lbs without upward fabrication; and the algorithm layer applies a 20-230 kg final clamp whose low bound under-doses.
1.40	2026-07-17	BionicLoop engineering	RA-009 closure package: SRS-SEC-001 amended (file sharing removed; CSV sealed to gated share; export posture decided), SRS-SEC-002 spool protection clause, SRS-LOG-012 added (sequence-numbered envelopes: durable outbox sequence + install/session identity on every upload; immediate markers reserve durable sequences; Scout completeness basis).
1.41	2026-07-17	BionicLoop engineering	SRS-CLIN-014 amended for reset delivery assurance: pre-reset final flush attempt with an undelivered-count consent line, best-effort telemetry.outbox.discarded marker, sequence-continuity-preserving erasure, no discard on blocked resets, and a deduplicated operator alert for permanent upload-rejection episodes.
1.42	2026-07-18	BionicLoop engineering	SRS-OUTAGE-006 amended after a field-observed pod-away gap was credited as one reconnect tuple: released-window accounting now uses live per-step crediting, and pod-away gaps use standard bounded schedule-weighted replay with baseline re-anchor, exactly-once accumulation, zero-delta retraction rows, identity-mismatch suppression, and pump-measured confirmation when credits accumulate.
1.43	2026-07-18	BionicLoop engineering	SRS-OUTAGE-006 amended after independent safety review: gap-replay shares use 0.01 U schedule-weighted largest-remainder allocation so booked and measured totals match; the persisted plan carries credit context across termination; and schedule weights use the engaged event's recorded profile timezone with device-zone fallback.
1.44	2026-07-18	BionicLoop engineering	SRS-MEAL-002 amended (sponsor field report 2026-07-18): meal announce is additionally blocked while the primary algorithm is forced-open (backup basal running during a released CGM outage) - a meal bolus cannot deliver in that state; new backupBasalRunning unavailable reason, self-clearing on BG entry or sensor recovery. Replaces the prior behavior where announce was allowed and the delivery modal spun indefinitely.
1.45	2026-07-18	BionicLoop engineering	Documentation truth-sync: SRS-STATE-004 no longer claims that active issued-dose reconciliation holds persist. The writer-less hold state and its guards were removed in c42f2a6; pending issued-dose attribution, consumed-delivery deduplication, discrepancy evidence, and reconciliation-failure lifecycle records remain the implemented controls. SRS-SEC-002 now includes the implemented protection/backup-exclusion requirement for app-enumerated Algo2015 diagnostic artifacts.
1.46	2026-07-19	BionicLoop engineering	Pending manual-BG and alert-precedence hardening: SRS-BG-004/SRS-MEAL-002 allow meal announce during forced-open only when a valid persisted fingerstick is targeted to the exact prospective meal step, while retaining every pump/reconciliation gate; SRS-ALERT-011 gives active pump signal loss precedence over same-severity check-BG prompts without overriding safety-critical severity.
1.47	2026-07-20	BionicLoop engineering	Manual-BG confirmation and request-emphasis hardening: SRS-BG-001 requires a spatially separate exact-value review confirmation; SRS-OUTAGE-003 extends Home BG-entry emphasis to direct due-soon and overdue fingerstick requests.
1.48	2026-07-20	BionicLoop engineering	SRS-PUMP-010 fresh-completion upgrade rule (field incident on 2026-07-20, sponsor-approved): the relaunch persisted-evidence deferral/suppression no longer freezes a non-final in-progress or assumed delivered figure when a fresh same-pod settled status at/after expected physical completion reports bolusNotDelivered = 0 — the adapter reconstructs and surfaces the pump-observed completed delivery, and matching non-assumed evidence below the requested amount is replaced by the strictly-higher same-pod post-completion pump observation before consumption. Canceled/interrupted partials (nonzero register), different/unproven pods, active-delivery, and pre-completion early-read shapes are explicitly excluded; no delivered figure is ever raised on assumption alone.
1.49	2026-07-20	BionicLoop engineering	SRS-MEAL-006 amended (sponsor-approved field report 2026-07-20): when the open composer was unlocked by the pending-fingerstick carve-out and a loop step consumes that BG before submit while the algorithm stays forced-open, the inline blocked messaging shall state the BG was already used by a dosing step and request another fingerstick or sensor recovery — not the generic backup-basal copy; selections stay preserved and the existing in-place re-arm / inline-clear recovery resumes the flow. The re-closed-loop sub-shape (BG-consuming step returns to closed loop) continues to heal through the existing stale-observed-step in-place re-arm.
1.50	2026-07-20	BionicLoop engineering	SRS-MEAL-006 consumed-carve-out clause corrected (sponsor correction 2026-07-20 of the 1.49 amendment, which mis-modeled the clinical behavior): an accepted fingerstick BG restarts the full CGM-dropout tolerance window and its consuming step publishes closed-loop state, so forced-open availability after the pending BG cleared but before the consuming step publishes is transient continuity — the composer holds armed on a passive waiting notice (never a demand for another fingerstick within the BG validity window) until that step's publication re-arms it, and the same hold applies to a backup-basal-blocked submit during the in-flight window. Generic backup-basal messaging applies only when forced-open persists after the consuming step published (pending BG expired unconsumed or not accepted).
1.51	2026-07-21	BionicLoop engineering	SRS-LOG-009 amended (sponsor request 2026-07-20, steady-cadence fallback schedule visibility): schedule_checked_unchanged events now carry the programmed four-entry schedule plus profile coverage metadata (omitting only the bulk 288-rate array); arm/refresh/unchanged events add per-six-hour-segment observed-slot counts (profile_observed_slot_counts_by_bucket); Recent Dose Steps schedule rows show the four segment rates, an armed/updated/unchanged outcome label, and per-segment observed-vs-imputed provenance (<50% observed marks imputed).
1.52	2026-07-21	BionicLoop engineering	SRS-PUMP-010 fresh-completion evidence rule corrected after review against the 2026-07-08 canceled-bolus field incident: bolusNotDelivered = 0 after relaunch is not completion proof for persisted partial evidence. A partial may be upgraded only when durable provenance identifies it as capped while delivery was still active; canceled and legacy-unclassified partial evidence remains authoritative. Assumed-full evidence may surface a matching fresh pump observation without increasing the conservative amount.
1.53	2026-07-21	BionicLoop engineering	SRS-MEAL-002 prospective forced-open guard: meal announce is blocked before dispatch when its borrowed/due step would be the 13th glucose-blind step and enter Algo2015 forced-open mode, even if the prior persisted output was still closed-loop. The same policy runs in UI preflight and in the coordinator before meal persistence; fresh CGM or a valid exact-step fingerstick permits the step. Blocked copy confirms the meal was not announced and no meal insulin was delivered.
1.54	2026-07-22	BionicLoop engineering	SRS-MEAL-002 presentation precedence corrected: when the active connected pod reports an in-progress delivery, meal preflight reports the pump as busy delivering even if issued-dose attribution is also pending; reconnect guidance remains for idle unresolved attribution.
1.55	2026-07-22	BionicLoop engineering	SRS-MEAL-006 open-composer recovery corrected for intermediate runtime publication: pending-BG consumption remains in flight until the exact step's qualifying-glucose marker publishes, even when a pre-command checkpoint already exposes that step as executed. Qualifying-glucose and live pump-status changes now trigger revalidation so recovered availability re-arms the composer and connected active delivery promptly replaces stale backup-basal guidance with pump-busy guidance.
1.56	2026-07-24	BionicLoop engineering	Added SRS-CLIN-016/017 and SRS-LOG-013 for the Pregnancy Temporary Target, explicit Standard-to-Pregnancy 90% meal draft default, and lifecycle/per-step app-to-Scout monitoring contract.
1.57	2026-07-24	BionicLoop engineering	SRS-CLIN-014 reset telemetry ordering and reset-boundary concurrency aligned to the reviewed implementation: ordinary prior-participant uploads must quiesce before durable outbox erasure; inability to quiesce or persist the erase fails closed; the best-effort discard marker is initiated only after erasure; live pod/session guards are rechecked after awaits; algorithm arming is blocked while reset owns the transaction; and all outgoing Temporary Target state, including pending lifecycle records, is removed by the full participant wipe.
1.58	2026-07-24	BionicLoop engineering	Clarified SRS-LOG-013 reset telemetry boundaries: same-participant/session reset emits the lifecycle record, while New Participant Reset erases the outgoing participant identity and pending lifecycle state without emitting a new outgoing-participant event.
1.59	2026-07-30	BionicLoop engineering	Extended SRS-CLIN-016 so the combined Exercise and Insulin Delivery screen directly owns the existing Pod suspend/resume control, the duplicate control is absent from normal Pod Settings, reminder duration remains reminder-only, and suspend-alert navigation reaches the relocated control.
1.60	2026-07-30	BionicLoop engineering	Clarified SRS-SEC-009 login recovery: signed-out active-therapy Home keeps a persistent top-level Log In control independent of alert ordering; the active alert, Alert Center, Account & Session, and alert notification all provide a direct route to login without stopping the local algorithm session.
1.61	2026-07-30	BionicLoop engineering	Extended SRS-CLIN-016 with Exercise and Insulin Delivery placement above User, app-standard Temporary Target selection controls, removal of the unrelated reset-location text, and explicit discard confirmation when a target or duration draft would otherwise be lost before review/activation.
1.62	2026-07-30	BionicLoop engineering	Extended SRS-UI-002 so the Home Manual BG and Meal Announcement actions remain visible and actionable while status, alert, and chart content scrolls; action eligibility and handlers remain unchanged.
1.63	2026-07-30	BionicLoop engineering	Amended SRS-LOG-012 so permanent telemetry rejection remains durable, structured local evidence and a BionicScout sequence gap without a participant-facing generic upload alert; actionable subject-identity conflicts retain their specific alert, rate limits remain retryable, and a one-time launch migration removes earlier-build generic alerts and notifications.
1.64	2026-07-30	BionicLoop engineering	Extended SRS-CLIN-016 so an ended suspension reminder offers a direct Resume Insulin command, remains active until pump-confirmed recovery, and escalates to safety-critical with a fresh notification when insulin remains suspended for 15 minutes.
1.65	2026-07-30	BionicLoop engineering	Tightened SRS-MEAL-002/SRS-PUMP-010/SRS-UI-002 for suspension: meal entry requires a confirmed idle Pod before algorithm execution, pump-confirmed resume clears the block without waiting for a loop step, definitively blocked bolus metadata cannot be reconstructed as delivery feedback, and Home displays persistent paused-delivery status.
1.66	2026-07-30	BionicLoop engineering	Added explicit and persistent G7 replacement acquisition, a staleness-never-releases identity control, ten-minute in-app acquisition guidance, and durably deduplicated adoption/stall telemetry requirements (SRS-CGM-006, SRS-ALERT-020, SRS-LOG-014).
1.67	2026-07-31	BionicLoop engineering	Tightened SRS-ALERT-014 blocker diagnosis so participant copy follows the latest unresolved runtime outcome or authoritative pump condition, represents suspension and fallback recovery explicitly, and cannot remain CGM-specific after contradictory evidence or a successful live step; clarified SRS-CLIN-014 reset isolation for asynchronous device-state persistence and telemetry completion.
1.68	2026-08-06	BionicLoop engineering	Extended SRS-LOG-001 so Recent Dose Steps identifies valid manual/fingerstick BG input, shows the exact value used, and preserves any concurrent CGM evidence.
1.69	2026-08-11	BionicLoop engineering	Added SRS-ALG-009 after field telemetry exposed meal-step pump commands that omitted the concurrent basal component and therefore failed the Algo2015 delivered-insulin reconciliation gate.
1.70	2026-08-11	BionicLoop engineering	Corrected SRS-CLIN-002/013 document drift: initial clinical configuration is available without an unlock only while no usable subject configuration exists; every later Clinical Settings entry/edit remains subject-scoped offline-unlock gated.
1.71	2026-08-13	BionicLoop engineering	Hardened SRS-LOG-012 for incident-scale offline telemetry: update-safe spool migration, incremental protected persistence, retained-evidence-first recovery, coalesced chatter-drop reporting, transition-only notification telemetry, and passive backlog visibility.
1.72	2026-08-17	BionicLoop engineering	Strengthened SRS-LOG-001/012 with complete active-session protected step evidence, an uncapped retained-clinical SQLite ledger, durable-enqueue/network-drain separation, retry liveness, and backward-compatible bounded batch ingest.
1.73	2026-08-20	BionicLoop engineering	Added SRS-BG-013 so Home distinguishes an accepted pending fingerstick BG from completed algorithm-use evidence without moving or duplicating the chart marker.
1.74	2026-08-20	BionicLoop engineering	Added SRS-LOG-015 for clinical-gated, session-scoped export of byte-faithful legacy Algo2015 artifacts using epoch grouping, bounded snapshots, partial-set disclosure, and protected temporary ZIP staging.
1.75	2026-08-20	BionicLoop engineering	Replaced the competing Settings export presentations with the established Recent Dose Steps share action and one protected ZIP containing the complete step CSV plus the matching/current legacy Algo2015 session artifacts.
1.76	2026-08-20	BionicLoop engineering	Extended SRS-ALERT-014 so fresh idle Pod status after a pump-status-unavailable attempt updates the existing interruption alert to communication-restored/waiting-for-glucose guidance without triggering algorithm work; stale or non-idle status cannot claim recovery.
1.77	2026-08-20	BionicLoop engineering	Extended SRS-UI-008 so the Home CGM chart renders discrete glucose points without a connector line or interpolated area fill while preserving point color, time placement, and scrub selection.
1.78	2026-08-21	BionicLoop engineering	Bound the controlled specification to the immutable 2026-08-21 software freeze and clarified the pending approval boundary. No requirement or product behavior changed.
1.79	2026-08-27	BionicLoop engineering	Replaced internal development labels and test-device shorthand with reviewer-neutral descriptions and updated the approval role. No requirement or product behavior changed.
1.80	2026-08-27	BionicLoop engineering	Aligned SRS-SEC-001 with the clinically approved supportive Scout boundary and official insulin-delivery source, recorded the confirmed participant-weight range, and corrected reset-drain wording. No product behavior changed.
1.81	2026-08-28	BionicLoop engineering	Added requirement-control methodology, applicability and safety-significance classification, controlled threshold definitions, addressable compound-clause ranges, and complete deferred/retired traceability disposition. Replaced implicit timing terms with frozen-baseline values. No product requirement or behavior changed.
1.82	2026-09-03	Software Developer	Completed the reviewer-style consistency audit: made frozen thresholds explicit, removed internal working-record citations from submission-facing text, clarified deferred security scope, and aligned controlled-source traceability. No product behavior or frozen-baseline requirement changed.

Historical interim revision identifiers such as 1.111 and 1.151 preserve the original controlled record and are not a chronological renumbering error.

Requirement Format

Each requirement uses a stable parent ID. A parent containing one normative shall or shall not occurrence is an atomic requirement. A parent containing multiple normative occurrences is a requirement family retained to preserve the frozen design and evidence links.

Within a requirement family, each normative occurrence has an addressable child clause ID formed by appending a two-digit sequence in textual order, beginning with .01. For example, the first and second normative occurrences in SRS-PUMP-010 are SRS-PUMP-010.01 and SRS-PUMP-010.02. A child clause is read with the subject, conditions, and definitions in its governing sentence. The sequence is controlled for this revision and shall not be reordered or reused without a documented traceability impact assessment.

RTM mapping to a parent applies to all of its child clauses. Parent-level verification or approval may be closed only after every applicable child clause has objective evidence or a documented disposition. Explanatory text under Team review notes, evolution notes, and revision history is informative and not an additional requirement.

Applicability

• Active: normative for the frozen baseline.
• Deferred: excluded from the frozen baseline; implementation or working evidence does not make it an accepted requirement without explicit scope re-entry.
• Retired: historical identifier retained for traceability and prohibited from reuse.

All requirements are Active except SRS-BG-008 and SRS-SEC-003..009, which are Deferred, and SRS-LOG-010, which is Retired.

Safety Significance

• C1 - direct therapy control: failure could directly affect insulin calculation, command authorization, delivery accounting, fallback delivery, device identity, or safety-critical clinical configuration.
• C2 - supporting safety control: evidence integrity, participant communication, cybersecurity, or operational support that does not itself authorize insulin delivery.
• D - deferred or retired: not part of the frozen-baseline claim.

Requirement set	Applicability	Safety significance
SRS-RUN-001..007	Active	C1
SRS-CGM-001..006	Active	C1
SRS-BG-001..007, SRS-BG-009..012	Active	C1
SRS-BG-013	Active	C2
SRS-BG-008	Deferred	D
SRS-PUMP-001..011	Active	C1
SRS-MEAL-001..012	Active	C1
SRS-OUTAGE-001..006	Active	C1
SRS-STATE-001..005	Active	C1
SRS-ALG-001..009	Active	C1
SRS-LOG-001..009, SRS-LOG-011..015	Active	C2
SRS-LOG-010	Retired	D
SRS-UI-002, SRS-UI-004, SRS-UI-005, SRS-UI-007	Active	C1
SRS-UI-001, SRS-UI-003, SRS-UI-006, SRS-UI-008, SRS-UI-009	Active	C2
SRS-CLIN-001..017, SRS-VAL-001	Active	C1
SRS-ALERT-019	Active	C1
SRS-ALERT-001..018, SRS-ALERT-020	Active	C2
SRS-SEC-001..002	Active	C2
SRS-SEC-003..009	Deferred	D

The C1 set is the reviewer-priority critical-requirement index for this SRS. The Risk Analysis and RTM remain authoritative for hazard linkage and residual risk; this classification does not replace those records.

Controlled Terms and Thresholds

Term	Frozen-baseline definition
Approved CGM freshness limit	Accepted CGM receipt age no greater than 5 minutes for algorithm-use and reconnect-fallback eligibility.
Approved interruption threshold	More than 15 minutes without a successful algorithm step while the session is armed.
Algo2015 CGM-dropout tolerance	60 minutes, represented by 12 consecutive five-minute blind steps after the last accepted CGM or fingerstick BG input; forced-open behavior begins on the next blind step.
Approved no-active-Pod/signal-loss debounce	5 minutes; display and alert debounce do not alter pump-command or dosing safety state.
Approved borrow window	At most 2 future five-minute slots, as constrained by SRS-MEAL-001.
Approved renewal window (fallback mask)	The final 20 minutes of the active 30-minute 0.0 U/hr mask.
Issued-dose request-unit match tolerance	Absolute requested-unit difference no greater than 0.025 U; delivered units must remain within 0...requested with a numerical tolerance of 0.0001 U.
Trustworthy G7 reading, for SRS-ALERT-016	A reading with the G7 reliable-glucose flag, a glucose value, and an observation age no greater than 11 minutes. This alert criterion does not broaden the separate 5-minute algorithm-input freshness limit.
Fresh pump status	A status obtained by the current required refresh operation rather than restored or cached status.
Settled pump status	A fresh pump delivery state of idle or suspended, not delivering or unknown.
Valid fallback candidate	A candidate derived from the current or latest successful algorithm step for the current subject/session and usable by the fallback schedule/rate selection defined in SRS-PUMP-006 and SDD-PUMP-001.
Credible pump-delivery evidence	Evidence satisfying the applicable pod-identity, request-step, measurement-window, delivered-range, schedule-compatibility, and partitioning controls in SRS-PUMP-009, SRS-PUMP-010, and SDD-PUMP-001.
Normal execution safety gates	The active-session, due-step, device-identity, fresh pump-status, delivery-state, suspension, fallback-recovery, and issued-dose reconciliation gates applicable to the requested wake path. The controlling requirements are SRS-RUN-002..006, SRS-PUMP-001..011, and SRS-STATE-001..005.
Protected local evidence	Exported CSV and temporary recovery-export staging use complete file protection. The telemetry ledger, current-session step archive, and enumerated live Algo2015 artifacts use complete-until-first-user-authentication protection. All are backup-excluded; see SRS-SEC-001..002 and SDD-LOG-001.

Compound Requirement Family Index

The following high-density families are called out because their clauses span multiple failure and recovery paths. Clause counts are the normative shall / shall not occurrences in this revision.

Requirement family	Child clause range	Primary verification mapping
SRS-RUN-002	.01..12	TV-RUN-001, TV-RUN-002, TV-RUN-005, TV-RUN-006, TV-MEAL-001, TV-MEAL-011, TV-SIM-001
SRS-RUN-006	.01..27	TV-RUN-008, TV-SIM-POD-001
SRS-PUMP-009	.01..13	TV-PUMP-008, TV-SIM-POD-003, TV-SIM-POD-004
SRS-PUMP-010	.01..34	TV-PUMP-009, TV-MEAL-013, TV-SIM-POD-004
SRS-MEAL-002	.01..16	TV-MEAL-002, TV-MEAL-005, TV-SIM-004
SRS-MEAL-006	.01..15	TV-MEAL-007
SRS-OUTAGE-006	.01..14	TV-OUTAGE-002, TV-PUMP-008, TV-RUN-008
SRS-LOG-009	.01..13	TV-LOG-009, TV-SIM-POD-002..004
SRS-LOG-012	.01..21	TV-LOG-012
SRS-CLIN-002	.01..15	TV-CLIN-001
SRS-CLIN-014	.01..14	TV-CLIN-015
SRS-CLIN-016	.01..22	TV-CLIN-017, TV-LOG-013, TV-ALERT-009
SRS-ALERT-014	.01..10	TV-ALERT-013
SRS-SEC-001	.01..10	TV-SEC-001, TV-LOG-015
SRS-LOG-015	.01..12	TV-LOG-015

The complete family-range register below makes every compound parent directly auditable. Parents not listed contain one normative occurrence and are atomic at the parent ID; SRS-LOG-010 is the retired zero-clause exception.

• Runtime: SRS-RUN-002(.01..12), SRS-RUN-005(.01..03), SRS-RUN-006(.01..27), SRS-RUN-007(.01..03).
• CGM and BG: SRS-CGM-006(.01..05), SRS-BG-001(.01..03), SRS-BG-002(.01..02), SRS-BG-004(.01..03), SRS-BG-005(.01..02), SRS-BG-006(.01..03), SRS-BG-013(.01..04).
• Pump: SRS-PUMP-006(.01..07), SRS-PUMP-007(.01..02), SRS-PUMP-008(.01..08), SRS-PUMP-009(.01..13), SRS-PUMP-010(.01..34), SRS-PUMP-011(.01..03).
• Meal: SRS-MEAL-002(.01..16), SRS-MEAL-006(.01..15), SRS-MEAL-007(.01..04), SRS-MEAL-008(.01..02), SRS-MEAL-009(.01..04), SRS-MEAL-010(.01..02), SRS-MEAL-012(.01..05).
• Outage, state, and algorithm: SRS-OUTAGE-001(.01..02), SRS-OUTAGE-002(.01..02), SRS-OUTAGE-003(.01..04), SRS-OUTAGE-004(.01..03), SRS-OUTAGE-006(.01..14), SRS-STATE-004(.01..05), SRS-STATE-005(.01..02), SRS-ALG-007(.01..02), SRS-ALG-008(.01..02), SRS-ALG-009(.01..02).
• Logging: SRS-LOG-001(.01..09), SRS-LOG-007(.01..02), SRS-LOG-009(.01..13), SRS-LOG-011(.01..06), SRS-LOG-012(.01..21), SRS-LOG-013(.01..04), SRS-LOG-014(.01..05), SRS-LOG-015(.01..12).
• UI and clinical configuration: SRS-UI-002(.01..04), SRS-UI-005(.01..02), SRS-UI-006(.01..03), SRS-UI-008(.01..03), SRS-CLIN-002(.01..15), SRS-CLIN-011(.01..02), SRS-CLIN-013(.01..08), SRS-CLIN-014(.01..14), SRS-CLIN-015(.01..05), SRS-CLIN-016(.01..22), SRS-CLIN-017(.01..02).
• Alerts and security: SRS-ALERT-005(.01..02), SRS-ALERT-011(.01..07), SRS-ALERT-012(.01..02), SRS-ALERT-014(.01..10), SRS-ALERT-015(.01..05), SRS-ALERT-016(.01..06), SRS-ALERT-017(.01..02), SRS-ALERT-018(.01..04), SRS-ALERT-019(.01..07), SRS-ALERT-020(.01..04), SRS-SEC-001(.01..10), SRS-SEC-002(.01..03), SRS-SEC-009(.01..04).

System Boundary and Operating Context

This SRS is read with the controlled IDE Software Device Description and Software Version and Configuration Identification. Those records identify the exact app, iOS/toolchain configuration, local packages, algorithm source, dependency resolution, and frozen source commit; the SRS does not duplicate configuration identifiers that are controlled there.

The software boundary comprises the BionicLoop iPhone application, BionicLoopCore runtime and safety policy, the two isolated Algo2015 controller instances, G7SensorKit/G7SensorKitUI, OmniBLE, LoopKit, and protected local state/evidence stores. External interfaces are Dexcom G7 and Omnipod DASH over Bluetooth Low Energy, iOS lifecycle/notification services, clinical-gated local export, and supportive BionicScout telemetry. Cloud availability is not an input to local dosing authorization.

Principal inputs are CGM and fingerstick glucose, pump status and delivery feedback, meal selections, clinical configuration, time/session state, and explicit participant actions. Principal outputs are algorithm records, allowed pump commands, participant status/alerts, protected local evidence, and supportive telemetry. Ranges, limits, defaults, error handling, and recovery behavior are specified in the requirement families below.

Runtime and Cadence

• SRS-RUN-001: The runtime shall maintain 5-minute algorithm cadence anchored to first successful step execution time.
• SRS-RUN-002: The runtime shall compute expected step index from anchored schedule and skip duplicate step execution for the same index. Before resolving ordinary cadence or meal-announce step selection, runtime shall reconcile persisted cadence state with the algorithm-reported next step; if the algorithm has already consumed the current due step while the persisted runtime state lags, runtime shall advance persisted lastExecutedStep to the algorithm-implied last executed step without re-anchoring the schedule, so live executedStep, pump request-step attribution, and algorithm input stepTime remain aligned. Loop work passes shall be single-flight: at most one load-maintain-persist-execute pass may be in flight at a time, concurrent wake triggers shall queue FIFO, and each queued pass shall load persisted state when it actually starts. If the algorithm-reported next step is ahead of the runtime step base beyond the one-step reconcile, runtime shall adopt the algorithm counter as the step base without re-anchoring the schedule, skip until wall clock reaches the adopted counter while fallback basal coverage remains in force, publish an informational auto-clearing re-sync note stating the resume window, and resume automatically; runtime shall not halt dosing or demand a manual algorithm reset on step mismatch. Pre-execution state persistence shall be monotonic within a session anchor: a pass shall not persist a lastExecutedStep older than the currently persisted value for the same firstSuccessfulStepAt anchor and shall instead abort benignly as a superseded pass; session resets with a different or cleared anchor may regress freely. Algorithm step-drift blocking shall therefore only ever be evaluated against state at least as fresh as the last completed pass.
• SRS-RUN-003: The runtime shall execute loop work only on the approved configured wake causes: cgmUpdate, bgCheck, mealAnnounce, and guarded pumpReconnect fallback paths.
• SRS-RUN-004: After the first successful anchored step exists, the runtime shall permit a guarded pump-reconnect fallback wake to execute the current due step when no accepted CGM receipt newer than the 5-minute CGM freshness limit exists and normal execution safety gates pass.
• SRS-RUN-005: Ordinary guarded pump-reconnect fallback for CGM absence shall not execute step 0, shall not re-anchor cadence, and shall not replay multiple missed slots; each ordinary reconnect-triggered execution may service at most the current due step. This row does not describe masked offline-fallback recovery after a persisted reconciliation-required state.

• SRS-RUN-006: Masked offline-fallback shall not arm a new fallback schedule or refresh the programmed fallback schedule unless the loop is armed, a current algorithm session identifier exists, and a valid fallback candidate is available from either the current just-computed algorithm step or a prior successful step. When a current step first produces a valid fallback candidate and no fallback is armed, runtime shall attempt the first fallback arm after primary/secondary algorithm calculation and before applying that same step's pump command, so step 0 and other first-candidate steps cannot let a bolus outrun fallback arming. Pre-execution masked-fallback arm, mask-renewal, and schedule-refresh maintenance shall require freshly refreshed idle pump status; unavailable, unknown, delivering, or refresh-failure status shall defer that maintenance and record the defer reason without mutating pump state. An already-masked fallback may renew its existing 0.0 U/hr mask before the next step executes once the runtime is inside the approved renewal window, but only while the current mask remains active and pump maintenance safety gates pass. If runtime later detects offline mask expiry (maskExpiredOffline) or any remask failure leaves the fallback schedule potentially exposed after possible schedule mutation or mask replacement, it shall persist a masked-fallback reconciliation-required recovery state, suppress ordinary loop doWork execution, and keep closed-loop stepping blocked until reconnect recovery either resolves by connected restore/disarm or is otherwise explicitly cleared; it shall not silently auto-resume authoritative closed loop in the same session immediately after detecting that exposure state. For the accepted baseline, if reconnect restore succeeds while the loop remained armed and basal-only reconnect evidence is confirmed or corrected, runtime shall preserve the existing session/cadence anchor, bound replay to missed steps before the resumed current due step whose delivery interval overlaps confirmed fallback-active time, and replay those primary and secondary/safety algorithm steps with unavailable CGM input (CGM=-1) and per-step pump-delivery input allocated from credible pump-reported delivered insulin using the persisted programmed fallback schedule as the per-step weighting model. Each fallback-only replay row after the first shall report unitsRequested as the algorithm's own issued ask from the preceding replay row: the Algo2015 reconcile gate only credits a reported delivery whose requested amount matches its own remembered ask within one mechanical step (0.01 U), so echoing the actual ask credits pod-measured shares at any fallback rate. When pre-fallback issued-dose replay rows precede the fallback window, the first fallback replay row shall echo the last preceding issued-dose replay row's ask across the seam; only a classic fallback recovery with no preceding replay rows keeps the allocated-share proxy on its first row (a released-outage pod-away gap replay instead echoes the persisted pre-gap ask carried in the plan's credit context, per SRS-OUTAGE-006). Disconnected missed steps before offline fallback activation shall remain missing and shall not be replayed as synthetic 0 U rows, except when a resolved issued dose requires pre-fallback attribution replay: the dead-gap window from the dose's first eligible attribution step to the step before fallback activation shall then be replayed as a pure issued-dose confirm row - whose pump tuple echoes the issued ask exactly and reports the reconciled delivered amount, so the reconcile gate cannot be broken by a fallback share riding on the requested side - followed by zero-delivery echo sentinel rows that retract each preceding offline ask (the pod was idle; these rows claim no fallback exposure). When the fallback window begins on the first eligible attribution step itself (no dead-gap room), the resolved issued dose shall merge into the first fallback replay row with unitsRequested echoing the issued ask exactly and the fallback share carried only in unitsDelivered; the algorithm credits that share as an over-delivery adjustment at its last-run buffer position (the request step), an accepted clinical policy bounded to one slot's fallback share booked early. The replayed steps shall not issue pump commands. The resumed live step shall then execute with actual refreshed CGM/pump status and shall not receive a duplicate aggregate recovered-delivery input. If reconnect evidence is ambiguous, runtime may resume the existing session on the current due 5-minute step without fallback delivery reconciliation, but that path shall be marked as an unreconciled resume rather than authoritative reconciliation, and when nonzero fallback insulin may have been delivered (pump-reported delta or modeled exposure greater than zero) runtime shall raise a safety-critical operator alert rather than resume silently. If connected restore/disarm cannot complete because the previous pod is known inactive/no-active, retired, or past hard service-stop while masked-fallback recovery remains pending, runtime may clear the recovery state without creating a new algorithm session by recording modeled fallback exposure as assumed_delivered_per_clinical_policy, queueing the same bounded no-command replay plan, and labeling the recovery as assumed rather than pump-confirmed. While a masked-fallback reconciliation-required recovery state remains pending, runtime shall keep reconnect recovery attempts live without requiring user interaction: any ordinary wake blocked by the pending state (including CGM-driven doWork) shall re-schedule a reconnect recovery attempt, and a recovery trigger arriving while an attempt is already in flight shall be retained and re-evaluated after that attempt completes rather than dropped. A queued fallback replay plan shall carry the reconciliation status of the recovery that authorized it, and replay authorization shall be judged by that stamp - a later fallback lifecycle event (such as the post-recovery re-arm, which is always pending) shall not mask an authorized plan into disposal; plans persisted before the stamp existed retain the legacy latest-event check. Pump-counter replay evidence shall be evaluated against the interval the measurement actually covers: the credited exposure window is bounded to the pod-total measurement time, recovery-completion latency after that measurement bounds rather than disqualifies the evidence, and the uncovered post-measurement tail is not replayed. After a successful connected restore, runtime shall prefer pod totals re-read after the restore (totals-only overlay preserving pre-disarm schedule and temp-basal evidence) so fallback delivered during the disarm itself is measured and credited. A same-pod pump-counter delta that does not exceed modeled fallback exposure plus tolerance shall reconcile as corrected pump-anchored replay even when the delivery baseline exceeds the freshness limit; the unreconciled resume is reserved for genuinely unusable evidence (no delta with mismatched schedule evidence, over-tolerance delta, or unproven pod continuity).

• SRS-RUN-007: The runtime shall never terminate an algorithm session or block dosing pending manual user intervention as an automatic failure response. Automatic failure handling shall degrade to fallback basal coverage and self-healing realignment; algorithm session reset shall remain available only as an explicit user-initiated action.

Team review notes: - SRS-RUN-003 reflects the currently implemented wake-cause policy. - Guarded reconnect fallback is implemented as a secondary wake path from pump-status recovery, not raw BLE connect. - Current reconnect-fallback gate is accepted CGM receipt age > 5 minutes, matching the present CGM freshness limit for algorithm-use eligibility.

CGM Input Handling

• SRS-CGM-001: The runtime shall map CGM values outside 39...401 mg/dL to unavailable input (-1) before algorithm invocation.
• SRS-CGM-002: Step 0 shall require a fresh in-range CGM input.
• SRS-CGM-003: Step >0 shall be allowed to run with unavailable CGM input (-1) when fresh in-range CGM is not available.
• SRS-CGM-004: The UI shall show loop reason/state when step execution is blocked for missing fresh CGM at step 0.
• SRS-CGM-005: When the loop is armed and no successful algorithm step has completed for more than 15 minutes, the app shall detect that loop stepping is stalled and expose that condition to alert/status logic.
• SRS-CGM-006: Dexcom G7 Settings shall always provide an explicit Scan for new sensor action independent of routine BLE scanning for the currently bound sensor. Invoking replacement acquisition shall durably record its start time, prior sensor identity, and trigger before clearing the old binding; relaunch shall preserve that acquisition episode; successful authenticated sensor adoption shall clear it. CGM reading age or connection staleness alone shall never clear the bound sensor identity or initiate replacement adoption.

Team review notes: - SRS-CGM-005 is implemented with a 15-minute threshold based on the most recent successful step time; before the first successful step exists, the threshold is measured from session start / first-step wait state. - The interruption condition is recomputed on foreground from persisted runtime/session state and is distinct from the protocol Dexcom Bluetooth interruption alert (> 2 hours).

Fingerstick BG Input Handling

• SRS-BG-001: The app shall provide a manual BG entry flow with explicit Review, exact-value Use, Change, and Cancel actions; the exact-value confirmation shall appear on a spatially separate review surface so repeated taps at the entry action cannot submit without explicit confirmation. The app shall enforce accepted input range 20...600 mg/dL, capture a submission timestamp at user confirmation time, and show user-facing guidance that manual BG is used for algorithm dosing decisions and does not calibrate CGM.
• SRS-BG-002: Manual BG submit shall trigger a dedicated runtime wake cause (bgCheck) with no future-slot borrowing and shall create/update a single pending BG candidate for the next eligible algorithm step.
• SRS-BG-003: If submit occurs after the current due step has already executed, the pending BG candidate shall roll forward to the immediate next step (not discarded immediately).
• SRS-BG-004: During bgCheck, manual BG shall map to algorithm BG input (BGval) while CGM input mapping policy remains independent (CGM may be unavailable -1). If meal announce executes the exact step targeted by a valid pending manual BG, that single step shall carry both the manual BG and meal inputs to the primary and safety algorithms, and shall consume the pending BG once.
• SRS-BG-005: BG submission shall not override pump command-application safety gates; when pump status is unavailable/unknown, runtime may execute algorithm step but shall block command application.
• SRS-BG-006: Runtime shall bound manual BG staleness through step-scoped candidate validity: a submitted BG is valid only for the immediate next eligible algorithm step and shall be discarded unconsumed once that step passes (see SRS-BG-009), so the BG age at algorithm consumption cannot exceed one cadence interval plus the SRS-MEAL-001 borrow window of at most 2 future five-minute slots. Rejected or discarded submissions shall produce an explicit user-visible reason.
• SRS-BG-007: Telemetry shall record BG source (manualBG), submitted value, submit timestamp, and execution result for each bgCheck attempt.
• SRS-BG-008: Step-0 BG rescue is deferred from the current software baseline. If a future approved baseline enables step 0 BG rescue, it shall permit execution only when fresh in-range CGM is unavailable and a valid fresh manual BG is present.
• SRS-BG-009: Pending BG candidate shall be valid for one step only and must be discarded if not consumed on that immediate next step.
• SRS-BG-010: If a new manual BG is submitted while a pending BG candidate exists and has not yet been consumed, the newer submission shall replace the older candidate.
• SRS-BG-011: Manual BG submit shall not execute bgCheck when loop runtime is disarmed (Algorithm Off state) or when masked-fallback reconciliation is pending.
• SRS-BG-012: Until step-0 BG rescue is explicitly approved, manual BG submit shall be rejected before the first successful anchored step exists (firstSuccessfulStepAt == nil).
• SRS-BG-013: After a manual BG candidate is accepted and persisted, Home shall immediately render an unfilled red blood-drop chart marker at its submission time. The marker shall become filled only when a completed algorithm step records that BG as consumed. Pending and consumed evidence for the same target step shall render as one marker at the original submission time; rejected, replaced, expired, or otherwise discarded unconsumed candidates shall not render as consumed.

Team review notes: - SRS-BG-008 is deferred from the current software baseline; current accepted behavior remains CGM-only at step 0 via SRS-BG-012. - Manual BG accepted range is currently set to 20...600 mg/dL. - Staleness is enforced by step-scoped candidate validity. A separate wall-clock validity limit is not part of the frozen baseline and would require controlled requirements, risk, and verification review before inclusion. - SRS-BG-011 is implemented in app runtime to prevent loop-off execution from manual BG UI. - SRS-BG-012 is currently enforced in runtime; step-0 BG rescue remains disabled by default.

Pump Handling

• SRS-PUMP-001: On pump-status refresh failure or unknown state, runtime shall continue algorithm execution with unavailable pump input fields and block command application.
• SRS-PUMP-002: In closed-loop mode, manual bolus command paths shall not be exposed.
• SRS-PUMP-003: Dosing command handling shall respect DASH delivery constraints, including the supported 0.05 U command quantum.
• SRS-PUMP-004: Home pod status tile shall update to reflect actual connect/disconnect state transitions without requiring user entry into pump settings.
• SRS-PUMP-005: While pump delivery is in progress, Home and meal-availability pump state shall auto-refresh without requiring navigation into pump settings.
• SRS-PUMP-006: For the masked offline-fallback path, the app shall maintain a connected 0.0 U/hr / 30 minute temp-basal mask over the programmed fallback basal schedule while communications remain healthy. The programmed fallback schedule shall be derived from the secondary/safety algorithm track's persisted q5 nominal-basal profile when available by averaging four local-time six-hour blocks (00:00-06:00, 06:00-12:00, 12:00-18:00, 18:00-24:00) and rounding each block to a supported DASH basal rate; if no profile can be generated yet, runtime may fall back to the latest rounded scalar safety-track nominal-basal candidate. Existing masked fallback shall enter renewal once the active mask reaches its final 20 minutes; pre-execution renewal and schedule refresh shall first verify fresh idle pump status, and if renewal is temporarily blocked but the current mask remains active, runtime shall defer maintenance and record the defer reason rather than treating the attempt as an immediate hard failure. Programmed fallback schedule refresh shall use the IDE baseline cadence of no more often than every 6 hours unless explicitly overridden for controlled hardware validation. If successful step execution stalls or deferred maintenance continues long enough for the active mask to expire, the pod may autonomously resume the programmed fallback schedule and runtime shall record that transition for later reconciliation rather than continuing ordinary authoritative loop stepping.
• SRS-PUMP-007: Masked fallback schedule arm, refresh, and disarm shall be treated as disruptive programmed-basal replacements and shall be blocked unless pump delivery state is known and safe for maintenance (no active bolus, no unknown basal-delivery state, and no nonzero temp basal).
• SRS-PUMP-008: If an active algorithm session has no currently armed masked fallback and a valid rounded nominal fallback candidate is available from the current or most recent successful step, runtime shall program the fallback schedule before any later same-step pump command when the candidate was just computed, or in the next safe pre-execution maintenance pass with fresh idle pump status when the candidate was already persisted, and shall apply the connected 0.0 U/hr mask in the same maintenance sequence. The pre-pump-command first-arm attempt shall run only with refreshed pump status that is not unavailable and not unknown; otherwise runtime shall leave first-arm maintenance for a later safe wake and allow the current step's normal pump command path to classify the unavailable or unknown pump state under its own safety rules. The programmed schedule shall prefer the secondary/safety q5 nominal-basal profile-derived four-block schedule over the scalar candidate once at least one valid q5 profile observation exists. If that first arm attempt is cleanly blocked before any schedule mutation, runtime shall leave fallback explicitly unarmed and record the blocked arm as a failure requiring retry, not as ordinary deferred masked maintenance, while the current step's normal pump command may still be attempted under its own safety gates; runtime shall not immediately retry that first arm again in the same cycle after emitting a pre-command fallback event. If schedule programming may have succeeded but the immediate 0.0 U/hr mask fails, is blocked, or is uncertain, runtime shall persist reconciliation-required masked-fallback recovery context and block the current step's normal pump command.
• SRS-PUMP-009: Session reset/disarm after masked fallback has been armed shall attempt to restore the original programmed basal schedule and shall record restore success or failure for operator review. If restore fails, the app shall preserve recoverable restore context and block the next algorithm start until masked-fallback recovery is resolved. When masked-fallback recovery remains pending across reconnect, app start, or foreground, the app may retry connected restore/disarm of the original programmed schedule; if that retry succeeds after offline mask expiry or any remask failure that may have left the fallback schedule exposed while the loop remained armed and basal-only reconnect evidence is confirmed, corrected, or assumed_delivered_per_clinical_policy, it shall preserve the existing session/cadence anchor, clear the blocked recovery state, queue fallback delivery reconciliation, and then permit same-session recovery. Reconciliation shall use pump-reported delivered-insulin delta when same physical pod continuity is proven and the connected delivery-counter baseline credibly spans the exposure window. If pump-reported delivery evidence is unavailable rather than contradictory, same physical pod continuity is proven, recovered schedule evidence matches the persisted fallback schedule, and no pending issued meal/correction dose requires pump-total partitioning, runtime may record persisted-schedule modeled fallback exposure as assumed delivered per clinical policy. Historical CGM is not required to authorize fallback delivery reconciliation; instead, confirmed, corrected, or assumed recovery shall replay only the bounded missed primary and secondary/safety algorithm steps whose delivery interval overlaps the fallback-active interval, with CGM=-1, per-step pump-delivery input allocated from the authoritative pump-reported delta when available or from the assumed modeled exposure when pump evidence is unavailable, explicit 0 U input for fallback-active replayed steps with no allocation, and no catch-up pump commands before resuming the current due step. Pre-activation disconnected missed steps shall not be replayed. When credible pump-reported delta exists, that delta shall remain the authoritative total; schedule-derived exposure shall be used only as the deterministic weighting model, including actual overlap duration when replay slots cross fallback-schedule boundaries or midnight. If the persisted schedule is unavailable or the schedule weights sum to zero while the reconciled/assumed delivered amount is positive, replay shall be suppressed rather than guessed; if the authoritative pump-reported delta is 0 U, replay may still backfill the fallback-active missed step range with explicit 0 U inputs. If reconnect evidence is ambiguous, from a different/new pod, from unknown pod identity, has a delivery-counter/history discontinuity, has recovered schedule evidence that contradicts the persisted fallback schedule without compatible pump-delivery evidence, or cannot safely separate pending meal/correction insulin from fallback basal exposure, the app may instead permit same-session resume on the current due 5-minute slot without fallback delivery reconciliation, but it shall record that outcome as an unreconciled resume for operator review. Successful reconnect recovery shall also retain modeled fallback exposure and, when compatible same-pod pump-evidence baseline data are available, the pump-reported delivered-insulin delta for operator review. If the operator explicitly reset or turned the loop off before recovery completes, the successful restore shall keep the loop off. Exception: when the original pod is known inactive/no-active, retired, or past hard service-stop and connected pump-reported evidence is therefore unavailable, the app may use the persisted fallback schedule to record modeled fallback exposure as assumed delivered per clinical policy, replay the bounded fallback-active missed steps without pump commands, retain the assumed-vs-confirmed distinction in UI/telemetry, and preserve the existing algorithm session.
• SRS-PUMP-010: For any automatic algorithm-issued bolus command (including meal, correction, mixed, or basal micro-dose commands), runtime shall persist issued-dose attribution when the command is applied or its delivery outcome is uncertain. The attribution shall include request step, first eligible attribution step, requested units, request time, expected physical completion time, component split when available, flow ID when applicable, pod identity when available, and the algorithm-visible request step used for meal-learning exclusion when available. If the next due step arrives while that dose is still delivering, runtime shall skip the algorithm step rather than advancing with provisional delivery evidence. The accepted DASH liveness bound for this no-boundary-cancel policy is that supported automatic bolus sizes physically complete before the next 5-minute step under fresh connected pod status; communication loss, pod expiry, and no-active-pod paths shall report unavailable/unknown rather than active delivery and therefore leave the active-delivery skip path. If communication resumes after one or more missed steps and pump evidence matches the same request step, requested units within supported rounding tolerance, proven same pod identity, and delivered units within the credible range of 0...requested units (within tolerance), runtime shall replay the missed primary and secondary/safety algorithm steps before the live resumed step, inject the reconciled delivered amount only at the first missed step after the request step, use unavailable CGM input (CGM=-1) for synthetic missed steps, and issue no catch-up pump commands. If persisted matching evidence exists and the live due step is exactly the first eligible attribution step, runtime shall feed that evidence into the live step without creating synthetic replay rows. Pump status restoration after relaunch shall pass persisted matching issued-dose reconciliation evidence into the pump adapter; when such evidence exists for the current request step, the adapter shall defer to that evidence and shall not reconstruct a new lastDelivery from pod bolusNotDelivered counters. Persisted pump-last-delivery evidence may be restored as the adapter's last delivery, while assumed-delivered or otherwise non-pump evidence shall suppress reconstruction without being surfaced as pump-observed delivery. Exception (fresh-completion upgrade rule): when the current refresh is a fresh same-pod observation, with proven pod identity and settled (idle/suspended) delivery state, taken at or after the attributed dose's expected physical completion time, and the pod's bolusNotDelivered register reports zero insulin undelivered, the adapter shall reconstruct and surface the pump-observed completed delivery instead of deferring, so a non-final in-progress or assumed evidence figure cannot permanently freeze the displayed/recorded delivered amount below what the pod actually delivered; runtime shall likewise replace matching non-assumed issued-dose reconciliation evidence whose delivered figure is below the requested amount with a fresh same-pod settled post-completion pump observation reporting strictly more delivered insulin before that evidence is consumed. This upgrade shall never occur while the pod reports active delivery or unknown status, before the expected physical completion time (the post-accept early-read shape), for an unproven or different pod identity, or while the register reports a nonzero undelivered remainder; a canceled or interrupted bolus therefore retains its observed partial delivered amount — and a delivered figure shall never be raised on assumption alone. After an issued-dose request step has been consumed into replay or live algorithm input, runtime shall not feed that same request step to the live algorithm again in the same session, regardless of whether a later pump observation reports different requested or delivered units; any same-request-step unit mismatch shall be recorded as discrepancy evidence and telemetry rather than treated as fresh insulin delivery. If fallback-basal replay is also pending and reconnect recovery has a same-pod cumulative pump-delivered insulin delta that includes both the pending issued dose and fallback basal exposure, runtime shall first partition the known pending issued-dose requested amount from the pump total, persist that partition as issued-dose reconciliation evidence, use only the residual pump delta for fallback-basal credibility and replay allocation, and retain the raw pump total separately for telemetry/operator review. If the pump total cannot cover the pending issued dose, the pending dose cannot be matched to the same pod/request, or the residual does not credibly match modeled fallback exposure, runtime shall not guess the split, shall not store or display the raw pump total as actual fallback-basal delivery, and shall suppress replay under ambiguous/unresolved reconciliation. If fallback-basal replay is also pending, issued-dose replay shall be monotonic and non-duplicating with fallback replay. While the pod still reports active delivery or unknown status, or no post-request pump-status evaluation exists yet, runtime shall keep the attribution pending and skip live advancement. Once a fresh settled post-request pump status exists and the original pod has not been proven replaced, matching evidence that is unavailable, mismatched, non-credible (delivered units outside 0...requested), or missing pod identity shall resolve as assumed delivered per clinical policy: runtime shall record exactly the requested units as the assumed delivered amount, feed that amount into the first eligible attribution step (by replay or live-step input, under the replay rules above), retain the assumed-vs-confirmed distinction in UI and telemetry, and schedule meal-adaptation exclusion for meal-linked assumed doses so algorithm meal learning does not adapt on assumed evidence. Clinical rationale: under-crediting delivered insulin risks re-dosing insulin already given, so assuming the full requested amount is the conservative direction for insulin-on-board accounting while preserving dosing liveness; the SRS-MEAL-012 user-confirmed unavailable-pod escape is the explicit-operator variant of this same disposition. On relaunch or reconnect with a reachable pod, runtime shall not create assumed-delivered evidence from cached same-pod idle/suspended status, different-pod status, or unresolved-idle status until at least one fresh pump-status refresh has completed for that pod; known old-pod unavailable/no-active/service-stop escape paths retain existing liveness behavior. If a different/new pod is observed before reconciliation, runtime shall record different_or_new_pod, preserve the current algorithm session, assume the issued dose was delivered, feed the assumed delivered amount into the first eligible attribution step by replay or live-step input, clear the old-pod pending attribution after that consumption, scrub unrelated replacement-pod lastDelivery from the resumed live algorithm input, and shall not block later insulin-adding automatic commands solely because the original pod cannot be reconciled. For the SRS-MEAL-012 user-confirmed unavailable-pod escape, runtime may consume assumed-delivered clinical-policy evidence without pod identity only when request step, requested units, delivered-unit bounds, and non-active pump status match. Legacy persisted different_or_new_pod_unresolved holds shall be treated as nonblocking under this policy. Controlled clarification (v1.52; supersedes the broader fresh-completion exception sentence above): a zero bolusNotDelivered register after relaunch shall not by itself override persisted partial-delivery evidence. Runtime shall persist issued-dose observation context when known. A larger settled same-pod observation may replace a partial pump observation only when the persisted context explicitly identifies that partial as capped while delivery was still active. Persisted canceled partials and legacy partials without that positive in-progress provenance shall remain authoritative. Assumed-delivered evidence already records the full requested amount and may be accompanied by a matching fresh pump observation only without increasing the amount attributed to the algorithm. Controlled clarification (v1.65): if the physical bolus command path starts locally but returns a definitive blocked/not-issued outcome, runtime shall clear matching pending attribution and instruct the pump adapter to invalidate only the matching request-step/requested-unit cache. That rejected request shall not later be reconstructed from bolusNotDelivered as delivered insulin, displayed as delivered insulin, or fed into any algorithm step. Uncertain outcomes shall retain the cache and attribution for reconciliation.
• SRS-PUMP-011: Every pump command and status await shall be bounded by an app-level watchdog (120 seconds, well above the transport's bounded worst case) that fails the command as uncertain (or the status read as blocked) instead of stalling the serialized loop work pass; a late transport completion after the watchdog fires shall be ignored safely. The synchronous-completion contract of the pump-event storage delegate callback shall be regression-pinned.

Meal Announce

• SRS-MEAL-001: Meal announce shall only use borrow execution when request time is before the next scheduled slot and within borrow window (<= 2 future 5-minute slots).
• SRS-MEAL-002: Meal announce shall be blocked unless an active pod is present, pump status is known, and pump delivery state is confirmed idle. Unavailable-reason precedence shall report noPump when no active pod is present, reserve signalLoss for active-pod unknown-status conditions, report pumpDelivering when an active connected pod is currently delivering even if issued-dose or meal-delivery attribution is also pending, and report pumpSuspended when insulin delivery is suspended; only an idle unresolved attribution shall use reconciliation/reconnect guidance. A suspended rejection shall occur before accepted-meal persistence or either algorithm executes, shall issue no pump command, and shall not create a meal recommendation or delivered-dose chart entry. A fresh pump-confirmed transition from suspended to idle shall clear this availability block without requiring another algorithm step. Meal announce shall additionally be blocked while the primary algorithm is in forced-open-loop mode (openLoopMode == 2, backup basal running during a released CGM outage), because every pump command is blocked in that state and a meal bolus cannot deliver. The app shall also block before dispatch when the exact prospective meal step would exceed the characterized 12-step glucose-blind tolerance and therefore enter forced-open mode, even if the prior persisted algorithm output was still closed-loop. The app shall persist the algorithm step that consumed each qualifying CGM or fingerstick, use it for this prospective check, and repeat the check in the runtime coordinator after exact step selection but before persisting accepted meal state or executing either algorithm. A current fresh CGM input or a valid persisted 20...600 mg/dL manual BG targeted to that exact prospective step permits the combined step; a stale, future-step, invalid, or missing BG shall not bypass the block, and no glucose state shall bypass pump, pod, signal-loss, fallback-reconciliation, delivery, suspension, or request-in-progress gates. A prospective or established forced-open rejection shall map to backupBasalRunning, shall not create pending meal state or a delivery-progress state, and shall tell the user that the meal was not announced and no meal insulin was delivered. Availability shall clear automatically once a qualifying fingerstick or sensor reading permits closed-loop stepping.
• SRS-MEAL-003: Meal announce UI shall provide explicit unavailable reason and next retry time when applicable, including reconnect/recovery-required guidance when masked fallback may have become active.
• SRS-MEAL-004: If meal announce is requested after the next scheduled slot is already due/missed, runtime shall execute meal input on the current due step (expectedStep) instead of rejecting solely due to late borrow timing.
• SRS-MEAL-005: Meal announce shall be blocked until the loop establishes the first successful anchored step (firstSuccessfulStepAt), even when pump and CGM are otherwise available.
• SRS-MEAL-006: If the meal announce composer remains visible while runtime availability changes, the app shall revalidate meal availability on runtime events, foreground refresh, and immediately before submit; qualifying-glucose publication and live pump-status changes shall be revalidation triggers so stale inline guidance cannot remain after the condition changes. Unavailable state shall block dispatch and present current blocked messaging instead of using stale availability. During revalidation of an open composer, a stale observed step whose fresh availability check is available shall re-arm the composer in place (selections preserved, observed step updated, transient notice shown) rather than dismissing it; genuinely unavailable conditions shall render current blocked messaging inline within the composer with selections preserved, and shall clear automatically when a later revalidation reports availability. If the open composer was unlocked by a pending fingerstick BG during a released CGM outage (the SRS-MEAL-002 exact-step carve-out) and a loop step consumes that BG before submit, the app shall treat forced-open (backup-basal) availability as transient continuity while the pending BG is cleared but the exact captured step's qualifying-glucose marker has not yet published, even if an intermediate pre-command checkpoint already exposes that step as executed. The composer shall remain armed with selections preserved, shall present at most a passive waiting notice stating the fingerstick BG is being applied and the meal will go with the next dosing step, and shall not instruct the user to enter another fingerstick BG within the accepted BG's validity window (an accepted fingerstick restarts the full CGM-dropout tolerance window). Publication of that qualifying-glucose marker shall revalidate and resume the standard recovery flow without dismissing the composer; a live connected .delivering pump status shall instead promptly replace stale backup-basal guidance with pump-busy guidance. The same waiting hold shall apply to a backup-basal-blocked submit issued during the in-flight window. If forced-open availability persists after the qualifying marker has published, or a later executed step proves the captured target passed without qualification, the generic backup-basal messaging shall apply. Submit-time blocking behavior is otherwise unchanged: a blocked submit shall never dispatch.
• SRS-MEAL-007: Meal announce submit shall not be presented or logged as success until runtime/coordinator result is known. Executed success shall only be shown after runtime completion, and blocked/rejected outcomes shall produce explicit user-visible result messaging. Uncertain command outcomes shall produce explicit blocked guidance rather than optimistic success.
• SRS-MEAL-008: Once a meal announce request is accepted for execution, the app shall persist pending meal-request state across relaunch until the request is explicitly cleared, reconciled against executed step history, or reset by session reset/disarm. Persisted state shall include the concrete target step accepted by runtime and the correlated meal flow identifier needed for lifecycle telemetry closure.
• SRS-MEAL-009: While a persisted prior meal request remains pending, additional meal announces shall be blocked after relaunch and the user shall be informed that a meal request is already in progress. If the prior request has an uncertain command outcome, duplicate meal entry shall remain blocked until reconciliation or session reset/disarm, and the user shall be informed that the prior meal delivery outcome is uncertain.
• SRS-MEAL-010: If a competing trigger or slot conflict prevents meal execution on the originally observed slot, runtime shall not silently lose or reinterpret the meal request. The app shall block the submit with explicit slot-conflict/retry guidance rather than silently reassigning the meal to a different borrowed step.
• SRS-MEAL-011: If meal announce is requested while pump bolus delivery is already in progress, the app shall present a destructive cancel-delivery path on Home that can cancel the current bolus, report the actual insulin delivered before cancellation in Home's standard alert-summary region, and preserve that delivered amount for subsequent algorithm-step accounting when the operator later reopens meal announce.
• SRS-MEAL-012: If a meal-announcement delivery-progress modal remains unresolved because the original pod cannot be confirmed, the app shall provide an explicit user-confirmed pod-replacement escape only for the matching meal-linked issued-dose attribution. The escape shall become available when the original pod is known unavailable, past hard service-stop, known different/replaced, or when the expected physical completion time has elapsed by at least 2 minutes without matching evidence. On confirmation, runtime shall record assumed-delivered issued-dose evidence using the original requested units and pod identity when available, record an auditable user_abandoned_unavailable_pod disposition, clear only the meal-progress UI fields, preserve the issued-dose attribution for replay/live-step insulin accounting, and route the operator to pod setup. The escape shall not resolve correction-only or basal-only pending issued-dose attributions.

Team review note: - SRS-MEAL-004 is accepted for the current software baseline as the implemented late-submit meal behavior. - Meal tooLate retry messaging shall point to the immediate next due-step time boundary (not an added fixed 5-minute delay). - SRS-MEAL-007 through SRS-MEAL-012 are now implemented in the app baseline through runtime-result-gated meal success handling, blocked/rejected submit messaging, persisted pending meal-request state + flow correlation, uncertain-outcome duplicate blocking, relaunch reconciliation against executed-step/pump-delivery evidence, explicit slot-conflict blocking when another step advances after the meal flow was opened, a destructive cancel-delivery flow when meal entry is attempted during active bolus delivery, user-confirmed pod replacement for unconfirmed old-pod meal delivery, and correlated accepted/resolved lifecycle telemetry closure.

CGM-Outage Sustained Dosing (BG-Run)

Clinically approved 2026-07-13/14. The controlled behavior is specified by SRS-OUTAGE-001..006, allocated in the Software Design Description, assessed under RA-018, and verified by the mapped SVVP/RTM controls.

• SRS-OUTAGE-001: During a CGM outage the runtime shall maintain a persisted BG-due schedule anchored to the last qualifying glucose (an accepted CGM reading or an accepted fingerstick BG): next BG due = qualifying-glucose time + 120 minutes, or + 60 minutes when the measured value is >200 or <80 mg/dL. Each newer qualifying glucose re-anchors the schedule; the context shall persist across relaunch.
• SRS-OUTAGE-002: While a CGM outage is active the Home screen shall show the next fingerstick-due time (countdown line), including whether backup basal is running; the line clears on CGM recovery. A CGM outage is active for these surfaces when an executed step ran without an accepted CGM value AND any of: the algorithm reports its CGM-dropout offline mode (openLoopMode == 2), the step was fed an accepted fingerstick BG, or the persisted schedule's last qualifying glucose was a fingerstick (BG-run in progress). An isolated blind step with the dropout clock intact (e.g., a relaunch or wake step firing ahead of a healthy sensor's next reading) is not an outage and shall not show the countdown.
• SRS-OUTAGE-003: Outage alerting shall be tiered: an actionable "BG due soon" tier pre-scheduled as an OS notification at 15 minutes before the due time; an informational "backup basal running" note while the bridge is released; and a safety-critical "BG overdue" tier pre-scheduled at the due time. The due-soon and overdue tiers shall visibly emphasize the separate Home BG-entry control, shall fire even when no loop step executes near the deadline, and shall be replaced on re-anchor and cleared on CGM recovery or session end.
• SRS-OUTAGE-004: Backup-basal bridge: on a connected forced-open executed step with the 0 U/hr mask armed, the runtime shall actively cancel the mask (the pod's programmed fallback basal resumes immediately) and record the released-for-outage state; mask renewals shall be suppressed while released; on the next non-forced-open executed step the mask shall be re-established BEFORE that step's pump command. A failed cancel keeps the mask (existing forced-open alerting covers the participant) and retries on subsequent forced-open steps; a failed re-arm blocks that step's insulin-adding command (never dose on top of running fallback basal) and retries.
• SRS-OUTAGE-005: There shall be no automatic maximum-outage stop: dosing is sustained indefinitely by qualifying BGs (sponsor/clinical decision 2026-07-13/14; deliberate divergence from the iLet 48/72-hour cutoffs, rationale recorded in RA-018).
• SRS-OUTAGE-006: Fallback basal delivered while the bridge is released shall be accounted for in the algorithm's insulin accounting using the mechanism characterized against the real Algo2015; no new reconciliation evidence class is introduced. Connected released steps shall be credited live, one synthetic per-step pump tuple per executed step: the tuple echoes the algorithm's actual previous ask (retiring the blocked mode-2 ask) and reports the identity-guarded pod-counter delta as delivered at its actual tick timing (no schedule smoothing); per-step credits accumulate in runtime state for the window. A pod-away gap within a released window (one or more due steps not executed - skipped for unavailable pump status or never attempted while the phone was dark - followed by a pump status carrying pod totals whose pod identity matches the preserved baseline) shall NOT be credited as a single reconnect-step tuple: it shall be reconciled by the standard bounded fallback replay (sponsor direction 2026-07-18, field incident) - the authoritative total is the identity-guarded pod-counter delta against the preserved baseline, distributed across the missed steps at per-step weights from the persisted programmed fallback schedule over each missed step's real slot (weights evaluated in the engaged event's recorded profile timezone, device zone fallback, matching the classic replay path), with per-row shares allocated as whole multiples of the algorithm's 0.01 U insulin-ledger resolution by schedule-weighted largest-remainder allocation - zero-share rows permitted - so the algorithm's booked row total equals the measured delta exactly (the C++ books each row's delivered at 0.01 U resolution; fractional shares would inflate its ledger), replayed as CGM=-1 rows under the SRS-RUN-006 echo-ask convention with the first row echoing the persisted pre-gap ask; a zero-delta gap shall still replay (zero-delivery echo rows retract the window's offline asks); replay rows shall not issue pump commands, and the released mode shall persist through the replay. The synthesized plan shall carry its credit context - the measured delta, the re-anchor counter and pod identity, and the first-row echo ask - in persistent state, and consuming the plan shall apply that context regardless of which work pass executes the replay, so an app termination at any intermediate persistence point between synthesis and consumption neither loses nor double-counts the delta. After the replay, the pod baseline shall re-anchor to the reconnect counter, the measured delta shall accumulate exactly once, and the resumed live step's credit tuple shall therefore compute a zero delta (no double count). An identity mismatch at reconnect shall not replay: the live tuple retracts the persisted ask with zero credit and the baseline re-anchors to the observed pod. At mask re-arm, the release window shall be quantified on the engaged fallback event record - window duration plus the modeled exposure integrated over the pod's programmed fallback schedule - upgraded to a pump-measured confirmed total when per-step credits were accumulated, and labeled resumed_without_reconciliation (modeled only) when no credit observation landed.

State Persistence and Recovery

• SRS-STATE-001: The app shall persist algorithm state and runtime cadence state across relaunch.
• SRS-STATE-002: Same-Participant Reset (formerly Reset Algo) shall clear persisted algorithm state, persisted cadence state, and step timeline/session history to start a fresh session.
• SRS-STATE-003: Pump and CGM manager state shall persist across relaunch to avoid forced re-pairing.
• SRS-STATE-004: When masked fallback is armed, runtime persistence shall retain the original programmed basal schedule, the currently programmed fallback schedule/rate, safety target, last known pod identity, last known pod total-delivery baseline/timestamp, last mask-renewal / schedule-refresh timestamps and outcomes, any restore-pending, restore-failed, or reconciliation-required recovery context needed for safe connected maintenance and later disarm/restore, and any pending pump-delta reconciliation state needed for reconnect recovery after offline mask expiry, confirmed/corrected missed-step algorithm replay, or explicit ambiguous unreconciled resume. Runtime persistence shall also retain separate primary and secondary/safety q5 nominal-basal profiles, with local-time slot observations, so fallback schedule generation is traceable to the safety-track nominal basal values rather than the primary dosing track. Runtime persistence shall retain pending issued-dose attribution, the most recent consumed issued-dose delivery, the most recent issued-dose delivery discrepancy, and the most recent issued-dose reconciliation failure disposition needed to avoid guessing or double-feeding delivered insulin across relaunch or pod replacement; stale consumed/discrepancy/failure records shall have a defined expiry path. Meal-linked pending issued-dose attribution shall retain the algorithm-visible request step when available so assumed-delivered meal-learning exclusion can be matched to the algorithm's time base rather than a drifted runtime label.
• SRS-STATE-005: Algorithm start, stop, reset, and replacement algorithm-session creation shall occur only in response to an explicit operator action. Runtime recovery, pump reconnect, pod replacement, CGM recovery, fallback reconciliation failure, app launch, app foreground, scheduler wake, telemetry replay, or cloud/auth state shall not independently stop the algorithm, start the algorithm, reset the active algorithm session, or create a replacement session. Recovery logic may block command application, suppress replay, mark missed steps as unreconciled, and continue the existing session at the current cadence slot.

Algorithm Verification Controls

• SRS-ALG-001: The Algo2015 implementation and bridge path shall maintain a deterministic golden-vector regression suite with fixed inputs and expected outputs under version control.
• SRS-ALG-002: Algo2015 verification shall include structural coverage reporting for C bridge and C++ algorithm sources, with predefined coverage targets and documented rationale for uncovered regions.
• SRS-ALG-003: Bridge contract behavior for null inputs, state reset edge conditions, sentinel mappings, and subject-id boundary handling shall be explicitly verified.
• SRS-ALG-004: Algorithm state continuity shall be verified across multi-step execution, persistence/reload, and reset-to-fresh session boundaries.
• SRS-ALG-005: Any change to pregnancy configuration inputs (target, meal upfront, TMAX) shall include differential algorithm-output evidence against baseline replay vectors.
• SRS-ALG-006: Formal Algo2015 verification runs shall include a static-analysis lane for algorithm/bridge sources with logged findings status and run linkage metadata.
• SRS-ALG-007: MISRA assessment for the host-side investigational Algo2015 lane shall be risk-based and conditional: each formal run shall include either linked MISRA evidence with signed deviation handling (if applicable) or an explicit not-applicable decision rationale with compensating controls.
• SRS-ALG-008: The runtime shall host the primary dosing track and the secondary/safety track on isolated algorithm instances such that neither track's execution can read or advance the other's algorithm state (buffers, counters, adaptation history, or persisted state). Instance isolation shall be regression-verified, including the primary track's CGM-dropout tolerance measured in its own executed steps.
• SRS-ALG-009: For every insulin-adding algorithm step, the host pump recommendation shall equal the sum of Algo2015 bolusInsulinRequested, basalInsulinRequested, and mealInsulinRequested. The persisted issued-dose request and later pump-feedback unitsRequested shall use that same total so a completed delivery can satisfy the Algo2015 delivered-insulin reconciliation gate without omitting or double-counting any component.

Telemetry and Traceability

• SRS-LOG-001: For each executed step, telemetry shall include an explicit step execution timestamp (step_executed_at), algorithm input snapshot, output snapshot, and pump command result. The app shall retain a complete protected, backup-excluded step archive for the active algorithm session and use that archive for the clinical-gated CSV export; the Recent Dose Steps presentation cache may remain bounded to the newest 576 rows. Explicit algorithm-session reset shall clear the active-session archive. Local Recent Dose Steps review shall identify an executed step whose algorithm input included a valid manual/fingerstick BG value, show the exact fingerstick value used, and retain any concurrent CGM value rather than replacing it. Algorithm output telemetry shall retain Algo2015's read-only delivered-insulin echo fields (bolusInsulinDelivered, basalInsulinDelivered, mealInsulinDelivered, and deliveryTime) and cloud loop-step telemetry shall flag delivery-echo divergence when matching reconciled pump input differs beyond pump mechanical resolution. When a pump observation disagrees with already-consumed issued-dose delivery for the same request step, telemetry shall record the consumed-vs-observed discrepancy fields while suppressing the observation from algorithm insulin input. If an assumed-delivered meal-learning exclusion expires without algorithm acknowledgement after the analysis window, step telemetry shall include dashboard-visible disposal evidence and shall not require a participant-facing alert.
• SRS-LOG-002: Telemetry storage shall support export with stable column definitions.
• SRS-LOG-003: Telemetry persistence shall not perform CSV or recovery-ZIP generation, file copying, or compression synchronously on the main actor; export work shall use staged asynchronous processing so the participant UI remains responsive.
• SRS-LOG-004: The default cloud-log upload threshold shall be Error with inclusive evaluation (selected level and higher severities). Upload level is raised only by a server-issued remote logging config (SRS-LOG-011); no in-app logging control is exposed in any build (the former debug-build threshold and integration-session controls were removed 2026-07-16, and the build-designated profile was superseded the same day - study logging is configured server-side only).
• SRS-LOG-005: Clinical settings save flow shall emit ui.critical telemetry for state_viewed, submit, cancel, and blocked outcomes with stable screen_id/element_id values and old/new field details for changed clinical parameters.
• SRS-LOG-006: app.lifecycle.launched and app.lifecycle.foregrounded telemetry payloads shall include timezone and clock-check context fields: device_timezone_id, device_utc_offset_seconds, clock_check_result, and when available clock_check_skew_seconds, clock_check_rtt_ms, clock_check_at_utc.
• SRS-LOG-007: Meal-announce telemetry shall expose a correlated request lifecycle so cloud reconstruction does not rely on optimistic submit success alone. Implemented baseline includes submitted, accepted, success, blocked, uncertain, and resolved transitions keyed by meal flow_id, with replay state persisted until emission so accepted and resolved are not lost across terminate/relaunch windows; resolved is emitted for immediate completion, relaunch/pump-evidence reconciliation after uncertainty, or session-reset clear. Loop command telemetry shall preserve command outcome semantics, including uncertain delivery, rather than collapsing all non-success outcomes into generic blocked state.
• SRS-LOG-008: Target-selection telemetry shall capture clinician-controlled regular-settings target profile changes and participant target-change approval-capture events with stable ui.critical event identifiers and required detail fields (target_range_profile, requested/applied target, approval metadata, and blocked/cancelled reasons where applicable).
• SRS-LOG-009: Masked fallback review telemetry shall capture fallback arm, maintenance deferred, mask renewal, schedule-refresh unchanged checks, schedule refresh, offline mask expiry, and restore success/failure with selected fallback rate, source, safety target, duration, reconciliation status, pod-continuity result, and failure detail sufficient for Home Recent Dose Steps review. Resolved reconnect-recovery events shall also retain modeled fallback delivery and, when available from proven same-pod continuity, pump-reported delivered insulin since the last connected fallback baseline. Per-step local review telemetry shall also retain the executed primary and secondary algorithm step summaries needed to display each track's step count, suggested dose, nominal basal, and instant basal in Recent Dose Steps. When confirmed/corrected same-session fallback delivery reconciliation occurs, local review/export shall include only fallback-active missed-step primary/secondary algorithm replay rows allocated from the credible same-pod pump-reported delivered-insulin delta using the persisted programmed fallback schedule as the weighting model; each replay step shall use unavailable CGM input (-1), that step's delivered-insulin allocation including explicit 0 U input when no pump allocation belongs to that fallback-active step, and no pump command application. Pre-activation disconnected missed steps shall remain absent from replay telemetry rather than appearing as synthetic 0 U rows. The resumed live step shall use actual refreshed pump status and shall not receive a duplicate aggregate recovered-delivery input. Cloud telemetry shall additionally emit a dedicated loop.fallback.event family with a stable fallback_event_id, lifecycle kind, structured delivery/reconciliation summary fields including pod_continuity, and explicit occurrence timestamps so BionicScout can render fallback-related events separately from ordinary loop-step telemetry and distinguish modeled fallback delivery, pump-reported delivered insulin, and reconciled delivery when available. Fallback arm and schedule-refresh cloud events shall include the programmed four-entry schedule, safety q5 profile source/kind metadata, observed/imputed slot counts, per-six-hour-segment observed-slot counts (four counts, each out of that segment's 72 five-minute slots), profile timezone metadata, and the 288 q5 profile rates used for that specific schedule-programming operation. The steady-cadence schedule_checked_unchanged maintenance event shall carry the same programmed four-entry schedule and profile coverage metadata (source/kind, observed/imputed slot counts, per-segment observed-slot counts, timezone metadata, and the profile last-updated timestamp) while omitting only the bulk 288-rate array, so the active fallback schedule and its provenance remain visible in recent telemetry and in Recent Dose Steps even when a stable profile produces no arm/refresh event for days (sponsor request 2026-07-20); routine mask renewals shall continue to carry no schedule/profile payload. Recent Dose Steps fallback schedule rows (arm, schedule refresh, and unchanged check) shall show the four programmed segment rates, a plain outcome label distinguishing armed/updated/unchanged, and per-segment provenance that marks a segment as imputed when fewer than half of its 72 slots are observed.
• SRS-LOG-010: Superseded 2026-07-16 (sponsor direction), never shipped to a study participant. The build-designated cloud-log profile (Info.plist-baked level/end-date/label establishing an on-phone integration logging session) is removed: the server-issued logging config (SRS-LOG-011) is the sole study logging lever, and the app reads no session or profile state (storage left by pre-removal builds is ignored). Requirement text retained in revision 1.34 history for traceability; ID retired, never repurposed.
• SRS-LOG-011: The app shall fetch the server-issued logging config (GET /v1/config/logging, authenticated) at launch, on each foreground, and periodically (nominal 30-minute interval) while running, all outside UI-test mode, and apply it as a remote upload-level override carrying the server-supplied expiry. The server-issued config is the sole study logging lever: no build-baked profile or on-phone logging session exists, and the upload threshold is the active override's level, else the default (SRS-LOG-004). A null or expired server config shall clear any stored override; a malformed response shall leave the stored override untouched; fetch or auth failures shall never block or alter app behavior (the last-applied override keeps applying until its own expiry). When a fetch changes the stored override, the app shall log a threshold-exempt cloud marker (remote_logging_config_applied with the config level/expiry/reason, or remote_logging_config_cleared); unchanged re-fetches log nothing. The config is issued only from the BionicScout admin surface (dashboard scope + clinician/admin group). Settings shall present the effective logging state (level, expiry, and whether it comes from the study team or the default) as read-only status text with no controls.
• SRS-LOG-012: Every uploaded telemetry envelope shall carry a durable monotonic sequence_no assigned by the persistence ledger at enqueue (the uploaded bytes and durable row shall be structurally unable to disagree), plus install_id and session_id. Events posted outside the ledger (e.g. dropped-events markers) shall reserve a durable sequence number so a failed send is server-detectable as a gap. Sequence numbers enable BionicScout to prove per-install delivery completeness; events from earlier builds without sequence_no are evaluated on a steps-only basis and shall not register as gaps. The protected, backup-excluded SQLite outbox shall transactionally and repeatably migrate any existing file-spool backlog during an update, including a later fallback spool created after a transient ledger-open failure, and delete source data only after committed import. Retained clinical/runtime entries shall not be evicted by an arbitrary count cap. Telemetry emission shall return after durable local commit and schedule network drain independently; a newer immediate drain shall not cancel an older event's scheduled retry. Recovery shall deliver retained evidence before bounded debug/log chatter while preserving sequence numbers and per-class FIFO order. Chatter evicted at its class cap shall be counted without immediate per-event network work and summarized in one aggregate dropped-events marker after transport progress resumes. The client may upload up to 50 unchanged persisted envelopes and 512 KiB through an additive batch route with per-event acknowledgement; unsupported batch routes shall return every selected row to pending and fall back to the existing single-event route without loss or duplicate clinical effect. New Participant Reset shall physically recreate the outbox database and remove its WAL/shared-memory sidecars before participant-scoped reset completion, while preserving only install-scoped monotonic sequence metadata. Repeated notification clear requests shall emit lifecycle telemetry only for a persisted scheduled-to-cleared transition. Settings shall provide passive, non-alerting visibility of pending and permanently rejected study-data records without changing dosing or reset policy. A permanent client-side telemetry rejection (HTTP 4xx other than rate limiting) shall remain in the protected local outbox as failed-permanent evidence carrying the event type, sequence number, failure timestamp, HTTP status, and error detail, and shall remain visible to BionicScout as a sequence gap. The app shall not surface a generic participant-facing alert for that non-actionable transport condition; a subject-identity conflict shall retain its specific actionable alert without also producing a generic upload alert, and HTTP 429 shall remain retryable. A one-time launch migration shall clear any orphaned generic telemetry-rejection notification from an earlier build, and loading persisted alerts shall always remove an earlier-build generic telemetry-rejection alert and its scheduled notification.
• SRS-LOG-013: Temporary Target telemetry shall emit durable lifecycle events for activation, first algorithm use, replacement, early end, expiry, session stop, profile change, and same-participant/session reset with a stable override identifier, subject, temporary/permanent/safety targets, duration, absolute start/end timestamps, and first-applied step when applicable. New Participant Reset is the intentional exception: it shall erase the outgoing participant identity, Temporary Target state, and pending lifecycle records without emitting a new outgoing-participant lifecycle event. Every loop-step telemetry payload shall expose the permanent target, target source, temporary-target identifier/expiry, whether the override was actually applied to that step, and the safety target. BionicScout shall project the lifecycle and applied-step evidence into an operator-visible state that distinguishes an active target awaiting first use from one observed in algorithm use, preserves terminal state against delayed/out-of-order events, and does not change telemetry wire-field types.
• SRS-LOG-014: G7 replacement acquisition shall emit stable, deduplicated telemetry for ten-minute acquisition stall and successful sensor adoption. Evidence shall include the acquisition event, trigger, previous sensor identity when available, new sensor identity on adoption, and event time. Successful durable enqueue shall be marked in persisted acquisition state so repeated manager sync or relaunch cannot reserve an additional wire sequence for the same event; failed enqueue shall remain retryable. Until BionicScout accepts dedicated sensor-acquisition event types, the app shall carry these payloads through the accepted cgm.state.changed family without changing wire-field types.
• SRS-LOG-015: The clinical-unlock-gated share action in Recent Dose Steps shall produce one recovery ZIP containing the complete retained step-telemetry CSV and byte-faithful copies of the applicable legacy Algo2015 run artifacts, without modifying their writer or lifecycle. Timestamped BP_<epoch>.txt and BP_LOG_<epoch>.txt files shall be grouped by session epoch; the fixed-name BP_ReadMatrix.m shall join only the epoch it references. When the active algorithm inspection epoch is known, only that exact group may join the CSV; if the exact group is unavailable, export shall remain CSV-only rather than attach another run. When no inspection epoch is available after relaunch, the newest valid grouped epoch may join the CSV. Export shall copy every included source only through a protected, backup-excluded temporary snapshot before creating the ZIP and shall never archive a live path directly. The CSV is required; any subset of the three algorithm files may accompany it. An unavailable CSV shall expose no share item and shall never produce an empty archive. The archive name shall include a sanitized subject-or-device identifier and export timestamp. Collection, copy, and archive generation shall execute off the main actor, sharing shall use the existing system ShareLink, and temporary export data shall be removed when the Recent Dose Steps view closes.

UI Safety and Status

• SRS-UI-001: Home loop-status card shall use deterministic state precedence: No Session > No Pod > No CGM > Ready > age-based states, where age-based states are derived from cadence due-time (firstSuccessfulStepAt + (lastExecutedStep + 1) * 300s) rather than raw lastSuccessfulRunAt.
• SRS-UI-002: Home availability and status messaging shall align with runtime behavior (no false available state for blocked actions). While the pump reports suspended delivery, Home shall display Insulin delivery is paused. independently of the reminder interval. The Home Manual BG and Meal Announcement primary actions shall remain visible and actionable in a bottom safe-area control surface while Home status, alert, and chart content scrolls; persistent placement shall not bypass or change either action's existing availability policy.
• SRS-UI-003: Initial CGM and Pod startup/setup modals shall provide an explicit Cancel action that dismisses the modal without forcing entry into settings.
• SRS-UI-004: If the meal announcement composer is visible and the app transitions to background, the composer shall auto-dismiss/cancel so meal intent does not persist across lifecycle interruption.
• SRS-UI-005: If the latest CGM reading is older than 11 minutes, or if the latest CGM reading is present but not reliable (hasReliableGlucose == false), CGM display surfaces shall mask the reading as -- and shall not display a trend arrow.
• SRS-UI-006: The app shall perform UTC drift checks on launch, on timezone/significant-time-change events, and on foreground when the last successful check is older than 24 hours. If absolute clock skew exceeds 600 seconds, the app shall present a non-blocking actionable warning no more than once per 24 hours; unavailable UTC checks shall not show warning spam.
• SRS-UI-007: CGM display surfaces shall render boundary readings as textual values LOW (<=39 mg/dL) and HIGH (>=401 mg/dL) instead of numeric mg/dL values.
• SRS-UI-008: Home CGM chart y-axis scaling shall use bounded stepped maxima (300, 350, 400 mg/dL) based on displayed data peak. Glucose samples shall render as discrete, value-colored points at their recorded timestamps without a connector line or interpolated area fill; chart/scrub rendering shall keep boundary-value interpretation consistent with SRS-UI-007.
• SRS-UI-009: The Home investigational badge text shall be server-configurable (GET /v1/config/banner, fetched on the shared SRS-LOG-011 cadence: launch, foreground, 30-minute periodic): an absent config shows the built-in default NOT FOR HUMAN USE (fail-safe - a fetch failure or unset config can never remove the investigational label), a configured string shows verbatim (<= 60 characters, issued only from the BionicScout admin surface), and an explicitly blank configured string renders no badge at all (no empty capsule). The BionicScout dashboard chrome mirrors the same three-state behavior.

Clinical Settings and Pregnancy Configuration

• SRS-CLIN-001: The app shall provide a dedicated Clinical Settings area for clinician-only configuration and control actions.
• SRS-CLIN-002: After a usable subject clinical configuration has been saved, entry to Clinical Settings and every subsequent clinical-setting edit shall be gated by a subject-scoped offline clinical unlock verifier. The only exception is initial configuration while no usable subject configuration exists, as defined by SRS-CLIN-013; that exception shall close immediately after the first successful save. The app shall provide a secure local material-installation path for provisioned verifier material; installation shall validate the subject/material match, persist verifier material in local secure storage, preserve the last locally accepted counter across material refresh, clear any active unlock expiration on material refresh, and reset local failed-attempt/lockout state. After verifier material is provisioned into local secure storage, code verification shall not require internet access. The verifier shall normalize grouped ASCII numeric code input, search only counters greater than the last locally accepted counter through the provisioned offline lookahead limit, compute the HMAC code using the provisioned current/supported secret version, persist the matched counter before opening clinician controls, set a local unlock expiration timestamp for the provisioned unlock duration, and reject malformed codes, non-ASCII digits, same/lower counters, wrong-subject codes, counters beyond lookahead, and unsupported secret versions. Manual lock shall persist unlock expiration clearing; if that persistence fails, the app shall keep clinician controls visibly unlocked and show a storage-failure message rather than falsely presenting a locked state. The app shall provide an operator-facing provisioning entry (visible while clinician controls are locked) that accepts the subject ID and the BionicScout-issued one-time provisioning code (30-byte payload, Crockford base32 with format version, subject binding check, and checksum), decodes it offline, and installs the resulting verifier material through the same validated installation path; decoding shall reject malformed/truncated codes, checksum failures, unsupported format versions, and subject mismatches. Installed verifier material shall contain only the per-subject derived device secret; the issuing master secret shall never be provisioned to or stored on the device. The app shall additionally support fetching the provisioning code over the authenticated BionicScout session (subject-device token; the backend releases material only for the subject claimed by that account) and shall validate and install the fetched code through the same decode/installation path as typed input, including rejecting responses whose subject does not match the requested subject. Production master secrets shall not be hardcoded in app source.
• SRS-CLIN-003: Subject ID, Weight, Start Algo, and Same-Participant Reset (formerly Reset Algo) controls shall be hosted in Clinical Settings and not exposed in non-clinician settings sections.
• SRS-CLIN-004: Target selection shall support 90, 100, 110, 120, and 130 mg/dL only.
• SRS-CLIN-005: Meal upfront percentage selection shall support exactly 75% and 90%.
• SRS-CLIN-006: TMAX selection shall support 40...70 minutes inclusive, in increments of 5.
• SRS-CLIN-007: Clinical settings values shall be persisted with versioned defaults/migration so runtime behavior is deterministic across relaunch and app update.
• SRS-CLIN-008: Relocating Start Algo and Reset Algo (since relabeled Same-Participant Reset) into Clinical Settings shall not change their runtime behavior semantics.
• SRS-CLIN-009: Clinical Settings shall provide a clinician-controlled target-access profile for participant-facing settings with exactly two values: Pregnancy and Standard.
• SRS-CLIN-010: Participant-facing settings and the clinician target selector shall expose only the target options enabled by the current target-access profile: Pregnancy -> 90, 100, 110 mg/dL; Standard -> 110, 120, 130 mg/dL.
• SRS-CLIN-011: Participant target changes in regular settings shall require approval capture before apply. The app shall block the change unless the operator records the approving clinical staff member name and an approximate approval time.
• SRS-CLIN-012: If the clinician changes the target-access profile in Clinical Settings (outside first-launch setup) while the draft target is outside the newly selected profile subset, the app shall normalize the draft target to the nearest allowed value before save rather than preserving an out-of-profile target. During first-launch setup, a mode switch instead applies that mode's default target per SRS-CLIN-013.
• SRS-CLIN-013: First-launch clinical defaults shall be the Standard target-access profile with a 120 mg/dL regular target, 75% meal upfront, and 40-minute TMAX (clinical direction 2026-07-14; study insulin Fiasp). Defaults shall apply only to new setups and shall never rewrite previously persisted participant values. Loading an empty configuration store shall return the first-launch defaults WITHOUT persisting them, so the first-launch setup gate stays open until an operator saves. While no usable subject configuration exists, study staff shall be able to review and save the initial clinical configuration without a clinical unlock code; the successful first save shall close that exception, after which SRS-CLIN-002 governs all Clinical Settings access and edits. In first-launch setup, switching the mode shall select that mode's default target (Standard -> 120, Pregnancy -> 110 mg/dL), and the review summary shall include the selected mode.
• SRS-CLIN-014: Clinical Settings shall provide a New Participant Reset, distinct from the same-participant algorithm reset, that erases all participant-scoped data on the device - clinical configuration, algorithm and runtime state, Temporary Target state including pending lifecycle records, local step telemetry and its CSV export, the cloud telemetry outbox, alert history, stored pump and CGM manager state, the subject-scoped clinical-unlock material including burned counters, and onboarding completion/claim - and signs the account out, returning the app to first-launch setup. The reset shall invalidate device-state persistence callbacks and matching in-flight device telemetry before erasing stored manager state so an asynchronous completion cannot recreate prior-participant state after the wipe. The reset shall be refused while a pod is active and shall require explicit destructive confirmation; when an algorithm session is armed, the control shall offer to stop the session first and then proceed to the reset confirmation. Before the erase confirmation, the app shall attempt a final telemetry upload flush and, when undelivered records remain, the confirmation shall state their count and that resetting discards them permanently - the reset itself remains allowed (sites must be able to reset a broken phone). On confirmation, new telemetry transport shall be gated, any ordinary prior-participant transport already in flight shall be allowed a bounded interval to quiesce, and the reset shall fail closed without wiping participant state if transport cannot quiesce or outbox erasure cannot be persisted. The live algorithm-session and active-Pod guards shall be rechecked after asynchronous work, and algorithm arming shall be unavailable while reset owns the transaction. A reset that proceeds with undelivered records shall first erase the outbox durably while preserving the install's telemetry sequence continuity, then initiate a nonblocking best-effort telemetry.outbox.discarded marker carrying pending and rejected counts; a failed marker remains server-detectable as a reserved sequence gap (SRS-LOG-012). Resets blocked by their initial armed-session or active-Pod guard shall discard nothing.
• SRS-CLIN-015: Weight entry shall support 50...500 lbs inclusive; a configuration whose weight is outside this clinically confirmed range shall not be usable for arming. The configuration store shall clamp persisted weight to at most 500 lbs and shall never raise a lower entry (an unset 0 remains unset so first-launch setup stays gated; a sub-plausible positive value remains visible but unusable). As a last rail, the dosing algorithm layer shall clamp the weight it consumes to 20...230 kg, where the low clamp reduces dose scale (safe direction) and the high clamp bounds runaway dose scale.
• SRS-CLIN-016: The participant-facing Exercise and Insulin Delivery settings area shall appear above the User section and provide a Pregnancy-only Temporary Target with explicit, non-preselected target choice (120 or 130 mg/dL) and duration choice (30, 60, 90, or 120 minutes). Target and duration controls shall use the app's standard outlined selected-state treatment. If either choice has been made and the participant attempts to leave before successful review and activation, the app shall warn that the selections will be lost and require explicit confirmation before discarding them. Activation shall require an armed algorithm session, an active Pod, and no pending masked-fallback recovery; it shall issue no immediate Pod command and shall become effective only when a valid algorithm step executes. The override shall be subject-bound, persisted with an absolute expiration timestamp, restored across relaunch, shown with its end time on Home and Settings, replaceable deterministically, and endable early. The first algorithm step at or after expiration shall use the permanent target regardless of notification delivery. Only the primary-controller target shall use the override at each row's actual execution time, including historical replay rows; the safety controller, permanent target, q5 fallback profile, and programmed backup-basal schedule shall remain derived from the permanent Pregnancy configuration. Profile change away from Pregnancy and explicit session stop/reset shall clear the active override without automatically starting, stopping, resetting, or re-anchoring an algorithm session; New Participant Reset shall remove all Temporary Target state. The same combined screen shall directly expose the existing Pod Suspend Insulin Delivery / Resume Insulin Delivery command while normal Pod Settings shall omit that duplicate control; unrelated participant-reset guidance shall not be shown on this screen. Suspension shall retain the existing 30, 60, 90, or 120 minute reminder choices; the selected duration shall not automatically resume insulin, and delivery shall remain suspended until the participant explicitly resumes it. The action shall be disabled when no active usable Pod exists or while the Pod is changing suspension state. When a suspension reminder ends, the active alert shall offer a direct Resume Insulin action that uses the existing Pod resume command, prevents duplicate in-flight commands, remains retryable after failure, and stays active until the pump alert lifecycle confirms recovery. If insulin remains suspended for 15 minutes after that reminder, the alert shall escalate to safety-critical severity and issue a fresh background notification without automatically resuming insulin. Suspend-notification taps shall continue to route to Settings > Exercise and Insulin Delivery.
• SRS-CLIN-017: An explicit Clinical Settings draft transition from Standard to Pregnancy shall initialize meal upfront to 90%, while retaining 75% as a selectable value before save. Opening settings, canceling without save, relaunching, or loading an existing Pregnancy configuration shall not silently rewrite the persisted meal-upfront value.
• SRS-VAL-001: Weight entry shall be pounds on UI, integer-only, stored as kilograms for runtime/algorithm use; in current UX scope this entry is clinician-gated.

Team review notes: - SRS-CLIN-002 is accepted for the current software baseline as an investigational single-device clinical unlock control. Broader production authorization/role-based access remains outside this IDE baseline unless explicitly pulled into scope. - The Pregnancy configuration control set is defined by SRS-CLIN-001..017 and its allocations in the SDD, Risk Analysis, SVVP, and RTM. - Implemented baseline now includes a clinician-controlled participant target-access profile (Pregnancy / Standard), participant target-change approval capture in regular settings, and a clinician target selector that is constrained to the currently selected profile subset.

User Alerts and Escalation

• SRS-ALERT-001: The app shall normalize alerts from pump (OmniBLE), CGM (G7SensorKit), algorithm/runtime, and app safety policies into a single alert domain model.
• SRS-ALERT-002: Each alert shall include source, severity, timestamp, user-facing message, and recommended action metadata.
• SRS-ALERT-003: Alert presentation shall apply severity-based channels and deterministic precedence so critical alerts are never hidden by lower-severity alerts.
• SRS-ALERT-004: The app shall apply a 5-minute display and alert debounce to transient pump signal-loss and no-active-Pod indications. This presentation debounce shall not delay or alter pump-command, connection-safety, or dosing gates.
• SRS-ALERT-005: Alert life-cycle behavior shall define clear/acknowledge rules per alert type (auto-clear vs explicit acknowledge). Internal reconciliation evidence such as expired meal-learning exclusion disposal shall be routed to telemetry/dashboard review rather than participant-facing active alerts unless a separate safety condition requires user action.
• SRS-ALERT-006: Protocol-required alert conditions and response wording shall match the controlled alert inventory and SDD-POL-008, and each claimed condition shall map to an executed verification identifier in the RTM.
• SRS-ALERT-007: For high-priority non-CGM alerts (actionable/safetyCritical), the app shall issue background local notifications with de-duplication and per-severity cooldown to avoid alert spam.
• SRS-ALERT-008: The app shall provide an in-app Alert Center showing both active alerts and recently cleared alerts.
• SRS-ALERT-009: Pump and CGM alert issue/retract lifecycle state shall persist across app relaunch, including lookup of unretracted alerts and restoration of active alert visibility.
• SRS-ALERT-010: Alerts with time-sensitive countdown wording shall refresh displayed remaining time at least once per minute while active so user-facing timing remains current.
• SRS-ALERT-011: Home shall present active alerts as a severity-prioritized stack (severity first, then condition-specific precedence, then recency) that always shows the highest-priority alert, indicates multiplicity explicitly, and provides an expansion affordance revealing all remaining Home-visible alerts in place. Within the same severity, active ALERT-PUMP-SIGNAL-LOSS shall appear above ALERT-ALGORITHM-CHECK-BG-REQUESTED so a disconnected Pod is not masked by a newer fingerstick prompt; any safety-critical alert shall still outrank both. Generic alerts whose root cause is already named by a specific active alert (per the sponsor-approved suppression matrix in SDD-POL-008) may be hidden from the Home surface only; safety-critical alerts shall never be suppressed, and Alert Center shall always show the complete active list. When suppression hides one or more active alerts, the Home stack shall indicate how many related alerts are hidden and shall provide a direct affordance to open Alert Center, so the Home surface and the alert-count badge never silently disagree.
• SRS-ALERT-012: Safety-critical pump alerts (ALERT-PUMP-FAULT, ALERT-PUMP-INCOMPATIBLE) shall not auto-clear solely due to hasActivePod == false; they shall clear only on explicit lifecycle retraction/recovery or explicit acknowledge workflow.
• SRS-ALERT-013: When armed-loop execution has no successful algorithm step for more than 15 minutes, the app shall issue an actionable interruption alert distinct from G7 unavailable/failed/expired alerts and clear it once successful step execution resumes or the loop is disarmed.
• SRS-ALERT-014: The interruption alert shall use broader Algorithm Stepping Interrupted semantics, triggered when the armed loop has not achieved a successful algorithm step for more than 15 minutes, regardless of whether the immediate blocker is missing CGM, missing pod, pump signal loss, suspension, fallback-delivery recovery, or another runtime execution gate. Blocker-specific participant copy shall be derived from the latest unresolved runtime outcome or authoritative current pump condition; a broad CGM lifecycle/status alert alone shall not be treated as proof that CGM caused the missed step. Current suspension shall outrank fallback-recovery detail, fallback recovery shall outrank stale persisted CGM or pump-status detail, and a successful live step shall invalidate the persisted interruption blocker and clear the active interruption alert. After a pump-status-unavailable attempt, a pump-status refresh may replace the stale unavailable guidance only when it proves an active Pod has a newer idle status; the same alert shall then state that Pod communication is restored and automated dosing is waiting for the next glucose update. This status-only alert transition shall not trigger algorithm execution or a pump command. Stale, unknown, delivering, suspended, or no-active-Pod status shall not claim recovery, and a later unknown status shall restore unavailable guidance.
• SRS-ALERT-015: BionicLoop CGM availability/failure alerts shall be in-app informational status only on Home / Alert Center, shall not require explicit acknowledge, and shall not schedule background local notifications. The FDA-cleared Dexcom application shall be treated as the source of truth for CGM alarming and shall be configured accordingly in study use.
• SRS-ALERT-016: When a trustworthy G7 reading is <55 mg/dL, the app shall issue an in-app-only urgent-low review alert on Home / Alert Center, shall allow clinician acknowledge/review capture, shall not schedule background local notifications, and shall auto-clear the active alert state on a later trustworthy G7 reading >=55 mg/dL. This alert shall be app-derived from CGM data and shall not claim Dexcom-app acknowledgement.
• SRS-ALERT-017: Any no-active-pod condition shall raise a safety-critical pump alert after a 5-minute debounce and shall repeat background local notification attempts at least every 30 minutes while the no-active-pod condition remains true, until active pod state is restored or explicit alert-lifecycle recovery clears the alert.
• SRS-ALERT-018: When Algo2015 output checkBG is active, the app shall surface a deduped actionable fingerstick BG prompt with foreground haptic feedback and visible emphasis on the Home BG entry control. The prompt shall clear on manual BG entry or a later algorithm output where checkBG is inactive, shall not re-alert while the same active request persists across successive steps, and shall not be restored as stale active alert state after app relaunch.
• SRS-ALERT-019: When Algo2015 primary or safety algorithm output openLoopMode equals LOOP_MODE_FORCED_OPEN, the runtime shall record the algorithm step and telemetry, preserve pre-command fallback-basal maintenance, suppress that step's automated pump command, and keep the session and cadence intact: forced-open is the algorithm's self-clearing CGM-dropout indicator, not a session-fatal condition (sponsor decision 2026-07-08, consistent with SRS-RUN-007). The app shall surface a deduped auto-clearing informational note for the condition; the note shall escalate to safety-critical advisory wording only when the condition persists for at least 3 consecutive executed steps. Escalated wording shall instruct entering a fingerstick BG to resume automated dosing plus sensor-check and study-team contact guidance, and shall never demand an algorithm-session reset or claim insulin delivery that is not occurring. The alert shall remain active across skipped/no-telemetry publications and shall clear only after a later algorithm output reports forced-open inactive. While the backup-basal bridge is released (SRS-OUTAGE-004), this note is superseded by the outage alert set (SRS-OUTAGE-003) and retracted.
• SRS-ALERT-020: When an explicit or device-lifecycle-triggered G7 replacement acquisition remains unresolved for 10 minutes, the app shall surface a deduplicated, actionable, auto-clearing in-app alert directing the participant to finish starting the sensor in the Dexcom app and retry from Settings. The condition shall clear on successful adoption or replacement-acquisition termination, shall survive relaunch through persisted acquisition state, and shall not schedule a BionicLoop background CGM notification because the Dexcom app remains the CGM alarm source under SRS-ALERT-015.

Alert evolution notes: - Current implemented baseline is ALERT-ALGORITHM-STEPPING-INTERRUPTED. - The alert triggers on absent successful step execution rather than CGM-specific receipt loss alone. - Algorithm Stepping Interrupted preserves root-cause visibility so stronger underlying pump alerts remain available and prioritized while CGM state remains visible as separate informational context.

Alert source inventory and normalized mapping baseline: - Alert Inventory and Mapping

Security and Privacy

• SRS-SEC-001: Telemetry architecture shall support secure cloud upload, with delivery provable per SRS-LOG-012, as a supportive monitoring and corroboration function; local dosing shall not depend on cloud availability. The BionicLoop exported CSV shall be the official insulin-delivery outcome source, and the clinical-gated exact-session recovery ZIP shall be the primary software session-reconstruction record for its covered interval. Local CSV and legacy Algo2015 source and staging artifacts shall use the specified complete or complete-until-first-unlock protection, shall be excluded from backups, shall not be exposed through OS file sharing (UIFileSharingEnabled and LSSupportsOpeningDocumentsInPlace shall remain absent), and shall be accessible solely through clinical-gated in-app share flows. No software baseline shall permit ungated local file access.
• SRS-SEC-002: The telemetry spool shall use complete-until-first-user-authentication file protection and backup exclusion. App-enumerated Algo2015 diagnostic artifacts shall receive the same protection and backup exclusion without blocking algorithm execution if attribute application fails. CSV and recovery-ZIP staging shall use complete file protection, shall remain unavailable outside the clinical-gated in-app share flow, and shall be removed after sharing or cancellation.
• SRS-SEC-003: Protected cloud API access is deferred from the current software package. If cloud-backed protected APIs are included in a future accepted baseline, they shall require authenticated user identity managed by Cognito before access is granted.
• SRS-SEC-004: Multi-provider onboarding policy is deferred from the current software package. If included in a future accepted baseline, onboarding shall define the allowed Sign in with Apple, Google, and Email paths explicitly.
• SRS-SEC-005: Cloud authorization-role enforcement is deferred from the current software package. If included in a future accepted baseline, authorization shall enforce least-privilege role and scope checks for telemetry and dashboard access.
• SRS-SEC-006: Protected-cloud authentication failure handling is deferred from the current software package. If included in a future accepted baseline, authentication and session failures shall fail closed for protected cloud operations while preserving safe local app behavior.
• SRS-SEC-007: Cognito password-recovery workflow is deferred from the current software package. If included in a future accepted baseline, email/password onboarding shall provide reset-code request and confirmation with explicit success/failure feedback.
• SRS-SEC-008: Launch session-restore behavior is deferred from the current software package. If included in a future accepted baseline, authenticated persisted sessions shall attempt secure restore/refresh without unnecessary manual re-login when restore succeeds.
• SRS-SEC-009: Auth-failure Home-bypass continuity behavior is deferred from the current software package. If included in a future accepted baseline, the app shall support explicit local Home bypass when unauthenticated local loop state remains active. While that bypass is active, Home shall keep a persistent top-level Log In control independent of alert ordering; the login-required Home alert, Alert Center, Account & Session, and login-required notification shall provide direct login routes; and entering login shall not stop or reset the local algorithm session.

Team review notes: - SRS-SEC-003..009 are deferred from the current software package and require explicit scope re-entry before closure is claimed. - Existing development implementation may cover portions of SRS-SEC-007..009, but that implementation is not being claimed as closed scope in this package. - Clinical, engineering, and administrative cloud roles and token-lifecycle controls are outside the accepted local-software scope and require explicit scope re-entry before they are claimed.

Traceability Source Mapping

Controlled traceability sources:

• this Software Requirements Specification;
• the Software Design Description;
• the Risk Analysis;
• the Software Verification and Validation Plan;
• the Requirements Traceability Matrix; and
• the controlled clinical-document consistency crosswalk in the IDE software packet.