← Tepna preprints
⛔ CORRECTION — v3, 2026-08-13. The ~96 ms "physiological floor" was instrumental. Read this before anything below.

v2 refuted v1's clock explanation and replaced it with a physiological one: that beat-level PAT is blocked by ~96 ms of beat-to-beat scatter in the peripheral foot time, "a property of peripheral pulse-wave timing and foot detection at these sites, not of timekeeping". That is now refuted in turn. The ~96 ms was never physiology. It is the sum of three rate/axis errors and one windowing artifact:

  1. The ECG sample rate was rounded to its nominal 130 Hz, derived from the lossy [ms] column instead of the integer [ns] counter — 46–126 ppm, i.e. 1.25–4.16 s of drift per night. A clock error, in this suite's own code.
  2. The O2Ring's row rate was read as its sample rate — the ring inserts one marker row per beat, so rows run at 125.000 × (1 + HR/7500): ~6,900 ppm.
  3. PHYS = [200,650] is a 450 ms acceptance window, and 450/√12 = 129.90 ms — arithmetically is the "131–136 ms" that was reported as a measured spread. A uniform distribution's standard deviation was read as a property of the cardiovascular system.
  4. Every historical verdict here was computed on the phone corpus, which has no second clock at all. DexClock.hostAxis returns independent: false on those nights — host-column residual spread 0.98 ms, exactly one stamp quantum — because the host column was derived from each device's own stamp. Box captures return independent: true on 30/30 stream-nights (residual spread 318–2968 ms). The corpus underlying v1 and v2 cannot identify inter-device timing, because there is only one clock in it.

What this does and does not establish. Solidly established is the negative: the ~96 ms figure was measured through a broken axis, a mis-read rate and a fixed window, so nothing built on it survives. Not established is a positive result. With (1) fixed and (2) avoided, on box captures the R-peak → finger-foot interval has a within-5-min-bin σ of 10–23 ms on three of six nights against a 60 ms bar — but that is one session, not gate-backed, and it is the reason the old verdict is withdrawn, not a reason to publish a new one. Whether a wall exists at all is now open.

The current blocker candidate is neither crystal nor physiology. It is a per-connection BLE buffering offset: the same two devices on the same host are separated by a delay whose spread between recordings is 2.2 s (within-night σ 29–36 ms). PAT needs ~10 ms. This is measurable from host arrival stamps but has not yet been directly tested.

And the gate that produced "0 of 54 pairings" was itself defective in two ways found on 2026-08-11: it weighed a statistic that saturates at its own pairing window, and PHYS was applied as a plausibility filter when it is a censoring cut — discarding data on 16 of 19 box site-nights, one at 97.4 % censored with an uncensored median lag of 831 ms. The censored share is bimodal (0.0–0.2 % vs 4.9–97.4 %, nothing between), and low censoring does not identify a good night. The usable box corpus is 2 site-nights, not the ~8 previously assumed.

Two claims made on 2026-08-11 and withdrawn the same day, recorded so they are not re-adopted: "100 Hz ACC unlocked PEP" (it did not — 50 Hz was always sufficient; the failure was a cardiac-locked control and a 4-sample SNR baseline), and "p = 0.0005" for PEP↔lag coupling (impossible with 14 distinct circular shifts; the floor is ~1/15). Pre-ejection period is now measured: seismocardiography from the chest accelerometer puts aortic opening at 92–124 ms across four nights, up to 19.6× a phase-scrambled control. Full record: briefs/PAT-COMPENDIUM-2026-08-10-BRIEF.md.

CORRECTION — v2, 2026-07-29. The negative result stands; its stated cause does not. Draft v1 attributed the failure to ~48 ppm inter-device quartz drift and prescribed single-host acquisition as the remedy. Both are now refuted. The ~1.15 s "drift" was one cardiac cycle — an artifact of a beat-coupler that searched a 2,000 ms span (wider than one RR) while only displaying its 200–650 ms physiological window, so a missed pulse foot let the next beat's foot be accepted. v1's own Table 1 already contained the refutation and it was not noticed: the drift does not scale with recording duration (r = +0.17, where a fixed ppm requires r ≈ +1). Measured directly, the inter-device rate is ~1.5 ppm, not 48 — and the single-host path caps accumulated drift at 8.6 ms even at the claimed rate, yet couples no better (18.8 % vs 19.0 %), so the prescribed remedy is both applied and unhelpful. The real limit is ~96 ms of beat-to-beat scatter in the peripheral foot time. The wall is real; this paper had the wrong map of it. Full account in §7; v1's numbers are retained throughout so the correction is checkable.
⚠ SCOPE — 2026-08-02: v2's rate bound holds for PHONE-captured sessions and does not generalise to the vigil capture host.

v2 bounds the inter-device rate at a median 1.46 ppm and excludes v1's 47.7 ppm on 51 of 54 nights, on the argument that the ~1.15 s per-night excursion is one RR interval — beat slip, not clock wander. On this paper's corpus (20 overnight sessions, one Android phone via Polar Sensor Logger) that argument stands, and the beat-slip mechanism it identifies is real: it was independently rediscovered on 2026-08-01 as a comb of coincidence peaks one RR apart, and as a per-block offset that falls back exactly one RR when it drifts past a tooth boundary (IBI-ALIGNMENT-LIMIT §Retraction).

But six nights captured on the vigil host behave differently.

⛔ CROSS-SESSION CORRECTION — 2026-08-02, added by a parallel session. The 90–216 ppm figures below are contradicted by a direct measurement that needs no beat matching, blocking, comb or unwrap. Every raw file already carries two clocks — Phone timestamp (host; chrony, 0.008 ppm) and sensor timestamp [ns] (device crystal). Regressing one on the other inside a fragment gives ppm directly. Over four nights: H10 ≈ −20 ppm (±2), Verity ≈ −27 ppm (±3), each stable across fragments and across nights, so the inter-device rate is ≈ 7 ppm — 176 ms over a 7 h night, well under one RR. The table below is therefore 13–30× too high.

The mechanism: at 7 ppm a pair needs ~47 h to accumulate one RR, so a one-RR slip cannot be drift — it is a pairing failure. An unwrap that removes slips and then reports the remaining slope as drift is removing the signal and fitting the noise, which is what produces a linear-looking ramp at R² 0.99. This does not touch v2's headline (1.46 ppm by halfDrift) — the direct figure is the same order and the same conclusion, that the clocks are stable for this purpose. It retracts only the scope note added on top of it. Evidence and tool: briefs/WEARABLE-DRIFT-DIRECT-2026-08-02-BRIEF.md, tools/dual-clock-rate.mjs.

