The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Sorting a review queue by "worst reading first" hid the fraud
Docket's review queue used to sort by the worst extraction first. We replayed it on 122 waiting documents where the right answer was known. The money-at-risk ones (duplicates, bank-detail changes, PO mismatches) sat at an average position of 95, and only one was in the top 20.
The reason: a forged bank-detail change is read perfectly, so it sank.
The new order puts any failed gate first, then a wrong value, then risk score. Fraud in the top 20 went from 1 to 14, and the average position from 95 to 33. A second-opinion model placed before the score made the ranking worse, so it now only breaks ties.
If your AI pipeline has a review queue, check what actually rises to the top.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Re-measure what you publish
Two numbers I had to correct on my own site:
The AI receptionist's lead decision was published as 2.8 s, from a one-day benchmark. On 281 real leads the median is 3.0 s and the p95 is 12 s (one model misses its deadline and the next one answers).
The site claimed 137 leads scored. Most were owner test leads and development runs. The real number was 6.
Now every public number comes from the running system, and test rows are tagged and excluded rather than deleted. Live status: status.adaptivesystems.dev
If a vendor shows you AI metrics, ask where they were measured.
Landing page for an AI search analytics platform, 2nd variation.
The lighter background makes the CTA the first thing you see. Motion adds a premium feel.
A visitor decides in about 5 seconds whether to stay. In this design, the CTA does the job well.
A/B testing like this is one of the best ways to see which design w
Nice work
One real document beat 100 synthetic ones
Dossier caught 100% of our synthetic forged applicant packs with zero false alarms. Then the first genuine UK bank statement arrived by email, and it was flagged as "balances don't add up".
Every row did add up. The problems were all ours:
Side-panel figures ("Average credit balance") were read as row balances.
The same amount, paid in and paid out, was matched to the wrong column.
Dates printed without a year were marked wrong.
A four-line address wasn't found, because the verifier joined at most two lines.
Two identical payments on one day were merged into one row.
Each got a general fix. The code now learns each money column per page, and skipped rows are found by re-walking the running balance. The forgery eval is unchanged.
The lesson: synthetic data proves your checks catch what you forge. It doesn't prove your reading survives real layouts.