Measuring Error Propagation on Google Willow: Detecting the "Butterfly Velocity" of Quantum Errors

Published at getqore.ai/blog/otoc-error-propagation

TL;DR: Using temporal-spatial correlation analysis on Google Willow's d=7 surface code data, we detected 19 error propagation patterns traveling at 2.94 grid units/shot and discovered that hot spots can indicate physics (error convergence) rather than hardware defects.

Key Results at a Glance

✅ Error Propagation Patterns: 19 detected ✅ Butterfly Velocity: 2.94 grid units/shot ✅ Center vs Edge Firing Rate: 1.36× higher in center (p=0.003) ✅ Processing Time: ~12 seconds for 50K shots at d=7 ✅ Key Insight: Detector #21 hot spot = error convergence (physics), not hardware defect

What is Error Propagation in Quantum Error Correction?

The Problem

When quantum errors occur on a surface code, they don't stay isolated. Errors spread across the qubit lattice through:

1. Physical propagation: Crosstalk between qubits
2. Logical propagation: Syndrome measurement back-action
3. Error chains: Sequential errors forming correlated paths

Why This Matters: If errors propagate faster than your QEC cycle time, they can create undetectable error chains that fool decoders and cause logical errors.

The Traditional Approach (Limited)

Conventional QEC analysis focuses on: - Error rates (ε) - Logical error rates (p_logical) - Lambda (error suppression factor)

What's Missing: These metrics don't reveal how or where errors flow through the system.

Our Approach: Temporal-Spatial Correlation Analysis

We analyze syndrome measurements using lagged correlations to detect:

Corr(detector_i(t), detector_j(t+Δt))

Where: - t = syndrome round - Δt = time lag (in shots) - If Corr increases with lag → Error propagation detected

This is inspired by Out-of-Time-Order Correlators (OTOC) used to measure quantum information scrambling, but adapted for error propagation in QEC syndromes.

Our Methodology

Input Data

Google Willow public dataset (d=7): - Surface code distance: d=7 - Shots: 50,000 - Detectors: 97 (X-stabilizers + Z-stabilizers) - Data format: Stim .b8 binary syndrome data - Source: Zenodo DOI: 10.5281/zenodo.13273331

Analysis Steps

1. Detector Layout Reconstruction
2. Use correlation-based MDS to infer 2D positions of 97 detectors

3. Validates spatial geometry (68-76% neighbor accuracy)

4. Lagged Correlation Calculation

5. For each detector pair (i, j):
   • Calculate Corr(det_i(t), det_j(t+Δt)) for Δt = 0, 1, 2, ..., 5 shots

6. Identify pairs where correlation increases with lag

7. Propagation Pattern Detection

8. Threshold: Corr_increase > 0.1

9. Extract source detector, target detector, optimal lag, propagation speed

10. Butterfly Velocity Calculation

11. For each pattern: velocity = distance / lag

12. Aggregate: mean_velocity = 2.94 grid units/shot

13. Center vs Edge Analysis

14. Group detectors by position (center vs boundary)
15. Compare firing rates with t-test
16. Result: p=0.003 (highly significant)

Results: Error Propagation Patterns

Summary Statistics

Example Propagation Patterns

Here are the top 5 strongest error propagation patterns:

Pattern: Most propagation occurs at lag=1 shot, suggesting errors spread within a single QEC cycle.

What is "Butterfly Velocity"?

The Concept

In quantum chaos theory, the butterfly velocity measures how fast quantum information scrambles across a system. We adapt this concept to measure error propagation speed in QEC codes.

v_butterfly = spatial_distance / temporal_lag

Our Measurement

Butterfly velocity = 2.94 grid units/shot

Interpretation: - Errors spread ~3 lattice sites per syndrome measurement round - Comparable to Google's measured OTOC velocity (1.85 sites/cycle in their Nature paper) - Fast enough to create correlated error chains within a few cycles

Why This Matters

For a d=7 surface code (7×7 lattice), errors can traverse the entire code in ~3 shots. This means:

✅ QEC cycles must be fast enough to catch errors before they form chains ✅ Decoders must account for correlated errors, not just independent random errors ✅ Hardware tuning should minimize crosstalk to reduce butterfly velocity

