# Recorded authentication verdicts

Verdict lines excerpted from three real authentication runs on the dev phone,
2026-09-02. Only the `AUTH` lines are carried: the full transcripts are ~40 KB
each and are thick with the device's SFS container names, none of which this
test needs. Originals are in the fp6 journal under
`journal/fingerprint/captures/`.

| file | run | recorded outcome |
|---|---|---|
| `auth-enrolled-finger.txt` | the enrolled finger, `max_authentication_rescan_times: 0` | 15 match, 5 rejected, 5 frames the matcher never saw |
| `auth-wrong-finger.txt` | a different finger, same config | 0 match, 19 rejected, 2 never ran |
| `auth-stock-budget.txt` | the enrolled finger at the stock rescan budget | 8 match, 31 "no match", 9 never ran |

The third file is the important one and uses an **older label**: its 31 "no
match" lines are `rc=-11` frames, which mean *not identified yet, attempts
remain* — not rejections. Counting them as rejections turns an 8-for-8 run into
an apparent 8-of-39 and reads as a flaky sensor. That mislabelling happened
three separate times before the comparison producing `-11` was actually read,
which is why the counting rule has a test at all.

The two forced-terminal runs set the rescan budget to 0 so every frame yields a
verdict. Their 15/20 is therefore a per-frame figure measured with the retry
mechanism disabled, **not** a shipping reject rate; per press it was 5 of 5.

`fid=1296911490` is the enrolled template's identifier on one dev phone. It is
an opaque id, not biometric data — a template is a separate 258850-byte
QTEE-encrypted container that never leaves the TEE.