# Seconds per step — two honest instruments, and the rule for each

The article says the wide adapter took **ten minutes and eight seconds** to train. That
figure is the trainer's own banner and nothing here disputes it. What follows is the
smaller number underneath it — seconds per optimiser step — because two instruments in
the same run report it differently, and a reader who divides the banner by the step count
will not get the number the lab's ledger calls authoritative.

**The whole disagreement is 2.0 seconds of wall clock,** and it is named rather than
resolved: both readings are true of different things.

## The wide run (`20260831T023450Z-mnml0`, 159 tracks, 400 optimiser steps)

| reading | s/step | denominator, and what it counts | where it is written | authoritative? |
|---|---:|---|---|---|
| **A — all ten passes** | **1.5150** | the ten `[OK] Epoch` lines sum to 606.0 s; 606.0 / 10 = 60.60 s per pass, ÷ 40 steps per pass. **Excludes** model load and the two checkpoint writes, because the pass clock does not run during them. | the lab's ledger, marked authoritative; the tool line reads *"derived from [OK] epoch lines"* | **yes** |
| **B — passes 2–10** | **1.5169** | passes 2..10 sum to 546.1 s; 546.1 / 9 = 60.6778 s, ÷ 40. Drops pass 1 as the warm-up pass, which is how the three composer runs in the earlier exhibits were counted. | the composers' materials pack | the composers' figure only |
| **C — the banner** | **1.5200** | 608 s ÷ 400 steps. **Includes** model load and both checkpoint writes, because the banner clocks the whole run. | the lab's ledger, marked NOT authoritative; the tool line reads *"derived from the Training Complete banner"* | explicitly **no** |

Same three rules as seconds per training sample: **A 0.3811** · **B 0.3816** · **C 0.3824**.
Mean pass time, stored beside them: **60.60 s**.

Spread A→C is 0.0050 s/step — **0.33 %**. Nothing in the article turns on which one you
pick; the point of printing all three is that the difference is a counting rule, not a
measurement error, and a reader who recomputes from `train-mnml0.log` should land on one
of these three and know which.

A partial unique index in the ledger makes *"exactly one authoritative row per (subject,
metric)"* a database constraint rather than a habit: both readings coexist as rows, and
only one of them is the answer.

## The one-artist control (`20260831T193904Z-fmctl0`, 24 tracks, 60 optimiser steps)

Three readings, the same way: **1.5267** (91.6 s of pass time ÷ 60 — the basis the article
uses) · **1.55** (the 93 s banner ÷ 60) · **1.70** (102 s of wrapper wall clock, which also
counts model load).

## How to recompute either one

Both logs are in this kit. The pass lines are the ones beginning `[OK] Epoch`; the banner
is the `Total time` line inside the `Training Complete` block. Rule A sums the pass lines
and divides by the steps the log's own `Total steps` line reports. Nothing else is needed,
and nothing in either log was altered except the filesystem paths and the card's name —
`provenance.json` says how many times each substitution fired.