Quantum Platform Readiness Assessment — Operating Quantum Computers

This appendix provides a practical assessment rubric for a team building, buying, or operating a quantum platform.

J.1 Assessment model

Diagram loads as you read

J.1 Assessment model · Figure 1

View diagram source

flowchart TB
    Readiness[Platform readiness] --> Strategy[Strategy]
    Readiness --> Hardware[Hardware and access]
    Readiness --> Runtime[Runtime and tooling]
    Readiness --> Operations[Operations]
    Readiness --> Evidence[Evidence and science]
    Readiness --> Governance[Governance]
    Readiness --> People[People and culture]

Score each domain from 0 to 5.

Score	Meaning
0	absent
1	ad hoc
2	repeatable for experts
3	governed internal capability
4	productized platform
5	continuously optimized operating system

J.2 Strategy domain

Illustrative listing · yaml

strategy_assessment:
  questions:
    - Is the investment thesis explicit?
    - Are use cases separated from capability-building work?
    - Are kill criteria written before funding gates?
    - Are PQC risk and compute opportunity governed separately?
    - Is there a roadmap assumption registry?

Diagram loads as you read

J.2 Strategy domain · Figure 2

View diagram source

flowchart LR
    Strategy[Strategy] --> Thesis[Thesis]
    Strategy --> Portfolio[Portfolio]
    Strategy --> Gates[Stage gates]
    Strategy --> Assumptions[Assumption registry]

J.3 Hardware and access domain

Question	Evidence
Are target capabilities versioned?	target snapshots
Is calibration freshness visible?	calibration telemetry
Are reservations or sessions governed?	scheduler records
Are backend failures classified?	incident records
Are modality tradeoffs documented?	architecture decision records

Diagram loads as you read

J.3 Hardware and access domain · Figure 3

View diagram source

flowchart TB
    Hardware[Hardware readiness] --> Capabilities[Versioned capabilities]
    Hardware --> Calibration[Calibration freshness]
    Hardware --> Access[Access model]
    Hardware --> Incidents[Incident taxonomy]

J.4 Runtime and tooling domain

Illustrative listing · yaml

runtime_assessment:
  evidence_required:
    - runtime contract schema
    - compiler versioning
    - target profile compatibility checks
    - simulator preflight path
    - structured refusal codes
    - result uncertainty schema

Diagram loads as you read

J.4 Runtime and tooling domain · Figure 4

View diagram source

flowchart LR
    Runtime[Runtime readiness] --> Contract[Contracts]
    Runtime --> Compiler[Compiler versioning]
    Runtime --> Preflight[Preflight]
    Runtime --> Refusal[Refusal codes]
    Runtime --> Results[Uncertainty schema]

J.5 Operations domain

Diagram loads as you read

J.5 Operations domain · Figure 5

View diagram source

flowchart TB
    Ops[Operations readiness] --> SLO[SLOs]
    Ops --> Runbooks[Runbooks]
    Ops --> Oncall[On-call]
    Ops --> Telemetry[Telemetry]
    Ops --> Capacity[Capacity planning]
    Ops --> Cost[Cost engineering]

Minimum evidence:

SLO catalog
incident runbooks
QPU utilization report
cost per useful result
calibration and drift dashboards
postmortem examples

J.6 Evidence and science domain

Capability	Low maturity	High maturity
baselines	chosen after results	pre-registered
uncertainty	informal	machine-readable
raw artifacts	partial	retained and hash-addressed
mitigation	hidden defaults	explicit and validated
review	individual judgment	independent review process

Diagram loads as you read

J.6 Evidence and science domain · Figure 6

View diagram source

flowchart LR
    Evidence[Evidence readiness] --> Baseline[Baselines]
    Evidence --> Uncertainty[Uncertainty]
    Evidence --> Artifacts[Artifacts]
    Evidence --> Mitigation[Mitigation disclosure]
    Evidence --> Review[Independent review]

J.7 Governance domain

Illustrative listing · yaml

governance_assessment:
  controls:
    - IAM and tenant isolation
    - export-control review where relevant
    - PQC migration governance
    - vendor acceptance tests
    - data retention policy
    - claim labeling policy
    - AI/autonomous-control guardrails

Diagram loads as you read

J.7 Governance domain · Figure 7

View diagram source

flowchart TB
    Governance[Governance readiness] --> IAM[IAM]
    Governance --> Export[Export review]
    Governance --> PQC[PQC migration]
    Governance --> Vendor[Vendor tests]
    Governance --> Claims[Claim labels]
    Governance --> AI[AI guardrails]

J.8 People and culture domain

Diagram loads as you read

J.8 People and culture domain · Figure 8

View diagram source

flowchart LR
    People[People readiness] --> Physics[Physics literacy]
    People --> Systems[Systems engineering]
    People --> Statistics[Statistics]
    People --> Security[Security]
    People --> Product[Product management]
    People --> Review[Review culture]

A platform team is ready when it can reject weak claims without killing curiosity.

J.9 Summary scorecard

Illustrative listing · yaml

readiness_scorecard:
  strategy: 0-5
  hardware_and_access: 0-5
  runtime_and_tooling: 0-5
  operations: 0-5
  evidence_and_science: 0-5
  governance: 0-5
  people_and_culture: 0-5
  overall_stage:
    0-7: exploratory
    8-14: ad_hoc
    15-24: repeatable
    25-31: governed
    32-35: productized

Diagram loads as you read

J.9 Summary scorecard · Figure 9

View diagram source

radar-beta
    axis Strategy
    axis Hardware
    axis Runtime
    axis Operations
    axis Evidence
    axis Governance
    axis People
    curve Current{2,2,2,1,2,1,2}
    curve Target{4,4,4,4,4,4,4}

If a Markdown renderer does not support Mermaid radar charts, replace the final diagram with a table or bar chart.