Teardowns

Physical AI Product Teardowns

A case study tells you what a vendor says happened. A teardown shows you a product you can go and look at, and names the decision that produced what you see. These are three, from product families where the decisions are visible in the behaviour.

How these are written

Each teardown starts from something observable without insider knowledge — how the product behaves, what its specification says, which standard it implements. From there it names the product decision that best explains the observation, what that decision cost or protected, and the rule that transfers. Where the analysis carries first-hand standing, that is stated. Where it is public observation, that is stated too. Nothing here discloses an internal decision, rationale or figure from any employer.

Three teardowns

Public EV charging — the reliability decision

What is observable
Anyone who has used public charging has met a charger that authenticated, then failed; or a bay reported available that was not. In everyday use, reliability appears to differ between networks, including networks that run similar hardware.
The decision behind it
Reliability in charging is bounded by product architecture decisions before operations can influence it, decisions made before the first unit ships: what the charger does when the backend is unreachable, whether a session can start offline, what is diagnosable remotely versus needing a van, and how a payment or authentication failure degrades. Where the same physical unit behaves differently in two networks, differences in those decisions are the most likely explanation.
What it cost
A network that defers the degraded-mode decision takes on a field-service cost that scales with the fleet. That cost is hard to reduce later, because it comes from the architecture rather than the operation.
The rule that transfers
In connected hardware, the ceiling on availability is set at design time; operations decide how close you get. Ask what the unit does with no backend before asking what the uptime target is.
Standing
This teardown uses publicly observable network behaviour and published specifications only; it contains no confidential employer information.

Android Automotive in a production vehicle

What is observable
Infotainment in recent vehicles increasingly runs a full general-purpose OS with an app store, not an embedded HMI. Renault OpenR Link, built on Android Automotive, is one example.
The decision behind it
Putting a general-purpose OS inside a homologated vehicle forces a decision most software teams never face: two clocks. Apps expect a weekly release cadence; a vehicle expects type approval, regional homologation and a support life measured in years. You either sandbox the fast layer hard enough that it cannot touch the certified one, or you inherit the vehicle's cadence for everything — and the second choice makes the app store pointless.
What it cost
The sandbox decision determines whether the platform can accept third-party software at all. It is made once, early, and everything downstream — signals exposed to apps, update channels, what a bad app can degrade — follows from it.
The rule that transfers
When a fast-moving layer meets a certified one, the interface between them is the product decision. Draw it before either team starts, or the certified side sets the pace for both.
Standing
former-employer connected-services product leadership across multinational vehicle programmes. Written from publicly documented platform behaviour.

Video platforms at fleet scale

What is observable
Set-top boxes and video platforms update in waves, not all at once, and carry telemetry far beyond what a feature needs. Users notice neither — which is the point.
The decision behind it
Past a certain fleet size, you cannot recall a device and you cannot ask a person to look at one. Staged rollout and remote diagnosability stop being process and become architecture: if the update mechanism cannot halt mid-wave, or a fault cannot be diagnosed without a visit, no amount of QA compensates. That decision has to precede the first deployment, because it constrains how the software is built.
What it cost
Platforms that treated rollout as a release process rather than a product capability discovered the gap during their first bad update — the moment when the cost of not having it is highest and the option to add it is gone.
The rule that transfers
Ask what full deployment costs per unit for every recurring operation. A cost that scales linearly with fleet size has to be covered by per-unit revenue; if it is not, it is a launch blocker, not an optimisation.
Standing
former-employer product experience on globally deployed video platforms. Analysis of publicly observable update and telemetry behaviour.

What these are not

These are not client case studies — Hyperion publishes none, because it has none to publish. They are not audits of the companies named, and they do not claim the decisions described are the ones those teams actually debated; they are the decisions that best explain what is observable. Nothing here discloses confidential product, contract or roadmap detail from any employer. Where a teardown draws on first-hand standing, the analysis is the contribution; the internals are not disclosed and will not be.

The same reading, on your product

A Product Decision Review applies this to your own programme and returns a written decision memo rather than an assessment score.

Discuss your product decision