Record a Calibration Capture Rate Before the Backfill Erases It

Backfill the window a capture rate measured, and the figure reads 100% by construction. SuperconducTED's noise engine lost its first ordinary-operation capture figure that way. Measured again with the order reversed, its IBM calibration pipeline missed 27 of 227 documents in one week, and one device state of 48.

A backfill turns the capture rate of the window it repairs into 100%

The engine archives calibration documents, the snapshots backend.properties() returns, on a data branch fed by an hourly poll. Issue 54 reported how much of IBM's stream that poll caught over 12 to 14 August 2026. A read-only enumeration of IBM's own history, run on 2 September and recorded in PR 52, was diffed against the archive and put capture at most 70.2%: 33 of at least 47 documents.

A backfill then filed the missing documents into that same window. The register row, NC-032, now reads at most 100%, 50 of at least 50, beside a note that the bound is vacuous (numerical claims register). An archive holding every document anyone can prove existed scores 100% whatever the poll did.

Nothing inside the pipeline could have flagged the loss. Its ledger records what was fetched, so a document nobody fetched leaves no row to count (implementation record). Only IBM's history shows what is missing, and only until someone files it.

A one-hour grid cannot reliably see a document that lives twenty minutes

Since 11 September a daily sweep also re-reads IBM's history over a 48-hour trailing window at a 1 h step. PR 105 measured the pipeline with both paths live: two read-only enumerations of ibm_fez at a 15-minute step over 13 to 20 September, a week in which two sweeps had already covered every stamp. Diffed against the archive at commit b70d7b4, 200 documents were held and 27 were missing, so capture was at most 88.1% (NC-058).

Every missed document was superseded within 0.75 h. Their median lifetime was 0.42 h, against 0.71 h for captured documents, and misses fell on all seven days (capture evidence). The record explains this as aliasing: a grid of step Δ at a random phase sees a document that lives L < Δ with probability about L/Δ, and it files that as an explanation rather than a registered prediction.

The enumeration's step matters as much as the sweep's. At 15 minutes it served all 200 held documents (NC-059), where a 1 h enumeration of the August window had served 87.9% (NC-031). On the sweep's own grid it would share the sweep's blind spots and report near-full capture, so a test, TestWorkflowPins, fails if the two steps ever meet; setting the capture step to 1 h was checked to fail it.

PR 105 also replayed the nine real sweeps that overlapped the window, to predict what a finer sweep would catch. The replay matched the ledger 219 times and disagreed 167 times, which the record reads as IBM's history index lagging publication by a variable amount. A model that fails its own validation carries no number, so no figure for a 0.5 h or 0.25 h sweep was registered.

Twelve percent of documents was one device state in 48

The training floor (NC-012) counts distinct device states, since a repeated state is no new sample, and about half of all documents repeat the previous state (NC-057). The missed documents' qubit digests stayed unknown until the backfill recovered them, so the state loss could only be measured afterwards. Of the 48 device states first seen in the window, one was carried only by missed documents: state capture at most 97.9% (NC-060), against at most 88.1% for documents.

So the two figures cite different commits. NC-058 holds at b70d7b4, which lacks the 27; NC-060 holds at 41ebadc, which has them. The backfill that produced 41ebadc ran only after the evidence was pushed, filed 28 new documents (the 27 plus the run's own live fetch) with no collision, and turned the same diff into 227 of 227.

The 1 h sweep stays for now. The state-level cost is about one state a week, and the step change is its own decision, still open as issue 104.

The daily capture job records each miss without recovering it

The measurement now repeats every day. A capture job enumerates one settled day at 15 minutes, the day three days back, which two daily sweeps have covered, and appends a row per document to health/capture.tsv. The dashboard publishes a rolling seven-day figure from it.

The job writes only that record. One that filed the documents it found missing would read 100% by construction, which is the NC-032 failure again.

Review found a second way to heal by accident: a manual backfill dispatched before the job runs files the missed documents, and an archive diff then counts them as captured. Capture is now judged by what scheduled runs retrieved, and a document held only through a dispatch counts as missed. The 11 October render read 206 of 248 documents for 2 to 8 October, 83.1%, an upper bound for the same reason NC-058 is (health metrics).

Pin the loss to a commit before you heal it

Any archive of a source that overwrites itself on a schedule can lose data the same way. Three habits from PR 105 carry over:

• Enumerate the source's own history with a read-only job, at a step finer than your sampler's.
• Push the result, citing the archive commit it was measured against, before any backfill touches the window.
• Count the loss in the unit your consumer uses, which here was device states.

The same failure shape, a run that succeeds while measuring nothing, left two of the engine's benchmark circuits without installed noise in September. Read NC-056 to NC-060 in the SuperconducTED repository before reusing the method, or browse the SuperconducTED case study for what the archive feeds.