Strengthened and partly self-corrected, same day (WEARABLE-HOST-AXIS-2026-08-02). Two amendments, both from measuring the adjacent thing:
(i) The direct method had its own defect — it selected fragments by file size, and bytes are not span. It quoted the same H10 at −20.3 ppm (373 min) and −65.8 ppm (10.9 min), both counted equally, because host stamps are non-monotonic (2,948 backward steps, max 287 ms) so one endpoint slip is 712 ppm over 11 min and 21 ppm over 373. Gated at ≥60 min, the result survives and tightens: H10 −17.3…−23.0, Verity −26.0…−33.1 across long fragments. Every wild value was a short fragment.
(ii) No O2Ring figure in this family was ever a crystal property. Its sensor timestamp is drawn, not measuredsample_index × 7,953,045 ns, a single delta value at 100 % across 16 files, i.e. an assumed 125.738 Hz. Its apparent ppm is the error in that assumption, which is why it ranges −527 to −2990 ppm and is occasionally near-perfect. From 2026-07-28 the ring emits real timestamps and its nominal matches truth to 1 ppm. ⛔ The correct response is not to re-calibrate the constant — O2RING-PROTOCOL §109–111 already did that once (125.0 → 125.738 over 2.6 M samples), and a better number makes a drawn axis more plausible without making it a measurement, while erasing the evidence that it is drawn.
Refitting the H10↔Verity offset in 5-minute blocks and unwrapping the one-RR slips, the remaining series is a straight line on four of six nights:

nightR² of linear fitslope1st half2nd half
2026-07-250.991216 ppm178244
2026-07-260.98389 ppm7497
2026-07-270.976104 ppm87137
2026-07-280.924102 ppm5665
2026-07-290.108−25−1−105
2026-07-300.459223111

A random walk of beat slips does not fit a line at R² 0.99 with agreeing half-slopes. The two nights that do not fit (R² 0.11, 0.46) are precisely the two that fail an independent falsifier — three-source closure, d(A↔B) ≡ d(A↔C) − d(B↔C), which holds at −2.2 and −7.0 ppm on 07-27 and 07-28 and fails by 99–265 ppm elsewhere. Three independently-unwrapped pairwise fits do not close to 2 ppm by accident.

What this does and does not say. It does not reinstate v1: v1's 47.7 ppm was derived from the beat-slip artifact v2 correctly identified, and its causal account remains wrong. It says the rate bound is a property of the capture path, not of the devices — v2's own §Methods scopes it to one phone and one logger, and the conclusion should carry that scope explicitly. On a host that stamps and re-syncs differently, a linear 90–216 ppm ramp is present and is not beat slip. Scope note corrected 2026-08-08: that 90–216 ppm is a beat-derived figure, and it is retracted as a statement about the devices. Measured directly off the two clocks carried in every capture file — Phone timestamp against sensor timestamp [ns] — the H10 runs −20.3 ppm and the Verity −27.0 ppm versus the capture host, each stable to ±2–3 across fragments and nights, so the inter-device rate is ≈7 ppm, not 90–216 (over 7 h: 202 ms, not 2.5 s). The paper's conclusion is unaffected — 7 ppm still exceeds the ~2.4–3 ppm a beat-resolution consumer can absorb, which is precisely why the inflated figure survived: the ordering holds at both rates, so nothing downstream went red while the stated reason was wrong by an order of magnitude. See briefs/WEARABLE-DRIFT-DIRECT-2026-08-02-BRIEF.md. Caveat: these ppm are measured against the capture host's clock, so a change to how that host stamps or disciplines time re-opens them. Anything downstream that assumes a single constant offset per night inherits the difference. See briefs/CROSS-DEVICE-DRIFT-AND-CLOSURE-2026-08-01-BRIEF.md.

Unresolved: which capture path is at fault, and why. The two corpora differ in host, stamping and re-sync behaviour at once, so this cannot attribute the ramp to a device oscillator rather than to the host's timestamping. That needs a capture-side measurement, not more analysis of exports.

One phone is not one clock: two corrections to a negative result on beat-level fusion of two consumer wearables

Michal Planicka  ·  corresponding author — Tepna Project

Single-subject methods case study, Tepna physiological-signal suite

Draft v3 (second major correction — supersedes v2 of 2026-07-29, which superseded v1 of July 2026) · 2026-08-13 · Methods / negative-result note · regenerates from PAT Feasibility.html, pat-align.js, pat-gate.js and tools/acc-acc-control.mjs on the author's overnight corpus · 100% local

Abstract

