Decision framework
The Prototype-to-Product Decision Gate
A Physical AI prototype that demos well and never ships has usually failed one of five decisions — and failed it long before the demo. These are the five, in the order they get expensive.
Why prototypes stall
An industrial AI pilot can stall before production even when its model performs well. A prototype is judged on whether it works. A product is judged on what it does when things are not as the prototype assumed: the network is gone, the light is wrong, the operator disagrees, the hardware revision changed, or an assurance body asks who owns the release case. Those are product decisions, and each is cheaper to make before the prototype exists than after it works.
The five gates
Ordered by when the decision becomes irreversible, not by when teams usually get to it. Most teams reach gate 1 last.
Gate 1
Degraded mode ownership
When the system cannot do the smart thing, what does it do — and who decided that?
- Why it is first
- This is first because it is the only gate whose answer shapes the architecture. Retrofitting a degraded mode means changing where authority lives, which touches everything. Deciding it on day one costs a conversation.
- The test
- Name the person who owns the degraded behaviour and the document it is written in. If the answer is 'it falls back to manual' with no owner, the decision has not been made — it has been deferred to whoever is on shift when it happens.
- What it prevents
- A connected service that is excellent with signal and undefined without it. The product is not the feature; the product is the feature plus its absence.
Gate 2
The variant decision
Is your hardware and market variant count a decision, or an accumulation?
- Why it is first
- Variants multiply silently: a market, a trim, a hardware revision, a regulatory regime. Each one is defensible alone. The total is what kills the release train, and nobody ever chose the total.
- The test
- Write the number down. If nobody in the room can state it within one, the count is an accumulation and the roadmap is already fiction.
- What it prevents
- A validation matrix that grows faster than the team, so the last variant is always the one that slips — and it is always someone's primary market.
Gate 3
Field survival, not demo survival
What breaks when the environment is not what the demo assumed?
- Why it is first
- A demo is run by someone who wants it to work, in conditions chosen because it works there. Every one of those conditions is a hidden requirement, and they surface as field failures rather than as requirements.
- The test
- List the demo's implicit conditions — lighting, cleanliness, connectivity, operator skill, temperature — and ask which are guaranteed in the field. The ones that are not are your actual backlog.
- What it prevents
- A perception system validated indoors and deployed outdoors; a connector that works clean and fails dirty. Both pass their acceptance test.
Gate 4
The scale delta
What must be true at full deployment that is not true at pilot scale?
- Why it is first
- Some assumptions hold at ten units and break at ten thousand: manual intervention, per-unit configuration, anything requiring a person to look. They do not degrade gradually — they work until they do not.
- The test
- For each operational step, ask what it costs at target fleet size. Any step whose cost scales linearly with units is a launch blocker, not an optimisation.
- What it prevents
- A fleet you cannot recall, cannot update in one wave, and cannot diagnose remotely — discovered after the units are in the field.
Gate 5
The signature
Who signs the safety and compliance case, and when did they start?
- Why it is first
- Certification is a lead time, not a step. Under the Machinery Regulation, AI performing a safety function requires third-party assessment by a notified body rather than self-declaration — and that applies from 20 January 2027, more than eighteen months before the EU AI Act's Annex I deadline (2 August 2028) it is usually planned against.
- The test
- Name the assessor and the date they were engaged. If the answer is 'we will handle compliance later', the launch date is not real.
- What it prevents
- A finished product that cannot be placed on the market, discovered when the schedule has no slack left to absorb it.
Scoring your own programme
Not a maturity score. Each row is a signal you can check this week without instrumenting anything.
| Signal | Not ready | Ready |
|---|---|---|
| Degraded mode | Described as 'graceful fallback' with no named owner | A written behaviour, owned by a named person, tested deliberately |
| Variant count | Nobody can state it from memory | A number, a rationale for it, and a rule for adding one |
| Demo conditions | The demo environment is the only validated environment | Implicit conditions are written down and separately tested |
| Scale assumptions | Operations steps that assume a human looks at each unit | Every recurring step is bounded independently of fleet size |
| Compliance | Compliance is a workstream that starts after feature freeze | An assessor is engaged and the lead time is on the critical path |
Where this comes from
These are the decisions that recurred across shipping software inside physical products: former-employer connected-services product leadership across multinational vehicle programmes; and former-employer product experience on globally deployed video platforms. Different industries, the same five questions, and the same pattern of which one gets asked too late.
What this framework does not do
It does not tell you whether to build the product, and it will not rescue one whose value proposition is wrong — a well-governed programme can ship something nobody wants. It assumes a working prototype already exists. It is a set of questions, not a methodology or a certification, and it is deliberately short enough to use in a single meeting.
Apply it to your programme
A Product Decision Review runs these five gates against your actual prototype and returns a written decision memo — including the gates you have already passed.
Discuss your product decision