Learning rewrites the template in place, which means a rate that climbs over an
evening has three explanations and the numbers cannot tell them apart: the
template got better, the sensor got wiped clean, or the user learned where the
sensor likes to be pressed. Jorijn named the second and third while the numbers
were still going up. All three move the same way on the same time axis, and the
first trend run had no way to separate them because no earlier version of the
template survived.
A snapshot makes the paired test possible. Measure the learned template, restore
the older one, measure again within the same session -- the sensor is equally
clean and the user equally practised across both halves, so the only thing that
differs is the template. A rate that falls back on restore is learning. A rate
that stays up is not.
Restore stops the daemon before swapping the files and brings it back with
learning off, because the trustlet caches the template in memory once loaded and
because a restored template that immediately starts learning again is not a
control.
Two changes to the measurement, both about not wasting a finger.
The wrong-finger control is off by default now. Across every run this project
has made the wrong finger has matched zero times out of forty-odd taps; the
question that is still open is the false-negative rate, and each control tap
spends a press that could have measured it. Pass a count to put the control
back, and the summary says plainly when it was not run rather than printing a
zero that reads like a result.
And a trend run now reports how many frames learning folded, out of the daemon's
own transcript, alongside the container size. Without that a run cannot tell
"learning fired and did not help" from "learning never fired" -- which is exactly
the confusion that let the first trend run measure a static template three times
and look like a result.
Default trial length goes to fifteen taps, since dropping the control freed the
presses and ten was too few to separate three-in-ten from five-in-ten.
Measured 2026-09-04: the trustlet's duplicated-finger check refuses to re-enrol
a finger it already has a template for -- 0 accepted of 7 presses, rc=0 on each,
while a never-enrolled finger progressed normally. Re-enrolment adds a template
and there is no trustlet-side remove, so a measured finger's old template has to
go before it can be enrolled again.
wipe does that the way it has been done by hand twice: backup first, daemon
stopped so the trustlet reloads from the store, only the template containers
removed, the group index kept because deleting it risks the RPMB anti-rollback
counters going stale, the name map cleared, then a restart and the sizes.
enrol checks the name map and refuses a finger that is already there, pointing
at wipe, so the refusal cannot be mistaken for bad pressing again.
Learning rewrites the template on every matched press, so run two is not a
repeat of run one and an A/B against a moving template is not an A/B. The order
is the measurement:
enrol a fresh template at 20 samples with no position prompts, which is also
the outstanding replication of the best result this lane has seen
base learning off: the clean number for that template, and the only figure
comparable to every rate already recorded
trend learning on, three times: the rate should climb, with the container
size as an independent witness that it is the template moving
A rate that climbs while the body grows is learning. A rate that moves while the
body does not is noise, and the daemon's own learn: lines say which. Run one of
the trend is not evidence that learning helped; it starts on the template the
baseline ended on.
One limit the script states rather than letting someone discover it: learning
only fires on a press that matched, so a template that never matches never
improves. That is why the protocol re-enrols instead of building on a template
already measured at 0 of 10.
