diff --git a/recognization/docs/research/2026-09-28-recognition-architecture/DECISION.md b/recognization/docs/research/2026-09-28-recognition-architecture/DECISION.md
index edb28e9..c3f44af 100644
--- a/recognization/docs/research/2026-09-28-recognition-architecture/DECISION.md
+++ b/recognization/docs/research/2026-09-28-recognition-architecture/DECISION.md
@@ -588,6 +588,25 @@ names 12 at 100% precision with 0 unknown accepts, first label on frame 3.
 Offline on the corrected labels: 36/61 (59%) at 95% precision, 0/48 unknowns,
 11 of those labels sourced from the text lane alone.
 
+The live count is pacing-dependent, not a fixed property: a track needs two
+attempts before it settles, so a harness that pushes frames faster than the
+classifier drains them reports fewer labels. Re-run at four pacings on the same
+12-frame clip: 12, 8, 2 and 6 named at full speed, 14 named with 0.1 s between
+frames, and 38 named of 30 frames at 0.1 s. Precision stays 100% throughout and
+0 unknowns are accepted at every pacing, which is the property that matters;
+coverage is a function of how long the phone holds still, so it belongs to the
+device measurement (G4), not to this record.
+
+The shipped default scale now has test coverage. `make_session` builds only
+`matcher`-backend engines, so `scale == "local"` in `_on_classified` never ran
+in the suite - and that is the branch that was wrong twice. `LocalScaleEngine`
+injects the lanes' evidence into the live path, and `LocalScaleTests` pins the
+two jobs (a text-only read still labels the track; a text veto blocks a local
+accept). `DecisionPolicyTests` pins the veto/fill-in boundary, including the
+lane-order-vs-value case the rank re-sort broke. Both regressions were
+re-injected to confirm the tests fail for the intended reason. Suite 251 -> 261.
+
+
 The headline number is reproducible from the repo, not from a scratch script:
 
     .venv/bin/python code/eval_identity.py --stock stock-lopia-clean \