The physical AI data layer is a chain of custody for machine decisions

Physical AI will be decided by what a machine can show about the data behind its actions, not by model architecture alone. When a vehicle brakes or a robot arm moves, the system around it should be able to establish that the value it acted on was current, complete, delivered inside the window the decision needed, and unaltered on the way. That is a chain of custody for machine decisions. The physical AI data layer is the part of the system that keeps it, covering everything that captures, stores, moves, and verifies data reliably from sensor to action.

For anyone carrying a P&L or an engineering roadmap, this is where the money is. A prototype tolerates a reboot. A fleet of a million units in the field does not, and the cost of a data layer that cannot hold custody shows up as recalls, warranty exposure, certification delays, and audits that have to be run a second time. None of that appears in a demo. All of it appears at volume, which is the point where a physical AI program stops being a research artifact and becomes a product.

Tuxera has been building this layer for more than 30 years, across file system engineering and storage software now running in billions of devices, most of it long before physical AI had a name. The discipline is old and the stakes are new. What follows is about the stakes.

Key takeaways

• Physical AI puts intelligence into machines whose actions have physical consequences, so a wrong value moves hardware rather than producing a wrong answer on a screen.
• What decides these programs is whether a system can show that the data behind an action was current, complete, on time, and unaltered. That is a chain of custody for machine decisions.
• The physical AI data layer is the part of the system that keeps that custody, capturing, storing, moving, and verifying data reliably from sensor to action.
• Custody is a property of the whole system rather than of any component. Every part can be correct in isolation and the system can still be unsafe.
• The economics change at volume, and regulation is moving the same way. ISO 26262 assesses the item rather than the part, and ISO 21448 covers hazards that arise when nothing has failed at all.

What is physical AI?

Physical AI is intelligence that perceives, reasons, and acts in the physical world through machines: vehicles, robots, drones, and industrial systems whose actions have physical consequences. It differs from software-only AI in one decisive respect. A language model that produces a wrong answer produces a wrong answer, and a physical AI system that acts on a wrong value moves a machine. That is what turns the data beneath it from a quality concern into a safety concern, and it is why the failure modes end up on a balance sheet rather than in a bug tracker. For what changes in the infrastructure beneath the model as physical AI moves into production, see our post on physical AI infrastructure.

What a system has to be able to show

Custody is a useful standard because it is testable. In a laboratory, a sample is worth nothing if nobody can account for where it has been and who handled it. It is reasonable to hold a machine decision to something similar. Four things have to hold at the moment of action, and they have to hold every time rather than most of the time.

The data has to be current, meaning the value reflects the world as it is now rather than as it was several cycles ago. It has to be complete, so that nothing was silently dropped between the sensor and the decision. It has to be timely in the strict sense, arriving inside a bounded window rather than eventually. And it has to be unaltered, with corruption caught before the machine acts rather than discovered afterward in a log.

Model quality sits on top of those four. It does not substitute for any of them. A system that cannot establish them is not really making decisions, it is making guesses that happen to be well informed most of the time, and the gap between those two things is where physical consequences live.

What is the physical AI data layer?

The physical AI data layer is the part of a system that captures, stores, moves, and verifies the data a machine uses, from sensor to action, under any condition. It is where custody is either kept or lost, and each stage along the path has its own way of breaking the chain.

What the layer guarantees is simple to state and hard to keep: what the decision consumes is exactly what the sensor meant, every time, under every condition the field will produce. The layer is not any one component along that path. It is the property that the path as a whole holds.

Custody is a property of the whole system, not a component

This is the part I would ask any engineering leader to sit with, because it is where the expensive surprises come from. Consider a system in which every component is correct in isolation: a file system that never loses data on power loss, sitting on flash whose wear is no longer being managed, feeding a controller that assumes every read it receives is fresh and valid. Nothing has failed. The chain of custody is broken anyway, because it was never held by any single part.

The consequences of that are practical. Custody is not a line item you can buy, because no datasheet describes an interaction. It is not something you inherit from a supplier, because each supplier certifies its own piece against its own assumptions. And it will not surface in component-level testing, because the failures live in how parts behave together under stress, late in a deployment, when the flash is worn, the temperature is out of range, and the write load has been continuous for three years.

This is also, in my experience, where programs stall between the lab and the field. I would not claim the models are blameless, since they are new and carry failure modes of their own. The difference is visibility. A model failure is usually measurable and reproducible, while a broken chain of custody presents as something much harder to pin down: an intermittent fault, an incident nobody can recreate, a fleet that behaves differently in month 14 than it did in month 2.

White paper

Why physical AI breaks at scale

Where physical AI deployments run into trouble between the lab and the field, and what the data layer has to hold for them to scale.

Read the paper

One requirement, different safety cases

The physical AI framing pulls automotive, robotics, industrial, aerospace, and defense into one category, and that is useful as long as it is not oversold. Their safety cases are not interchangeable. An SAE Level 4 driving system is certified against different standards than a surgical robot or a factory cell, with different hazard analyses, different regulators, and different evidence to produce. What they share is the requirement underneath, which is data that can be accounted for from sensor to action. Seeing them as one category rather than separate verticals is what makes the common layer visible, and worth engineering deliberately instead of rediscovering one vertical at a time.

Regulation is already moving this way

Safety standards increasingly judge how a system behaves as a whole rather than how a single component performs. ISO 26262 assesses the item rather than the part. ISO 21448 goes further and addresses hazards that arise when nothing has failed at all, which reads to me like a formal acknowledgment that correct components can still add up to an unsafe system. Both judgments rest on the data layer beneath them. A field that can name that layer can specify it, reason about it, and produce evidence for it inside a certification package, and the naming is not a branding exercise. It moves the decision from the bottom of a bill of materials to the top of an architecture review, which is where its consequences have always lived.

What keeping the chain of custody requires

None of this is aspirational. We built the layer before it had a name, and the requirements are specific enough to put in a specification.

• Power-fail safety, so data is not corrupted when power drops mid-write. In the physical world, power loss is a routine event rather than an edge case.
• Deterministic behavior under continuous write workloads, so performance does not degrade unpredictably as a system logs sensor data around the clock for years.
• Guaranteed data integrity rather than probabilistic outcomes. A machine that is usually right about the physical world is not safe. It is a liability waiting for its statistics to catch up with it.
• Flash endurance for relentless sensor data, so the storage outlives the deployment instead of wearing out halfway through it.
• Certified software for constrained hardware, so the layer carries its own weight through ISO 26262, DO-178C, and IEC 61508 audits rather than becoming the gap that sinks a certification.
• Lifecycle support measured in decades, because that is how long these systems stay in the field, long after the model that made headlines has been retrained twice.

Physical AI will not be won on model architecture. It will be won by the organizations whose systems can account for the data behind every action they take, at volume, for as long as the hardware stays in the field. That is what the physical AI data layer is for. The teams treating it as an architectural commitment now are the ones who will still be shipping when the certification questions get harder, and the definitions written today are the ones this field will inherit.

Frequently asked questions