Track IBM Quantum backend drift with Bell tests, Sheets, Gmail and OpenAI

Quick overview Quantum processors drift every single day. This workflow runs a Bell state test on the least busy IBM Quantum backend, picks the healthiest qubit pair straight from live calibration data, logs every run to Google Sheets, and emails you a short OpenAI written note about what actually changed. How it works 1. Every morning the schedule trigger loads your settings from one Set node: shot count, minimum qubits, the CZ error ceiling, the QPU seconds you want kept in reserve, and the tag that ties everything together. 2. It reads how much QPU time your IBM Quantum plan has left. If you are below the reserve it emails you and stops there, so an active schedule can never quietly drain a free Open Plan allowance. 3. It asks IBM which backend is least busy right now, then downloads that machine's live calibration report. That report is refreshed by IBM roughly every few hours and it changes constantly. 4. A Code node scores every two qubit link on the chip. For each CZ pair it adds the gate error to the readout error of both qubits, then sorts. Links whose calibration looks broken get filtered out first. On a 156 qubit Heron processor that means ranking around 350 candidate pairs before choosing one. 5. The winning pair gets a Bell state circuit written directly in the backend's native gate set, using rz, sx and cz on the physical qubit indices. This matters more than it sounds. IBM's runtime does not transpile for you, and a textbook circuit with h and cx comes straight back rejected with error 1517. Generating ISA gates in the workflow means you never need a local Qiskit install. 6. The job goes to the Sampler with your tag attached, the run is written to Google Sheets as pending together with a full snapshot of the calibration numbers, and this flow ends. Nothing waits on the queue, which can be sixteen seconds or over an hour depending on the hour of the day. 7. A second trigger wakes up when IBM reports that tagged job as finished. It fetches the measurement counts, finds the pending row by job ID, and computes the correlation: the share of shots that landed on 00 or 11, which for a perfect Bell pair would be 1.0. 8. That measured number gets compared against what the calibration data predicted before the job ran. The gap between the two is the interesting part, and it is the thing you cannot get from IBM's published numbers alone. 9. The row is completed in place, the recent history is read back, and OpenAI writes three to five sentences comparing today against the rolling average. The prompt is deliberately strict: it is told not to invent numbers and not to blame a qubit pair change unless the history actually shows one. 10. You get an email. A normal digest when things look fine, a degradation alert when the correlation falls under your threshold. Both carry the full table of numbers underneath the summary. 11. A third trigger watches for tagged jobs that failed or were cancelled and emails you the reason IBM gave, including the error code. The pending row stays in the sheet so you can still see which qubits that job was aimed at. Setup 1. Add four credentials: IBM Quantum Platform API, Google Sheets OAuth2, Gmail OAuth2, and an OpenAI API key. The IBM credential is the same one you would use from a Python script, nothing special. 2. Create a Google Sheet and add a tab named exactly runs. Leave it completely empty. The workflow writes all 25 column headers itself on the first run, so you do not need to prepare anything. They come from the Create Pending Log Entry node, which returns exactly the fields that become columns. 3. Select that spreadsheet in all four Google Sheets nodes: Log Pending Benchmark to Sheet, Locate Pending Entry in Sheet, Update Benchmark Log Entry, and Fetch Benchmark History. 4. Put your email address in three places. Set Watchtower Parameters covers the morning flow, Set Alert Configuration covers the scoring flow, and Alert Job Failure Report has its own field. They are separate because e