Skip to main content
Avanti Robotics
Join the waitlist
AVM-WR-018Datasheet

Safety case

How an Avanti robot behaves when something goes wrong, what the platform is allowed to send it, and the regimes every robot is engineered against.

Designed in Britain, answerable in Britain.

1Behaviour when the link drops

A robot that needs the cloud to decide what to do has an unpredictable failure mode: when the link drops, its behaviour changes. Avanti robots run navigation, patrol and their safety responses on the device. An outage changes what you can see, not what the robot does.

That is why the offline-first architecture is treated as a safety property here, and why it belongs in a safety case at all. A carer who cannot reach the app at two in the morning still has a robot behaving exactly as it behaved at ten the night before.

2What every robot is engineered against

A connected consumer device sold in Great Britain carries four separate obligations. Each one is listed below with the regime that imposes it and what it requires.

Table 1 — Conformity obligations for a connected consumer device sold in Great Britain, and what each one requires.
ObligationWhat it requires
UKCA markingGreat Britain product-safety conformity markingConformity assessment against the essential requirements for an electrical consumer product, a declaration of conformity, and the mark applied before sale.
Connectable-product securityProduct Security and Telecommunications Infrastructure Act 2022, and the security requirements regulations made under itNo universal default passwords, a published means of reporting security issues, a published minimum security-update period, and a statement of compliance supplied with the product.
Radio equipment conformityRadio Equipment Regulations 2017Assessment of the wireless interface against the applicable essential requirements, and a declaration covering the frequency bands the robot uses.
Data Protection Impact AssessmentUK GDPR, for the Avanti Care monitoring use caseA written assessment of the risk to the monitored person, the mitigations, and the residual risk, completed before processing begins.

Each obligation is engineered in from the start, and every declaration ships with the product it covers.

3What the platform may send a robot

An update from the Avanti platform is a behaviour document: a set of parameters describing when the robot should patrol, where, and what to do when it finds something. It is not a firmware image. The platform has no firmware distribution channel, and a robot receiving an update is receiving instructions; no machine code travels this path.

Before it leaves the platform, every update is cryptographically signed, and the robot refuses anything that does not check out.

How a signed update reaches a robotAn elevation on a single ground line. On the left the platform is drawn as a building cut through in section, with three floors labelled compose the behaviour, sign it with a detached signature, and publish it per tenant and per robot. Between the building and the right of the sheet stands a heavy hatched wall marked trust boundary, with exactly one opening cut through it. Two lanes pass through that one opening: the signed document going out to the robot, and the robot's error rates coming back. Beside the building a ladder of four equal rungs shows the update going to one per cent of a fleet, then ten, then fifty, then a hundred. On the right of the wall the robot stands on the same ground line, drawn as an undimensioned outline, with a verify step in front of it: a good signature is applied, and a missing, wrong or altered one meets a hard stop marked refused, nothing is applied.GROUNDTHE PLATFORM1COMPOSEthe behaviour,as a document2SIGNdetached signature.No key, no deployment3PUBLISHper tenant, per robotSTAGED1%10%50%100%of a fleet, in that orderTRUSTBOUNDARYthe signed documentand nothing elseerror rates backand the platform rolls the update back by itselfwhen error rates climb past the threshold4VERIFYbefore anything runssignature goodapplied5REFUSEDsignature missing,wrong, or alterednothing is appliedTHE ROBOTENVELOPE ONLYform not decidedELEVATIONNOT TO SCALEUNDIMENSIONED
AVM-FIG-03How a signed update reaches a robot
Key
Cut through the platform, and the trust boundary itself
Key
The signed document, travelling
Key
What comes back, and the refusal
Key
The robot — an outline for reference, undimensioned
Key
Hatching, ladder, ground and annotation

An update is a behaviour document — a versioned definition of what the robot should do, not compiled code. The platform composes it, puts it into a canonical form and signs it. The signing step is not optional in the sense that matters: if the signing key is unavailable, the deployment fails. It does not go out unsigned.

The wall across the middle of this sheet is a trust boundary, and it is drawn as a wall because that is what it is: the platform's authority ends at it. Exactly one opening is cut through it, and only the signed document goes out through that opening. Everything else the platform might want to do to a robot has no way across.

Beyond the wall the robot verifies the signature itself. If the signature is missing, wrong, or over a document that has been altered, the robot refuses, and the refusal is drawn as a hard stop rather than described as a policy, because it is a real outcome and not a reassurance.

A fleet does not receive an update all at once. It goes to one per cent of the fleet, then ten, then fifty, then all of it — so a problem is found on a handful of robots rather than every robot. If error rates climb past the configured threshold, the platform rolls the update back without waiting to be asked. Those error rates are the second lane through the same opening; there is no second hole in the wall.

The four percentages are the only figures on this sheet, and they are proportions of a fleet. The ladder is drawn as four equal rungs rather than four bars of scaled length, so nothing here can be read as a quantity we have not stated.

4Data protection for the care use case

Monitoring an older person at home processes some of the most sensitive data this platform will ever hold: where someone is inside their own house, and footage of them in the rooms they live in. UK data protection law classes that as high-risk processing, and high-risk processing requires a Data Protection Impact Assessment before it starts.

A DPIA is a written document with a required shape. It has to describe the processing, say why it is necessary, assess the risk to the person being monitored — who is very often not the person who bought the robot — and record what has been done to reduce that risk and what risk remains.

Three things are already settled: the monitored person can close the camera shutter herself and no account holder can reopen it remotely; the robot reports the smallest amount of data that makes the feature work; and an erasure request removes footage.

5The shutter is a safety feature

A camera and a microphone in a home are a safety question as much as a privacy one, particularly for someone who did not choose to have them there. The physical shutter gives the person living with the robot a control they can operate with their hand and confirm with their eyes: closed means the lens is covered, and no setting, no account and no support engineer can open it from somewhere else.

A software toggle asks a worried person to trust a screen. A shutter asks them to look.