Improving Accuracy Without Guessing

PROBE now gives a clear found-or-not-found answer in 75.92% of our production-parity tests, up from 72.44%. Decision accuracy rose from 95.34% to 96.38%, and recall for known accounts rose from 85.05% to 88.70%. Most importantly, none of the 648 missing-account controls were reported as found.

Start with evidence, not a bigger claim

We began by collecting browser evidence across all 373 active sources. That run recorded response codes, redirects, page content, screenshots, and selected JSON responses. It did not automatically label every source as working or broken. A challenge page or identical response shell is evidence of uncertainty, not evidence that an account exists.

We then compared that browser evidence with the same request and classification path used by the live service. The measurement campaign contained 947 controls across all 324 automatic sources: 299 usernames expected to exist and 648 expected not to exist. The remaining 49 active sources are manual-only and stay outside the automatic accuracy score.

Change only what a paired test supports

Each source fix needed a known account and valid missing usernames that produced a repeatable difference. That exposed exact signals such as an availability response, a missing-profile title, a source-specific status code, or a stable identity field. Generic rules such as “HTTP 200 means found” were not accepted.

The controls also had to resemble usernames that each platform would accept. Our earlier generated names were long and contained underscores. Some sites rejected that format before checking whether the username existed. We replaced them with short, lowercase alphanumeric controls so the test reaches the behavior it is meant to measure.

Where a page echoed any requested username into a generic shell, PROBE was changed to abstain rather than treat the reflection as proof. That conservative rule removed a false match found during the final verification pass.

A repeatable improvement cycle

The work is now organized as a cycle instead of a collection of broad rescans:

• run one complete production-parity campaign;
• group unclear results by body guard, unusual status, blocking, timeout, or request error;
• retry only the actionable cohorts at low concurrency;
• apply a source rule only after paired positive and negative evidence agrees;
• run focused checks, the full test suites, and one final campaign;
• preserve checkpoints and provenance so a later run can be compared honestly.

This matters because repeating the full catalog until the numbers look better would mix temporary network variation with real improvement. The targeted retry showed that most remaining uncertainty is structural: generic response shells, access blocks, unusual server responses, and timeouts.

What the result means

The final campaign made 719 clear decisions from 947 controls. It fully verified 196 of 324 automatic sources, compared with 177 in the published baseline. Calibration was ready, and the held-out test retained 100% decision accuracy at 83.87% coverage.

Zero observed false matches does not mean a false match is impossible. It means none appeared in this controlled run, and the release gate prevents us from trading that result away merely to increase coverage. Public username data remains a lead, not proof that two accounts belong to the same person.

Ready for the live service

At the time of this historical campaign, the reported release gate met its configured thresholds, including 100% observed found precision. A subsequent audit found that eight positive controls in this run were promoted from archive history rather than confirmed by a live response. The historical numbers above are preserved, but they must not be interpreted as independently verified current-account precision or as a release assessment of today's classifier. Automatic archive promotion has now been removed.