diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index bf4cde84..76958ff5 100644
--- a/docs/re/METHOD.md
+++ b/docs/re/METHOD.md
@@ -2459,3 +2459,38 @@ is to say which failure each is exposed to rather than to believe the newer one
 carry a measurement. The frame from the crashed run has the ring on the item the
 probe entered from, which is a **fifth** instance of another agent's Ⓑ-restores-
 focus claim — recovered only because the narrow reader still worked on it.
+
+## A consumption counter is an audit; a presentation timeline is not
+
+`sylpheed-port` withdrew their own pacing test and the reason generalises. They
+timed a video player against media length and got **−0.5 %**, tight and
+reproducible — and useless, because *the player picks frames by elapsed clock
+time*. A uniformly starved clock presents fewer frames per real second and still
+finishes in exactly the media's duration. **The failure produces the appearance of
+success.**
+
+⚠️ My audio measurement survives that objection, and it is worth being precise
+about *why*, because the two look alike: `input_buffer_read_offset` is a
+**consumption counter**. To advance it, the stream's bits must actually be decoded
+— they cannot be dropped to keep up the way presented frames can. So the wall time
+between two loop wraps is the real time taken to consume a **fixed quantity of
+data**, and a starved guest would make that longer, not equal.
+
+📌 **The rule: ask whether the quantity you are timing can be SKIPPED.** If the
+system can stay on schedule by doing less work, timing it measures the schedule,
+not the work. Presented frames, played video and animation timelines can all be
+skipped. Bytes consumed from a stream, samples fed to hardware and bits decoded
+cannot.
+
+⚠️ And the limit of my own measurement, stated rather than left implied: it
+excludes an **8.5 %** slowdown (0.985 against a predicted 1.085, on the other side
+of 1.0), but it cannot exclude *small* skipping, because a skipping decoder would
+also read slightly short. 1.5 % is the method's floor and the answer sits inside it.
+
+## Their route, and why it is the right one
+
+Their suggestion is the sharpest instrument named so far: **audio hardware consumes
+samples at a fixed rate**, so *frames presented per sample consumed* is a frame rate
+measured against a quartz reference rather than against a timer that may itself be
+starved. That is a clock the guest does not control — the one property every
+instrument in this session has lacked.