Technology Readiness and Stage-Gate Governance

Quantum programs fail when they move from research enthusiasm to production language without an intermediate discipline. A useful program does not ask whether a workload is “quantum” in the abstract. It asks whether the workload has reached the next operating gate: simulated, emulated, hardware-demonstrated, reproducible, costed, governed, and supportable.

NASA systems engineering material treats life-cycle reviews and decision gates as mechanisms for managing baselines, technical maturity, and stakeholder commitments [R197]. GAO’s Technology Readiness Assessment guide gives a complementary way to evaluate maturity before committing acquisition, scale, or deployment resources [R198]. Quantum platforms need both: a technical readiness view and an operating readiness view.

flowchart LR
    Idea[Problem idea] --> Concept[Concept review]
    Concept --> Sim[Simulation readiness]
    Sim --> Emu[Emulation readiness]
    Emu --> HW[Hardware evidence readiness]
    HW --> Prod[Production candidate]
    Prod --> Scale[Scaled service]
    Scale --> Retire[Retirement review]

Why stage gates matter

A quantum experiment can look successful while still being impossible to operate. It may depend on a single researcher’s notebook, a transient calibration window, an undocumented compiler seed, or a queue slot obtained through a special arrangement. Stage gates prevent this from being mistaken for product readiness.

flowchart TB
    Demo[Promising demo] --> Hidden1[Undocumented assumptions]
    Demo --> Hidden2[Unstable calibration dependency]
    Demo --> Hidden3[Unbounded shot cost]
    Demo --> Hidden4[No reproducibility packet]
    Hidden1 --> Gate[Readiness gate]
    Hidden2 --> Gate
    Hidden3 --> Gate
    Hidden4 --> Gate
    Gate --> Decision{Advance?}
    Decision -- yes --> Next[Next maturity level]
    Decision -- no --> Remediate[Remediation backlog]

The gate should be hostile to vague claims and friendly to evidence. Its job is not to slow the team down. Its job is to make the next investment credible.

Dual maturity: technology and operations

Technology readiness and operations readiness are different. A circuit family may be theoretically promising but operationally immature. A platform may be operationally strong but not yet capable of supporting the algorithmic depth required by the workload.

flowchart LR
    Workload[Workload candidate] --> TRL[Technology readiness]
    Workload --> ORL[Operations readiness]
    TRL --> Board[Readiness board]
    ORL --> Board
    Board --> Decision{Decision}
    Decision --> Advance[Advance]
    Decision --> Hold[Hold]
    Decision --> Kill[Kill]
    Decision --> Pivot[Pivot architecture]

A useful gate records both scores:

Gate taxonomy

A quantum program needs small gates, not ceremonial reviews. The most useful gates are tied to irreversible commitments: more hardware access, a public claim, a customer-facing milestone, or a platform expansion.

stateDiagram-v2
    [*] --> Intake
    Intake --> SimGate: simulation plan accepted
    SimGate --> HardwareGate: evidence passes
    HardwareGate --> ClaimGate: reproducible hardware run
    ClaimGate --> ServiceGate: bounded service contract
    ServiceGate --> ScaleGate: demand and reliability proven
    ScaleGate --> RetireGate: value exhausted or replaced
    RetireGate --> [*]

Each gate should have entry criteria, evidence required, reviewers, decision options, expiry date, and rollback condition.

Readiness packet

The packet is the unit of review. It should be complete enough that a skeptical reviewer can reconstruct the decision without attending the meeting.

flowchart TB
    Packet[Readiness packet] --> Problem[Problem statement]
    Packet --> Baseline[Classical baseline]
    Packet --> Circuit[Circuit or model family]
    Packet --> Target[Target assumptions]
    Packet --> Evidence[Evidence bundle]
    Packet --> Risk[Risk register]
    Packet --> Cost[Cost model]
    Packet --> Ops[Runbook delta]
    Packet --> Decision[Requested decision]

A packet that says “results look promising” is not a packet. A packet that says “for workload family A, under target profile B, with mitigation policy C, we observe distribution D with confidence interval E and cost F” is reviewable.

Review board design

The review board should be small and role-based. It should not be a committee for general interest.

flowchart LR
    Submitter[Submitter] --> Board[Readiness board]
    Physicist[Hardware or physics reviewer] --> Board
    Compiler[Compiler/runtime reviewer] --> Board
    Data[Evidence reviewer] --> Board
    Security[Governance reviewer] --> Board
    Product[Product owner] --> Board
    Board --> Record[Decision record]

The board can approve, approve with constraints, defer, redirect, or retire. Every decision should produce a decision record and a follow-up owner.

Expiring approvals

Quantum approvals should expire. Hardware calibration policies change, compilers change, SDKs change, queue behavior changes, and evidence standards improve. A gate passed in January may not justify a claim in July.

flowchart LR
    Approval[Approval] --> Timer[Expiry timer]
    Timer --> Drift{Material drift?}
    Drift -- no --> Renew[Lightweight renewal]
    Drift -- yes --> ReReview[Full re-review]
    ReReview --> NewDecision[New decision record]

Expiration is not bureaucracy. It is the mechanism that keeps past success from becoming current mythology.

Practical rule

No workload advances unless it can name its current maturity level, next gate, evidence gap, and kill condition. That one rule prevents the most common quantum program failure: a portfolio of demos with no path to operation.