What the modelgets wrong
I built a viewer for the model's mistakes one by one — and it pointed at the preprocessing, not the model.
A summary metric tells you how often a model is wrong. It does not tell you why. So the project included an interactive error-analysis viewer — for each examination, ground truth against prediction, frame by frame.
The point was to separate two kinds of mistake: errors the model could plausibly learn to fix, and errors that are out of its reach given the data it is shown. The second kind is the more useful finding.
The model was not the problem. The preprocessing was.
The viewer made a pattern obvious: the model struggled most with very small pathologies. Tracing it back, the cause was not the architecture — it was a preprocessing step. FA frames are captured at 334 × 334 pixels and resized to 224 × 224 before the backbone ever sees them.
The finding was taken directly to the engineer who owns the preprocessing pipeline. He confirmed the concern was real — but it is a genuine trade-off: more detail costs memory and inference latency. Weighed against the project’s hard efficiency requirement, the change was set aside, not buried — documented as a known, deliberate limitation for the next phase.