BioFlow Requirements
System Requirements
SYS-001
change in progress 1. First-launch readiness for local enrolment UID: SYS-001 TYPE: functional STATUS: Approved RELATIONS (Child): STATEMENT:

When the device is opened on a workstation that has no pre-existing BioFlow data directory, a default local clinic shall be present and immediately available for the clinician to attach newly-enrolled patient records, without requiring the clinician to first create or configure a clinic record manually.

 RATIONALE:

Stakeholder commitment: clinicians installing the device on a fresh workstation expect to enrol their first patient within minutes of starting the application, without learning a separate clinic-management workflow as a prerequisite. Auto-provisioning a default local clinic removes that friction.

 REVIEWED_HASH:

1c8a5a84aebeb1b05f0044436dce6685870daaaade275946cde09b1b935e7fc5

 REVIEWED_BY:

@DougYoungberg
  • SRS-001
    change in progress 1. First-launch database initialisation UID: SRS-001 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    On first launch, when no database file exists at the configured application data path, the software shall create the local database, apply the current schema version, and create a default local clinic record that serves as the container for locally-created patient records.

     RATIONALE:

    Refines SYS-001: the software-level mechanism that realises the device's first-launch readiness commitment. Establishes the minimum persistent state required for any subsequent clinical operation — without it, patient records cannot be stored and recording sessions cannot be attached to a patient.

     REVIEWED_HASH:

    98b05f66e64fdd504ec9ab458d051d1bf7ac6ef1cc6703c83eec0bbfcfa52d83

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-001 on clean install — fresh workstation, first launch, verify the local clinic is visible in the Patients menu.
  • ST-001
    change in progressSkipped 1. Local clinic visible in Patients menu UID: ST-001 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

    With the application launched on a workstation that has no pre-existing BioFlow data directory, navigate to the Patients menu and open the clinics dropdown. The local clinic entry shall be visible in the dropdown.

     ACCEPTANCE_CRITERIA:

    Preconditions: application is launched on a clean workstation (no prior data directory); the main screen is visible. Steps: navigate to the Patients menu; open the clinics dropdown. Verification: a VisionTrace AI agent.verify(...) call confirms the local clinic is visible in the dropdown. No error dialog appears during launch or navigation.

     REVIEWED_HASH:

    1abfb93d30805f56ec9159fab5db3477d395bc27c4bc8ac0c6b4aac3b6164005

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    Launching the application on a clean workstation is a test precondition handled by the VisionTrace app_session fixture, not a step in the test body. Test code lives in this repo at visiontrace_tests/bioflow/st001/, decorated with @visiontrace_test_case("ST-001"). The agent.verify(...) call takes a screenshot of the current UI and asks an AI model to confirm the described condition — for this test, that the local clinic is present in the dropdown. Running this test in CI requires VisionTrace to be installed in the CI environment and a Windows runner with a usable desktop session. Multi-link verifies SYS-001 (operator can enrol on first launch) and SRS-001 (software creates default clinic); both close via this same end-to-end observation.
SYS-002
change in progress 2. Confidentiality of patient data at rest UID: SYS-002 TYPE: regulatory STATUS: Approved RELATIONS (Child): STATEMENT:

The device shall keep clinic, patient, clinical-user, recording, and audit-log data stored on the local workstation confidential against any party gaining access to the workstation's filesystem without the operator's BioFlow credentials.

 RATIONALE:

BioFlow workstations are deployed in clinical environments where multiple staff and IT roles share physical access, and the local data store carries identifiable patient records. HIPAA Security Rule §164.312(a)(2)(iv) (encryption of ePHI at rest) and GDPR Art. 32(1)(a) (encryption as appropriate technical safeguard) require that filesystem-level access does not yield readable PHI on its own.

 STANDARD_REF:

45 CFR §164.312(a)(2)(iv); GDPR Art. 32(1)(a)

 REVIEWED_HASH:

940ecc884b9e74e53cf0626b9253a7be885b903762de73e2a7b847831533eebb

 REVIEWED_BY:

