qreservoir-mlops¶
An MLOps proof of concept on AWS for machine learning with a simulated quantum reservoir as the feature generator.
The platform runs repeatable customer-style engagements on time series data: governed batch and event-driven ingestion into per-engagement KMS-encrypted S3 buckets, versioned datasets, feature generation against a device with queues, calibration drift and outages, a benchmark harness that compares deep learning models with and without reservoir features and against classical baselines on equal terms, MLflow tracking, HTTPS serving with a classical fallback, monitoring that can be joined to device calibration events, cost instrumentation and customer data governance. Infrastructure is Terraform, applied by GitHub Actions with OIDC when the owner dispatches the workflow; Argo CD deploys to EKS.
Disclaimer
The quantum device here is a small numerical simulation of a textbook quantum reservoir (a transverse-field Ising model, after Fujii and Nakajima, 2017). It does not represent any company's hardware, and nothing here claims quantum advantage. Results are reported with confidence intervals and corrected tests, including where classical baselines win.
Author: Xi (Sean) Chen, chenxi840221@gmail.com. The repository is private. This site is built by the publish-site.yml workflow and served through CloudFront next to the published reports; only reports of public and synthetic engagements are ever published, and confidential reports never leave their engagement bucket.
Where to start¶
| If you want to | Read |
|---|---|
| Understand the goals, scope, phases and cost model | Plan |
| See how the AWS and application components fit, the data contracts, the customer data boundary and the CI identities | Architecture |
| Know why things are the way they are | Decisions, one ADR per decision |
| Run the platform day to day and know which switches only the owner holds | Operations |
| Fix something that is alerting | Runbooks |
| Check which capability is demonstrated by which code, test and artefact | Capabilities |
| Know what it costs and which guardrails keep it that way | Cost |
| Set up the AWS account and the GitHub repository once | AWS setup |
| See the ordered backlog with acceptance criteria | Tasks |
| Call the simulated device | The OpenAPI document api/qpu-sim.json, exported by make openapi |
The system in one paragraph¶
A simulated quantum processor (qpu-sim) runs on Amazon EKS with SQS FIFO queues per chip and a DynamoDB calibration and job store. Each chip is a small transverse-field Ising spin system used as a quantum reservoir, with calibration events, drift and outages. A Dagster pipeline ingests a customer's dataset into that customer's own KMS-encrypted S3 bucket, in batch or as event-driven micro-batches, validates and versions it, generates quantum features through a typed SDK with idempotent retries and provenance, trains deep learning models with and without those features alongside classical baselines under identical walk-forward splits and tuning budgets, tracks everything in MLflow, and produces a benchmark report with block-bootstrap intervals, corrected statistical tests and an accuracy-versus-training-cost frontier. Everything derived from a customer's data stays in that customer's bucket. The champion model is served over HTTPS behind a Terraform-managed load balancer, with a classical fallback when the device is unavailable. Prometheus, Grafana, Evidently, OpenCost and AWS Budgets cover latency, accuracy, drift, utilisation and cost, and calibration events are visible on the same dashboards.
How to read the results¶
- Every number in a report traces to an MLflow run: dataset version, git SHA, configuration, chip, calibration state and simulated device time.
- Intervals come from a moving-block bootstrap; comparisons use Diebold-Mariano tests with HAC variance, the Harvey-Leybourne-Newbold correction and a Holm correction across comparisons (ADR 0011).
- The headline comparison is the same deep learning model with and without reservoir features; an echo state network is the matched classical control (ADR 0013). A gain, a loss or no difference are all reportable outcomes.
- The device is simulated (ADR 0007). A handful of optional Amazon Braket runs in Phase 8 would be illustrative, not a benchmark.
Data and licences¶
energy-ett(public): the ETT Electricity Transformer Temperature dataset, fetched at run time with a pinned checksum, licence CC BY-ND 4.0. It is never committed or republished; public reports show metrics and residual plots only, never the series.telecom-synth(synthetic): seeded synthetic cell traffic with known ground truth, delivered in batch and as an event stream; it validates the harness and is the only data CI processes.finance-sparse(confidential, Phase 6): synthetic, labelled confidential on purpose to demonstrate the private path.
Status¶
Under construction. Progress is tracked in Tasks; criteria marked (cloud) are ticked only after the owner's runtime sessions. Pages on this site describe both what exists today and what a later task adds; where a page refers to something not yet built it names the task.