The most common failure mode in enterprise AI is not a bad model. It is a pilot that shipped a compelling demo in month three, entered a slow negotiation with reality in month six, and was quietly reclassified as an "internal research project" in month eleven. The board-deck number — that roughly seventy per cent of AI pilots never reach production — is directionally right and diagnostically useless. The reasons the pilots stall are knowable, they repeat across sectors, and the operating tempo that avoids them is a specific one.
The tempo I run engagements against is a 90-day clock. Ninety days from the point a working pilot exists to the point the production system is owned by the client team, running on live traffic, and covered by an incident playbook. Faster than that and every architectural decision becomes irreversible before the evidence is in. Slower than that and the pilot accumulates enough sunk cost, political weight, and "just one more feature" scope to die a permanent-experiment death. Ninety days is not a marketing number. It is the operating window inside which a small engineering team can hold enough context, resist enough scope creep, and produce enough forcing functions to get one Physical AI system across the line.
This article is the operating manual for that clock. It is written for the AI programme lead who has a pilot that works in the lab and a board demanding production within the fiscal year, and it maps to the Pilot-to-Production Program we run at Hyperion — the same engagement referenced in the Physical AI taxonomy piece and shaped by the architectural constraints in the flagship. The clock is not the whole ladder — a Production Readiness Review sits before it to establish the evidence base, and an operating-partner phase can carry the system beyond day 90 — but the 90 days is the fulcrum. Everything else exists to make it possible.
Why 90 days, specifically
The honest answer is that 90 days is the shortest window in which a Physical AI system can be brought from pilot to production without cutting the corners that come back in year two, and the longest window in which a small engineering team can hold the deployment together as a single continuous effort. Both bounds matter.
Squashing the clock under 90 days — the six-week sprint, the four-week rebuild — forces every architectural decision to be irreversible before there is evidence for it. The team chooses the silicon before the model has been quantised on it, the OTA platform before an update has been rolled back on it, the observability stack before the first drift signal has fired. Those decisions do not stay wrong quietly; they surface eighteen months later as a rebuild whose budget is a multiple of the original programme. I have inherited three of those rebuilds in the last two years, and every one of them was traceable to a six-week production sprint that never had space for the second-order questions.
Stretching the clock past 90 days invites the opposite failure. Every additional week gives the pilot another reason to add scope. A stakeholder wants one more site included in the initial rollout. A vendor slips the silicon delivery and the team fills the wait with a refactor. The regulatory team asks for a documentation pass that grows into a full audit rehearsal. None of the individual asks is unreasonable; the aggregate is a pilot that has forgotten what production means. Ninety days is short enough that the team can push back on every one of those asks with "that is a phase-two ask, and phase one has to ship first". That posture is impossible to hold on a six-month clock.
The clock also has a physiological dimension. A small engineering team — five to nine people is the range I plan against — can hold the full mental map of a Physical AI deployment for about a quarter before context loss starts eating into decision quality. Beyond that the team either has to grow, which introduces onboarding overhead, or start writing detailed handover documents to itself, which is the same overhead spelled differently. Ninety days aligns the engineering tempo to the human tempo, and that alignment is what makes the clock actually work rather than merely fit on a slide.
Days 1–15 — Audit and decide
The first fifteen days are not build days. They are the days that decide whether the next seventy-five days are worth spending at all. The output of this phase is a single artefact: a written kill-or-proceed decision that both the client executive sponsor and the engineering lead have signed, backed by a graduation-criteria document that fixes what "production" means for this specific system before anyone writes another line of code.
The audit itself has a fixed shape. We inspect the pilot along seven axes, each rated red-amber-green with a specific remediation cost if it is not already green:
- Latency budget measured in the actual deployment environment, at the worst time of day, not in the lab.
- Safety envelope and the deterministic checks around every AI output that can move a physical actuator.
- Offline-operation duration and the state architecture that supports it when the network drops.
- Silicon target and the per-unit BOM contribution of the AI compute inside the product margin.
- OTA path — signed, A/B partitioned, with a rollback story that has been executed at least once.
- Audit trail and the regulatory classification against Annex III of the EU AI Act.
- Owning team — who holds the pager after day 90, and whether they have the skills to do it.
Every axis is drawn from the Physical AI Stack we publish, and every one is where I have seen a pilot stall when it went uninspected.
In a representative engagement for a European charging operator, this playbook would kill two of the seven pilot use cases inside the first week. One would be a load-balancing feature whose safety envelope has never been written down and whose failure mode is a tripped breaker on a shared substation — not a bug, an entire missing engineering discipline. The other, an OTA capability demonstrated over a warehouse Wi-Fi link that would not survive a rural site's LTE profile. Killing both cases in week one leaves the remaining five a plausible 90-day path. Not killing them means a nine-month engagement that ships the wrong system.
The graduation-criteria document is where the pilot is translated into a production contract with itself. It fixes the acceptance thresholds — accuracy floor on the long-tail input set, latency ninety-ninth percentile at the deployment site, sustained inference rate at the ambient temperature envelope, mean time between drift-detector fires — and it fixes what the safe state looks like and how the system enters it. It names the auditor who will sign off the conformity assessment. It names the on-call rotation that will hold the pager after day 90. It fixes the blast radius of the initial canary — how many sites, how many devices, how many production hours before the rollout expands. Every number in the document is a forcing function for the seventy-five days that follow. The document is boring to write and it is the single highest-leverage artefact of the entire engagement.
The kill-or-proceed decision is what closes the phase. The default answer at day 15 is "kill" unless the graduation criteria are achievable inside the remaining budget of time, silicon, and headcount. Killing at day 15 is cheap — one sprint of engineering time, no procurement commitments, no organisational face lost because no rollout has been announced. Killing at day 60 is expensive — a partial migration, sunk silicon orders, and an executive who has already told the board this quarter would ship. The whole point of the fifteen-day audit is to buy the option to kill cheaply.
Days 16–45 — Build the production architecture
The second phase is the longest and it is where the majority of production engineering happens. The trap here is that a team newly promoted from pilot to production reflexively wants to work on the model — a better base checkpoint, a bigger fine-tuning corpus, an architecture change. The audit will almost never justify that. The work of days 16–45 is not the model; it is the system around the model, which the model will then be selected to fit into.
The system decomposes into six workstreams that we run mostly in parallel. Real-time runtime — the ONNX or TensorRT inference path on the target silicon, benchmarked in the actual thermal envelope rather than on a workstation. Edge state — the local storage, the message bus, the state that has to survive a network outage for the offline duration the audit fixed. Safety topology — the deterministic checks, the safe-state entry conditions, the independent kill paths, all reviewed by a safety engineer who can read the control law. Telemetry — the metrics, the drift detectors, the traces that will make the system diagnosable once it is on live traffic. OTA — the signed update path, the A/B partition scheme, the automated health check that decides whether to promote an update or roll it back. Audit trail — the model card, the conformity artefacts, the change log that the regulatory pathway will consume. Each workstream has an owner, a definition of done, and a demo scheduled for the end of the phase.
At Vectis — the vehicle-intelligence platform we build, whose fanless enclosure fixes a twelve-watt sustained budget before any feature list is discussed — this is exactly the decision the phase exists to force. A candidate model that meets the accuracy target on the reference GPU but draws nineteen watts sustained at INT8 on the target Jetson is the wrong model, however good its benchmark line looks; a smaller candidate that runs at nine watts and reaches ninety-four per cent of the larger model's accuracy once quantisation-aware training is folded back in is the right one. That is the correct direction for the decision: the enclosure is a physical constraint the audit surfaced in week one, the model is the negotiable component, and shipping the twelve-watt model in production beats shipping the nineteen-watt model that would have thermal-throttled to a lower effective accuracy in the field. The four production failure modes piece is a longer version of why every one of these constraints is worth honouring before the deployment leaves the lab.
The governance side of the workstream is where the compliance clock starts running in parallel with the engineering clock. The audit-trail workstream is not a documentation exercise appended at the end; it is a discipline of emitting the conformity artefacts as the engineering produces them, so that on day 90 there is nothing to write from memory. The technical documentation demanded by Annex IV of the EU AI Act is generated as a side effect of the engineering rather than as a separate project — the model card is a build artefact, the data-governance plan is a check-in gate, the risk-management log is populated on every design review. Running this workstream late is how compliance ends up costing three months instead of the three weeks it has budget for.
Day 45 closes with an internal end-to-end demo of the production architecture running on the target hardware in a simulated deployment environment. Not on a laptop. Not on a lab bench. On the silicon, in the enclosure, at the temperature, on the network profile the audit specified. If the demo does not survive the environment, the remaining time is not enough to fix it, and the engagement returns to the day-15 kill-or-proceed conversation with new evidence.
Days 46–75 — Shadow and canary
The third phase is where the production architecture meets live traffic without yet owning any decisions. The bridge from lab to field is not a single event; it is a graded sequence with two named stages, shadow and canary, and every one of them is designed to catch a class of failure before the blast radius is customer-scale.
Shadow mode is the cheapest and most under-used stage in the sequence. The new system runs on live inputs, produces its outputs, and those outputs are logged rather than acted on. The existing non-AI baseline — the manual inspection, the rules-based control, the human operator — remains the source of truth for every decision that actually affects the physical world. The value of the stage is not the outputs themselves; it is the comparison between the new system's outputs and the baseline's decisions on the same live inputs. Every disagreement is a diagnostic signal that would not have surfaced in any lab benchmark. Shadow mode of two weeks against the actual operational tempo catches classes of failure — sensor calibration drift, edge cases the training set never sampled, adversarial inputs the environment produces without anyone designing them — that no bench test will ever surface.
Canary release is the second stage and it inherits its blast radius from the graduation-criteria document written on day 15. The first canary is small on purpose: one production line out of forty at a manufacturer, five charging sites out of two hundred at an operator, one truck out of a fleet at a mobility client. The AI system is now in the control loop, making decisions that affect the physical world, but the exposure is bounded and the rollback is automated. The rollback path itself is tested at least once inside the canary window — a deliberate trigger, a real revert, a measured recovery time — because a rollback path that has never been exercised is not a rollback path, it is a hopeful comment in a runbook.
The monitoring stack from the second phase is what makes both stages legible. Drift detectors on the input distribution, latency histograms at the ninety-ninth percentile, safe-state entry counts, mismatch counts against shadow, incident-response drills. Every metric has an alert threshold that was written into the graduation-criteria document at day 15 rather than tuned reactively during the canary. Tuning them reactively is how a canary becomes a fog of soft signals that never resolve into a promote-or-roll-back decision.
Day 75 closes with a written go/no-go review against the graduation criteria. Every threshold gets a green-amber-red rating with evidence from the canary. Amber and red do not automatically block the cutover; they force an explicit exception decision that both the executive sponsor and the engineering lead have to sign. The point is not to fetishise the criteria — it is to make the decision to ship despite an amber threshold a deliberate, documented act rather than an unnoticed drift. Every real-world cutover has at least one amber. The engagement is graded on how it handles them, not on whether they exist.
Days 76–90 — Cut over and own
The final phase is the smallest and the one where the most engagements underinvest. The cutover itself is one working day out of the fifteen. The other fourteen are the capability transfer, the incident-response rehearsal, and the operational documentation that the client team will actually read once we are gone.
The cutover schedule is boring by design. The rollout expands from canary to full traffic in a predetermined sequence — scoped on day 15, rehearsed in the canary phase — with an automated pause and a manual approval at each step. The point of staging is not caution for its own sake; it is to keep the blast radius of an undetected regression bounded to a fraction of the fleet at each step. Full expansion typically takes three to five working days, not because the automation is slow but because the drift detectors need time to accumulate signal against each expanded input distribution before the next step is safe.
Capability transfer is the deliverable of the phase, not the model. The client team has to own three things by day 90: the operational runbook, the incident playbook, and the change-management process for future model updates. The runbook is written by the client team with our support rather than by us in isolation — writing it is the mechanism by which the team learns the system. The incident playbook contains scripted responses for the first three production incidents we expect to see, based on the specific failure modes the canary surfaced and the classes of failure the audit flagged as residual risk. The change-management process names the reviewers, the promotion gates, and the rollback authority for every future OTA update, so that the team does not lose the discipline of the clock the moment we are no longer in the room.
At Achilles — the static analyser we build for AI-generated code — this phase pattern is the internal discipline we drill on our own systems. Every code path that reaches production is signed off by an owner, the incident playbook is drilled against a synthetic outage before the cutover, and the change-management review is the same lightweight two-person review the team will run in perpetuity. The output of the drill is a list of specific gaps in the runbook that get fixed before day 90, not a certificate that the drill was held.
The last three days are documentation completeness against a checklist that has been written from prior engagements. The technical documentation demanded by Annex IV is finalised as a produced artefact rather than as a pile of Markdown, the conformity assessment package is filed with the regulatory function, the audit-trail feed is confirmed to be piping to the compliance data warehouse, and the on-call rotation for the first month of production is staffed and named. The engagement closes with a written handover memo — one page, sponsor and engineering lead as signatories — that fixes what the client team owns, what the next thirty days of stabilisation look like, and where the escalation path runs if something surfaces after we are gone.
What kills the clock
The clock has a small number of failure modes that recur across engagements, and the mitigations are worth naming so a programme lead can pattern-match early. Procurement lead time on the target silicon is the most common — a Jetson family part with a fourteen-week lead time will consume the entire clock before any engineering is done. The mitigation is to place the silicon order in the discovery week preceding day 1, on the audit's likely target rather than the confirmed one, and to accept the small write-off risk as the price of the clock. "Let us add one more feature before we ship" is the second; the mitigation is the graduation-criteria document, which gives the programme lead a written basis for saying no without the conversation being read as risk aversion. "We are waiting for the perfect dataset" is the third; the mitigation is to size the day-15 audit around the dataset that exists, and to programme the OTA path so the perfect dataset can arrive in month four rather than block the month-three cutover.
All three failure modes have the same shape. The clock is not killed by one dramatic event; it is killed by a sequence of small reasonable-sounding delays that individually are hard to argue with and collectively are fatal. The 90-day tempo works because it makes those delays visible against a fixed reference. Take the reference away and they disappear again.
The clock is the discipline
The 90-day pilot-to-production clock is not a promise that every Physical AI system can ship in ninety days. Some cannot, and the audit at day 15 will surface them honestly. It is a promise that the ones that can will actually ship, and that the ones that cannot will be killed cheaply rather than allowed to consume a year of engineering while accumulating enough political weight to keep themselves alive against the evidence.
The engagement pattern that runs on this clock is what the Pilot-to-Production Program at Hyperion is designed around, and every artefact named above — the audit, the graduation criteria, the six workstream demos, the shadow and canary reviews, the handover memo — is a by-product of the work rather than a documentation project appended to it. The clock is the discipline. The artefacts are what it leaves behind. What the client team owns on day 91 is a production system, an incident playbook, and an operational tempo — not a proof of concept with a promising future and a permanent research budget.
The teams that finish the clock and then keep it running as their internal tempo for every subsequent Physical AI system are the ones that build the moat. The first system takes ninety days because the discipline is new. The second takes sixty because the artefacts are templates and the team knows the workstreams. By the third, the tempo is the culture, and the enterprise has quietly stopped being one of the seventy per cent whose AI pilots never reach production. That is the actual objective.
