How review works
Every game is checked by a machine and then by a person before anyone can play it. Here is exactly what happens, and what each status means.
- Validator first
- Then a human
- Resubmit anytime
The path from submit to live
There is one pipeline. A game your agent built and a file you uploaded by hand go through exactly the same three gates, in the same order.
- 1ValidationAutomatic and instant. Static checks plus a real load of the game. Errors block submission; warnings do not.
- 2Drafts, if an agent built itA game built by an agent lands in your Drafts rather than the queue. Nobody is reviewing it yet. You play it and submit it yourself — that step is where you accept the licence over your work, so an agent cannot do it for you. A game you upload by hand skips this: the form is where you accept.
- 3The moderation queueYour game joins the queue as soon as you submit it. A moderator plays it and reads it against the content policy.
- 4Live in the feedApproval publishes it immediately. Nothing else has to happen and there is no scheduled release.
What the validator checks
The validator is not a taste test — it only looks for things that would make your game broken or unsafe in the feed. It runs in milliseconds, so your agent can call it after every edit and repair what it finds without you being involved. A submission needs zero error-severity issues; the count is re-derived on the server when you submit, so a stale pass cannot be reused.
A game generated under a token limit often stops mid-function, which reaches a player as a black rectangle. Every script is syntax-checked, and the game is then loaded for real so runtime errors surface before a moderator ever sees it.
The sandbox blocks outbound requests at the CSP level, so a fetch() or an external <script src> is not a style preference — it is a game that will silently fail in the feed. The validator names each call and the file has to be self-contained before it can be submitted.
An agent key left in the HTML is a blocking error, never a warning. Your game's source is served to every player, so a token in it is a token you have published.
The file has to be under the upload size limit, and achievement keys your code unlocks are cross-checked against the ones you declared. Key mismatches are warnings — they will not block a submission, but the unlock will do nothing in the feed.
Uploading by hand gets you the same report in the browser at /create/upload. The constraints behind these checks are written out in full in the SDK reference and in the agent spec, which is the version to hand an agent before it starts writing.
The moderation queue
Passing validation does not publish anything. It puts your game in a queue where a person opens it, plays it, and decides. There is no auto-approval path and no risk score low enough to skip this — an agent-built game is reviewed exactly as closely as a hand-written one.
What a moderator is judging is whether the game belongs in a public feed that anyone can swipe into: it does what its title and description say, it is playable rather than a broken shell, and its content and cover art are within the content policy. If a game is a borderline call they can escalate it for a second opinion rather than guessing.
Review is done by people, so it takes as long as it takes — there is no queue-jumping and nothing you can pay to speed it up. You do not need to keep the page open, or keep checking back: the decision comes to you as a notification in the bell, and as an email where enabled.
What each status means
In review
Submitted and waiting. This covers a game sitting in the queue and one a moderator currently has open. Nothing is public yet.
Escalated
A moderator wanted a second opinion before deciding. It is a routing step inside review, not a verdict — most escalated games are approved.
Approved
Live. The game is in the feed, its leaderboard is open, and its play counts start moving.
Rejected
Declined, with a moderator note saying why. Fix what the note describes and resubmit, or open an appeal if you think the call was wrong.
Appealed
You have asked a moderator to look again at a rejection. While an appeal is open the game is frozen — you cannot swap its HTML or its cover, because the decision has to be about the version that was actually judged.
If your game is rejected
A rejection always carries a moderator note. Read it first — most rejections are a specific, fixable thing rather than a judgement on the whole game.
- Fix and resubmit. Upload a new build of the same game and it goes back into the queue with the moderation note cleared. Your agent can do this for you by opening an update session against the existing game.
- Or appeal. If you think the decision was wrong rather than the game, open an appeal from the game and say why, and a moderator looks at the rejection again. While the appeal is open the game is locked — you cannot resubmit its HTML or change its cover until it resolves, because the decision has to be about the version that was judged.
What sends a live game back to review
Approval covers the exact version a moderator saw. Change what the public gets and it needs approving again — while it is back in review the game leaves the feed, then returns when it clears.
Replacing a live game's HTML — which is exactly what an agent update session does — puts it back in review. Your agent is warned about this before it submits, and told again afterwards. Plan updates for when you can afford the game to be out of the feed for a while.
A cover is public-facing content, so swapping it on a live game sends it back for re-approval too. On a game that has not been decided yet the swap is silent — there is no decision to invalidate.
Player reports are the other route back. A report does not change your game's status by itself — it opens a case a moderator reads, and they decide whether the game keeps running, comes back to the queue, or comes down.