BPM Tap Tempo mechanism

Model scope

The BPM formula itself is correct under the stated millisecond assumption. Review is required to define the rolling-window size and startup behavior, specify timestamp units, define confidence/variance, and establish validation for duplicate, non-monotonic, insufficient, or zero-length intervals.

• BPM=60000/avg(interval_ms) is the standard formula when the average interval is expressed in milliseconds.
• The rolling-window size and policy are unspecified, including how many intervals are included and how startup windows are handled.
• The claimed confidence/variance output has no formula or definition, so it cannot be verified.
• The input timestamp unit is unspecified even though the formula requires intervals in milliseconds.

Units and conventions

• The constant 60000 is milliseconds per minute.
• Tap timestamps must be converted to milliseconds before interval averaging.
• Timestamps are assumed to be monotonically increasing.
• The average is the arithmetic mean of consecutive tap intervals in the selected rolling window.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "timestamps": [
      1000,
      1500,
      2000,
      2500
    ],
    "timestamp_unit": "ms"
  },
  "expected_outputs": {
    "BPM": 120
  },
  "working": "Intervals: 1500-1000=500 ms, 2000-1500=500 ms, 2500-2000=500 ms. Average interval=(500+500+500)/3=1500/3=500 ms. BPM=60000/500=120 BPM."
}

Failure boundary

BREAK_CLAIMED · SELF_FLAGGED

Coincident timestamps produce a zero denominator and therefore an undefined BPM, with no specified rejection behavior. The specification also leaves timestamp units and handling of out-of-order taps insufficiently defined, allowing materially different outputs.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json
• evidence-tranche4/tranche4-results.json
• BOUNDARY_HAZARD_CATALOG.json