The Detector #21 Mystery: Physics or Hardware Defect?

The Hot Spot

In our spatial fingerprinting analysis, we detected Detector #21 as a hot spot with 59% excess firing rate above geometric expectation.

Initial Hypothesis: Hardware defect (faulty qubit or readout)

OTOC Analysis Reveals the Truth

Detector #21 appears in the center detector group: - Center detectors: [3, 8, 9, 21, 23, 32, 33, 34, 40, 41, 44, 45] - Mean center firing rate: 8.34% (vs 6.13% at edges) - Statistical significance: p=0.003

New Interpretation: Detector #21 is not defective—it's an error convergence point.

Error Convergence vs Hardware Defect

Detector #21 Verdict: ✅ Error convergence (physics), ❌ NOT hardware defect

Center vs Edge Effect: A Fundamental QEC Phenomenon

The Finding

Center detectors fire 36% more often than edge detectors (p=0.003)

Center firing rate: 8.34%
Edge firing rate:   6.13%
Ratio:              1.36×
t-statistic:        3.32
p-value:            0.003 (highly significant)

Why Does This Happen?

1. Boundary Conditions
2. Edge detectors have fewer neighbors

3. Fewer error propagation paths converge at boundaries

4. Error Convergence

5. Center detectors receive errors from all directions

6. Edge detectors only receive errors from inward directions

7. Geometry of Surface Codes

8. Topological boundary conditions reduce error visibility at edges
9. Center regions experience full 2D error dynamics

Implications for QEC Design

✅ Expected behavior: Center-edge gradient is a feature, not a bug ✅ Decoder design: Weight center detectors differently from edge detectors ✅ Hardware calibration: Account for topology when interpreting hot spots

Use Cases: Why Measure Error Propagation?

1. Debug Hardware Defects

Problem: Is a hot spot a faulty qubit or normal physics?

Solution: Check OTOC propagation patterns: - Isolated hot spot + no correlations → Hardware defect - Hot spot + incoming propagation paths → Physics (error convergence)

2. Optimize Decoder Performance

Problem: Decoders assume independent errors, but real errors are correlated.

Solution: Use propagation patterns to: - Weight edges in MWPM decoder based on propagation likelihood - Pre-condition syndrome data to remove correlated noise - Tune decoder parameters based on butterfly velocity

3. Validate Error Suppression

Problem: Does increasing distance d reduce error propagation speed?

Solution: Measure butterfly velocity vs distance: - d=3: v_butterfly = ? - d=5: v_butterfly = ? - d=7: v_butterfly = 2.94 grid units/shot

Expected: Velocity should decrease with distance (more robust codes suppress propagation).

4. Benchmark Quantum Hardware

Problem: How do different platforms compare in error propagation?

Solution: Compare butterfly velocity: - Google Willow: 2.94 grid units/shot (this work) - IBM Quantum: TBD - IonQ Aria: TBD - Benchmarking metric for hardware quality

How Fast is This Analysis?

Scalability: Linear in shots, polynomial in detectors. Fast enough for production QEC debugging workflows.

Code Example: Using the getQore API

import requests

# 1. Upload syndrome data
url = "https://getqore.ai/api/v1/otoc_analysis"
files = {
    'syndromes': open('willow_d7.b8', 'rb')
}
data = {
    'platform': 'google_willow',
    'distance': 7,
    'n_detectors': 97,
    'max_lag': 5
}

# 2. POST request
response = requests.post(url, files=files, data=data)
results = response.json()

# 3. Extract metrics
print(f"Propagation patterns: {results['summary']['n_propagation_patterns']}")
print(f"Butterfly velocity:   {results['summary']['mean_velocity']:.2f} grid units/shot")
print(f"Center vs edge:       {results['center_vs_edge']['rate_ratio']:.2f}× (p={results['center_vs_edge']['p_value']:.4f})")

Output:

Propagation patterns: 19
Butterfly velocity:   2.94 grid units/shot
Center vs edge:       1.36× (p=0.0031)

Comparison with Google's OTOC Work