@DougYoungberg
  • SRS-002
    change in progress 2. Local database confidentiality at rest UID: SRS-002 TYPE: security STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall keep the local database file unreadable to any process that opens it without supplying the database credential, and shall reject database read and write operations when the credential is missing or incorrect.

     RATIONALE:

    Refines SYS-002. A workstation that is lost, stolen, imaged, or backed up off-site shall not yield PHI from the local database file alone. Tying readability to a credential held outside the database file ensures offline copies of the file cannot be opened independently of the BioFlow application's credential pathway.

     STANDARD_REF:

    NIST SP 800-111; IEC 81001-5-1 §5.5

     THREAT_REF:

    PHI exfiltration from a lost, stolen, or imaged Windows host

     REVIEWED_HASH:

    bbce0aa8a344b16781b9aa4fd86855e614b296b31d614039b4a2221e7e5bda23

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-002 attempts to read the on-disk file without a credential and confirms the read does not yield plaintext records, then opens it through the application's pathway and confirms the records are readable.
SYS-003
change in progress 3. Integrity of patient data at rest UID: SYS-003 TYPE: regulatory STATUS: Approved RELATIONS (Child): STATEMENT:

The device shall preserve the integrity of clinic, patient, recording, and audit-log data stored on the local workstation against accidental alteration, partial writes, referential inconsistency, and concurrent-write corruption — such that any record returned by the device represents a complete and consistent state authored through the application.

 RATIONALE:

BioFlow's local data store is the authoritative source for clinic and patient records on a given workstation; clinical decisions and uploads to the cloud are made against it. A record silently corrupted by a partial write after a crash, by a dangling foreign-key reference, or by a schema-violating row would mis-attribute a recording, mis-identify a patient, or strand orphan rows that mask deletion intent. HIPAA Security Rule §164.312(c)(1) (integrity) and GDPR Art. 5(1)(f) (integrity and confidentiality, including accidental loss, destruction or damage) both require the device to protect ePHI against improper alteration or destruction; the standards explicitly include accidental corruption, not only adversarial tampering. SYS-003 is the device- level commitment that the local store does not silently drift out of internal consistency.

 STANDARD_REF:

45 CFR §164.312(c)(1); GDPR Art. 5(1)(f); GDPR Art. 32(1)(b)

 REVIEWED_HASH:

2c29cc4c8c670d6d9fa809e35fac9e1425ad652f765332fccf15573952b5eb69

 REVIEWED_BY:

@DougYoungberg
  • SRS-003
    change in progress 3. Local database integrity enforcement UID: SRS-003 TYPE: data STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall enforce referential integrity between clinic, patient, and recording records through database foreign-key constraints; shall wrap any multi-row or cross-table mutation in a single transaction such that a crash or process termination during the mutation leaves the database in either the pre-mutation state or the post-mutation state and never a partial state; and shall reject — rather than silently truncate or drop — any write that would violate a NOT NULL, FOREIGN KEY, or CHECK constraint declared in the schema.

     RATIONALE:

    Refines SYS-003. Three independent failure modes can corrupt the local store: (1) concurrent or crashing writes that complete only part of a multi-row update; (2) referential drift where a child row outlives its parent or never had one; (3) constraint-violating inserts that older code paths or migrations may attempt. Each is addressed by a specific software mechanism — schema-declared constraints applied by the persistence layer, transactional wrappers around use-case writes, and the underlying database engine's constraint enforcement — and each is observable through a failed write or a post-condition query. The requirement names the three mechanisms together so that removing any one of them (for example, disabling foreign-key enforcement for a performance change) is a visible regression against SRS-003 rather than a silent loosening of guarantees relied on by the rest of the application.

     STANDARD_REF:

    45 CFR §164.312(c)(1); GDPR Art. 5(1)(f)

     REVIEWED_HASH:

    0de558744d983b3d37d5f67856e20552eba80bae3e3f3fb4a235b12bbb886ee3

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-003 exercises each rejection category named in this requirement against the production encrypted-connection pathway: (a) FK violation — attempt to insert a patient with a non-existent clinic_id; (b) transactional atomicity — perform two writes inside a transaction, throw, and assert no partial state remains visible on re-open; (c) CHECK violation — attempt to insert a clinics row with an out-of-set origin value; (d) NOT NULL violation — issue a raw SQL INSERT (bypassing the typed API which guards NOT NULL at compile time) that supplies NULL for a non-nullable column. Test file location: test/integration/database_integrity_integration_test.dart.
SYS-004
change in progress 4. Audit trail of clinical record operations UID: SYS-004 TYPE: functional STATUS: Approved RELATIONS (Child): STATEMENT:

