---
title: "Every motion needs a receipt"
url: "https://kyberbot.com/blog/every-motion-needs-a-receipt"
description: "When a machine damages something, the useful question is not whose fault it was but what the robot believed at that moment. That answer has to be recorded, not inferred."
---

# Every motion needs a receipt

July 5, 2026·3 min read·Editorial team

A rounded recorder module on a robot arm's wrist joint, with a short curl of paper tape coming out of it

A robot clips a rack. Nobody is hurt, a few thousand euros of stock is on the floor, and the question everyone asks is whose fault it was. That is the wrong first question. The useful one is: what did the machine believe at that moment, what was it permitted to do, and why did it think the motion was fine? If that answer has to be reconstructed from fragments, you will get a story rather than a cause.

## What most systems actually record

Three logs, none of them designed for this.

The controller has a motion log: joint positions and velocities at high frequency, retained for a short window, unreadable without vendor tooling. The fleet manager has task history: this robot was assigned that job at that time. The perception stack may have kept some frames, if disk space allowed.

Nothing joins them. The moment you want — what did it see, what did it conclude, what was it allowed to do, what did it choose — has to be assembled from three sources with three clocks, and the assembly happens under pressure, days later, by people with an interest in the answer.

## What a receipt contains

A motion receipt is a single record, written at decision time, that answers the whole question without a join.

**What was requested.** The intent: pick this, move there, on whose authority and under which task.

**What the machine believed.** Localisation and its confidence, the relevant perception output and its confidence, the state of the things it was about to interact with.

**Which envelope applied.** The harness version in force, and the specific limits relevant to this motion. This is the field almost nobody keeps, and it is the one that turns “the robot moved too fast” into “the robot moved within a limit that had been raised on the 14th”.

**What was decided.** Permitted, modified, or refused — and if modified or refused, which rule did it.

**What happened next.** The outcome, including whether a human overrode anything.

Written once, at the moment of decision, with a single clock.

## Why this is not just logging

Two properties separate a receipt from a log line.

It is **written at decision time**, not reconstructed afterwards. A log that records outcomes lets you replay what happened; a receipt records what the machine believed, which is the only way to explain why. Those diverge exactly in the cases you care about.

It is **complete for its own question**. You should never need a second system to interpret a receipt. When an incident is being investigated six months later, the fleet manager has been upgraded, the perception model has been replaced twice, and the vendor tool no longer opens the old format — a self-contained record survives all three.

## The uses beyond incidents

Incident reconstruction justifies the work, and it turns out to be the least frequent use.

**Refusal analysis.** Every refusal is a place where the world and the envelope disagreed. Cluster them by zone, time and task and you get a map of where the model of the site is stale, usually months before anything goes wrong.

**Change validation.** Replay a week of receipts against a proposed envelope and see exactly which motions would now be refused. Safety changes stop being arguments and become measurements.

**Insurance and procurement.** “Show me that this machine has operated inside its limits for six months” is a question with a real answer, which is worth something commercially — and the question is going to get asked more often, not less.

## The cost, honestly

Receipts are bigger than log lines and they contain sensitive operational detail, so retention and access have to be decided deliberately rather than by default.

The compromise we keep landing on: keep full receipts for a defined window, keep the decision and envelope fields much longer, and keep perception payloads only for refusals and overrides — which are rare and are exactly the ones worth having in full.

What you should not compromise on is writing the receipt at all. A machine that moves in the physical world without a record of why is a system you can only apologise for, never explain.

-   audit trail
-   incident
-   logging
-   accountability

## Keep reading

-   [What it means for an assistant to know you best](https://kyberbot.com/blog/an-assistant-that-knows-you)
-   [How an assistant hands work to a swarm](https://kyberbot.com/blog/how-an-assistant-hands-work-to-a-swarm)