The orchestrator
Durable workflow execution, the rule library, fleet management, the immutable action ledger, and the explanation service that turns a numeric proposal into a sentence someone can act on in four seconds.
Durable, not best-effort
A workflow that is halfway through paging cardiology when a node dies resumes from that point on another node. It does not restart, and it does not page twice.
Rules are versioned artefacts
Every change records who edited it, what changed, and which approver released it to the fleet. A proposal in the ledger names the exact rule version that raised it.
Replay against yesterday
Take last Tuesday's recorded signal, run a modified rule over it, and see precisely which proposals would have changed before anything ships to a device.
Fleet as a first-class object
Firmware versions, attestation state, battery and last-seen across thousands of devices, with staged rollout to a ward, a shift or a squad at a time.
What gets written, every single time
| Field | Why it is there |
|---|---|
| Signal window | The evidence that caused the proposal, at the sample rate it was captured |
| Rule version | Which exact rule fired, so a later edit cannot rewrite history |
| Trust and urgency | The scores that selected the approval mode |
| Responder identity | Bound to a FIDO2 authenticator, not a shared ward login |
| Answer and latency | What they decided and how long it took them |
| Outcome | What the workflow actually did, including retries and failures |
Records are hash-chained and append-only. Export is a supported operation, not a support ticket.
Start with one ward, one shift, or one squad
A pilot runs four to sixteen weeks depending on deployment model. You bring the population and the responders. We bring devices, gateways and the first set of rules, and we measure override rate and time-to-answer from day one.