A software-defined vehicle platform is often described as layers: compute, operating system, middleware, services, applications and cloud. That view is useful to architects, but it misses the product decision.
A platform exists to make a class of vehicle experiences faster to create, safer to change and more economical to support across models and markets. If the shared foundation does not improve those outcomes, it is a common codebase, not yet a product platform.
This article is a product-system field note informed by automotive connected-services and platform work. It does not describe a Hyperion client engagement or claim a deployment outcome.
Decision 1 — Define what the platform makes repeatable
Start with the repeated product job, not the technology. A platform might make identity, vehicle state, energy management, diagnostics, feature delivery or fleet learning reusable. Each creates a different boundary.
Write three lists:
- capabilities every vehicle line should inherit;
- capabilities that must vary by brand, market, hardware or regulation;
- capabilities that should remain outside the platform.
The third list matters most. A platform that absorbs every requirement becomes a central program that slows every product it was meant to accelerate.
Product System gate: Strategy. Decide where shared capability creates customer and business value.
Decision 2 — Separate stable contracts from changing implementations
Vehicle programs move at different speeds. Hardware generations, supplier components, cloud services and customer-facing features do not share one release rhythm. The platform must make those differences manageable.
Stable contracts can include hardware abstraction, service interfaces, identity, telemetry schemas, update policy and safety boundaries. Implementations behind those contracts can evolve.
The product question is not merely whether an API exists. It is whether a vehicle program can depend on the contract, test it independently and understand how a change affects field behaviour.
Product System gate: Productization. The platform needs explicit compatibility, change and acceptance rules.
Decision 3 — Make vehicle variation a first-class product concern
A demo runs on one configuration. A vehicle platform has to cope with variants: compute, sensors, connectivity, markets, trims, suppliers and product generations. Variation handled through forks creates invisible operating cost and weakens the ability to learn across the fleet.
Create a variability model. Mark what is configured, extended, replaced or prohibited. Put an owner beside every extension point. A component that can be changed but has no compatibility owner is not an extension mechanism; it is an integration risk.
Product System gate: Discovery and Productization. Test the platform against real program variation before declaring the common core stable.
Decision 4 — Treat data rights and learning loops as product architecture
Software-defined does not mean every vehicle streams everything to a cloud service. The useful learning loop depends on what can be observed, retained, transferred, interpreted and acted on.
For each learning objective, define:
- the event or state the product needs to observe;
- whether raw data, a derived signal or an exception sample is sufficient;
- the user's and operator's expectations;
- access, retention and market constraints;
- how evidence changes a product, model or policy;
- how the change is evaluated before release.
A data lake without a product decision attached is storage. A learning loop connects field evidence to a governed change.
Product System gate: Launch and Scale. The operating model must turn field evidence into controlled product improvement.
Decision 5 — Put safety and cybersecurity outside the feature backlog
Features may be software-defined. Physical consequences remain system-defined. A remote or model-driven change must stay within deterministic safety boundaries, secure update policy and a known recovery path.
Document who can authorize a change, what evidence accompanies it, which vehicle states permit it, how rollout is staged, and how rollback works. Do not treat those controls as platform services that product teams can adopt later. They are conditions for participation in the platform.
Product System gate: Productization and Launch. A change mechanism is incomplete until its authority and recovery path are defined.
Decision 6 — Design the platform as an internal product
Vehicle programs are platform customers. They need an offer they can understand: supported capabilities, integration path, service levels, roadmap, evidence, constraints and escalation.
Measure the platform by decisions and outcomes it enables, not by component count. Useful internal questions include:
- Did a program reuse a capability without creating a fork?
- Could it integrate and test against a stable contract?
- Did a field issue produce evidence that improved the shared foundation?
- Can the organization explain who owns support across platform and vehicle teams?
These are operating questions, not vanity metrics. They reveal whether the platform is becoming a product or remaining an architecture initiative.
The platform decision memo
Before expanding an SDV platform, publish a decision memo that names:
- the repeated product job;
- the shared and variable capability boundary;
- stable contracts and their owners;
- the variability model;
- the field-learning loop;
- safety, cybersecurity and update authority;
- the internal product offer;
- the next program evidence required.
The same lens applies beyond automotive. Robotics fleets, charging products and intelligent industrial equipment all need a coherent answer to what is shared, what varies, who can change it and how the field teaches the product.
Use the Physical AI Product System when the platform debate spans product value, system architecture, field operations and economics. The Product Decision Review is designed for the point where those views need one written recommendation.
Source anchors
This platform decision method is Hyperion's synthesis, not a claim that one architecture is mandated. UN Regulation No. 155 addresses vehicle cyber security and cyber security management systems. UN Regulation No. 156 addresses software updates and software update management systems. Applicability depends on vehicle category, market and approval route; the sources anchor why change authority, lifecycle controls and update evidence belong in an SDV product decision.