Background. Pulse-arrival time (PAT), the delay from the ECG R-peak to the peripheral pulse foot, is an attractive cuff-free vascular marker, and consumer wearables can now supply both legs — a chest ECG (Polar H10) and a peripheral raw-PPG (Polar Verity Sense) — logged simultaneously by one phone. It is widely assumed that same-phone logging yields a common time base. Objective. Test whether beat-level cross-device PAT is recoverable from such captures — and, in this corrected version, whether the mechanism v1 blamed is the actual one. Methods. Twenty overnight sessions (one subject; H10 chest ECG, Verity peripheral raw-PPG; one Android phone via Polar Sensor Logger) were auto-paired; 11 met a start-alignment + beat-parity co-recording gate (145,586 coupled beats). Production detectors (Pan–Tompkins R-peaks; 3-LED-consensus PPG feet) timed each fiducial on its device's own clock. v2 adds three things v1 lacked: a beat-coupler with its physiological window enforced rather than merely displayed; an offset-free re-measurement (54 pairings over two corpora) scoring stability about each night's own modal lag; and a known-answer control for the accelerometer re-synchronisation, run on two sensors that share one acquisition clock. Results (v2, read with the v3 caveat below). Beat-level cross-device PAT is not recoverable — 0 of 54 pairings clear a coupling ≥ 55 % / IQR ≤ 60 ms gate. v3: that gate is now known to be defective and those pairings to come from a corpus with no second clock, so the sentence describes what the runs produced, not what the measurement can do. But every causal claim in v1 fails. (i) The ~1.15 s per-night "drift" is one RR interval, not clock wander: it does not scale with recording duration (r = +0.17 against the r ≈ +1 a fixed ppm demands), the millisecond value is more stable across nights than the ppm rate (CV 8.1 % vs 10.8 %), and its 1,156 ms median is this subject's RR at 51.9 bpm against a stated ~50 bpm. An offset-free wander metric immune to beat-slip passes 47 of 54 nights (median 19.7 ms), which bounds the actual inter-device rate at a median 1.46 ppm on the 27 longest nights — and excludes v1's 47.7 ppm on 51 of 54 nights. (ii) v1's headline coupling (89 %) and beat-to-beat spread (48 ms) are artifacts of the same defect; a gated mutation control shows the spread does not move at all under slip, which is precisely why the secondary metric looked healthy. (iii) v1's prescribed fix was applied and does not help. The single-host acquisition path disciplines both device clocks from a host clock held by chrony against a local stratum-1 server (5.9 µs offset, 0.008 ppm residual), and re-anchors every capture fragment — median 3.0 min — so accumulated inter-device drift is structurally capped at 8.6 ms even at v1's claimed 47.7 ppm. Coupling on that path is 18.8 %, against 19.0 % for the un-disciplined phone path. (iv) The accelerometer re-synchronisation failure reproduces, but not for the stated anatomical reason: on two accelerometers sharing one clock, the same wide-range search recovers a planted −39 min offset on only 1 night in 13, while the same code at its design range aligns 13/13 to sub-1.6 s. Its correlation gate is inoperative — the chance-maximum correlation over 24,001 candidate lags (≈ 0.41) exceeds the acceptance threshold (0.35). Conclusion (v2, now itself corrected). v2 concluded that the wall is real but is not a clock wall, and that the limit is ~96 ms of beat-to-beat scatter in the peripheral foot time. v3 withdraws that. The ~96 ms was not physiology: it is the sum of an ECG sample rate rounded to its nominal 130 Hz (46–126 ppm, i.e. 1.25–4.16 s per night), an O2Ring row rate read as a sample rate (~6,900 ppm), and a 450 ms acceptance window whose uniform standard deviation — 450/√12 = 129.90 ms — is arithmetically the value that was reported as a measured spread; and all of it was computed on a corpus with no second clock (host-column residual spread 0.98 ms, exactly one stamp quantum, because that column was derived from the device's own stamp). What survives is a negative about the evidence rather than about the world: nothing built on the ~96 ms stands. On box captures with the axis fixed, the within-5-min-bin σ is 10–23 ms on three of six nights against a 60 ms bar — one session, not gate-backed. Whether beat-level cross-device PAT is recoverable is therefore open; the leading blocker candidate is now a per-connection BLE buffering offset whose spread between recordings of the same two devices is 2.2 s. The transferable lesson survives both corrections and is sharpened by the second: each time, the mechanism was decided by an instrument that had never been asked to recover a known answer — and in v2's case the "physiological" constant was recoverable in closed form from the analysis window itself.

Keywords: pulse arrival time · cross-device synchronization · beat-slip · measurement artifact · known-answer control · calibration of null results · negative results · consumer wearables · Polar H10 · Verity Sense · reproducibility · self-correction

Layman overview (delete before submission). A chest heart-monitor and a pulse sensor can both record the same night through one phone, and you'd think the phone lines them up in time. It doesn't quite — but that turned out not to be what broke this measurement, and the first version of this paper got that wrong. We were trying to measure the short delay between a heartbeat and the pulse arriving at the skin. We found a roughly one-second disagreement building up over each night, and blamed the gadgets' quartz clocks ticking at slightly different rates. They do tick differently — but that is not what we were looking at. Our software was allowed to match a heartbeat to a pulse up to two seconds later, which is longer than the gap between two heartbeats, so whenever it missed one pulse it happily grabbed the next one instead. The "one second of clock drift" was simply one heartbeat. The giveaway sat in our own table all along: real clock drift has to grow with a longer recording, and ours didn't. We also claimed that re-aligning the two gadgets from their motion sensors was hopeless because chest and leg don't move together. But when we ran that method on two sensors we knew shared a clock, it failed there too — so the method was broken, not the idea. We then said what actually defeats the measurement is that the pulse arrival time itself jitters by about a tenth of a second from beat to beat. That was wrong too, and for a plainer reason than the first mistake: our software only ever accepted delays between 200 and 650 milliseconds, and if you spread numbers evenly across a 450-millisecond band you get a scatter of almost exactly a tenth of a second no matter what the body is doing. We were measuring the width of our own window and calling it biology. On top of that, two sample rates were miscounted — including one where we rounded a heart monitor's true rate to its advertised one, which alone slides the two recordings a second or more apart over a night — and the recordings we used all along contained only one clock, not two, so they could never have answered the question. The honest summary: we drew the wrong map twice, and we no longer know whether this measurement is possible. The lesson is that a negative result is only as good as the check that the tool could have found the answer at all — a check we failed to run a second time, on our own correction.

1. Introduction

Pulse-arrival time — the interval from the ECG R-peak to the foot of a downstream pulse wave — tracks arterial tone and blood pressure and needs no cuff, which makes it a standing target for consumer-wearable fusion. The premise is simple: record a chest ECG and a peripheral raw-PPG at the same time and subtract their beat times. Consumer hardware now supplies both legs, and a single phone app (Polar Sensor Logger) can stream and log two Bluetooth-Low-Energy sensors together, writing a "Phone timestamp" column that looks like a shared clock. This paper asks whether that premise survives contact with the data, and reports that it does not — for a specific, quantified, and generalizable reason. The contribution is not a physiological result but a timing-methodology one: a measurement of the inter-device drift, a demonstration that same-phone logging does not synchronize the streams, and two failed attempts to repair it post-hoc, each with its mechanism. The claims are scoped to a single subject and one device pair; the drift magnitude, however, is a property of quartz-crystal tolerance and is expected to generalize.

2. Methods

Capture. One subject wore a Polar H10 chest strap (raw ECG, ~130 Hz) and a Polar Verity Sense on the left ankle (raw 3-LED PPG, ~176 Hz) overnight. Both sensors streamed over BLE to a single Android phone running Polar Sensor Logger, which writes per-stream CSV/TXT with a "Phone timestamp" and a device "sensor timestamp [ns]" column. Twenty nights were collected. Pairing. Files were auto-grouped into nights by filename stamp (sessions before noon folded into the previous evening); the largest ECG and largest PPG per night were paired. A night entered the analysis only if it passed a co-recording gate — start times within 5 s and beat counts within 12 % — which excludes non-simultaneous fragments; 11 of 21 eligible nights passed. Fiducials. R-peaks were detected by the production Pan–Tompkins pipeline (ECGDSP); PPG feet by a 3-LED-consensus detector (PPGDSP). Each fiducial's absolute time was reconstructed from its file's start anchor plus its own device's elapsed time (ECG: sample index ÷ device rate; PPG: device nanosecond clock). Coupling. Each R-peak was matched to the first following foot; a beat "couples" if that lag lies within ±90 ms of a ±30 s local-median baseline (a global baseline wrongly penalizes a slowly-drifting-but-coherent lag). Drift was the range of the per-5-minute median lag; its ppm rate is drift ÷ overlap duration. ACC re-sync. Two schemes estimated the relative clock offset from the two accelerometers' motion envelopes: (a) sliding 2-min windowed normalized cross-correlation; (b) event-triggered — strong isolated chest movements, each cross-correlated in a tight ±1.6 s window against the ankle. Recovered offsets were interpolated and subtracted, then coupling was recomputed. All analysis is browser-local and reproducible from PAT Feasibility.html.

