S3 Design Readiness Index¶
S3 starts as a no-QPU readiness gate for ML-augmented pulse and ansatz design. The current slice does not train a model and does not submit hardware jobs. It ranks deterministic candidate families so that later ML surrogate training has a validated artefact schema and a strict claim boundary.
Canonical command:
Generated artefacts:
data/s3_pulse_ansatz_design/s3_design_readiness_2026-05-06.jsondata/s3_pulse_ansatz_design/s3_design_readiness_2026-05-06.md
Current candidate families:
ansatz: Kuramoto-XY structured circuits scored by depth, size, and two-qubit gate proxy.pulse: hypergeometric Trotter-step pulse schedules scored by analytic infidelity and pulse-count proxy.
Allowed claims:
- Candidate rows are reproducible no-QPU design proxies.
- The artefact schema is ready for later ML surrogate training and held-out validation.
- No provider-specific pulse feasibility or hardware improvement has been established.
Forbidden claims:
- No learned optimiser has been demonstrated yet.
- No pulse-level hardware improvement is established without backend calibration data.
- No quantum advantage or backend-independent performance claim is permitted from this readiness gate.
Next S3 work:
- Add a held-out surrogate-training harness over generated candidate rows.
- Compare promoted ansatz candidates against VQE or observable targets.
- Add provider-specific pulse feasibility probes before any pulse-level submission.
- Attach hardware-job dossiers before QPU or pulse-level execution.
Surrogate rehearsal¶
The first no-QPU surrogate rehearsal is regenerated with:
It expands the deterministic candidate grid across several small system sizes, fits a closed-form ridge linear surrogate to proxy scores, and reports held-out and per-family metrics. This is deliberately a rehearsal over proxy scores, not evidence of a hardware pulse improvement or VQE improvement.
Ansatz observable validation¶
Promoted ansatz candidates are checked against exact no-QPU observables with:
The validation reports exact statevector energy expectation, exact dense ground energy, energy error, and a simple synchronisation proxy for the lowest-resource ansatz candidates. It is an observable sanity check, not VQE optimisation and not a hardware result.
Pulse feasibility probe¶
Provider metadata can be checked against the S3 hypergeometric pulse schedule without opening provider sessions:
The probe reports ready, blocked, manual-review, or unknown decisions from metadata only. It does not calibrate pulses, submit jobs, or establish hardware performance.
Hardware-job dossiers¶
Promoted S3 follow-up candidates are packaged for human review with:
The dossiers record purpose, hypothesis, falsification boundary, expected observables, budget state, platform fit, risks, decision tree, paper impact, follow-up avenues, prerequisites, and reproducibility artefacts. They do not authorise hardware execution.