How we build it,
how we test it.
Glucose Republic is being built on a common spine with the regulated medical-device version that will follow. The product ships today as a wellness companion. The documentation behind it is being kept in sync with the codebase, so the transition into a cleared device is a maturation rather than a re-architecture.
Three frameworks, all in scope.
IEC 62304 — Software Lifecycle
Software classification under IEC 62304 (medical-device software lifecycle) is under active analysis. GR:eat is currently treated as a Class B candidate — software whose failure or unsafe operation could lead to non-serious injury — and the development process is being aligned to the standard's lifecycle requirements (planning, requirements analysis, architectural design, integration testing, release).
ISO 14971 — Risk Management
A formal hazard analysis and software risk control matrix per ISO 14971 is in scope for 2026. The current Design History File catalogues known gap areas — safety gating before prediction display, audit logging, consent evidence model, cybersecurity hardening — as inputs to the risk file. None are stable yet; all are tracked.
FDA Human Factors Engineering
Use-related risk analysis and a formative-then-summative human-factors plan per the FDA's Applying Human Factors and Usability Engineering to Medical Devices guidance (Feb 2016) is in scope. Critical tasks are being identified from the requirements set; validation testing protocol is in draft.
The Design History File is alive.
The DHF is generated from and maintained alongside the code. Requirements have code anchors. Code has traceability rows. Tests have requirement references. Everything is version- controlled, reviewable, and current.
- Open
Software Requirements Specification (excerpts)
Reverse-engineered from the as-built code; covers 63 requirements (54 functional + 9 nonfunctional) with code anchors. 70% currently linked to verification. - Open
Architecture description
Component, sequence and data-flow diagrams covering Flutter client, Python backend, Firebase persistence, and Terra-mediated CGM ingestion. - Open
Interface and data-flow specification
All external integrations (HealthKit, Health Connect, Terra, Spoonacular-proxy, ML backend) with their data categories and security posture. - On request
Verification evidence baseline
Per-requirement test mapping and current pass/fail summary. Shared with partners and prospective acquirers under NDA. - On request
Medical-device gap analysis
An honest, code-grounded summary of the gap between the as-built product and a regulatory submission target. Workstream-by-workstream.
Reviewing the company? We will share the full evidence package under NDA.