3. Results

3.1 The two streams are the same heartbeats — stands, but the coupling figure does not

Co-recording is genuine, not assumed. On the representative night of 2026-07-06 the ECG and PPG start 1.4 s apart, run the same 401 min, and yield 19,922 vs 19,926 beats (0.02 % apart). Beat parity to 0.02 % is a robust observation and it survives v2 unchanged: the detectors are seeing one heart on two devices, so what follows is not a gross detection failure.

Superseded in v2. v1 continued: "89.5 % of R-peaks couple to a coherent foot with a 47.5 ms beat-to-beat spread… median coupling 69 %, median spread 45 ms", and concluded "whatever follows is therefore a timing problem, not a detection or a wrong-pairing problem". It was a wrong-pairing problem. Both figures were produced by a coupler that accepted the first foot with lag ≥ 0 anywhere inside a 2,000 ms search span while declaring a 200–650 ms physiological window that only ever fed a display diagnostic. 2,000 ms exceeds one RR at this subject's ~50 bpm, so a single missed foot let the next beat's foot be accepted as this beat's PAT — and be counted as a coupled beat. With the window enforced, coupling on this corpus falls to 15–27 %. Beat parity does not rescue the pairing: equal counts are consistent with local insertion/deletion pairs that preserve the total while scrambling which foot belongs to which beat (§7.4).

The 47.5 ms spread deserves separate blame, because it is what made the defect survive. A gated mutation control that re-opens the search past one RR shows the beat-to-beat IQR does not move at all under slip — ten slipped beats in sixty cannot shift a quartile. The metric standing beside the drift number was structurally incapable of reporting the error, and read healthy throughout.

3.2 The R→foot lag drifts ~1 s per night, at a fixed ppm — REFUTED; it is one cardiac cycle

v1's claim. "The lag baseline wanders across the night by a median of 1,156 ms — of the order of a full cardiac cycle at the subject's ~50 bpm. Normalized to the recording length this is 47.7 ppm (37.7–55.3), and it is strikingly consistent night to night (Table 1) — the signature of a fixed difference between two quartz crystals." The non-linearity (median linear-fit R² = 0.03) was read as wander that a two-point correction cannot capture.

Why it is wrong. The parenthesis in v1's own sentence is the answer: 1,156 ms is a full cardiac cycle, and it was recorded as an aside rather than as the explanation. Three tests separate a fixed-ppm crystal offset from one slipped beat, and all three can be run on v1's published Table 1 alone — no new data:

  1. Scaling with duration — decisive. A fixed ppm rate must produce a drift proportional to recording length: r(duration, driftms) ≈ +1. A one-RR slip is independent of length: r ≈ 0. Measured on Table 1's 11 nights: r = +0.17. Correspondingly r(duration, driftppm) = −0.71 — the strong negative correlation you get when a roughly constant numerator is divided by a varying duration.
  2. Which quantity is actually invariant. v1 called the ppm the consistent one. In its own table the millisecond value is the more stable of the two: CV 8.1 % for drift in ms against 10.8 % for drift in ppm, with duration itself varying by 8.6 %. Under a fixed-crystal model this ordering must be the other way round.
  3. The value is the subject's RR. Median drift 1,156 ms = RR at 51.9 bpm, against v1's own stated ~50 bpm. The full range 973–1,304 ms spans RR at 46–62 bpm — an ordinary sleeping heart-rate range for one subject. The night-to-night "consistency" that looked like a crystal signature is the consistency of a sleeping heart rate.

The apparent agreement with quartz tolerance (±20–50 ppm) is arithmetic coincidence: one RR interval divided by one night's duration — 1,156 ms ÷ 6.6 h — lands at 48 ppm. Two independent quantities were multiplied into a third that happened to match a familiar band, and the match was taken as confirmation.

What the wander actually is. Re-measured with a metric immune to both slip and window placement — halfDrift, the absolute difference between the median lag of the night's second half and its first — the lag barely moves: 47 of 54 pairings pass a 60 ms bar, median 19.7 ms, and 20 of 54 come in under 10 ms. The two clocks are, for this purpose, stable. The R² = 0.03 "non-linearity" is consistent with this: a slip is a step, not a ramp, so it does not fit a line.

Nightoverlap (min)coupling (%)median lag (ms)drift (ms)drift (ppm)≡ RR at (bpm)
2026-06-1042869622116245.352
2026-06-1146371694104737.757
2026-06-1242870732117445.751
2026-06-1544684703130448.746
2026-06-2436461584108949.855
2026-06-2541873705122548.849
2026-06-2741469792125250.448
2026-06-284164039297339.062
2026-06-3033838420112255.353
2026-07-0143234587115644.652
2026-07-0640190454114747.752

Table 1 · The 11 gated co-recording nights (145,586 coupled beats). v1 caption: "Median drift 47.7 ppm — within the ±20–50 ppm tolerance band of ordinary wearable-grade quartz." 2026-07-06 (highlighted) is the worked example in §3.1. v2: the added last column converts each night's drift to the heart rate whose RR interval it equals — 46–62 bpm, a sleeping heart-rate range, not a crystal signature. Drift in ms does not track overlap duration (r = +0.17) and is more stable across nights (CV 8.1 %) than the ppm rate it was normalised into (10.8 %). This table refutes its own caption; the ppm column is a division artifact and is retained only so the correction can be checked.

3.3 The phone timestamp is not a common clock

