Keep one person's glucose safely in range, around the clock, with a system they own, understand, and can trust to keep working when parts of it fail.
BasaltAPS does this by running a personal artificial pancreas not as one large app but as a set of small, independent ones that cooperate — today a pump driver, a data store, an algorithm, a viewer, a watch; tomorrow whatever the loop needs — each doing one thing, each able to fail and restart without taking the others down. Robustness is the organizing priority: the loop is spread across modules and devices so no single failure can stop it. Everything else the suite offers — predictions, fewer false alarms, better control — is built on that foundation, never traded against it.
Why basalt. When lava cools slowly it fractures into separate, mostly hexagonal columns that pack together into a single formation. Each column stands on its own; the formation stands because of all of them — and it has no fixed number of columns. That is the architecture: independent parts, as many as the loop needs, one formation.
Values
Robustness first
The measure of the system is whether it keeps working — through a crash, a dead battery, a lost connection, a missing device. Features are welcome on top of that; nothing is allowed to weaken it.
Safety is a property of failure, not success
Anyone can be safe when everything works. The system is judged by where it lands when a part dies mid-operation — and it must land somewhere safe by default.
You own the loop
Your data, your devices, your decisions. Nothing on the critical path depends on a server you don't control or a vendor who can switch it off. Cloud copies are extras, never the only copy.
No silent failures
Every part reports its own state — fresh or stale, measured or estimated, running or stopped — and the absence of a signal is never read as health. A failure that announces itself is manageable; a quiet one is the dangerous kind.
Every alert earns its interruption
An alert is a request for action, so each one must be actionable and valuable — an alert that can be ignored teaches you to ignore the next one. Noise cannot be driven to zero; it is the price of alarming on doubt. But it is minimized relentlessly, under one fixed condition: reducing alerts must never reduce what is detected. Prediction is how that price is paid down — better signal, fewer interruptions, the same coverage.
Principles
Redundancy that scales
Robustness isn't won by making one app bulletproof — it's won by having spares. A second phone, a watch, another copy of the data: each adds a fallback, and there is no fixed number of them. One device or several; one store or many — locally, in the cloud, on a monitoring server.
Any part, replaceable at any time
Pump, sensor, algorithm, screen, storage — each sits behind a plain contract, so any one can be swapped, upgraded, or — when it fails — taken over by a standby, without disturbing the rest.
Fail safe by default
Every failure path resolves to a safe state on its own. The loop going silent means insulin delivery reverts to profile basal as the pump's own timers expire — never a dose that runs away.
Bias every error toward the safe side
The two ways to be wrong are not equal, and the safe direction depends on the layer. Detection errs toward alarming — a missed failure is unbounded. Action errs toward withholding — a skipped dose is recoverable next cycle; insulin delivered on a bad reading cannot be taken back. Prediction earns its place by shrinking the doubt on both sides: fewer false alarms, fewer withheld doses, without moving either bias.
One authority at a time, many copies
Exactly one component commands the pump at any moment, and exactly one record is authoritative; every other copy is a fallback. When copies disagree, truth is re-derived from the device that did the work — the pump for insulin, the sensor for glucose.
Trust no caller
Each app enforces its own limits regardless of who is asking. The algorithm reasons about doses; the pump still refuses anything past its hard caps. Two independent layers, not one.
Engineer the catch-up, not the perfect handoff
Seamless cutovers are brittle. Let a gap happen when a device takes over, then reconcile from the authoritative record. A reliable recovery beats a fragile handoff every time.
Recovery must be simple under stress
A fallback you can't operate while low, tired, or without your glasses isn't a fallback. Taking over on another device is a few confirmations, not a setup ceremony — and the person is always the last fallback: manual takeover is never more than a tap away.
Small enough to hold in one head
Each app is bounded so it can be understood and tested completely. A safety domain you can't fully reason about isn't one you can trust.
Reuse what's proven; invent only where you must
The algorithm, the constraints, the safety machinery are borrowed from years of field-tested work. Novelty is spent only where the design genuinely requires it, and paid back with extra validation.
Earn authority with evidence, one column at a time
Nothing commands the pump until it has run alongside the trusted system in shadow mode and survived deliberate failure drills. New parts join the formation one at a time while the working loop keeps running — there is never a day when everything changes at once.