The device shall maintain an audit trail that independently records every operation that creates, modifies, or deletes a clinical record on the local workstation, and every action that exports such a record to an external system. Each entry shall capture the action, the affected record, and a system-generated UTC timestamp. Audit entries shall not be modified in a way that obscures previously recorded information after they are written.

 RATIONALE:

An audit trail of clinical-record operations is a stakeholder-level commitment of the device. It supports the clinical organisation's internal review duties (knowing what happened to which clinical record, and when) and the integrity of the local clinical data store (so that accidental or unauthorised modifications can be reconstructed and investigated after the fact). The record-modification clause is included because an entry whose content can be silently overwritten after the fact ceases to be a useful record of what happened.

 REVIEWED_HASH:

f4ff59b59ede96ba3085b89a1e864d2debc3215cb3b0042298a5801c5207b53a

 REVIEWED_BY:

@DougYoungberg
  • SRS-004
    change in progress 4. Audit logging of clinical record operations UID: SRS-004 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall write one audit-log entry for each of the following operations on local clinical records: creation, modification, and deletion of a patient; start, stop, and deletion of a recording; and successful upload of a recording to the cloud. Each entry shall carry the action, the identifier of the affected record, and a system-generated UTC timestamp. After an entry is written, the software shall not modify it in a way that obscures previously recorded information, and shall not delete audit entries.

     RATIONALE:

    Refines SYS-004. The list of audited operations corresponds to the operator-initiated mutations and exports of patient or recording data that the application currently exposes. Clinic and clinical-user mutations are not in scope because the application does not permit those operations on the local workstation — clinics are read-only mirrors of an external cloud directory the device is configured to sync with; clinical users are authenticated rather than created in-app. The required content per entry (action, target, time) is the minimum that lets an audit reviewer reconstruct what happened: which clinical record was affected, what action was performed, and when. The immutability clause expresses the underlying invariant that an audit entry must remain a faithful record of the operation it describes; an application-layer path that overwrites the details of a prior entry would functionally be a record change that obscures original information, and is therefore prohibited.

     REVIEWED_HASH:

    8670efd17561286bd5396fe9d81ff480539400a00719b06c3f4619af3242feb4

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-004 exercises the audit chain end-to-end by invoking each of the audited operations through the application's use-case pathway (or the corresponding production caller when no use case exists) and asserting that the audit-log entry is written with the correct action, target identifier, and system-generated timestamp. IT-005 verifies the data-shape and immutability commitments — entries have the required fields and an existing entry's content cannot be changed after write.
  • SRS-005
    change in progress 5. Audit-trail review and export UID: SRS-005 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall present the local audit trail to an authorised operator in a form that lists each entry's action, affected record, and system timestamp, ordered by time. The software shall additionally provide a means to export the current audit trail to a file in a portable, human-readable format that preserves the same fields as the on-screen presentation, so that the exported file can be examined off the device by an auditor or by the clinical organisation's own information-security review.

     RATIONALE:

    Refines SYS-004. Capturing audit entries in the local database is necessary but not sufficient: the entries live inside the encrypted application database, which an internal reviewer or external auditor is not expected to access directly. The device therefore surfaces the trail to an authorised operator inside the application and provides an exportable copy that can be examined off the device. Without a viewer-and-export surface, the audit trail is opaque to the clinical organisation's own review duties — the entries exist but cannot be examined without direct access to the encrypted database file. The "human-readable" wording is deliberate: a binary or schema-coupled export defeats the off-device review use case, which is conducted by people reading entries on a workstation other than the device. The "ordered by time" presentation rule keeps the on-screen view faithful to the chronology of operations; the export preserves the same fields so that the exported copy is a copy of the on-screen trail rather than a transformation of it.

     REVIEWED_HASH:

    3da5c78892fc7f563c2fd96cb6b7e93ad305672d437b12b2a59dd039044ad207

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-006 verifies the export round-trip — written audit entries appear in the exported file with the same fields and content. ST-002 (planned, to be authored once the viewer surface ships) verifies an operator can locate the audit trail in the application, see the expected entries, and invoke the export from the workstation.
SYS-005
reviewed 5. Operator workstation for recording sessions UID: SYS-005 TYPE: functional STATUS: Approved RELATIONS (Child): STATEMENT:

