How a Take Gets Resolved: Inside Standom's Resolution Engine

A prediction platform lives or dies on one thing: whether people trust the settlement. You can build the prettiest market card in the world, but if a player makes a correct call and the platform quietly decides otherwise, that player never comes back — and they tell their group chat why.

So this article is the least glamorous and most important thing we can publish: exactly how a take on Standom gets from "open" to "settled", who decides, what evidence counts, and what we do when the evidence isn't good enough.

The three states a take can end in

Every take resolves to one of three outcomes.

Yes. The event described in the take happened, as described, inside the window described.

No. The window closed and the event did not happen, or the opposite happened.

Void. The question could not be answered fairly. Everyone's Stars are returned as if the take never existed. This is the outcome we work hardest to avoid, because a void is a small failure of authorship — it means the question was written in a way reality did not cooperate with.

There is no fourth option. We do not leave takes open indefinitely, and we do not resolve a take on vibes, on what most players predicted, or on which outcome is cheaper for us.

Step one: the deadline is an instant, not a day

Every take carries two timestamps. The acceptance deadline is when new predictions stop being accepted. The resolution deadline is the moment the question is due to be answerable.

Both are stored as absolute UTC instants, not as calendar days. This sounds pedantic until you have watched a cricket match finish at 11:40 PM IST on a Tuesday and had a market disagree with itself about whether "Tuesday" had ended. Days are a display concern. Deadlines are physics.

What players see is localised to IST, because that is where most of our players are. What the engine compares against is the instant.

Step two: the scheduler notices

A background job wakes up on a fixed cadence and asks a simple question: which takes are past their resolution deadline and not yet settled?

We use polling rather than per-event timers on purpose. A timer scheduled for 8:00 PM three weeks from now is a promise your infrastructure probably cannot keep — it dies with the process that created it, and a single deploy silently drops it. A poll that runs every fifteen minutes and asks "what is due?" is boring, survives restarts, and catches every take that a timer would have missed.

Only one instance of the platform runs these jobs at a time, even when several are serving traffic. That coordination is a lease: an instance claims the right to run scheduled work, renews it while it is healthy, and releases it on shutdown. Without that, three servers would each try to resolve the same take at the same moment.

Step three: the engine looks for evidence

Now the interesting part. For each due take, the engine assembles what it needs to answer the question:

• The question text itself, exactly as players read it.
• The resolution criteria — the plain-language description of what makes it Yes, written when the take was authored, never edited afterwards.
• The source class the take was written against: a scorecard, an official announcement, a certified box-office reporter, a governing body's published result.
• The search evidence gathered at check time.

That evidence goes to a typed resolution step that has to return a structured verdict: an outcome, a confidence, the reasoning, and the specific sources it relied on. It cannot return prose that a human then interprets. If it cannot fill in the structure, it has not resolved anything.

Step four: the confidence bar

A verdict on its own is not enough. The engine sorts what comes back into three buckets.

High confidence, clear evidence. The take settles automatically. This is the overwhelming majority: a match has a scorecard, an award has a ceremony, a release date either happened or didn't.

Medium confidence. The engine does not settle. It schedules another look, with a backoff — the interval between checks widens as attempts accumulate, so a take whose evidence is still arriving is not burning a check every fifteen minutes for a week. Cricket scorecards land within hours. Certified box-office figures take days. A market about a certification body's decision can take longer than either. The recheck cadence follows the take, not the clock.

Low confidence, or contradictory evidence. The take escalates.

We learned the value of that middle bucket the hard way. An early version of the engine could return "suggest" indefinitely — medium confidence, look again later, forever. Takes sat in "Resolving" for days because nothing ever forced a decision. Now the number of attempts is bounded: after the last one, a take either resolves or goes to a human. Ambiguity has a deadline too.

Step five: escalation, and the second opinion

When a take reaches its final attempt without a clean answer, one more thing happens before a human sees it.

A second resolver — a different approach entirely — takes a pass. Where the main pipeline is a single deterministic shot at the question, this one works the way a person would: plan what to look for, search, read what came back, reassess, search again from a different angle, and only then commit to an answer with the sources that support it.

If that resolver comes back with a clear outcome backed by at least two independent sources, the take settles. If it doesn't, the take goes into a human review queue with everything attached: the evidence, the reasoning, and its suggested answer with the reason it wasn't confident enough to act alone. A person makes the final call.

We publish this detail because it is the honest shape of the system. Most takes are settled by machine. The hard ones are settled by a person reading what the machine found.

Step six: settling is idempotent, and that matters

When an outcome is applied, two things have to be true, and both are enforced rather than hoped for.

A take can only be resolved once. The write that applies an outcome is conditional on the take still being in a resolvable state. If a retry, a duplicate job, or a second instance tries to apply an outcome to a take that already has one, the write is refused rather than overwritten.

Every prediction settles exactly once. Payouts claim each active prediction individually as they move it to its final state, behind a settled flag on the take itself. A job that crashes halfway through and restarts finishes the remaining predictions instead of paying the earlier ones twice.

This is unglamorous plumbing. It is also the difference between a leaderboard that means something and one that quietly duplicates a payout during a deploy.

What we do when we get it wrong

We will get some wrong. Two failure modes matter and they are different.

A check that fails — a source is unreachable, a search returns nothing usable — is not evidence of "No". It is an absence of evidence, and the engine treats it that way: no outcome, try again. Conflating the two would settle takes against players every time an external site had a bad afternoon.

A question that was badly written — ambiguous wording, a window that couldn't be met, criteria that reality sidestepped — is our error, and it voids. Stars go back. The take is removed from the leaderboard's inputs. We would rather refund a market than defend a wording nobody could have read the way we meant it.

If you think a settled take was decided wrongly, dispute it. A settled take is not a closed conversation; it is a decision with reasoning attached, and reasoning can be checked.

Why any of this should matter to you as a player

Two practical consequences.

Read the resolution criteria before you make a call, not after. Most disagreements about outcomes are not disagreements about what happened. They are two people reading the same sentence differently. The criteria are on every take, before you commit a single Star.

Prefer takes with a clean source. A question that resolves against a published scorecard is a question that will resolve quickly and predictably. A question that depends on someone announcing something is a question with a longer tail and more ways to end in Void. Both are legitimate to play. They are not the same risk.

The engine's job is to be boring and predictable. If we have done it well, you will never think about it — you will just notice that the answer arrived when it should have, and that it was the answer you already knew was right.