A Physical AI pilot should not become an indefinite research program. Set a decision clock. Ninety days is a useful default for forcing assumptions into the open, assigning owners and collecting the evidence needed for a clear recommendation.
It is not a delivery guarantee. Product scope, hardware, field access, safety obligations and regulatory path can require a different timeline. The clock governs the decision process; the evidence governs the product plan.
This is a public method, not an account of a Hyperion client engagement. The examples are illustrative and contain no claimed outcome.
Days 1–15 — Frame the decision
Start with the decision the sponsor actually needs to make. Examples include whether to authorize productization, narrow the operating envelope, change a supplier, collect different field evidence, or stop.
Write:
- the buyer and product outcome;
- the prototype behaviour already observed;
- the conditions under which it was observed;
- the unresolved customer, technical, safety, operational and economic assumptions;
- the decision options;
- the evidence that would distinguish those options.
Do not start by expanding the backlog. A long backlog can conceal an undefined decision.
Output: a signed decision charter and evidence register. Signed means accountable ownership, not agreement with a predetermined answer.
Days 16–45 — Attack the decisive assumptions
Prioritize the assumptions that can reverse the recommendation. A product may depend on operator acceptance, a latency bound, a supplier interface, field data access, installation time or a safe degraded mode.
Design the smallest credible test for each one. Keep observed results separate from estimates. Record test conditions, failures and missing evidence.
An illustrative vision-product test might compare behaviour across the actual camera, lighting variation and line speed while observing how an operator handles an uncertain result. The purpose is not to produce a persuasive demo. It is to discover whether the product promise survives contact with the field.
Output: a versioned evidence pack with methods, observations, limitations and owners.
Days 46–75 — Test the whole product candidate
A model test cannot prove a product. Connect the candidate to the surrounding system and workflow.
Review:
- sensors, compute, connectivity and hardware variation;
- deterministic controls, human authority and safe state;
- deployment, identity, observability and rollback;
- installation, training, acceptance and support;
- data lineage, access, retention and change approval;
- supplier responsibilities and exit;
- product economics as ranges.
Use a realistic field or bounded test environment. Label simulated evidence as simulated. Label an illustrative dossier as illustrative. Neither becomes customer production evidence through repetition.
Output: a productization dossier and a list of residual risks with named owners.
Days 76–90 — Make the decision
Reassemble the evidence around the original options. Do not score the pilot by activity completed or demo quality. Ask which option the evidence supports.
The recommendation should be one of:
- Proceed to the next Product System gate with acceptance criteria.
- Change the product boundary, operating envelope or value proposition.
- Partner where ownership or capability should sit elsewhere.
- Pause for one named item of unavailable evidence.
- Stop because the opportunity or product case no longer justifies investment.
A stop decision can be a successful outcome of the clock. It prevents more spending on an unsupported thesis.
Output: a two-page decision memo, evidence appendix, residual-risk owners and next review date.
What invalidates the clock
The process fails when:
- the decision is rewritten after evidence arrives;
- a deadline is treated as permission to skip safety or field evidence;
- simulation is presented as field acceptance;
- an optimistic estimate is copied as an observed result;
- nobody can stop the work;
- the team hides an unresolved assumption inside a future phase;
- the output is automatically described as "production-ready."
The remedy is governance, not more velocity. Keep the decision charter stable, maintain an evidence ledger and make changes visible.
Adjusting the timeline honestly
Shorten the clock only when the decision is narrow and the evidence environment already exists. Extend it when evidence depends on seasonal operation, hardware lead time, regulated review, safety validation or access that cannot responsibly be compressed.
If the clock changes, record why, what evidence is blocked and who owns the next date. An extension without that record is drift.
Where it fits
The decision clock can be used at any Physical AI Product System gate. It is most valuable between Discovery and Productization, where technical feasibility must meet customer, field, safety, operating and economic evidence.
The Physical AI Product Decision Review uses the same principle: create one written, evidence-backed recommendation before another consequential product investment is authorized.
Source anchors and boundary
Ninety days is Hyperion's governance default, not a benchmark or standards deadline. The NIST AI RMF Core includes an explicit determination of whether an AI system achieves its intended purpose and whether development or deployment should proceed. NASA's Systems Engineering Handbook decision-analysis guidance describes alternatives, uncertainties, review purpose and entry/success criteria. They anchor the evidence-and-decision discipline; the clock must still be adapted to the product's actual constraints.