The natural objection is that a single phone should supply a single clock, so timing each fiducial on its device crystal (as §2) merely fails to use the shared reference. It does not exist. For the Verity 2026-07-06 file, the "Phone timestamp" advances by 23,811.246 s between first and last row while the device "sensor timestamp [ns]" advances by 23,811.2467 s — equal to within the phone column's 1-ms rounding over 6.6 h (Table 2). The logger therefore writes phone timestamp = session start + device-elapsed: it anchors the start to the phone wall-clock once, then counts on the device's own crystal. Each stream's "phone timestamp" consequently rides its own crystal, and the two diverge at exactly the inter-device rate of §3.2. Same-phone logging pins the two streams' start to a common instant (±1.4 s) but never their sample timing.

Elapsed over 6.6 h (Verity 2026-07-06)value (s)
"Phone timestamp" column23,811.246
Device "sensor timestamp [ns]" column23,811.2467
Difference< 0.001 (phone ms rounding)

Table 2 · The phone timestamp tracks the device clock exactly → it is not an independent acquisition clock.

3.4 Passive accelerometer re-synchronisation fails — outcome stands, stated cause NOT established

The observation, unchanged. Windowed cross-correlation of the two motion envelopes cut the median lag range only 1,156 → 1,127 ms (2.5 %); event-triggered matching on strong isolated movements did nothing (1,156 → 1,158 ms). In both, the recovered per-window offset ranged over 2–3 s, wider than the quantity it was meant to estimate. The re-synchronisation did not work.

v1's explanation, withdrawn. v1 attributed this to anatomy: "a chest strap and an ankle band register largely different motion (torso versus leg), so even a gross whole-body turn produces uncorrelated accelerometer signatures", concluding that motion re-sync "needs the two inertial sensors on the same body segment, which defeats the purpose." That is an inference from a failure, and the instrument that failed was never checked against a known answer. It has now been checked, and it fails there too.

The control. A capture host writes a Polar H10 chest accelerometer and a Polar Verity accelerometer through one daemon on one clock, so their true relative offset is zero by construction — while they remain two different sensors on two different body segments, correlated only through real body movement. That is the same problem shape with a known answer. 13 nights:

Why the wide search cannot work. A ±50 min search at 250 ms bins evaluates 24,001 candidate lags, while a ±15 s window supplies only 121 bins to correlate. For ~121 quasi-independent samples the sample correlation has sd ≈ 1/√121 = 0.091, so the expected best-of-24,001 spurious correlation is ≈ 0.091·√(2 ln 24001) ≈ 0.41 — above the 0.35 acceptance threshold the wide search was lowered to. Chance alone clears the gate, so the reported peak is noise, and the median of that noise is pulled toward the centre of the search range. Lengthening the window restores the gate and recovery improves monotonically — ±60 s → −27.3 min (3/13), ±240 s → −31.4 min (6/13) — a dose-response confirming the mechanism, though it never converges, and a window that long no longer isolates a single movement.

Scope of the withdrawal. The control pairs chest with arm; v1's corpus placed the PPG on the ankle. So this does not establish that chest and ankle motion are correlated. What it establishes is that the method used could not have detected the offset either way — so the failure is not evidence about anatomy. v1's anatomical claim, and its corollary that inertial sensors must be co-located, are unsupported rather than disproven.

3.6 Corpus-scale closure (added 2026-08-15) — two-thirds of per-night rates on this hardware are not measurements

§3 above applies three-source closure to the handful of nights where a pairwise rate was in dispute. The whole capture corpus has since been re-folded under current code (tools/trio-batch.mjs, 2026-08-15), which runs that same falsifier on every night rather than on the contested ones, and the corpus-scale answer is stronger than this paper has so far claimed:

closure verdict on the H10↔Verity pairwise fitnightssharemedian ppm
consistent — the rate is a measurement1732.7 %−3.0
INCONSISTENT — closure fails, at least one fit is wrong1019.2 %+7.5
unclosed — no third source, so untestable2548.1 %+8.0
all nights carrying a pairwise ppm fit52100 %+5.0

Only 33 % of per-night rates survive their own falsifier. The remaining 67 % split into fits that provably fail closure and fits that cannot be tested at all for want of a third source — and, critically, the three populations are indistinguishable from their ppm values alone. They occupy the same range, over the same night lengths (median span 467, 456 and 414 min respectively). Nothing in a rate figure reveals which kind it is; only the closure column does.

The pooled median is not merely noisier than the quotable one — it has the opposite sign. Pooling all 52 nights gives +5.0 ppm; restricting to the 17 that close gives −3.0 ppm (IQR −23 to +6). A corpus median taken over a population that is two-thirds non-measurements does not estimate a noisy version of the right answer; here it does not even estimate the right direction. That is the sharpest available argument for this paper's own thesis, and it applies to this paper's own method: §3.1's 1.46 ppm median is a different and slip-immune estimator, but it too is a median over nights that were not screened by closure, and it should be read as bounded rather than measured until it is.

Two further nights fail a prior control. 2026-07-04 and 2026-07-11 do not clear their own chance baseline for beat correspondence, so no rate should be read off them at any closure verdict. Across the 27 nights where closure could be computed the residual runs a median 5.9 ppm and a maximum 55.8 ppm — the same order as the effects being claimed, which is why the verdict and not the residual magnitude is the reportable quantity.

What this does not do. It does not re-open v1's 47.7 ppm: that figure was refuted on mechanism (a beat-slip artifact), and a mechanism refutation is unaffected by how many nights close. Nor does it supply a corrected corpus rate — the honest output of this section is a screen, not a new headline number, and the 17 closed nights are too few and too dispersed (IQR spanning 29 ppm) to support one. The contribution is a rule this paper had applied locally and can now state generally: on this hardware, a per-night clock rate quoted without its closure verdict is more likely than not to be a non-measurement.

4. Discussion

The separation v1 drew between co-recording and synchronisation is real and worth keeping: two consumer sensors on one phone are co-recording — same subject, same night, same heartbeats, startable to ~1 s — while no shared clock times their samples (§3.3). What v1 got wrong is the size and the consequence of that gap. It is not ~1 s per night; measured with a slip-immune metric it is a median of 19.7 ms, and it passes a 60 ms bar on 47 of 54 nights. Two free-running crystals do diverge, but on this hardware over one night they diverge by tens of milliseconds, not by a cardiac cycle.

Quantifying the term v1 blamed. halfDrift is the divergence of the R→foot lag between a night's two halves, whose midpoints are separated by about half the overlap. Dividing one by the other converts each night's wander into an implied inter-device rate, directly comparable to v1's 47.7 ppm. Two features of the result settle the question. The median implied rate is 2.50 ppm across 54 pairings, and v1's rate is excluded on 51 of them. More tellingly, the implied rate falls as nights get longerr(overlap, implied ppm) = −0.54 — which is the signature of a metric hitting its own noise floor on short recordings, not of a fixed rate. On the 27 nights of ≥ 240 min, where a genuine fixed rate accumulates most and is easiest to see, the median implied rate is 1.46 ppm and the maximum is 8.6 ppm. A real 47.7 ppm offset cannot hide on a 7-hour recording.

