clowdr.devThe Clowdr AI Standard: What Counts as Shippable Work
AI game development standards for Clowdr: human ownership, verification, rights, disclosure, and contributor checks before AI-assisted work ships.
AI arguments usually collapse into a purity test. That is useless for a game project.
Clowdr needs a standard a developer, artist, composer, designer, writer, or project lead can use before AI-assisted work becomes part of a game that ships. Not a vibe. Not a debate prompt. A bar.
This is that bar for code, visual art, audio, design, and narrative. It explains who owns the work, what kind of verification counts, what fails, what gets disclosed, and what happens when contributors disagree.
The Standard In One Sentence
No generated work ships without human ownership and an appropriate verification pass.
"AI is fine, ship whatever comes out" dodges the point. So does "AI touched it, so the work is poisoned." The harder question is whether a human contributor owns this work well enough to put it in the game.
Inside Clowdr, generated material starts as draft material: an agent-written patch, generated prop sheet, temp cue, mechanic list, or dialogue pass.
Drafts can unblock a prototype, make a conversation concrete, or reveal a direction the team should reject before anyone wastes a week polishing it.
Draft is not delivery.
Delivery starts when a contributor can say: I know why this belongs here, where it came from, what I changed, how it was checked, and why I accept responsibility for it.
That is true for AI-assisted and handmade work. A hand-painted sprite with unclear rights and no in-build readability check fails the same way a generated sprite fails. A hand-written system nobody can maintain fails the same way agent-written code fails.
Human Ownership Is Not A Vibe
Human ownership means a named contributor takes responsibility for the final work.
Not the prompt. Not the model. Not "the agent wrote it." Not "the generator made it." A person owns the decision to use the result, the edits made after generation, the risks introduced, and the verification performed.
For Clowdr work, ownership has three parts: decision, source, and handoff.
Own the decision
The contributor must be able to explain why the work belongs in this project.
For code, that means explaining architecture and edge cases. For art, it means explaining style fit, readability, polish, and rights. For audio, it means explaining emotional intent, timing, mix, implementation, and license status. For design and narrative, it means explaining player intent, coherence, constraints, and what changed after testing.
If the answer is "it looked good" or "the model gave me this," the work is not owned yet.
Own the source
Generated work needs source notes.
Every experiment does not need a legal memo. Anything proposed for project use needs enough recordkeeping that another contributor can inspect the decision later.
At minimum, keep the tool name, date, contributor, intended use, license or terms note, and whether the output is concept, temp, internal, or proposed final material. If the terms are unclear, the work does not move into final without review.
This matters because platforms already ask about it. Steam's content survey now has a generative AI section for pre-generated and live-generated AI content, and it asks developers to describe AI use in development or in the product. Steam also says pre-generated AI content is reviewed like other content. See the Steamworks content survey.
Copyright does not appear because a prompt was clever. The U.S. Copyright Office's 2025 copyrightability report says prompts alone do not provide enough human control to make the user the author of the output under current generally available technology. See the Copyright Office Part 2 report.
The practical rule is simple: if nobody can explain the source and rights status, nobody should promote the work.
Own the handoff
AI-assisted work still has to move through a team.
The next contributor should not inherit a mystery box. A handoff should say what the material is, what a human changed, what still needs review, and who signs off.
A generated image board handed to an artist with "make this final" is not a handoff. A generated combat prototype handed to another developer with no notes about edge cases is not a handoff. A temp music cue handed to a composer with unclear rights and no authority to replace it is not a handoff.
What Verification Means For Code
Code verification is not only unit tests.
Games are not SaaS dashboards. Sometimes the right check is a unit test. Sometimes it is a clean build, a smoke test, a profiling run, or a playtest because the bug only appears when a human opens the menu during a transition, dies, reloads, and tries again.
The developer proposes a verification pass proportionate to the risk, and reviewers can require more before the change ships.
An AI-assisted code change clears the bar when a developer can explain the change, place it inside the architecture, name the failure modes, and show that verification matched the risk.
Example that clears the bar: an agent drafts a save migration for a new inventory schema. The developer reviews the data shape, removes unnecessary abstractions, writes a migration test for old saves, runs the build, smoke-tests load and reload, checks the editor workflow, and documents the change.
What Verification Means For Visual Art
Visual art verification happens in the game context, not in an isolated image preview.
A generated image can be reference, mood board, prop direction, color test, placeholder, or throwaway exploration. It becomes shippable only when an artist owns the final direction and the asset works inside the project's visual language.
Example that clears the bar: a project lead generates ten prop variants for a potion shop. The artist uses them as reference, redraws the final props in the project's style, simplifies silhouettes for gameplay size, checks palette against the biome, tests compression, confirms the license path, and adds the final assets to the style bible.
Example that fails: a generated character concept looks expensive, so the team promotes it to final. There is no turnaround, animation plan, material consistency, gameplay-scale silhouette, source note, or rights clarity. That is not final art. That is a JPEG with debt attached.
Artists are not there to rubber-stamp output. They own coherence, polish, readability, optimization, and rights. When that ownership is missing, the asset stays draft.
What Verification Means For Audio
Audio verification happens in the build, against gameplay timing, dialogue, effects, transitions, loops, and player attention.
A track can sound good in a browser tab and still fail a game. It can loop badly, fight dialogue, cover important effects, miss the scene, or create implementation debt because there are no stems, tail, transition plan, or license clarity.
Generated audio is draft material until a composer or audio contributor owns emotional intent, timing, mix, implementation, and rights.
Example that clears the bar: a designer uses an AI tool to create a temp cue with a short motif for a forest boss. The composer treats it as mood reference, writes a new cue, splits stems for combat intensity, mixes against dialogue and hit sounds, tests the loop, checks transition timing, documents rights, and implements the cue in the build.
Example that fails: a generated boss track sounds huge in isolation, so the team drops it into the game. It loops after ninety seconds with an obvious seam, cannot be stemmed for phase changes, muddies combat readability, and nobody can explain the license. That is not cheap music. That is risk with reverb.
What Verification Means For Design And Narrative
Design and narrative AI work fails when it stays abstract.
A model can generate mechanics, quests, enemy ideas, economy loops, dialogue passes, item descriptions, lore fragments, and branching choices. None of it earns a place until a designer or writer turns it into coherent player experience.
For design, verification means contact with the player or the playable build.
Example that clears the bar: AI generates twenty movement upgrade ideas. The designer selects three hypotheses, cuts the rest, prototypes one, watches players exploit it, adjusts constraints, and decides whether it strengthens the core loop.
Example that fails: a generated mechanic sounds clever in a pitch document, so the team builds around it for two weeks. When playtested, it encourages players to avoid the best part of combat. A mechanic that only works in the designer's head is not a mechanic yet.
For narrative, verification means voice, state, continuity, and player context.
Example that clears the bar: AI drafts alternate bark lines for a merchant. The writer rewrites them for character voice, removes lore contradictions, checks quest-state variants, tests timing in the scene, and marks which lines are final. The tool helped generate raw material. The writer authored the scene.
Example that fails: generated quest text contradicts what happened in the previous mission, gives the wrong emotional temperature after a character death, and refers to an item the player may not have found. It reads fine alone. It breaks the game.
Design gets weak when it becomes too abstract. Clowdr's rule is to bring it back to the game. Press play. Watch the player. Check the scene. Then decide.
What Does Not Clear The Bar
Work does not clear the bar when no named person owns it.
It does not clear the bar when the source or license is unclear.
It does not clear the bar when the contributor cannot explain what changed after generation.
It does not clear the bar when the material only looks good in isolation.
It does not clear the bar when nobody tested it in the actual context where players will encounter it.
It does not clear the bar when the next contributor gets a pile of output with no handoff notes.
It does not clear the bar when a project lead accepts it because the team is tired.
That last one matters. A lot of bad AI use is exhaustion. The project is late, the artist is overloaded, the composer was brought in too late, the developer is cleaning up three systems, and the generated thing looks good enough to stop the pain.
That is exactly when the standard has to hold.
Slop is not "AI was involved." Slop is work without ownership and verification. The same standard catches bad handmade work too.
Rights, Disclosure, And Receipts
AI-assisted work needs receipts before it can ship.
Receipts need to answer the questions a project lead, contributor, platform reviewer, or future teammate will ask later.
For each AI-assisted contribution proposed for final use, record:
- The human owner.
- The tool or source used.
- The date and intended use.
- Whether the material is concept, temporary, internal, or proposed final.
- What the human contributor changed after generation.
- The rights or license note.
- The verification pass.
- Any disclosure needed for platform, storefront, credits, or contributor agreement.
Steam's AI survey is one reason this cannot stay informal. If a game used AI services during development or includes them in the product, the developer may need to describe that implementation. Storefront disclosure can become visible to players.
The goal is not paperwork for its own sake. The goal is to keep contributors from discovering the rights problem after the asset is already in the trailer.
When Contributors Disagree
Disagreement is normal.
An artist may reject a generated visual direction a developer thinks is good enough. A composer may refuse to clean up a generated track with unclear rights. A developer may block an agent patch because the author cannot explain the architecture. A writer may reject generated dialogue because it breaks character voice.
Inside Clowdr, that disagreement should not become a referendum on whether AI is good or bad. It is a production decision.
Use this process:
- Pause promotion of the work.
- Identify the domain owner or reviewer: artist, composer/audio contributor, developer, designer, writer, project lead, or editorial owner.
- Inspect the receipts: source, rights, changes, intended use, and verification.
- Test the work in context.
- Decide whether it clears the bar, needs revision, stays temporary, or gets cut.
- Record the decision so the same argument does not restart next week.
If the issue is rights, disclosure, or platform compliance, the conservative answer wins until the risk is resolved.
If the issue is taste or fit, the domain owner gets serious weight. Developers do not get to explain art back to artists. Project leads do not get to treat audio as decoration because the track already exists. Writers do not get overruled by a generated paragraph that sounds polished but breaks the scene.
The project lead still has to make calls. That is part of shipping. But the call should answer to the standard, not to who is most tired in the chat.
The Contributor Checklist
Before AI-assisted work moves from draft to final, answer these questions:
- Who is the human owner?
- What was generated, and by which tool or source?
- What is the material's intended use: concept, temp, internal, or final?
- What did a human change after generation?
- What rights, license, or source note is attached?
- What domain does this belong to: code, visual art, audio, design, narrative, or mixed?
- What verification pass fits the risk?
- Was the work checked in context, not just in isolation?
- Who signed off from the relevant domain?
- Does anything need disclosure on Steam, another storefront, credits, contributor agreements, or project notes?
- Can the next contributor understand the handoff without guessing?
If the checklist feels too heavy for a tiny internal experiment, keep the experiment internal. Use it when the work is proposed for project use.
The line is not complicated. It is just easy to skip when a shortcut looks like progress.
What To Do Next
This standard sits under How We Ship, the Clowdr manifesto for tools, taste, accountability, rights, and shipped quality.
The role spokes go deeper by discipline: Taste Is Still the Job for artists, Sound Is More Than Generation for composers and audio contributors, and The Tool Is Not the Architect for developers.
The shared rule is the same in every case.
Use the tools that help. Own the work. Verify it in context. Keep rights clear. Respect the contributors around you. Ship something that holds up.
If that sounds like the standard you want to work under, sign up.