INBOTransparent by design.
The parts that can be deterministic are deterministic. AI is bounded to the jobs where estimation is appropriate — and it is never the dose engine.
Bounded AI.
AI assists with tasks where a good estimate is genuinely useful: identifying food, estimating carbohydrates from a photo, interpreting a menu, and bounded narrative summaries. In every case the person confirms the result. AI does not choose therapy.
Deterministic clinical logic.
Where the private clinical-development edition performs dose calculation, the inputs are explicit, the formulas are explicit, the insulin-action math is explicit, and the thresholds are explicit. The behavior can be unit-tested and the output explained. It is arithmetic, not judgment.
An inspectable calculation, not a black-box number.
In the clinical-development edition, the clinically relevant inputs and the breakdown behind a result are designed to be visible — every term that goes into a total is shown, and the model and insulin-action curve used are recorded with the dose.
- Explicit inputs: glucose, ratios, correction factor, carbs, insulin on board
- Insulin-on-board from published insulin-action curves, interpolated per dose
- The curve source and model version recorded alongside each result
Private clinical-development edition — not the App Store product.
No silent auto-tuning.
INBO does not watch outcomes and quietly change a patient’s insulin ratios or settings. A user rating never writes back into the numbers. An auto-tuner on a child’s insulin would be a different product with a different regulatory posture — so there isn’t one.
Fail explicitly.
Where required inputs are missing, invalid, stale, or outside defined bounds, the private calculation path is designed to refuse rather than invent a result. Explicit guardrails and defined refusal conditions — not a guess dressed up as a number.
The public edition does not ship the dose engine.
Public and clinical editions are separately compiled experiences built from a shared core. The dose-calculation code lives in a module that the public build cannot even reach — it is left out of the app entirely, not hidden behind a switch or a subscription.
Verified, not asserted: the public build is checked against its own compiled bundle — the dose-calculation symbols and strings must be entirely absent before it ships. The separation is a property of the artifact, not a promise in the UI.
Testability.
Safety-relevant behavior is extensively unit-tested and regression-tested. Critical rules are pinned by tests that are watched to fail before they’re trusted — a check nobody watched fail is not a check.
Clinical-status transparency.
The private clinical edition is a development and private-use system. It has not completed clinical validation and is presented with no regulatory or outcome claims. Saying so plainly is part of the design.
Clinician-authored settings.
The portal-to-phone authorization chain attributes each setting change to the clinician who authored it, and the patient or guardian applies it. No silent changes. See the workflow →
Pediatric / guardian model.
Guardian relationships are part of the system architecture — affecting enrollment, permissions, approvals, and communication — rather than a checkbox added after the fact.
Separate what’s public today from what needs review.
INBO separates what is available publicly today from higher-risk clinical-development functions. Broader distribution of functions that require regulatory review should follow the appropriate regulatory pathway rather than being disguised as ordinary consumer functionality. The website does not classify specific functions as exempt or non-device — those determinations belong to the appropriate process, not to marketing copy.