So the practical hierarchy inverts, and the remedy is unnecessary rather than ineffective. v1 concluded that beat-level fusion needs a single acquisition clock and epoch-level fusion does not. The clock is in fact good enough for beat-level work by more than an order of magnitude — and beat-level work still fails, for an unrelated reason. We can be concrete about the remedy because the hardware exists: the acquisition host runs chrony against a local stratum-1 server, holding a 5.9 µs offset (19 µs std dev) with a residual frequency error of 0.008 ppm and 0.027 ppm skew. That is a genuine single acquisition clock, roughly 6,000× better than the rate v1 blamed, and it does not help — because there was ~1.5 ppm to remove, not 48.

The remedy was genuinely tested, and the architecture caps the term v1 blamed. The single-host corpus is not merely "a different app". Its acquisition daemon sets both device clocks from the host clock on every connect (an enabled-by-default setting, logged per sync), and it writes each session as fragments that are re-anchored to the host clock at their first row. Across 858 measured fragments the median is 3.0 min long. So the interval over which either device's crystal can free-run before being re-referenced is minutes, not a night — and the drift that could accumulate within a median fragment is 8.6 ms at v1's claimed 47.7 ppm, or 0.3 ms at the measured rate. Even had v1's rate been entirely real, this corpus structurally could not express it at a magnitude that matters against a 200–650 ms window. Coupling is nonetheless 18.8 %, against 19.0 % for the un-disciplined phone path. That is the remedy applied and the outcome unchanged.

One nuance worth recording, because it cuts against a naive reading of "one acquisition clock". The host does not use its own stamp as the sample clock: it writes sensor timestamp [ns] — the device's own counter — as the sample clock, and its host stamp only as an arrival time, deliberately, since arrival stamping inherits BLE burst jitter and steps backwards on 0.5–0.8 % of rows. The correct architecture is therefore neither "trust the device" nor "timestamp at the host", but the device's precise counter, repeatedly re-referenced to a disciplined host clock — which is what this host does, and which preserves sample-level precision while bounding accumulation. A literal single-clock capture that stamped every sample at arrival would be worse, substituting transport jitter for a stable counter.

Device-clock discipline is also imperfect in practice, and it does not rescue the hypothesis. The host's own logs show the peripheral device sitting −5.0 s from the host and, on one occasion, refusing to move after three re-syncs; the chest device does not implement the read-back command at all and has been observed with an epoch error of −239,071,318 s. None of this touches the analysis, which uses differences of the device counter anchored per fragment, so an epoch error cancels exactly. It does mean that absolute device time on these sensors is untrustworthy and only relative sample timing is usable — the opposite of the property v1 assumed it was measuring.

What actually binds. — WITHDRAWN in v3; this paragraph is retained as the claim being corrected. v2 argued: re-measured offset-free — scoring each beat against the night's own modal lag, so no absolute window and no assumed offset enter — the residual interquartile spread of the R→foot interval is ~96 ms against a 60 ms requirement, on 54 pairings across both corpora, with coupling ~19 %; the peripheral pulse foot is stable in its centre and loose in its detail; that is a property of peripheral pulse-wave timing and foot detection at these sites, not of timekeeping, and no timestamping improvement addresses it.

Why that is wrong. The claim "no absolute window enters" was false: the pairing still ran inside PHYS = [200,650], and a 450 ms acceptance band has a uniform standard deviation of 450/√12 = 129.90 ms. The reported spread is that number, not a measurement of the cardiovascular system — the analysis window is recoverable in closed form from the result it produced, which is the strongest possible sign that no signal was being observed. Two rate errors compound it: the ECG axis was derived from the lossy [ms] column and rounded to a nominal 130 Hz (46–126 ppm, 1.25–4.16 s per night — a timekeeping error after all, though in software rather than in a crystal), and the O2Ring's marker-inflated row rate was read as a sample rate (~6,900 ppm). Finally, every one of those 54 pairings came from the phone corpus, where hostAxis.independent is false: the host column is derived from the device stamp, residual spread 0.98 ms — one stamp quantum. There is no second clock in that corpus, so it cannot bound an inter-device quantity at all.

What replaces it: an open question and a named suspect. With the ECG axis fixed and the ring avoided, box captures give a within-5-min-bin σ of 10–23 ms on three of six nights against the 60 ms bar — which would make PAT feasible, except that this is one session and not gate-backed, so it withdraws the old verdict without establishing a new one. The gate that produced "0 of 54" is separately defective: it weighed a statistic that saturates at its own pairing window, and it treated PHYS as a plausibility filter when it is a censoring cut — discarding data on 16 of 19 box site-nights, one at 97.4 % censored with an uncensored median lag of 831 ms. The censored share is bimodal (0.0–0.2 % against 4.9–97.4 %, with nothing between), and a low censored share does not identify a usable night: 2026-08-02 is 0.1 % censored and still anatomically impossible. The usable box corpus is 2 site-nights. The leading blocker candidate is now a per-connection BLE buffering offset — the same two devices on the same host differ by a delay whose spread between recordings is 2.2 s, against a within-night σ of 29–36 ms — which is measurable from host arrival stamps and has not yet been directly tested.

The methodological point is the durable one, and it generalises past this device pair. v1's mechanism was decided by an instrument that had never been asked to recover a known answer. Three separate cheap checks would each have caught it, and all three were available at the time: (a) test whether the claimed drift scales with recording duration, which a fixed ppm must and a beat-slip cannot — v1's own Table 1 answers this and says +0.17; (b) ask whether the secondary metric could have registered the failure — the beat-to-beat IQR provably cannot move under slip, so its healthy 48 ms was uninformative rather than reassuring; (c) run the repair method on a pair whose offset is already known, before concluding from its failure. v1 instead noted twice, in passing, that the drift was "of the order of a full cardiac cycle" (§3.2) and that "neighbouring-beat aliasing" could occur but would not affect the drift range (Limitations) — the refutation appears three times in the original text and was each time treated as an aside.