The device shall present the operator a workstation interface for conducting EEG recording sessions in which the live EEG signal display remains continuously visible while the operator accesses recording controls and overlay menus.

 RATIONALE:

Stakeholder commitment: clinicians conduct EEG recording sessions while continuously monitoring the live signal. The operator interface must keep the signal display visible while the operator works with recording controls and menus, so that adjusting settings or navigating the interface never interrupts observation of the patient's EEG.

 REVIEWED_HASH:

36b7b9d007b3a35a6c4ae57ee8de812b64b42e0aee6f8fd3c1b193ece1339aa8

 REVIEWED_BY:

@DougYoungberg
  • SRS-006
    reviewed 6. Maximized main window on launch UID: SRS-006 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    On application launch, the software shall display the main application window in a maximized state.

     RATIONALE:

    Refines SYS-005. Maximising the main window on launch gives the EEG signal display the full available screen area from the start of a session, so the operator can monitor the live signal without first resizing the window manually.

     REVIEWED_HASH:

    dc7ca8a24c6e21afa7a978cbb02263cfeab63085a843e6e7432c25b610be934a

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST item (planned) — verify the main application window is maximized immediately after launch.
  • SRS-007
    reviewed 7. Always-visible recording control widget UID: SRS-007 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall display a recording control widget anchored to the top of the main window, and shall keep that widget visible in all interaction states, including signal-control mode, menu mode, and while any overlay is open.

     RATIONALE:

    Refines SYS-005. The recording controls govern the active session — its start, its stop, and its running status. Keeping the widget visible in every interaction state ensures the operator can always see and reach the recording controls without first dismissing a menu or overlay.

     REVIEWED_HASH:

    bccb9886c2528cb600bccee06daef365798ce97ad2887816160909f6270bd10f

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST item (planned) — verify the recording control widget remains visible in signal-control mode, menu mode, and while an overlay is open.
  • SRS-008
    reviewed 8. Bottom-bar signal and menu mode toggle UID: SRS-008 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall provide a bottom bar that switches between a signal-control mode and a menu mode when the operator activates the bottom-bar mode toggle.

     RATIONALE:

    Refines SYS-005. A single bottom bar that switches between signal-control functions and menu functions keeps both sets of controls reachable from one fixed location, without permanently consuming screen area that would otherwise reduce the live signal display.

     REVIEWED_HASH:

    a2bd1b9f841162a89db68d43b7a5e544d65872f6e094573158396d0f6e6f4943

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST item (planned) — verify activating the bottom-bar toggle switches the bar between signal-control mode and menu mode.
  • SRS-009
    reviewed 9. Dismiss overlay on ESC or click-outside UID: SRS-009 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall dismiss the active navigation overlay when the operator either presses the ESC key or clicks outside the overlay's content area.

     RATIONALE:

    Refines SYS-005. Navigation overlays float above the live EEG signal; providing the conventional dismissal gestures — ESC and click-away — lets the operator return to the unobstructed signal view quickly. An overlay with in-progress edits is guarded against accidental dismissal (see ARCH-010), so the dismissal applies to overlays that permit it.

     REVIEWED_HASH:

    b262c063b65c057df8f8d5f2d6aaaa0541cee3f7eb9887b695ffdbca7577e649

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-007 opens a navigation overlay and verifies it is dismissed both by pressing ESC and by clicking outside the overlay content.
  • SRS-010
    reviewed 10. At most one overlay open at a time UID: SRS-010 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall display at most one navigation overlay at a time; opening an overlay shall replace any overlay that is currently open.

     RATIONALE:

    Refines SYS-005. Limiting the interface to a single open overlay keeps the operator's focus clear and preserves the maximum visible area of the underlying signal display. The constraint is realised structurally by a single selected-overlay index rather than a navigation stack (see ARCH-010), so a second overlay cannot be layered over the first.

     REVIEWED_HASH:

    8b339f513a68052b72a0dab34f0ebc46b778848c38b8552a70abe5c96c660985

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-008 opens one overlay, then opens a second, and verifies only the second is shown.
  • SRS-011
    reviewed 11. Signal-mode bottom-bar controls UID: SRS-011 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    In signal mode, the bottom bar shall present the signal-parameter controls: a high-pass filter, a low-pass filter, a notch filter, a sensitivity control, a timebase control, and a montage selector.

     RATIONALE:

    Refines SYS-005. These are the per-recording signal adjustments the operator reaches without leaving the signal view; presenting them on the bottom bar in signal mode keeps them one interaction away while the live signal remains visible.

     REVIEWED_HASH:

    87a993af0ca2801932f9df334a3860d5e9de62d699450987430e7dd994b65a07

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-011 asserts the six controls render in signal mode; ST-006 confirms the signal-parameter controls are shown at the operator-facing tier.
  • SRS-012
    reviewed 12. Menu-mode bottom-bar navigation buttons UID: SRS-012 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    In menu mode, the bottom bar shall present the navigation buttons: Patients, Montages, Settings, and Activities.

     RATIONALE:

    Refines SYS-005. Menu mode replaces the signal-parameter controls with the four primary navigation destinations, each of which opens its overlay, so the operator reaches patients, montages, settings, and activities from the same fixed bar.

     REVIEWED_HASH:

    68a5f126aba7210ab6bfdf3c3998fa61d7efa723f3b4cd42215e59a1f7fd2099

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-011 asserts the four navigation buttons render in menu mode; ST-006 confirms the four items are shown at the operator-facing tier.
  • SRS-013
    reviewed 13. Recorded-duration readout format UID: SRS-013 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    While a recording session is active, the software shall display the recorded duration in HH:MM:SS format.

     RATIONALE:

    Refines SYS-005. A recorded-duration readout in a fixed HH:MM:SS format lets the operator see how much signal has been captured so far while keeping the live signal in view.

     REVIEWED_HASH:

    44a71204c417957885ee30f52c99c5b19e8e51c0e3da1d1cda7243ae850f84c6

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: UT-001 verifies the duration-to-HH:MM:SS formatting at the unit tier; ST-009 observes the readout shown in HH:MM:SS format in the running application during an active recording.
  • SRS-014
    reviewed 14. Patient name in recording widget UID: SRS-014 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    While a patient is selected, the software shall display the selected patient's name in the recording control widget.

     RATIONALE:

    Refines SYS-005. Showing the selected patient's name in the always-visible recording widget lets the operator confirm at a glance which patient the session is being recorded for while keeping the live signal in view.

     REVIEWED_HASH:

    3e52266db5d5faf9cfd839c7b4b8808bea0f43f535ef0af241b4cb0e72ffe88f

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-010 observes the selected patient's name shown in the recording widget in the running application; IT-008 confirms the widget renders the patient name from seeded state.
  • SRS-015
    reviewed 15. Bottom bar default and resting mode UID: SRS-015 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The bottom bar shall be in signal mode when the application launches, and shall return to signal mode whenever the open navigation overlay is dismissed.

     RATIONALE:

    Refines SYS-005. Signal mode is the operator's working view, so the bottom bar opens there and falls back to it once a navigation overlay is closed, keeping the signal-parameter controls available by default.

     REVIEWED_HASH:

    9c6b9513d6834a87fc4441c8cea891e78a3add74b32609de21884fb0a816ea9e

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-009 asserts signal mode at launch and IT-010 asserts the return to signal mode after the overlay is dismissed; ST-011 observes the launch-to-menu-to-signal cycle at the operator-facing tier.
  • SRS-016
    reviewed 16. Minimum main window size UID: SRS-016 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall prevent the main application window from being resized smaller than 1024 by 768 pixels.

     RATIONALE:

    Refines SYS-005. 1024 by 768 is the minimum size at which the operator workstation remains usable; preventing the window from shrinking below it keeps the live signal display and recording controls legible on lower-resolution laptops.

     REVIEWED_HASH:

    4200fb2d0be3aee20b1455b9e0faba8eab18e82f2097544c2a0921230dd51767

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-012 (planned) resizes the window below the minimum and asserts the reported window bounds are clamped to at least 1024 by 768 at the operator-facing tier. No flutter_test integration test is feasible — the minimum is enforced natively by the window_manager package, not in a widget tree.
  • SRS-017
    reviewed 17. Selectable application themes UID: SRS-017 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall provide three selectable visual themes — Light, Dark, and Dark Glass — and shall apply the operator's selected theme across the application.

     RATIONALE:

    Refines SYS-005. Offering Light, Dark, and Dark Glass themes lets the operator pick the appearance that suits the room's lighting and their preference, while the selection applies consistently across the workstation.

     REVIEWED_HASH:

    5e1badbc2e307e77ef9e1d06d69e677c0706f21a32b6a1d144b64768213b4160

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-013 observes the three themes offered and a theme change taking effect in the running application; IT-012 verifies that each theme type drives its application theme at the integration tier.
  • SRS-018
    inactive 18. Live signal display frame rate UID: SRS-018 TYPE: performance STATUS: Draft RELATIONS (Parent): STATEMENT:

    The software shall render the live EEG signal display at a sustained rate of at least 60 frames per second.

     RATIONALE:

    Refines SYS-005. A high, steady frame rate keeps the live signal readable without perceptible stutter during a recording session.

     REVIEWED_HASH:

    d6a0927e9b4a133f3ce35546a3661e34bc5f317ae66ba6df63ec5749b1393146

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    Pending: deferred per product decision (not required for now). Activating it needs a frame-timing measurement harness to verify the on-screen refresh rate, which does not yet exist. Revisit when that tooling is available.
  • SRS-019
    inactive 19. Multi-monitor window position restore UID: SRS-019 TYPE: ui STATUS: Draft RELATIONS (Parent): STATEMENT:

    The software shall remember the main window's position and restore it on the next launch, including when the window was placed on a secondary monitor.

     RATIONALE:

    Refines SYS-005. Restoring the window where the operator last placed it, across a multi-monitor workstation, avoids re-positioning the interface at the start of every session.

     REVIEWED_HASH:

    3cabfa2067b9f2552e762aa3cde45becd92844962e52f522e0c302304e7a402b

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    Pending: deferred per product decision (not required for now). Verification needs a multi-monitor test environment; the current CI/VisionTrace rig has a single virtual display. Revisit when that environment is available.
  • SRS-020
    inactive 20. Display-scaling layout integrity UID: SRS-020 TYPE: ui STATUS: Draft RELATIONS (Parent): STATEMENT:

    The software shall present the main interface without clipped or overlapping controls under Windows display-scaling settings of 100%, 125%, 150%, and 200%.

     RATIONALE:

    Refines SYS-005. Clinicians run BioFlow on laptops set to various display scales; the interface shall stay legible and fully laid out at each.

     REVIEWED_HASH:

    64012965b01b94657d7d12839d019de4def916e9e0282d8e6ac706380021a6bd

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    Pending: deferred per product decision (not required for now). End-to-end verification needs the ability to launch the app under different OS display- scaling levels, which is not set up. Revisit when that environment is available.