Use cases
An audit trail your customers trust.
What ran on which unit, when, deployed by whom, verified by what. One query answers the compliance review, the post-mortem, and the question about whether that customer is on 2.4.1 yet.
The question arrives long after the release
Nobody builds an audit trail on the day they ship. It gets built the week after an incident, when somebody senior asks which build was on unit 47 in March and the honest answer is a guess assembled from a deploy script's log output and someone's memory.
In regulated or contracted work the question is not hypothetical. A safety case references a software version. A customer agreement specifies what is running on their floor. An incident review asks who authorised a change and what evidence they had at the time. All three need a record that was written when the thing happened, not reconstructed afterwards.
The useful property of health-gated rollouts is that this record is a by-product. The system already knows which units confirmed, what their checks returned, and who approved the ring, because it needed all of that to decide whether to advance.
What gets recorded
| Recorded | Answers |
|---|---|
| Unit id bound to build hash and config version | What was actually running on that machine on that date, including which configuration overlay applied. |
| Applied at, and by which transport | Whether it arrived over the air or from a depot bundle, and when the switchover happened rather than when it was scheduled. |
| Approvals, with role | Who authorised the ring that touched this unit, in which role, against which release. |
| Verification results, with values | Not just that the unit passed, but what the checks returned. A margin of two percent and a margin of forty percent are different facts. |
| Self-reverts and halts | Which units saved themselves, and where a rollout stopped. The failures are the part an incident review cares about most. |
| Artifact provenance | Build id, source commit and toolchain behind the image, signed, so the chain from repository to robot is unbroken. |
Evidence as configuration
evidence: bind: unit_id, build_hash, config_version, applied_at approvals: recorded # who, which role, against which ring verification: retained # the checks that passed, and their values retain: 7y export: signed_manifest artifact: signature: required provenance: build_id, source_commit, toolchain
Retention is set per fleet because the requirement comes from outside your company. Seven years is common where a unit's work feeds into an engineering report or a safety case. The export is a signed manifest, so what you hand a customer or an auditor can be checked without trusting your database.
What this does not do
Worth being clear about
- It is not a certification. No tool makes you compliant with anything; this produces evidence that a compliance process can use.
- It does not write your safety case. It supplies the software version facts that a safety case has to reference.
- It does not audit what happens outside the update path. A change made by hand on a unit is visible as drift, not as an authorised change, which is the correct outcome but not the same as preventing it.
- It is not a data platform. Telemetry stays where it already lives; what is retained here is the release record and the verification results that gated it.
Early access
Running robots in the field?
We are taking on a handful of fleets this year, in agriculture, inspection, drones and logistics. Few enough that you get direct engineering time rather than a support queue.
Founding customers get direct engineering time and a permanent founding rate.