What survives unchanged. §3.3 stands entirely: the Polar Sensor Logger's "Phone timestamp" column is session start + device-elapsed, verified to within millisecond rounding over 6.6 h, so it is not an independent acquisition clock. That is a direct observation of a file format, not an inference, and it is the finding of v1 that needed no correction. The beat-parity observation (§3.1, 0.02 %) also stands. The headline negative result — beat-level cross-device PAT was not recovered on 54 pairings, in any configuration tried — stands as a description of what those runs produced, but v3 withdraws it as a finding about the measurement: the gate was defective in two ways, two rates were wrong, and the corpus had no second clock, so those 54 runs could not have recovered PAT even had it been there. A null from an instrument in that state is evidence about the instrument.

Limitations. One subject and, in the original corpus, one device pair. v3: the ~96 ms scatter figure is withdrawn and is not a replication target — it is the standard deviation of the analysis window (450/√12 = 129.90 ms), measured through a rounded ECG axis on a corpus with no second clock. The quantity a replication should target is the within-5-min-bin σ on captures where hostAxis.independent is true, and the outstanding measurement is the per-connection BLE buffering offset (2.2 s spread between recordings) that now leads the blocker list. Note also that the usable box corpus is 2 site-nights, so no claim here is powered. Two limits are load-bearing and are stated rather than buried. First, a lag component of one whole RR interval is indistinguishable from a one-beat slip by any statistic used here, so the per-night modal lag (172–1,171 ms across the corpus) must not be read as a measured inter-device offset. Second, beat counts matching to 0.02 % refutes net foot dropout but not local insertion/deletion pairs, which preserve the total while destroying which foot belongs to which beat — and would produce exactly the observed signature (plentiful feet, ~1 RR of lag spread, ~96 ms residual scatter). So "the foot detector is adequate" is not established here, only "it produces about the right number of feet"; a monotone one-to-one correspondence audit is the outstanding measurement. The §3.4 control pairs chest with arm rather than chest with ankle, so it withdraws v1's anatomical claim without replacing it. No blood-pressure ground truth was collected — this paper makes no PAT-accuracy claim, only a timing-feasibility one.

5. Reproducibility

