The audit question a site can answer

Sooner or later, on any floor with robots, something happens that someone has to explain. A near miss. A damaged pallet. A stop nobody ordered. A complaint from an employee about a camera. An auditor, an insurer, a safety officer, or a regulator sits down and asks a set of questions, and the quality of the site's answers decides how everything after goes.

The questions are predictable. This article lists them and shows, for each, where the answer lives on a Czar Grid. The short version is that every answer is on the operator's own hardware and readable by the person asking.

The question in four parts

Strip away the phrasing and the audit question about a robot floor has four parts. What were the robots told to do, and when. What served them that instruction, and what was it running. Who approved it, and under what limits. Where did the data about all of this go.

A site that can answer all four from its own records is in a strong position. A site that has to ask a vendor for some of the answers is in a weaker one, because the vendor's records are the vendor's, arrive on the vendor's schedule, and describe the floor from the outside.

The answers a cloud-served fleet gives

Consider a floor where each robot vendor runs its models in its own cloud. What the robots were told is in several vendors' logs, in several formats. What served them is a service the site cannot inspect, running a version the site may not know. Who approved the task may be a configuration change in a vendor console with no named approver at the site. Where the data went is wherever each vendor's agreement says, which the site must now read carefully.

None of this is anyone's bad faith. It is the shape of the architecture. The site is answering questions about its own floor from documents it does not hold. Vendor clouds and the copies of your floor explains how that shape arises.

The answers a facility pool gives

On a Czar Grid the four answers come from four records, all inside the building.

What the robots were told: the decision record. Substrate keeps the record of what the pool served each robot and when. The robot's own stops, speed limits, reflexes, and motion limits remain on the machine as the vendor delivered them, so the record also makes clear which behaviors came from the pool and which were the robot's own.

What served them: the attestation log. Each node attests what it is running before it joins the Grid and before it accepts a task. The attestation in force at the time of the decision identifies the node and the sealed, signed image it ran. Attestation before a node joins a Grid describes the step.

Who approved it: Agency Studio. Site tasks are authored, versioned, bounded with zones, speeds, distances, and stops, and approved by named roles. Every run is recorded and replayable. The approver's name, the version, and the bounds are part of the run's record.

Where the data went: nowhere. Camera feeds, captures, task records, adapted weights, and the decision record stay on the operator's hardware. On an air-gapped site there is no path out. On a connected site the declared routes are a short list the site wrote, and Local Bridge denies the rest.

There is often a fifth question, asked less about the incident than about the installation: what is this equipment and where did it come from. The provenance record answers it. Integration, sealing, and software load are recorded for every node, and the attestation log shows each node matching that record before it served. The site answers from a document, not from a reassurance. What a provenance record contains covers it.

Reading the record

What makes these answers useful to an auditor is that they are plain. The record is not a compliance badge and does not claim to be one. It is an account of events on the operator's hardware that the auditor can read directly: this task, approved by this role, with these bounds, run at this time, served by this node, running this attested image, with the data remaining here.

That is more persuasive than a certificate. A certificate says a third party was satisfied once. A record lets the auditor be satisfied now, about the specific night in question, from evidence the site did not have to request from anyone.

What the site still has to do

The record does not write the site's procedures. The site still has to decide who holds the approving roles, keep the route declaration honest, run updates as a procedure, and make sure the people who will be asked know where the record is. Who holds the keys on a facility pool lays out those decisions.

What the pool contributes is that, when the question comes, the answer exists and the site owns it. For the serving system that keeps the record, see Substrate; for the task layer and the rest of the stack, see Technology.