Skip to content

Software Requirements Specification (SRS)

Status: Draft v0.1
Owner: BionicLoop engineering
Scope: Closed-loop investigational runtime, device integration, and safety-critical UI behavior

Requirement Format

Each requirement uses a stable ID and a testable shall statement.

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.
  • SRS-RUN-003: The runtime shall execute loop work only on configured wake causes (current policy: new CGM reading timestamp).

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.

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 minimum practical delivery 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.

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 pump status is known and pump is not delivering.
  • SRS-MEAL-003: Meal announce UI shall provide explicit unavailable reason and next retry time when applicable.
  • 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.

Team review note: - SRS-MEAL-004 requires explicit clinical/team confirmation before lock for release behavior. - Meal tooLate retry messaging shall point to the immediate next due-step time boundary (not an added fixed 5-minute delay).

State Persistence and Recovery

  • SRS-STATE-001: The app shall persist algorithm state and runtime cadence state across relaunch.
  • SRS-STATE-002: 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.

Telemetry and Traceability

  • SRS-LOG-001: For each executed step, telemetry shall include algorithm input snapshot, output snapshot, and pump command result.
  • SRS-LOG-002: Telemetry storage shall support export with stable column definitions.
  • SRS-LOG-003: Telemetry persistence shall not block UI responsiveness (no heavy synchronous file generation on main actor).

UI Safety and Status

  • SRS-UI-001: Home loop-status card shall use deterministic state precedence: No Session > No Pod > No CGM > Armed > age-based states.
  • SRS-UI-002: Home availability and status messaging shall align with runtime behavior (no false available state for blocked actions).
  • 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-VAL-001: Weight entry shall be pounds on UI, integer-only, stored as kilograms for runtime/algorithm use.

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 debounce or coalesce transient reconnect/noise events to reduce false-alarm UX while preserving true fault visibility.
  • SRS-ALERT-005: Alert life-cycle behavior shall define clear/acknowledge rules per alert type (auto-clear vs explicit acknowledge).
  • SRS-ALERT-006: Protocol-required alert conditions and response wording shall be represented in app behavior and traceable to verification evidence.

Security and Privacy

  • SRS-SEC-001: Long-term telemetry architecture shall support secure cloud upload as primary transport, with local CSV as temporary/debug-only path.
  • SRS-SEC-002: Telemetry export and storage paths shall be controlled to minimize PHI/PII exposure.

Traceability Source Mapping

Primary upstream references:

  • Docs/Requirements/Requirements.md
  • Docs/Requirements/RiskAnalysis.md
  • Docs/Analysis/Marjorie_AlgorithmIO_GapAnalysis.md
  • Docs/Architecture/Architecture.md