6. References & provenance

  1. Tepna instrument: PAT Feasibility.html · pat-feasibility.js · pat-feasibility-worker.js (batch coupling + ACC-sync).
  2. v2 instruments: pat-align.js — the coupler extracted with its physiological window enforced (coupleRtoFoot), plus the anchor aligner (alignByAnchors); 16 gated assertions including the mutation control that re-opens the search past one RR and demonstrates the slip returning, and pins that the beat-to-beat IQR does not move under it. tools/acc-acc-control.mjs — the §3.4 known-answer control, read-only.
  3. v3 instruments: pat-gate.js — the coupling gate, whose driftRange statistic saturates at the pairing window and whose censoredPct/censoredN now report the share of beats PHYS discards · DexClock.hostAxis — publishes independent and spreadMs, the discriminator between a real second clock and a host column derived from the device stamp · ecgdex-dsp.jsfs now derived from the integer sensor timestamp [ns] counter rather than the rounded nominal.
  4. Decision records: PAT-FEASIBILITY-2026-07-08-BRIEF.md (v1's verdict — its cause attribution is corrected, its DONE status stands) · INTEGRATOR-PAT-VASCULAR-2026-07-18-BRIEF.md §2-RESULT and §2-RESULT-II (the windowed and offset-free re-measurements, now themselves corrected) · CROSS-DEVICE-CLOCK-SKEW-2026-07-29-BRIEF.md §2c (the wide-search calibration control).
  5. v3 decision records — read PAT-COMPENDIUM-2026-08-10-BRIEF.md first; it is the single entry point and its own standing verdict was superseded on 2026-08-11. Primary records for each measurement: PAT-UNEXPLAINED-130MS-DISCOVERY-2026-08-09-BRIEF.md §2 (no second clock in the phone corpus) · PAT-SAWTOOTH-ANSWERS-THE-130MS-2026-08-10-BRIEF.md (the window arithmetic) · PAT-WINDOW-CENSORING-2026-08-11-BRIEF.md (PHYS as a censoring cut) · PAT-PACKET-ARRIVAL-2026-08-11-BRIEF.md (the per-connection BLE buffering offset) · PAT-DRIFT-STATISTIC-2026-08-10-BRIEF.md (the saturating statistic) · PAT-GEOMETRY-PROBE-2026-08-11-BRIEF.md · WEARABLE-HOST-AXIS-2026-08-02-BRIEF.md and O2RING-SYNTHESISED-AXIS-2026-08-02-BRIEF.md (the two rate errors).
  6. Companion negative-results synthesis: papers/dead-ends.html (this finding is wall 2.7, corrected in the same revision).
  7. Capture provenance & the Clock Contract: CLAUDE.md §🎙️, §🔒; single-host capture: POLAR-SDK-CAPTURE-2026-07-07-BRIEF.md, CAPTURE-HOST — noting that v2 withdraws the recommendation to pursue the SDK path for this purpose.
  8. Sensors: Polar H10 (chest ECG), Polar Verity Sense (raw 3-LED PPG); logger: Polar Sensor Logger (j-ware), Android.

7. Correction record — what changed in v2 and v3, and why each was missed

This section exists so each correction is auditable rather than silently absorbed. v1 was published July 2026; v2 superseded it on 2026-07-29; v3 supersedes v2 on 2026-08-13. No raw data changed at either step. v2's corrections came from re-analysing the same corpus with the coupler's window enforced, plus one new control. v3's come from fixing two sample-rate derivations, recognising a fixed acceptance window in the reported spread, and discovering that the corpus both earlier versions used contains only one clock.

The title changed in v3, and that is itself a correction. v2 was titled "One phone is not one clock — but the clock was never the problem". The second clause is false: a clock error was the problem — not a crystal, but this suite's own ECG sample-rate derivation, rounding to a nominal 130 Hz and sliding the two streams 1.25–4.16 s apart per night. The first clause stands and is kept.

v1 claimstatus in v2what the evidence says
R→foot lag drifts ~1.15 s/nightartifactOne RR interval. Beat-slip from a 2,000 ms coupler search span > 1 RR, with the 200–650 ms window displayed but not enforced.
Drift is a fixed 47.7 ppm (37.7–55.3) — quartz-crystal tolerancerefutedDoes not scale with duration (r = +0.17 vs the required ≈ +1); drift in ms is more stable than the ppm (CV 8.1 % vs 10.8 %); 1,156 ms = RR at 51.9 bpm vs a stated ~50 bpm. Refutable from v1's own Table 1.
89 % coupling, 48 ms beat-to-beat spreadartifactSame defect. Window enforced → 15–27 %; offset-free → ~19 %, residual IQR ~96 ms. The IQR provably cannot move under slip, so it could not have flagged it.
Drift is ~24× the PAT signal, so PAT is swampedrefutedImplied inter-device rate 1.46 ppm median on the 27 nights ≥ 240 min (max 8.6); v1's 47.7 ppm excluded on 51 of 54 nights; implied rate falls with night length (r = −0.54), i.e. a noise floor.
Beat-level fusion requires a single acquisition clock (host-side SDK)unnecessaryApplied and ineffective, and unnecessary. The single-host path sets both device clocks from a host held to 0.008 ppm and re-anchors every ~3.0 min fragment, capping accumulated drift at 8.6 ms even at the claimed 47.7 ppm — coupling is still 18.8 % vs 19.0 %. Caveat recorded in §4: the host writes the device counter as the sample clock, not its own arrival stamp.
ACC re-sync fails because chest and ankle motion are decorrelatedunsupportedFailure reproduces, cause withdrawn. On a known-zero pair the same wide search recovers a planted −39 min offset 1/13; at design range the same code aligns 13/13. Its acceptance threshold (0.35) sits below the chance-maximum correlation (≈ 0.41).
Motion re-sync needs co-located inertial sensorsunsupportedCorollary of the above. Chest↔arm accelerometers align 13/13 across body segments at design range.
Phone timestamp = start + device-elapsed, not a shared clock (§3.3)standsDirect format observation, verified to ms rounding over 6.6 h. Needed no correction.
Beat parity 0.02 %; the two streams are the same heartbeats (§3.1)standsRobust. But parity constrains counts, not correspondence.
Beat-level cross-device PAT is not recoverable from these capturesstands0 of 54 pairings clear the gate, in every configuration tried. The negative result was right; its explanation was not.

Table 3 · v1 → v2 disposition. Three claims survive, four are refuted or withdrawn, two are artifacts. v3 note: the last row of this table — "beat-level cross-device PAT is not recoverable" marked stands — is the claim v3 withdraws. See Table 4.

7.1 v2 → v3 · the correction to the correction

v2 claimstatus in v3what the evidence says
The limit is ~96 ms of beat-to-beat scatter in the peripheral foot time — a property of pulse-wave timing, not timekeepingartifactThe pairing ran inside PHYS = [200,650], a 450 ms acceptance band whose uniform SD is 450/√12 = 129.90 ms. The reported spread is the window, recoverable in closed form from the result.
"Offset-free — no absolute window enters"falseThe absolute window was still applied during pairing. This is the sentence that made the artifact invisible.
The measurements bound an inter-device quantityunidentifiableAll 54 pairings are phone-corpus, where hostAxis.independent is false — host residual spread 0.98 ms, one stamp quantum, because the host column is derived from the device stamp. No second clock exists in that corpus. Box captures: independent: true on 30/30.
The ECG and PPG axes are sound; only the coupler was at faultrefutedECG fs was taken from the lossy [ms] column and rounded to nominal 130 Hz: 46–126 ppm, 1.25–4.16 s per night. The O2Ring's marker-inflated row rate was read as its sample rate: ~6,900 ppm.
"0 of 54 pairings clear the gate, in every configuration tried" — the negative result standswithdrawn as a findingTrue of those runs, but the gate weighed a statistic that saturates at its own pairing window, and PHYS censored 16 of 19 box site-nights (one at 97.4 %, uncensored median lag 831 ms). An instrument in that state could not have found a positive.
The corpus provides ~8 usable nightsrefuted2 site-nights. Censoring is bimodal (0.0–0.2 % vs 4.9–97.4 %), and a low censored share does not identify a usable night — 2026-08-02 is 0.1 % censored and anatomically impossible.
PEP is an untested inferencenow measuredSeismocardiography from the chest accelerometer puts aortic opening at 92–124 ms across four nights, up to 19.6× a phase-scrambled control.
Phone timestamp = start + device-elapsed (§3.3)standsSurvives both corrections. Now strengthened: it is why the phone corpus has no second clock.
v1's 47.7 ppm crystal explanation is refutedstandsv3 does not reinstate v1. The beat-slip diagnosis was correct; only what replaced it was wrong.
A negative result is only as strong as the proof the instrument could have found a positivestandsApplied to v2 itself, it is what produced v3.

Table 4 · v2 → v3 disposition. Three claims survive, four are refuted or withdrawn, one is an artifact, one is upgraded from inference to measurement.

Why v3's error was missed, stated plainly. v2's ~96 ms passed every check v2 had learned to run: it was stable across nights, it was measured with a slip-immune metric, and it was smaller than the quantity it replaced — it looked like the residue left after a careful correction. Three things hid it. First, the phrase "offset-free" was believed rather than verified; the window was still there, one call below the metric that claimed to be free of it. Second, the number was never divided by anything: 450/√12 is a one-line check that would have identified the window immediately, and nobody performed it because the figure was already believed to be physiological. Third, and most consequentially, the same corpus was used a third time without ever asking whether it contained two clocks. It did not, and one command (hostAxis.independent) answers it. v2 correctly diagnosed that v1 had trusted an uncalibrated instrument, then trusted an uncalibrated corpus.

The rule this second episode adds to v2's: when a correction replaces one mechanism with another, the replacement inherits none of the original's scrutiny and needs its own. A correction feels finished because it was hard-won, and the new mechanism arrives already wearing the credibility of the work that displaced the old one. Both of this paper's wrong mechanisms were plausible, quantified, and stable across nights; both were artifacts of the measuring apparatus; and the second survived four months longer than the first precisely because it was the product of a correction.

Why it was missed, stated plainly. The drift number was large, stable across nights, and landed inside a band that a known physical mechanism predicts — quartz tolerance. That coincidence supplied a ready explanation, and the check that would have broken it (does the drift scale with recording length?) was never run, because the answer felt already known. The secondary metric that should have provided independent confirmation was structurally blind to the failure mode. And the accelerometer repair was abandoned on the strength of its own failure, without ever asking whether it could succeed on a case with a known answer. None of the three omissions required new data or new equipment.

The generalisable rule this episode supports: a negative result is only as strong as the demonstration that the instrument could have found a positive one. A null from an uncalibrated search is not evidence about the world; it is evidence about the search. Where a plausible physical mechanism is invoked, at least one prediction that mechanism makes and its rivals do not should be tested — here, proportionality to recording duration, which costs one correlation over an already-published table.

v2.8.0