Completeness is not capability alone
Nine dimensions stay visible.
- capability
- reliability
- authority
- evaluation
- operations
- service
- commercial
- evidence
- scale
Hyperion Physical AI Product System
One product lifecycle. Six inseparable decisions.
Five stages, five decision gates, six lenses at every one. Nothing advances automatically — not in robotics, autonomous systems or intelligent machines.
Five gates from strategy to scale.
- Strategy
- Discovery
- Productization
- Launch
- Scale
Five gates from strategy to scale.
Cyclical, not a waterfall: evidence, incidents or economics can send a product back to an earlier stage.
Stage 1 of 5: Strategy
The decision
Is this the right product opportunity, for the right customer, with a credible path to value?
The gate
Opportunity approved for evidence-building — or stopped before avoidable engineering expenditure.
Representative outputs
- Product strategy memorandum
- Strategic roadmap with a go, redirect, partner or stop recommendation
- Accountable owner
- Executive sponsor and accountable product leader.
- Evidence threshold
- Intended use, target customer, value thesis, system boundary, economic hypothesis and stop criteria are explicit enough to fund or reject discovery.
- Reversal condition
- Customer, feasibility, risk or economic evidence invalidates the opportunity or materially changes its intended use.
Stage 2 of 5: Discovery
The decision
Is there enough customer, field, technical and economic evidence to justify product investment?
The gate
Validated problem, credible product concept, acceptable feasibility and sufficient evidence to invest — or a clear decision not to proceed.
Representative outputs
- Discovery evidence report with stakeholder and workflow maps
- Experiment results and a development recommendation
- Accountable owner
- Accountable product leader, with customer, operations and engineering owners.
- Evidence threshold
- Direct customer, operator and field evidence closes the priority assumptions in the product, feasibility, risk and economic thesis.
- Reversal condition
- Field learning contradicts the problem or value thesis, or a newly exposed constraint changes the product boundary.
Stage 3 of 5: Productization
The decision
Can this become a complete, dependable, supportable and commercially viable product?
The gate
A product candidate that meets explicit customer, technical, operational, trust and economic acceptance criteria.
Representative outputs
- ConOps and product requirements
- Development and integration mission with evaluation, acceptance and human-oversight evidence
- Accountable owner
- Accountable product leader and system architecture or engineering authority.
- Evidence threshold
- An integrated product candidate meets named acceptance criteria across all six lenses under representative operating conditions.
- Reversal condition
- Evaluation, incidents, field behaviour or architecture constraints fail an acceptance criterion or invalidate a discovery assumption.
Stage 4 of 5: Launch
The decision
Can the product be sold, installed, accepted, supported and operated responsibly?
The gate
Controlled market or operational release with measurable acceptance and support readiness.
Representative outputs
- Deployment playbook and site-readiness checklist
- Acceptance criteria, training and support model
- Accountable owner
- Named launch owner, with product, operations, support and safety owners.
- Evidence threshold
- The controlled-release plan covers installation, acceptance, training, support, monitoring, incident response and rollback with named owners.
- Reversal condition
- Acceptance, support, safety or field evidence crosses a stop threshold and requires a pause, rollback or return to productization.
Stage 5 of 5: Scale
The decision
Can customer value, deployment and economics be repeated across sites, machines, customers and product variants?
The gate
Evidence that value, deployment, support and unit economics are repeatable enough to justify scale.
Representative outputs
- Product KPI tree and fleet/deployment dashboard
- Cost-to-serve model and repeatability strategy
- Accountable owner
- Accountable product or portfolio leader, with operations and economics owners.
- Evidence threshold
- Value, reliability, deployment, support and unit economics repeat across enough sites, machines, customers or variants for the stated expansion decision.
- Reversal condition
- Cost to serve, reliability, adoption or site variance makes the repeatability thesis false and reopens launch or productization decisions.
Product System operating vocabulary
Trace the promise all the way through operated life.
A dependable Physical AI product keeps customer need, product claims, architecture, configuration, evidence, release, field learning and retirement connected. Reliability and exposure define the bar before architecture selection—not after a promising demo.
These are typed records and decision instruments inside the existing five gates and six lenses. They do not create another lifecycle, absorb OPDG or replace specialist authority.
T01 / 18
Customer need
Whose outcome or operating problem justifies the product?
T02 / 18
Workflow
How is useful work performed before, during and after automation?
T03 / 18
Product promise
What bounded outcome is the complete product expected to deliver?
T04 / 18
Product claim
Which exact statement must the evidence be able to support?
T05 / 18
Requirement
What verifiable product or system condition follows from the claim?
T06 / 18
Model and architecture decision
Which learned, explicit and deterministic structure satisfies the requirement?
T07 / 18
Configuration baseline
Which exact hardware, software, model, data and site state is under review?
T08 / 18
Hazard, threat and obligation
Which specialist constraints can limit or stop the product decision?
T09 / 18
Verification
How is the requirement checked for the named configuration and envelope?
T10 / 18
Evidence
What was observed, where, under which authority and with which limitations?
T11 / 18
Release decision
Is this configuration ready for this use, envelope and commitment?
T12 / 18
Commercial commitment
What may sales, delivery and support promise—and under which conditions?
T13 / 18
Deployment
Which site, people, dependencies and acceptance state receive the release?
T14 / 18
Operating metric
Does the product sustain valuable duty, recovery and acceptable cost in use?
T15 / 18
Incident
Which observed failure or near miss changes the accepted basis?
T16 / 18
Corrective action
What containment, root-cause and corrective action follows?
T17 / 18
Revalidation
Which claims and commitments must be checked again after change?
T18 / 18
Retirement
How are use, data, support, components and obligations ended responsibly?
Decision instruments · one system
Make productization gaps explicit.
World models, robot policies, simulation and new hardware can change how evidence is produced. They do not change the obligation to prove a complete, recoverable and economically viable operated product.
I01
Reliability and Exposure Profile
Set the exposure unit, operating envelope, severity-specific tolerance and recovery bar before selecting an architecture.
I02
Product Completeness Matrix
Make gaps visible across capability, reliability, authority, evaluation, operations, service, commercial, evidence and scale.
I03
Technology Curve Decision
Compare early progress with the required product bar, expected ceiling, future cost, plateau risk and migration path.
I04
Innovation Assimilation Contract
Give an experiment an adoption owner, evidence gate, target configuration, retirement plan, rollback and failure-learning path.
I05
Capability and Complexity Delta
Assess performance gain together with deployment, evaluation, support and fragmentation cost.
I06
Structure and Validation Surfaces
State what is learned, explicit, deterministic, constrained, independently validated, human-owned or specialist-owned.
I07
Multi-timescale Authority
Separate hard-real-time reaction, near-real-time planning, slower reasoning and offline learning or generation.
I08
Agent–Simulator–Critic
Version the evaluator, disclose shared dependencies and common-mode risk, calibrate it and preserve human escalation.
I09
Authority-Matched Evidence
Do not use evidence collected under lower authority or stronger supervision to justify a higher-authority release silently.
I10
Sensing, Priors and Hardware Evolution
Test redundancy, degradation, stale priors, calibration, hardware generations, cost trajectory and family compatibility.
I11
Human–Machine Authority Map
Name what the system may observe, explain, recommend, propose or actuate—and who intervenes, recovers or stops it.
I12
Evidence Passport
Carry origin, denominator, configuration, envelope, authority, maturity, review, limits, expiry and correction history with every record.
I13
Integrated Product Release Case
Answer why this exact configuration, use and operating envelope is ready—or not ready—for this exact commitment.
Authority is evidence-bound
Six levels prevent silent escalation.
- offline
- observe
- explain
- recommend
- propose
- bounded actuation
Cross-cutting operating contract · HC-PBC-001
Business intent goes into the build. Technical evidence comes back out.
A two-way product operating contract that translates customer, business and portfolio intent into product, architecture and development decisions—and translates technical, delivery and field evidence back into scope, economics, investment and customer commitments.
This contract crosses all five stages; it is not a sixth stage, a substitute for specialist authority or a promise that every product should use the same delivery framework.
Customer and business → product and technology
A bounded product promise, product and system boundary, architecture choices, development mission and acceptance evidence.
Starts with: Customer outcome, buyer and operator workflow, intended use, economics, portfolio priority and constraints.
Product Bridge Brief: outcome, constraints, decisions, owners, evidence threshold and non-goals. The evidence no longer supports the promise, boundary, economics or priority.
Technology and delivery → product and business
A change to product scope, sequencing, investment, pricing, risk posture, customer commitment—or an explicit decision to continue unchanged.
Starts with: Feasibility, model and system behaviour, integration cost, reliability, delivery flow, assurance findings and technical debt.
Evidence-to-decision trace with alternatives, dissent, consequences and named authority. New technical evidence or a material implementation change alters the decision conditions.
Strategy and portfolio → product team
A team mission with one outcome, decision rights, milestone, integration dependencies and a fit-for-context way of working.
Starts with: Strategic themes, funding guardrails, product-family choices, capacity and the next consequential decision.
Mission charter and decision-rights map, not a feature allocation alone. Portfolio priorities, dependencies or available capacity materially change.
Operations and customers → product and portfolio
A product, platform, operating-model or portfolio decision with a revised evidence plan and accountable owner.
Starts with: Adoption, incidents, operator interventions, service load, site variance, product economics and customer feedback.
Field-learning review linked to the affected product claim and upstream decision. The operating envelope, installed-life economics or repeatability thesis changes.
Verified released bundle · HC-OPDG-001 v0.1.0
Preserve why a decision was made—and what must reopen it.
An executable decision system that keeps product commitments linked to their declared evidence, assumptions, dependencies, authority and review triggers.
It executes the Product System rather than introducing a competing lifecycle. Its output reports declared change impact; it does not approve a product or release. Structural coherence and declared change-impact report only; not a safety, legal, regulatory, technical, deployment, or commercial approval.
- INPUTEvidence or assumption changes
- GRAPHDependencies expose downstream impact
- REVIEWNamed owners reopen affected decisions
Verified released bundle · source licensing pending
- 5 stages × 8 decision surfaces × E0–E4 evidence
- Typed decision contracts, review triggers and reversibility
- Deterministic CLI/MCP checker in launchpad-os
- Configuration-bound Release Case remains separate
Software-defined target state
Decide how far the physical product should evolve.
Software-Defined Product Transformation aligns the product model, technical platform and operating model so a physical product can evolve safely through software across its life.
This is a target-state profile—not a maturity ladder. The responsible destination can be any state.
Fixed
Connected
Updateable
Platformed
Fleet-operated
AI-enabled / bounded-adaptive
Method record
Versioned, citable and bounded.
A useful operating method states where it comes from, what it cannot decide, and what changed.
What this system does not replace
- It does not replace qualified legal, conformity-assessment, safety, cybersecurity or certification advice.
- It does not make weak evidence strong: thresholds must be tailored to intended use, risk and the decision at hand.
- It does not promise progression or scale. A defensible stop, rollback or return to an earlier stage is a valid result.
Suggested citation
Cherifi, Mohammed. The Hyperion Physical AI Product System: a decision-engineering application for Physical AI. Version 1.1, Hyperion Consulting, 2026.
Change record
Version 1.1 preserves the five gates and six lenses and adds end-to-end traceability, productization instruments, authority-matched evidence, the Evidence Passport and the Integrated Product Release Case.
The six decision lenses
All six lenses apply at every decision gate. Their depth, evidence threshold and emphasis change with the decision.
Applied at every decision gate
- Strategy
- Discovery
- Productization
- Launch
- Scale
Customer and operator value
Who buys it, who operates it, and why the change is worth making.
Business model and product economics
How it earns, what delivery and support cost, and when that repeats.
AI, data, evaluation and human-machine interaction
What the intelligence must do, how it is proven, how people work with it.
Hardware, software and system architecture
The physical and digital parts that must hold together as one product.
Safety, cybersecurity, governance, compliance and human oversight
The boundaries, controls and human oversight that make it responsible to operate.
Deployment, operations, product family, partners and ecosystem
How it installs, runs, repeats across variants, and fits a wider ecosystem.
Where is your product?
An engagement starts by locating the product honestly, then naming the next decision.