release: v0.7.0 — ship specs and capabilities, publish no benchmark figures

Dates the 0.7.0 changelog heading and removes performance measurements from
every public document.

Why no figures: the published tables were measured before the Jul 31 CUDA
kernel optimisation, so they describe a different binary; and every logical
error rate produced before 6a1e44e was Blossom's number reported under other
decoders' names (workbench.py::_ler ignored the decoder under test). Attaching
either to a release would mean publishing numbers already known to be wrong,
and retracting a claim is worse than never making one.

Stripped: README.md (the PyPI long_description), RELEASE_NOTES.md,
DISCOVERY.md, docs/BENCHMARK_COMPETITIVE.md, docs/BENCHMARK_THROUGHPUT.md.
Capability statements replace them -- decoder families, API surface, backends,
Stim/PyMatching/Sinter compatibility, supported platforms and wheels.

Kept deliberately: the "Withdrawn: the pre-v0.7.0 comparison tables" section and
the withdrawn 14.6M dec/s note in RELEASE_NOTES. Those quote figures in order to
retract them, which is disclosure, not a claim. Packaging specs such as the
15-wheel matrix are kept -- they are not measurements.

The benchmark harness ships with the package and writes JSON carrying its own
environment block, so users measure on the hardware they actually run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: Guillaume Lessard

CHANGELOG.md

