Quantum Platform Program: First 180 Days — Operating Quantum Computers

A quantum platform program can spend years in exploratory mode if it never defines operating milestones. The first 180 days should establish discipline, not final answers. The goal is to create a small number of reliable loops: intake, execution, evidence, review, cost visibility, and retirement.

Diagram loads as you read

Quantum Platform Program: First 180 Days · Figure 1

View diagram source

flowchart LR
    Day0[Day 0] --> D30[Days 1-30: baseline]
    D30 --> D60[Days 31-60: controlled workflows]
    D60 --> D90[Days 61-90: evidence discipline]
    D90 --> D120[Days 91-120: service contracts]
    D120 --> D150[Days 121-150: resilience and governance]
    D150 --> D180[Days 151-180: scale or kill decisions]

Days 1–30: baseline the reality

Inventory current work, tools, vendors, experiments, scripts, datasets, secrets, costs, and decision owners. Do not begin by standardizing everything. Begin by making the current state visible.

Diagram loads as you read

Days 1–30: baseline the reality · Figure 2

View diagram source

flowchart TB
    Inventory[Inventory] --> Workloads[Workloads]
    Inventory --> Tools[Tools]
    Inventory --> Vendors[Vendors]
    Inventory --> Data[Data]
    Inventory --> Costs[Costs]
    Inventory --> Risks[Risks]

Deliverables:

workload inventory
provider inventory
experiment artifact map
risk register
current spend baseline
first evidence schema draft

Days 31–60: control the inner loop

Diagram loads as you read

Days 31–60: control the inner loop · Figure 3

View diagram source

sequenceDiagram
    participant User as User
    participant Intake as Intake
    participant Broker as Broker
    participant Target as Target
    participant Evidence as Evidence
    User->>Intake: submit workload request
    Intake->>Broker: approved experiment contract
    Broker->>Target: execute
    Target-->>Broker: result and telemetry
    Broker->>Evidence: persist artifacts
    Evidence-->>User: review package

Build a minimal approved workflow for a small set of workloads. Require tagging, provenance, and cost capture. Stop accepting anonymous experiments.

Days 61–90: make evidence non-optional

Diagram loads as you read

Days 61–90: make evidence non-optional · Figure 4

View diagram source

flowchart LR
    Run[Run] --> Manifest[Manifest]
    Manifest --> Calibration[Calibration snapshot]
    Manifest --> Compiler[Compiler profile]
    Manifest --> Runtime[Runtime settings]
    Manifest --> Result[Result distribution]
    Manifest --> Review[Reviewer notes]

At this point, every meaningful run should have a manifest. Evidence discipline is the most important early habit because it makes later optimization and governance possible.

Days 91–120: publish service contracts

Define a few service classes. Do not offer an open-ended “quantum platform.” Offer scoped services.

Service class	Example promise
simulation sandbox	fast iteration with no hardware claim
managed QPU experiment	governed access to approved targets
benchmark run	controlled benchmark with evidence package
resource estimate	reproducible estimate with assumptions recorded
claim review	independent review of proposed external statement

Diagram loads as you read

Days 91–120: publish service contracts · Figure 5

View diagram source

flowchart TB
    Catalog[Service catalog] --> Sandbox[Simulation sandbox]
    Catalog --> Managed[Managed QPU experiment]
    Catalog --> Benchmark[Benchmark run]
    Catalog --> Estimate[Resource estimate]
    Catalog --> Claim[Claim review]

Days 121–150: exercise and govern

Run the first tabletop and one controlled game day. Use NIST-style test, training, and exercise structure as a baseline for rehearsal and after-action improvement [R193].

Diagram loads as you read

Days 121–150: exercise and govern · Figure 6

View diagram source

flowchart LR
    Tabletop[Tabletop] --> GameDay[Game day]
    GameDay --> Findings[Findings]
    Findings --> Remediation[Remediation backlog]
    Remediation --> Retest[Retest]

Days 151–180: scale or kill

By day 180, the program should decide which workloads to scale, hold, or retire.

Diagram loads as you read

Days 151–180: scale or kill · Figure 7

View diagram source

quadrantChart
    title 180-Day Quantum Portfolio Decision
    x-axis Weak evidence --> Strong evidence
    y-axis Low value --> High value
    quadrant-1 Scale
    quadrant-2 Investigate
    quadrant-3 Retire
    quadrant-4 Harden
    Workload A: [0.80, 0.82]
    Workload B: [0.42, 0.74]
    Workload C: [0.28, 0.20]
    Workload D: [0.76, 0.38]

180-day exit criteria

The program is healthier if it can say no. A failed workload with complete evidence is a useful outcome. A successful-looking demo without evidence is debt.

Diagram loads as you read

180-day exit criteria · Figure 8

View diagram source

flowchart LR
    Evidence[Evidence] --> Decision{Decision}
    Decision --> Scale[Scale]
    Decision --> Hold[Hold]
    Decision --> Retire[Retire]
    Decision --> Reframe[Reframe]

Chapter close

The first 180 days should produce operating habits: scoped intake, controlled execution, evidence, cost attribution, service contracts, exercises, and kill criteria. That is enough to prevent chaos and enough to support serious scaling.