Google's OTOC(2) Experiment (Oct 2025)

Paper: Quantum echoes on Willow: Verifiable quantum advantage

What They Measured: - OTOC(2) signature of quantum information scrambling - Butterfly velocity: 1.85 sites/cycle - Quantum advantage: 13,000× faster than classical simulation

Their Protocol: 1. Prepare initial state 2. Apply time-evolution Hamiltonian 3. Implement time-reversal sequence 4. Measure OTOC decay

Our Error Propagation Analysis

What We Measured: - Error propagation patterns in QEC syndromes - Butterfly velocity: 2.94 grid units/shot (errors, not information) - Center vs edge physics: p=0.003 significance

Our Protocol: 1. Collect syndrome measurements 2. Calculate lagged correlations 3. Detect propagation patterns 4. Measure butterfly velocity

Key Differences

Why Different Velocities? - OTOC measures quantum information spreading via unitary evolution - Error propagation measures noise spreading via decoherence and crosstalk - Different physical mechanisms → different velocities

Limitations & Future Work

Current Scope

✅ Validated: Google Willow superconducting qubits ✅ Code Type: Surface codes (d=7) ✅ Analysis: Temporal-spatial error propagation

Roadmap (Q1-Q2 2026)

🗓️ Multi-distance comparison (d=3, 5, 7) - Does velocity decrease with distance? 🗓️ IBM Quantum - How does error propagation compare on superconducting vs trapped ion? 🗓️ IonQ Aria/Forte - Measure butterfly velocity on trapped ion hardware 🗓️ XZZX codes, color codes - Generalize beyond surface codes 🗓️ Decoder integration - Use propagation patterns to improve MWPM performance

Why This Matters for the Quantum Industry

Current Pain Points

1. Hot Spot Ambiguity: Is it a hardware defect or normal physics?
2. Decoder Assumptions: Most decoders assume independent errors, but real errors correlate
3. Hardware Benchmarking: No standard metric for error propagation speed

Our Solution

✅ Distinguish physics from defects using temporal-spatial correlation ✅ Fast analysis (12 seconds for d=7, 50K shots) ✅ Platform agnostic - Works on Google, IBM, IonQ with calibration ✅ Actionable insights for decoder tuning and hardware debugging

Try It Yourself

Beta Program (Limited to First 10 Testers):

🎯 3 months FREE access 🎯 10 analyses/month 🎯 Google Willow support 🎯 Full error propagation reports 🎯 Email support

Sign up: getqore.ai

Technical Details

Author: R.J. Mathews Organization: getQore Website: getqore.ai Contact: support@getqore.ai

API Endpoint: /api/v1/otoc_analysis (Premium tier: $199/platform bundled)

Dataset: Google Willow public data (Zenodo DOI: 10.5281/zenodo.13273331)

References

1. Google Quantum AI. "Quantum error correction below the surface code threshold." Nature (2024). DOI: 10.1038/s41586-024-08449-y

2. Google Quantum AI. "Quantum echoes on Willow: Verifiable quantum advantage." Google Blog (Oct 2025). Link

3. Google Willow Syndrome Dataset. Zenodo (2024). DOI: 10.5281/zenodo.13273331

4. Swingle, B. "Unscrambling the physics of out-of-time-order correlators." Nature Physics 14, 988-990 (2018).

5. Nahum, A. et al. "Quantum entanglement growth under random unitary dynamics." Phys. Rev. X 7, 031016 (2017).

About getQore

getQore provides decoder-independent quantum error correction analysis for quantum hardware manufacturers and research institutions. Our proprietary temporal-spatial correlation analysis enables rapid error propagation measurement without complex decoder implementation.

Platform Support: - ✅ Google Willow (validated) - 🗓️ IBM Quantum (Q1 2026) - 🗓️ IonQ Aria/Forte (Q1 2026) - 🗓️ Amazon Braket (Q2 2026)

This article was originally published at getqore.ai/blog/otoc-error-propagation

Tags: #QuantumComputing #ErrorCorrection #OTOC #GoogleWillow #SurfaceCodes #QEC #ErrorPropagation #ButterflyVelocity