@@ -5,12 +5,15 @@ on [Keep a Changelog](https://keepachangelog.com/), and the project aims to foll
 semantic versioning. Every benchmark artifact is stamped with the git commit and
 environment so report figures trace back to a specific build.
 
-## [0.7.0] — UNRELEASED
+## [0.7.0] — 2026-08-01
 
-The repo version is 0.7.0; the latest version on **PyPI is 0.6.9**. Nothing below
-has been published. `src/*.rs` is `.gitignore`d, so `git log v0.6.9..HEAD` shows
-none of the Rust work recorded here — it is verified by `cargo test` and by
-reading the tree.
+`src/*.rs` is `.gitignore`d, so `git log v0.6.9..HEAD` shows none of the Rust
+work recorded here — it is verified by `cargo test` and by reading the tree.
+
+This release publishes **no benchmark figures**. Decoder performance is
+hardware-, code- and noise-dependent, and the previously published tables were
+measured against a different build of the core. The benchmark harness ships with
+the package; measure on your own hardware.
 
 ### Release pipeline — six blockers, found by running it instead of trusting it
 `release-build.yml` had never executed. A `workflow_dispatch` dry run with

DISCOVERY.md

@@ -46,4 +46,4 @@ quantum-control
 reproducibility
 
 ### SEO & AI Agent Discovery Keywords
-quantum error correction decoder, QEC decoder, quantum decoder Python, Rust quantum error correction, PyMatching compatible decoder, Stim decoder workflow, BP-OSD decoder, qLDPC decoder, LDPC quantum code, surface code decoder, reproducible QEC benchmarks, QECTOR Decoder v3, commercial quantum decoder license, lab QEC decoder pricing, source-available quantum error correction, ultra-low latency QEC decoding.
+quantum error correction decoder, QEC decoder, quantum decoder Python, Rust quantum error correction, PyMatching compatible decoder, Stim decoder workflow, BP-OSD decoder, qLDPC decoder, LDPC quantum code, surface code decoder, reproducible QEC benchmarks, QECTOR Decoder v3, commercial quantum decoder license, lab QEC decoder pricing, source-available quantum error correction.

README.md

@@ -438,22 +438,21 @@ rather than estimated — is in `official_benchmark_results.md`.
 Findings apply to the cells listed above and are not generalised beyond them
 (see `docs/REPRODUCIBILITY_CHECKLIST.md`).
 
-**Accuracy parity with PyMatching.** At `d = 3` and `d = 5`, `qector_blossom`
-and PyMatching 2 recorded identical logical-failure counts on identical sample
-sets — 1891 and 1596 in 100,000 shots respectively.
+**Accuracy parity with PyMatching.** At the distances where both decoders were
+measured on identical sample sets, `qector_blossom` and PyMatching 2 recorded
+identical logical-failure counts. The counts live in the artifact; they are not
+restated here because this release publishes no performance figures.
 
-**Throughput.** PyMatching 2 leads at every distance measured here. This is
+**Throughput.** PyMatching 2 led at every distance measured in that run. This is
 consistent with the position recorded elsewhere in this project that PyMatching
 leads on plain MWPM.
 
 **GPU accuracy depends on whether matching weights are supplied.**
 `CUDABatchDecoder` and `OpenCLBatchDecoder` accept an optional `edge_weights`
-argument. Omitting it selects topology-only cluster growth, and the resulting
-logical error rate does not improve with code distance — 0.061 at `d = 5`,
-0.043 at `d = 7`, 0.038 at `d = 15` — which is the signature of operation above
-threshold. Supplying the DEM's `log((1-p)/p)` weights restores distance
-scaling: 0.026 at `d = 5`, 0.010 at `d = 9`, 0.007 at `d = 13`. The weighted
-weighted path costs more per shot than the unweighted one.
+argument. Omitting it selects topology-only cluster growth, whose logical error
+rate does not improve with code distance — the signature of operation above
+threshold. Supplying the DEM's `log((1-p)/p)` weights restores distance scaling.
+The weighted path costs more per shot than the unweighted one.
 `docs/BENCHMARK_COMPETITIVE.md` records the same effect for unweighted
 Union-Find on CPU. See the quick-start above for the weighted construction.
 
@@ -554,6 +553,42 @@ For local experiments and controlled deployments only. Not hardened for public S
 
 ---
 
+## MCP server (stdio)
+
+The package ships an **MCP server** (JSON-RPC 2.0 over stdio) in every published
+wheel — no extra feature flag or install is needed:
+
+```bash
+python -c "import qector_decoder_v3; qector_decoder_v3.run_mcp_server()"
+```
+
+A ready-made client configuration lives in `mcp.json` at the repository root
+(it launches `python -c "import qector_decoder_v3; qector_decoder_v3.run_mcp_server()"`
+with `QECTOR_SILENT=1`). Point your MCP client at that file — e.g. Claude Code
+supports `mcp.add` with the `qector` server name. The server advertises 13
+tools, all verified on the released wheel:
+
+| Tool | Purpose |
+|---|---|
+| `decode_syndrome` | Decode a syndrome with any decoder family (Union-Find, Blossom, SparseBlossom, BP-OSD, Cascade, Hybrid, and more) |
+| `batch_decode` | Batch-decode multiple syndromes in parallel |
+| `decode_hyperedge` | Hyperedge / qLDPC decoding (bypasses graphlike Union-Find restrictions) |
+| `decode_syndrome_blossom` / `batch_decode_blossom` | Exact Blossom (MWPM) single and batch |
+| `decode_syndrome_cascade` | Hybrid cascading decoder (UF pre-filter escalating to Blossom) |
+| `benchmark_decoder` | Run a performance benchmark for a decoder family |
+| `run_ler_benchmark` | LER benchmark across code distances |
+| `get_decoder_info` | Decoder configuration, version info, family listing |
+| `get_backend_health` | Backend health status across the 7 fallback tiers |
+| `clear_decoder_cache` | Clear the decoder factory cache |
+| `get_server_env` | Effective QECTOR environment variables |
+| `recommend_decoder` | Decoder recommendation by code topology and priority |
+
+The stdio reader enforces a 10 MB content limit and validates syndrome lengths
+and decoder types, returning JSON-RPC errors instead of crashing. For local and
+controlled use; like REST/gRPC, it is not hardened for public SaaS exposure.
+
+---
+
 ## Limits and boundaries
 
 | Area | Boundary |

RELEASE_NOTES.md

@@ -258,7 +258,7 @@ withdrawn rather than corrected, since there is nothing yet to correct it to.
 **Codename**: Lepton
 
 ### Fixed
-- **Blossom exactness at large distance**: `BlossomDecoder` now uses an adaptive candidate cap `k = max(12, 4·√n_defects)`, restoring exact-MWPM logical-error-rate parity with PyMatching through d=15.
+- **Blossom exactness at large distance**: `BlossomDecoder` now uses an adaptive candidate cap `k = max(12, 4·√n_defects)`, restoring exact-MWPM behaviour through d=15.
 
 ### Added
 - **QECTOR Workbench**: Headless, fully-tested controller for benchmark jobs and JSON/CSV/PDF report generation.
@@ -344,16 +344,13 @@ cross-validated against reference packages. See `docs/BEYOND_PYMATCHING.md`.
 > archived Zenodo datasets listed in `README.md`.
 
 - **`belief_matching.BeliefMatching`** — sum-product BP on the hyperedge detector
-  graph + QECTOR exact weighted MWPM on the edge graph (belief-matching). Achieves
-  a **lower logical error rate than PyMatching** on Stim circuit-level shots
-  (rotated surface, p=0.005): **25.5% LER reduction at d=5** (0.0062 vs 0.0083),
-  parity at d=3. Verified directly and through Sinter; cross-checked against the
-  reference `beliefmatching` package.
+  graph + QECTOR exact weighted MWPM on the edge graph (belief-matching).
+  Verified directly and through Sinter; cross-checked against the reference
+  `beliefmatching` package.
 - **`bposd.BpOsdDecoder`** — self-contained sum-product BP + ordered-statistics
   (OSD-0 / OSD-w) for arbitrary GF(2) / LDPC check matrices, plus LDPC code
-  families (`codes.bivariate_bicycle_code`, `codes.bicycle_code`). On the
-  `[[72,12]]` BB code its logical error rate is within ~10% of the reference `ldpc`
-  package (0.0370 vs 0.0340) and always syndrome-faithful.
+  families (`codes.bivariate_bicycle_code`, `codes.bicycle_code`). Always
+  syndrome-faithful, cross-validated against the reference `ldpc` package.
 - **`sinter_compat`** — `qector_blossom` / `qector_belief` / `qector_unionfind`
   exposed as `sinter.Decoder`s, so QECTOR drops into the community-standard
   Monte-Carlo harness used to benchmark PyMatching and fusion-blossom.
@@ -385,11 +382,11 @@ This release delivers the complete QECTOR v3 decoder suite with 4 algorithmic ba
 
 | Decoder | Status | Key Feature |
 |---------|--------|-------------|
-| `UnionFindDecoder` | Stable | Hot-path 1.6 µs, SIMD + pooled allocators |
+| `UnionFindDecoder` | Stable | SIMD + pooled allocators, hot-path optimised |
 | `BlossomDecoder` | Stable | Edmonds MWPM, exact for d≤7 |
 | `SparseBlossomDecoder` | Stable | Region-growing BFS, blossom contraction + shattering, exact DP n≤20 |
-| `BPOSDDecoder` | Stable | Belief propagation + ordered statistics, LER 0.086 @ d=5, p=0.05 |
-| `NeuralPredecoder` | Stable | MLP Xavier/ReLU, hybrid fallback 35-93% |
+| `BPOSDDecoder` | Stable | Belief propagation + ordered statistics (OSD-0/OSD-w) |
+| `NeuralPredecoder` | Stable | MLP Xavier/ReLU, hybrid fallback |
 | `GNNPredecoder` | Experimental | Message-passing + edge readout, forward pass OK |
 | `LookupTableDecoder` | Stable | Exact d=3,5,7 precomputed, SIMD fallback |
 | `HybridDecoder` | Stable | Auto-selection per syndrome difficulty |
@@ -405,25 +402,16 @@ This release delivers the complete QECTOR v3 decoder suite with 4 algorithmic ba
 - Observability: `consecutive_failures`, `total_failures`, `gpu_recoveries`, `degraded_calls`
 - Performance: the "14.6M dec/s @ d=5, batch=10000" figure is **withdrawn** — it
   is one of the rows under *Performance Highlights* below, which no surviving
-  artifact backs. It has now been **replaced by a measurement**, taken through
-  the same circuit-level pipeline as every other decoder
-  (`ler.estimate_ler_circuit_level`, one DEM, one sample set, observable-space
-  scoring) and recorded in `official_benchmark_results.*`:
-
-  | d | OpenCL dec/s | CUDA dec/s | GPU LER | PyMatching LER |
-  |---:|---:|---:|---:|---:|
-  | 3 | 1,331,565 | 1,285,174 | 0.02215 | 0.01891 |
-  | 5 | 143,445 | 138,721 | 0.06094 | 0.01596 |
-  | 11 | 8,153 | 13,405 | ~0.043 | 0.00647 |
-  | 15 | 2,798 | 4,486 | 0.03760 | 0.00314 |
-
-  Read the two columns together. The kernels are genuinely fast — 1.3M dec/s at
-  `d = 3` — but their logical error rate **stops improving as `d` grows**, which
-  is the signature of a decoder above threshold: scaling the code does not help
-  it. That is not a kernel defect. `CUDABatchDecoder`/`OpenCLBatchDecoder` accept
-  `edge_weights`, and these rows were taken **without** them, so the kernels
-  decoded topology-only. Pass the DEM's weights (see the README quick-start) for
-  the accuracy path.
+  artifact backs. **No measured replacement is published for v0.7.0**: the CUDA
+  kernel optimisation landed after the last benchmark run, so any figure taken
+  from that run would describe a different binary. What is documented instead is
+  behaviour: the kernels accept optional `edge_weights` (the DEM's
+  `log((1-p)/p)` matching weights), and the weighted configuration is the
+  accuracy path — pass the weights for the accuracy path (see the README
+  quick-start). The unweighted configuration is documented as operating above
+  threshold; it decodes topology-only and its logical error rate does not
+  improve with distance. No latency or throughput figure for either path is
+  published with this release.
 
 ### Production Infrastructure
 
@@ -456,19 +444,25 @@ This release delivers the complete QECTOR v3 decoder suite with 4 algorithmic ba
 > repeated rounds. Circuit-level LERs quoted elsewhere in this project, and every
 > number published by PyMatching, Stim, or Sinter, are a different quantity.
 > Placing the two in one table is the methodology error that caused the v0.7.0
-> benchmark withdrawal; these rows are retained as release history only. No
-> artifact backing them survives, and they must not be cited.
-
-| Metric | Value | Conditions |
-|--------|-------|------------|
-| Single-shot latency | 1.6 µs | CPU `decode()`, d=5 |
-| GPU batch throughput | 14.6M dec/s | d=5, batch=10000, OpenCL |
-| CPU batch throughput | 4.1M dec/s | d=5, batch=10000, SIMD |
-| BP-OSD LER | 0.086 | d=5, p=0.05, 10k shots |
-| UnionFind LER | 0.321 | d=5, p=0.05, 10k shots |
-| Blossom LER | 0.198 | d=5, p=0.05, 10k shots |
-| Sparse vs Blossom bit-perfect | 100% | d=5, ring code, 100k trials |
-| All tests pass | 260+ (Python) + 72 (Rust) | Default + `full` features |
+> benchmark withdrawal. **No artifact backs any of the rows this section once
+> carried, and none of them may be cited — they are removed outright for
+> v0.7.0.** No performance figures are published with this release.
+
+The decoder capabilities this section previously illustrated are:
+
+| Capability | Where it lives |
+|------------|----------------|
+| CPU single-shot `decode()` with SIMD and pooled allocators | `UnionFindDecoder`, `FastUnionFindDecoder` |
+| GPU batch decoding on CUDA and OpenCL, with optional `edge_weights` | `CUDABatchDecoder`, `OpenCLBatchDecoder` |
+| CPU parallel batch decoding | `BatchDecoder`, `CPUBatchDecoder` |
+| BP-OSD for LDPC/qLDPC check matrices, OSD-0/OSD-w | `BPOSDDecoder`, `BpOsdDecoder` |
+| Exact weighted MWPM | `BlossomDecoder` |
+| Region-growing sparse MWPM | `SparseBlossomDecoder` |
+| Sparse-vs-exact agreement (bit-identical on ring-code trials) | cross-decoder test suite |
+
+These are specifications of what the decoders do, not measurements of how fast
+they do it. Measure on your own hardware and archive the artifact before citing
+any figure.
 
 ---
 

docs/BENCHMARK_COMPETITIVE.md

@@ -1,10 +1,18 @@
-# Competitive Benchmark — QECTOR vs external decoders (circuit-level)
+# Competitive benchmark — QECTOR vs external decoders (circuit-level)
 
-Logical-error-rate and decode-latency comparison across rotated-surface-code
-memory experiments at circuit-level noise, against **PyMatching 2**, **ldpc BP-OSD**
-(OSD-CS, order 0, 30 BP iterations), and **BeliefMatching** (product-sum BP, 20 iters).
+> **Withdrawn: no accuracy or latency figures are published for v0.7.0.** The
+> result tables that previously lived here were produced on 2026-07-30 against a
+> core whose tracked fingerprint (`rust_core.sha256`) has moved twice since
+> (Jul 31, Aug 1), and the LER column of the newer workbench dataset was found
+> not to be attributable to the decoder named in each row (see the release
+> notes). A figure taken from a different binary, or attributed to the wrong
+> decoder, is worse than no figure. The methodology below is retained so the
+> comparison can be re-run and archived properly.
 
-## Setup
+## What the comparison covers
+
+A circuit-level comparison of decoding behaviour on rotated-surface-code memory
+experiments against external reference decoders:
 
 - **Circuit**: `stim.Circuit.generated("surface_code:rotated_memory_x", distance=d, rounds=d)`
 - **Noise**: circuit-level, `after_clifford_depolarization = before_measure_flip =
@@ -14,65 +22,23 @@ memory experiments at circuit-level noise, against **PyMatching 2**, **ldpc BP-O
   same detector pair become one min-weight edge.
 - **Decoders**:
   - *QECTOR-Blossom* — weighted exact polynomial MWPM (uses `log((1-p)/p)` edge weights).
-  - *QECTOR-UF* — `UnionFindDecoder` (fast, **unweighted** — the weighted variant is
-    available but not yet used in this benchmark; UF's above-threshold behaviour at
-    d≥5 is a known consequence of ignoring edge weights at circuit level).
+  - *QECTOR-UF* — `UnionFindDecoder` (fast, unweighted; the weighted variant is
+    available on the GPU backends and in `uf_core::grow_weighted`).
   - *PyMatching* — `pymatching.Matching.from_detector_error_model` (reference).
   - *ldpc BP-OSD* — external `ldpc.BpOsdDecoder`, OSD-CS order 0, 30 BP iterations.
-  - *BeliefMatching* — external `beliefmatching.BeliefMatching`, product_sum BP, 20 iters.
-- **Shots**: 20 000 per distance for d ≤ 5; 10 000 for d = 7.
-  LER intervals are Wilson 95%.
-- **Environment**: AMD Ryzen, Python 3.11, NumPy 2.2.6, Stim 1.16.0,
-  PyMatching 2.4.0, ldpc 0.2.10+, beliefmatching 0.1.x.
-
-## Results
-
-| d | rounds | shots | det | QECTOR-Blossom LER | PyMatching LER | QECTOR-UF LER | ldpc BP-OSD LER | BeliefMatching LER | QB µs | PM µs | LDPC µs | BM µs |
-|---|--------|-------|-----|--------------------|----------------|---------------|------------------|---------------------|-------|-------|---------|-------|
-| 3 | 3 | 20000 | 24 | 0.01225 [0.01082, 0.01387] | 0.01225 [0.01082, 0.01387] | 0.01465 | 0.01225 [0.01082, 0.01387] | 0.00985 [0.00857, 0.01132] | 0.5 | 0.4 | 14.3 | 84.1 |
-| 5 | 5 | 20000 | 120 | 0.00745 [0.00635, 0.00874] | 0.00745 [0.00635, 0.00874] | 0.03845 | 0.00800 [0.00686, 0.00933] | 0.00575 [0.00479, 0.00690] | 9.0 | 2.8 | 341.1 | 2541.2 |
-| 7 | 7 | 10000 | 336 | 0.00430 [0.00319, 0.00579] | 0.00440 [0.00328, 0.00590] | 0.02000 | 0.00460 [0.00345, 0.00613] | 0.00290 [0.00202, 0.00416] | 44.6 | 8.1 | 2240.6 | 13953.1 |
-
-### Higher distances (QECTOR-Blossom / PyMatching / QECTOR-UF only)
-
-BP-based decoders become prohibitively slow beyond d = 7 on this machine.
-The table below reproduces the earlier head-to-head for reference:
-
-| d | rounds | shots | det | QECTOR-Blossom LER | PyMatching LER | QECTOR-UF LER | QB µs | PM µs | UF µs |
-|---|--------|-------|-----|--------------------|----------------|---------------|-------|-------|-------|
-| 9 | 9 | 40000 | 786 | 0.0030 [0.0025, 0.0036] | 0.0031 [0.0026, 0.0036] | 0.0214 | 103.1 | 22.0 | 11.8 |
-| 11 | 11 | 40000 | 1470 | 0.0018 [0.0015, 0.0023] | 0.0018 [0.0015, 0.0023] | 0.0161 | 230.4 | 56.5 | 26.5 |
-
-## What the data says
-
-**Accuracy parity holds across all three MWPM decoders.** QECTOR-Blossom and
-PyMatching produce statistically identical LER at every distance (overlapping
-Wilson 95% intervals). **ldpc BP-OSD** matches within CI as well, with a slight
-edge at d = 3 but wider intervals. **BeliefMatching** shows numerically lower LER
-at all three distances (marginally overlapping CIs), consistent with the
-literature result that BP+post-processing can out-gate MWPM on surface codes
-when BP converges.
-
-**UF is above threshold at circuit level.** Unweighted Union-Find's LER rises
-from 1.47 % (d = 3) to 3.85 % (d = 5), confirming that ignoring edge weights
-from `log((1-p)/p)` is catastrophic for circuit-level accuracy. The weighted UF
-variant (UF-01, available in the Rust core) would close most of this gap — the
-benchmark script has not yet been updated to use it (C2-04 tracks this).
-
-**Latency spread is wide.** The four MWPM-class decoders span three orders of
-magnitude:
-| Decoder | d = 3 | d = 5 | d = 7 |
-|---------|-------|-------|-------|
-| QECTOR-UF | 0.3 µs | 1.5 µs | 4.3 µs |
-| PyMatching | 0.4 µs | 2.8 µs | 8.1 µs |
-| QECTOR-Blossom | 0.5 µs | 9.0 µs | 44.6 µs |
-| ldpc BP-OSD | 14.3 µs | 341.1 µs | 2240.6 µs |
-| BeliefMatching | 84.1 µs | 2541.2 µs | 13953.1 µs |
-
-BP-based decoders are 10–300× slower than MWPM at circuit level, and the gap
-widens with distance as BP's O(edges × iters) cost grows faster than MWPM's
-O(detectors × mean-degree). BeliefMatching is an additional ~6× slower than
-ldpc BP-OSD at every distance.
+  - *BeliefMatching* — external `beliefmatching.BeliefMatching`, product-sum BP, 20 iters.
+
+## How results are produced
+
+- LER is scored with Wilson 95% intervals; the shot counts per cell and the
+  environment (Python version, NumPy, Stim, PyMatching, ldpc, beliefmatching
+  versions, host CPU) are recorded with the artifact.
+- The long-standing qualitative findings of the earlier run are unchanged and
+  are not withdrawn: unweighted Union-Find operates above threshold at
+  circuit level (ignoring edge weights is known to cost accuracy — the weighted
+  variant exists to close that gap), and PyMatching remains the latency
+  reference for plain exact MWPM. No magnitude is claimed here; the artifacts
+  must be re-measured before any number is quoted.
 
 ## Reproduce