Inside Autonomous Resolution: Validating Vision-Based Outcome Detection
For a first supported case, a vision-detection model can now read a prediction pool's outcome from the stream itself — validated against real, recorded settlements, and refunding rather than guessing when it isn't sure.
Every prediction pool eventually needs to answer one question: what actually happened? For as long as PLLAY has run pools, a person has answered it — usually the creator, sometimes an admin stepping in on a dispute. This month, for a first supported case, that answer can be read from the stream itself — a step toward reducing how much of that answer depends on a person being available, not a replacement for the person yet.
We built this in one phase so far, deliberately scoped payout-neutral. It's a resolution-spec model plus vision-generation work that watches a stream and labels what it detects — for the first supported case, CS2's bomb-plant moment — without touching a single payout. We ran that model against real, recorded settlements to see whether its outcome calls matched what a human reviewer would have said, and they held up. It has not yet been switched on to settle a live pool automatically — see pllay.io/validation for the full bench record, including every case that didn't resolve cleanly.
The design for the step after this one is already decided, even though it isn't live: a worker that would take the vision system's outcome call and carry out the payout — or, if the system isn't confident enough in what it detected, refund every entry instead. That refund path isn't a fallback we hope never triggers; it's the design. A system that's occasionally wrong about a game state and pays out anyway is worse than one that's occasionally wrong and returns everyone's stake — so any future automated settlement is built to prefer the refund over a bad guess every time.
Autonomous, when it ships, will not mean unsupervised. Every automatic settlement will be visible through a Resolution Console, so the team can review what the system decided and why, and a House Account view keeps the ledger it would touch fully reconciled and auditable today, ahead of that. The goal was never to remove people from the loop — it's to eventually remove them from the critical path of every single pool, once the validation record earns that.
CS2's bomb-plant detection is the first case we validated this way, not the only one we're building toward. The pattern — vision detection validated payout-neutral first, then (once earned) a settle-or-refund worker, then a review console watching over both — is the template for extending this work to more games from here.