A Physical-State Gate for Agents That Control Equipment

A command can pass a syntax check and still fail at the machine. An agent might instruct a parcel sorter to place a package in a full bin, use an empty label roll, or move a component through space occupied by a fixture. A TPM needs an admission rule: does this proposed action fit the equipment’s current physical state, and who authorized this exact action?

Google researchers Pooja Rao, Petar Sirkovic and Annalisa Pawlosky describe a related approach in their October 16 VERID post. Their prototype tracks workcell geometry and consumable state, runs virtual dry runs, blocks invalid hardware commands, and retains synchronized action and video records. Google also describes human authorization and supervision. These are design inputs for a non-biological equipment workflow, not proof that a state model catches every fault.

A mock parcel-sorter workflow

Consider a training rig with one conveyor, a pickup mechanism, two output bins, and a label printer. Packages are inert tokens. A proposed job says: take token `P-104`, print its route label, and place it in bin `B`. The rig has a capacity limit for each bin, a count of labels remaining, and a defined pickup path. No motor command is issued in this conceptual exercise; the point is to specify the admission contract before connecting a controller.

Keep four artifacts separate. A green result from one gate cannot stand in for the next.

1. State snapshot. Record the rig ID, snapshot version and time, token location, bin occupancy and capacity, label count, mechanism position, fixture layout, and controller status. Attach a source and freshness rule to each field. A camera estimate and a controller counter may disagree. An operator must resolve the discrepancy rather than let the agent choose a convenient value.
2. Simulation result. Bind the proposed job to the snapshot version and check token availability, bin capacity, label inventory, reachable pickup and placement positions, and clearance along the proposed path. Record each check, its input, and its pass or rejection reason. The result expires when relevant state changes.
3. Human authorization. Show an operator the proposed job, snapshot age, simulation findings, and unresolved discrepancies. Capture approval for the exact job and snapshot version, with operator identity and time. Approval of “sort the batch” does not authorize an altered path or destination.
4. Execution trace. If the controller accepts the approved job, record command IDs, acknowledgments, sensor observations, state transitions, stops, and operator interventions. Link this trace to the three earlier artifacts. Keep proposed, accepted, and observed actions distinct.

For this mock design, issue a command only when its job version matches the approved proposal, its snapshot remains valid, every required check passed, and the controller is in an allowed state. Recheck fast-changing fields at the controller boundary. A bin can fill between a dry run and dispatch. Hold the command for review when the version changes, a sensor reading is missing, approval expires, or the controller state is unknown. This admission contract is my proposed TPM exercise; Google did not test it on a parcel sorter.

Test the rejection paths first

A successful-path demonstration shows that the workflow can proceed. Design deliberate failures to test whether the boundary rejects stale or impossible actions. For each case, retain the input snapshot, check result, rejection reason and evidence that no command crossed the controller boundary.

• No labels: Set the label count to zero before proposing `P-104`. The gate rejects the print-and-place job and issues no printer or pickup command.
• Full destination: Mark bin `B` at capacity. The gate rejects placement into `B`; any other destination requires a new proposal ID and approval.
• Blocked path: Place a mock fixture in the path. The clearance check rejects the proposed path before dispatch and records the fixture-layout version.
• Stale simulation: Change bin occupancy after the dry run. The gate invalidates that result and requires a new snapshot and check. Preserve both state versions and the invalidation event.
• Changed job: Alter the destination after approval. The gate compares the approved job ID with the changed proposal and rejects the mismatch.

A rejection on a dashboard cannot prove that the command was stopped if it was already queued. Inspect the controller-side trace and assert that it contains no dispatch for the rejected job.

Treat an interrupted run as a state problem

Suppose the printer reports a fault after a label command, while the pickup mechanism has not reported a placement. The rig may contain a printed label, an unprinted token, or a token whose label status is uncertain. A stored plan cannot settle which state exists.

Stop the job and preserve the last confirmed command and observation. Reconcile the physical token location, label status, inventory count, and mechanism position with the trace. Mark unknown fields as unknown. Create a new snapshot and propose the remaining work. Give each action a stable ID so the controller can identify a command it has already accepted; do not infer that a timed-out acknowledgment means an action never occurred. Run the remainder through simulation and get operator authorization before dispatch.

This resume test has two acceptance criteria: no duplicate print or placement, and a record of how each uncertain state was resolved. If the rig cannot establish whether a command took effect, the operator keeps the workflow paused for inspection. Google reports a VERID prototype case in which retained state helped an agent resume after a plate-reader failure without repeating pipetting. That vendor-reported recovery motivates the mock test; it does not establish transfer to a parcel sorter.

Scope the claim

A state model can miss a loose fixture, a failed sensor, a slipping package, or wear that changes motion. Simulation checks the conditions its authors modeled. Human approval can become a formality if the review screen hides the state version or compresses failed checks into a single status light. Google’s October 16 post describes prototypes and cases, not an independent failure-rate study or a production safety guarantee.

For a TPM, the next deliverable is a gate with named inputs, invalidation rules, rejection tests, and an auditable command boundary. Test those paths on the mock rig and inspect the trace after an interruption. Any move to real equipment needs separate validation and a safety review for that machine and its operators.