The Five Proofs Your Game Needs Before Clowdr Publishes

Before you submit a Release Candidate, make it possible for someone else to check why the game is ready. Link the build, the observations, and the decisions behind each of Clowdr's Five Proofs of Release.

A Project is Done when its approved tickets are complete, its Release Blockers are resolved, and the integrated game meets the publishing standard. The Project Lead then submits the Release Candidate. Clowdr decides whether to publish it.

The requirements below come from How We Ship and the approved Clowdr Process. The evidence packet is a suggested way to apply them. All orchard-game examples in this guide are hypothetical, not observations from a Clowdr Project.

Start with one identifiable candidate

Give the submitted build an identifier, such as a release tag and commit. Keep the approved Player Promise, Feature Scope, and Quality Baseline beside it. Each proof should point to the build or artifact actually checked, with the date, conditions, responsible person, result, and limits of that check.

If you fix a blocker after testing, record what changed and repeat the affected checks. An observation about an earlier build needs a clear reason to remain relevant to the candidate you submit.

1. Promise Proof: deliver the approved player experience

Promise Proof asks whether the complete game delivers the approved Player Promise. Connect that promise to playtest observations across the intended experience, including its ending. A working mechanic is only part of that evidence.

Playtesting is mandatory. Clowdr does not prescribe a universal tester count or coverage formula. Record who played, what they tried, where you helped them, and what they could or could not do. Explain what remains uncertain.

Hypothetical example: an orchard puzzle game promises a short, calm experience built around choosing how to route water. A useful playtest record would show whether a player understood the choices, reached the ending, and experienced the intended pace. If the Lead explained every puzzle aloud, record that intervention. It limits what the session proves about the game's instructions.

2. Build Proof: check the critical path on every stated platform

Build Proof asks whether the critical path works on every platform you claim to support. Keep the platform and environment with each result, and test the distributed build through the actions required to complete the game.

For the hypothetical orchard game, that path might be launch, start a game, learn the controls, solve the puzzles, reach the ending, and return to the menu. Include saving or loading if those actions belong to the approved scope. A successful editor session cannot establish that a downloaded build works.

Hypothetical example: a desktop check would not establish browser compatibility. If both are stated platforms, collect evidence for both. A broken ending remains a Release Blocker even when every implementation ticket is closed.

3. Craft Proof: compare the whole game with the Quality Baseline

Craft Proof asks whether the complete game meets or improves on the approved Quality Baseline, without placeholders or Unowned Output. Use the approved Vertical Slice as a reference, then inspect the rest of the integrated game for the same standard of coherence and polish.

Check art at gameplay size: can players distinguish a water route, an obstacle, and a decorative prop? Check audio during play: do cues enter, loop, and stop correctly, and can players hear necessary feedback? Check design and writing together: do instructions match the rules and the choices the player can actually make?

Hypothetical example: a pleasant music cue that masks puzzle feedback needs an in-game mix check and a recorded correction. A standalone audio export cannot show that the cue serves the player in that scene.

Name the person who can explain, revise, integrate, verify, and hand off each contribution. AI-assisted work and deliberately non-AI work face the same craft requirement.

4. Ownership Proof: account for the work and its origins

Ownership Proof covers contributions, provenance, rights, AI disclosures, attributions, and credits. Keep those records connected to what appears in the candidate. The Lead maintains the credit list; check it against accepted contributions, including art, audio, writing, testing, and production work.

Hypothetical example: a final orchard sprite should have a traceable contribution record, its source and applicable rights information, any required attribution or AI disclosure, and the contributor's credit. An unresolved rights question belongs in the blocker record, not in an assumption that someone else already checked it.

The Release Candidate also needs a Final AI Production Note. Update the pitch's planned AI position into what actually happened:

• Actual AI use or deliberate non-use, and where it mattered.
• Material human decisions, including changes or rejected output.
• Verification performed and the evidence supporting it.
• Provenance, rights, required disclosures, and attributions.
• Material changes from the pitch note.

Keep detailed supporting records where needed. A concise version of the note is published with every Clowdr Release. A deliberate decision not to use AI still needs an honest final note.

5. Publication Proof: present the candidate accurately

Publication Proof asks whether the game and its release materials are ready to appear under the Clowdr brand. Compare the description, screenshots, instructions, supported platforms, credits, disclosures, and public production note with the candidate being submitted.

itch.io is the default release destination. A Lead may request another destination when compatibility is proven. Keep destination-specific evidence with the submission.

Hypothetical example: if the orchard game's page promises a browser version, a desktop-only download does not support that claim. Record the mismatch for resolution before publication. A screenshot should show the candidate's actual player experience rather than suggest a feature outside the approved scope.

Prepare five evidence entries for Publication Review

For each proof, write a short entry using this structure:

Proof: which requirement is being checked?

Candidate and artifact: build identifier and links to the relevant records.

Owner and check: who checked what, when, and under which conditions?

Result: what did the check establish?

Limits and remaining work: what did it leave unproven, and are any blockers unresolved?

The same playtest can support several proofs. Explain its relevance to each one. Attach the Final AI Production Note and publication materials so the reviewer can assess the complete submission.

Clowdr's Publication Review has three outcomes:

• Accepted: Clowdr publishes the game under its brand, by default on itch.io.
• Revision Required: Clowdr identifies correctable blockers and the Project stays on its publication path.
• Publication Declined: Clowdr makes the final decision not to publish the game under its brand.

An Independent Release requires both Publication Declined and explicit written Independent Release Authorization plus a project-specific sublicense from Freistil ApS. Silence, delay, Revision Required, membership changes, and an incomplete review grant no independent-release authority. Authorization excludes the Clowdr brand, accounts, trademarks, and storefront presence, and preserves credits, attributions, disclosures, and existing licenses.

Start your packet before the last ticket closes. For every missing proof, name the gap and the work needed within the approved scope. That gives the Lead a concrete path to a Release Candidate that Clowdr can assess.