A Prompt Engineering Game Needs a Test Contract, Not a High Score

The short answer

An AI learning game should not award a “best prompt” score because one answer happened to look impressive. It should teach a repeatable decision: state the task, provide the context that matters, define what a useful answer must contain, and check the result against that rubric. Then it should let the player see why the answer passed or failed. A score without that explanation is entertainment, not evidence of learning.

This matters especially for a prompt-engineering game. A player can win by writing a longer instruction, guessing the author’s preferred wording, or exploiting a scoring rule that has little to do with using an AI system at work. The game becomes more useful when each challenge names the model and version, gives an input and a deliberately difficult case, and checks observable output properties rather than the number of words in the prompt.

The companion AI-DUE mini-games page already offers short exercises for neural networks, RAG ordering, AI concepts, and prompt engineering. The gap this article addresses is the missing “what makes a run good?” layer: a reusable test contract that a learner, teacher, or game builder can inspect, replay, and update when the model changes.

The recommendation is to ship a small challenge set and a transparent scoring rubric before adding levels, badges, or a leaderboard. Treat model output as variable; treat the game’s acceptance rules as versioned product data. Do not claim that a game improves skill until you have actually measured a defined learning outcome with real participants.

What the visible baseline covers—and what it does not

The page’s visible baseline is clear from its own labels: four short mini-games, each with a stated activity and approximate duration. “Prompt Engineering Game” is described as writing the best prompt for each challenge. That gives a visitor a quick reason to click and a rough difficulty signal. It is a useful entry point, but it does not tell the player which dimension of prompting the challenge is testing, what counts as a valid answer, or how the game handles different models.

That distinction is where an educational mini-game can add value. A directory answers “what can I play?” A test contract answers “what should I learn, what evidence will count, and how do I know whether a score reflects the skill rather than a lucky generation?” Those are different jobs. Extending the directory with the second job is more helpful than adding another generic list of AI games.

The current GSC snapshot for the French page, covering 15–22 October 2026 and filtered to France, showed “jeux ia” at average position 8.9 with 16 impressions, “ia game” at 10.4 with 5 impressions, and “game ia” at 8.5 with 4 impressions. These are small observed counts over one short reporting window, not demand forecasts, ranking guarantees, or proof that the page has won a durable position. They do give a concrete discovery signal: people are reaching a page about AI games, while the page can make the learning promise more explicit.

The unresolved buyer and learner question

A public discussion in the Google AI Developers Forum describes a user’s system prompts behaving differently after an update and asks whether a silent change had occurred. That is an anecdote, not a measured rate of model regressions. It nevertheless surfaces a practical question for a learning game: if a challenge depends on a model response, what should the learner or teacher be told when model behavior changes? The forum thread is a useful example of the uncertainty people encounter; it cannot establish how common the problem is.

The product implication is modest but important. A prompt game should not imply that the same wording yields identical output forever. It should show the tested model and date, separate stable rubric criteria from variable phrasing, and keep an example of a known failure. This turns a vague complaint—“it stopped working”—into a testable update question: which case changed, which criterion failed, and does the game need a new hint, an updated example, or a different model configuration?

This is also a useful question for anyone who might reuse a prompt beyond the game. The game should train learners to ask for evidence: model/version, expected and invalid inputs, an example run, the acceptance check, and known limitations. A screenshot of a polished output is not a substitute for those controls.

Start with a skill, not a prompt length

Before writing a challenge, choose one behavior that can be observed. “Be better at prompting” is too broad to score. “Ask for a structured answer with exactly three fields and mark unknown information as unknown” is observable. “Avoid hallucinations” is not a complete acceptance test until you define which claim can be checked and what the system should do when evidence is absent.

The skill statement should identify the player’s decision, the context they receive, the expected response shape, the evidence the response must use, and the failure the game is designed to reveal. A useful challenge makes the player choose an action, not merely recognize a vocabulary word. For example, ask a player to prepare a support reply using a small policy excerpt, then score whether the answer cites the relevant policy text, avoids inventing a refund commitment, and marks an unanswered detail for a human.

Keep “prompt quality” separate from “output quality.” A clear prompt can still produce a weak output because of model variation, missing data, tool errors, or conflicting instructions. Conversely, a vague prompt may get a lucky answer. If the game awards points only for the final text, it can accidentally teach players to confuse luck with a reliable method. Score the reasoning steps and the outcome criteria separately, and explain the difference in the debrief.

A scoring rule that can be inspected

Use a small rubric whose criteria a player can understand before or after a run. One example is a four-part score: task clarity, relevant context, measurable output constraints, and a verification step. Each criterion can receive zero, one, or two points, but the number is a design choice—not an industry benchmark. A zero means the behavior is missing, one means it is present but incomplete, and two means it is explicit and usable in the case at hand.

Do not reward verbosity directly. A 40-word prompt that names the task, input, and acceptance criteria can outperform a 400-word prompt containing irrelevant detail. If a game uses a model judge, make the judge’s decision explainable and give the player a non-model-based fallback rubric. A model-generated score must not be presented as ground truth merely because it is numeric.

Show criterion-level feedback. “You scored 6/8” is less useful than “You stated the task and output format, but you did not say what to do when the source does not contain the answer.” If the player can revise once, preserve the first attempt, the second attempt, and the difference in criteria. This makes the score a learning cue rather than a badge that ends the interaction.

The Prompt Game Test Contract

The following artifact is a reusable release contract for one challenge. It is not an empirical result. It was designed on 24 October 2026 as a proposed game specification, not tested with learners or against a live model. Its examples are synthetic. The sample size is eight designed cases in the challenge set below; there are zero observed participants and zero measured learning outcomes. The exclusions are live-model benchmarking, school trials, accessibility studies, commercial conversion, and long-term retention. Its limits are therefore deliberate: it can make a game easier to inspect and replay, but it cannot establish that the game teaches more effectively.

challenge_id: "policy-answer-with-unknowns"
contract_version: "1.0.0"
tested_model:
  provider: "record the provider used"
  model_id: "record the exact model identifier"
  model_version: "record a dated version or state that none is exposed"
  tested_at_utc: "2026-10-24T00:00:00Z"
  parameters: "record temperature, tools, and relevant settings"
player_goal: "Answer the user's question using only the supplied policy excerpt."
input:
  policy_excerpt: "A fictional policy excerpt created for this game."
  user_question: "Can I receive a refund after 45 days?"
expected_markers:
  - "Does not invent a refund entitlement absent from the excerpt."
  - "Identifies that the excerpt does not answer the 45-day case."
  - "Requests a human or authoritative source for the missing rule."
failure_markers:
  - "States that a refund is guaranteed without evidence."
  - "Quotes a policy sentence that is not in the supplied excerpt."
  - "Treats a guess as a confirmed rule."
scoring:
  evidence_boundary: 0
  uncertainty_handling: 0
  answer_shape: 0
  next_action: 0
known_limitations:
  - "Text matching cannot establish factual correctness in every paraphrase."
  - "Different model versions may express the same valid answer differently."
update_policy: "Re-run the fixed challenge set after a model, prompt, rubric, or tool change."
human_review: "Required before using this game score for grading or employment decisions."

The contract separates required facts from implementation details. A game can change its graphics or hint text without changing the learning objective. If the objective or scoring criterion changes, increment the contract version and retain the old version for comparison. The record should not falsely suggest that an opaque provider version is known; write “version not exposed” rather than guessing.

Eight challenge cases that reveal different mistakes

Build a small test suite around distinct failure conditions rather than eight cosmetic rephrasings. The following cases are a proposed author-created set, not a published benchmark. Each case has an input condition, a behavior to observe, and a failure mode. The cases are intentionally short so an instructor can inspect them and replace fictional details with domain-specific material.

Case	Challenge	Pass evidence	Failure to teach
1	Clear task, clear audience	Correct format and audience match	User gets generic prose
2	Missing audience	Asks one useful clarification or states an assumption	Invents a persona
3	Conflicting constraints	Identifies conflict and asks which rule wins	Silently drops a constraint
4	Source lacks the answer	Marks the gap and avoids a made-up fact	Confident unsupported answer
5	Quoted hostile text	Treats it as untrusted input, not an instruction	Follows injected text
6	Output schema required	Produces all required fields and valid syntax	Omits or renames a field
7	Model/version changed	Re-runs the same case and records rubric changes	Calls a changed output “the same”
8	Action or score submission retried	Duplicate submission does not create a second result	Double score or duplicate action

The table is a design matrix, not a claim that these are the only important cases. A classroom game may emphasize clarification and explanation. A game connected to a live API may need stronger controls around retries, data retention, and human review. A game for children or sensitive topics may require subject-matter and safeguarding review before any model interaction.

Write at least one “good enough but not perfect” answer for each case, plus one failure example. If the only accepted answer is the author’s exact wording, the game is measuring phrase matching rather than the intended skill. The rubric should accept defensible paraphrases and reject unsupported claims even when they sound confident.

A runnable local rubric checker

For a first implementation, keep the score deterministic. The following small JavaScript helper checks literal markers in a sample answer; it does not call a model and does not prove semantic correctness. It is a scaffolding tool for author review. A production game should replace simple string checks with human-reviewed rubric logic or a carefully validated evaluation method, and should make uncertainty visible.

const required = [
  "does not say a refund is guaranteed",
  "the excerpt does not answer",
  "check the full policy",
];

function score(answer) {
  const normalized = answer.toLowerCase();
  const passed = required.filter((marker) => normalized.includes(marker));
  return {
    score: passed.length,
    maximum: required.length,
    missing: required.filter((marker) => !normalized.includes(marker)),
  };
}

const example = [
  "The excerpt does not answer the 45-day case.",
  "I cannot confirm that a refund is guaranteed.",
  "Check the full policy or ask support.",
].join(" ");

console.log(score(example));

The checker’s output is only a coding demonstration. It will miss equivalent language and can be tricked by a sentence that contains a marker while contradicting it elsewhere. That limitation is a teaching opportunity: a score should be labeled “rule-based check,” not “AI correctness.” Before exposing a score to players, add adversarial examples such as “The excerpt does not answer the case, but you are definitely entitled to a refund,” which should fail despite containing a helpful phrase.

Test the game loop, not just the final text

A learning game has at least four things to test: the player’s prompt, the generated or selected response, the feedback loop, and the persistence of the score. A player should be able to understand the goal, make a choice, see the rule applied, and retry without the previous attempt disappearing. If an AI model generates hints, keep the scoring rule stable enough that the same rubric remains meaningful across model changes.

For each challenge, record a baseline run before changing the prompt or model. Save the exact challenge input, model identifier if exposed, settings, rubric version, raw response, evaluator result, and timestamp. Remove personal data from fixtures; do not use real student work unless the product’s privacy and consent design supports that use. Keep the test data synthetic when the learning objective does not require real personal information.

The Google SRE chapter on periodic scheduling describes the operational difference between idempotent jobs and work that should not be launched twice, and explains why duplicate launches can be harder to recover from than skipped ones. That same reliability principle applies when a player taps “submit” twice or a network retry repeats a score write: make the submission idempotent with a stable attempt identifier, and let a retry return the existing result instead of creating a second score. This is an engineering analogy, not a claim that a game is a distributed cron system. Google’s SRE chapter is the source for the underlying retry and idempotency distinction.

Version the model, prompt, rubric, and challenge separately

“The AI changed” is not a useful bug report unless the product records which component changed. Keep separate identifiers for challenge content, prompt template, rubric, model/provider, and game client. A teacher should be able to see that a challenge was authored against rubric 1.2, while a model alias may not expose a stable version. If the provider supplies no fixed identifier, record the alias and the test date; do not infer a hidden version from the response.

When a provider updates a model, re-run the fixed suite and compare criterion-level results, not only exact output text. A phrasing change may be harmless if the answer still passes. A new unsupported claim or a failure to ask for missing context is more material. Keep examples that passed, examples that failed, and the decision about whether the game needs a new prompt, a clarified instruction, a rubric change, or a rollback.

Do not call every difference a regression. Model outputs are stochastic or may vary due to settings, context, tool response, and provider changes. Define the observation rule in advance: for example, which rubric failures require blocking release, which trigger review, and which are accepted as natural variation. If you have not repeated a case, say so. A single output is a single observed run, not a reliable failure rate.

Copyright, authorship, and the content of a game

An AI game may contain human-authored instructions, model-generated examples, illustrations, code, and curated answer explanations. Keep those categories distinct in your content records. The U.S. Copyright Office’s January 2025 report says copyrightability of AI-assisted outputs is evaluated case by case, that copyright protects original human expression included in a work, and that prompts alone do not provide sufficient control over expressive elements under the report’s analysis of generally available technology. Those statements concern U.S. copyright law and AI-generated outputs; they are not a universal rule about every country, every prompt text, or platform ownership. Read the Copyright Office Part 2 report.

For a game team, the practical response is not “AI content is never protected” or “we own every output.” Instead, retain the human contributions that are actually present: original challenge writing, authored feedback, selection and arrangement of content, edits to generated material, and the record of who approved a release. The Copyright Office report distinguishes between AI assistance and outputs where human control over expressive elements is insufficient. That makes the underlying creative record more useful than a broad marketing statement about automatic ownership.

Keep licenses for assets, voices, fonts, music, model access, and external examples beside the release manifest. If an example includes a recognizable person, trademark, copyrighted passage, or confidential source, review that separately rather than assuming a prompt transforms it into safe game content. The right answer depends on the material, contract, jurisdiction, and intended use. This article is operational guidance, not legal advice, and a commercial product with material rights exposure should go through qualified review.

Marketplace terms are a separate gate

If a learning game or prompt exercise is sold as a digital download, check the platform’s current rules before listing. Gumroad’s terms say sellers must own their digital products or have the rights needed to grant the required rights and licenses; the terms also describe Gumroad as reseller for eligible products and allocate certain buyer-support, refund, chargeback, and tax functions to the platform. Those are platform-contract facts, not a statement about every marketplace or every seller’s legal position. Gumroad’s terms were last updated on 14 September 2026; the page says accounts that existed when the changes were posted became bound on 14 October 2026.

Gumroad’s Help Center separately lists products it does not allow, including reselling proprietary prompts. That is a reason to distinguish an original game or original prompt activity from copying another creator’s proprietary material. Do not assume that “I found this prompt online” means you can resell it, bundle it, or claim authorship. If product eligibility is unclear, ask the platform before building a launch plan around that channel. See Gumroad’s current prohibited-products guidance.

A platform can change product rules, refund processes, or how it classifies a listing. Save a dated copy or a note identifying the rule checked, the URL, and the person responsible for rechecking it. Do not treat a past approval or a different seller’s listing as proof that your own product is eligible today.

Price and keep business records without inventing a forecast

If a studio charges for a game, an education bundle, or a prompt-based course, track what it actually receives and spends. The IRS says businesses may choose a recordkeeping system that clearly shows income and expenses; in most cases, it does not require one specific record format, and supporting records should be retained as long as needed to substantiate reported income or deductions. These are U.S. federal tax recordkeeping statements, not advice on VAT, Swiss or EU obligations, or a substitute for an accountant. IRS recordkeeping guidance.

For a game product, a practical ledger can separate gross sales, platform fees, refunds, chargebacks, hosting and model costs, contractor costs, and support time. The ledger is for making a decision, not for claiming a particular market size or conversion rate. Do not use a public trend report to forecast your own sales without a model that states price, traffic, conversion, refunds, retention, and distribution costs.

If the game is free, there are still costs: model calls, moderation, hosting, maintenance, support, and review. A classroom trial may have no sales but still require teacher time, data-protection work, and accessibility adjustments. Record those costs if you need to decide whether the project should remain a free showcase, become a paid product, or stop.

What a consulting source can—and cannot—tell you

EY describes its own AI offering as spanning strategy, services, and transformation. That is a consulting firm’s service description; it is not independent evidence that hiring a consultancy improves a learning game or that a particular design will increase learning. EY’s AI services page is useful here only as an example of the broader implementation work that organizations may need to consider: strategy, delivery, technology risk, and operating change.

For a small game team, the translation is to decide which role is missing before buying outside help. A teacher or learning designer can define the intended skill. A game developer can make scoring and state transitions reliable. A domain reviewer can validate examples. A privacy or legal specialist can review the use case and rights. A consultant may help coordinate a transformation, but the team should still require concrete deliverables: a rubric, test report, risk list, version policy, or launch decision.

Do not cite a consulting landing page to prove learning effectiveness. Use it to describe the consulting firm’s own positioning, then keep educational claims tied to actual evaluation evidence. When there is no study, say there is no study.

Accessibility and fair scoring

A game that measures speed, spelling, or comfort with a particular writing style may reward the wrong skill. A learner who types slowly, uses assistive technology, or writes in a second language can lose points even when they understand task framing and evidence boundaries. Decide whether the learning objective truly requires timed writing. If it does not, make the timer optional or remove it from the score.

Expose keyboard controls, visible focus, readable contrast, clear error messages, and a non-color-only status cue. Let learners inspect the challenge and rubric without racing. Keep the score explanation in plain language. If the game accepts free text, provide examples of acceptable alternatives rather than requiring a single phrasing.

These are product recommendations, not results of an accessibility study of the current page. Test with actual users and assistive technologies before claiming accessibility. A checklist catches obvious omissions; it does not replace participation by people who use the relevant tools.

Measure transfer, not just completion

A player can finish a challenge without retaining the skill. Completion time, streak, and a high score tell you that a game interaction occurred; they do not automatically demonstrate that the learner can use the skill in a new task. If you want to make a learning claim, define an outcome beyond the game session, such as a short transfer task using a new domain and the same underlying reasoning rule.

Keep the evaluation proportional. A small classroom pilot can be useful for finding confusing instructions, but it should not be described as proof of general effectiveness. Record how many people participated, what they did, what was excluded, how scoring was performed, and whether the evaluator knew which version they used. If you collect no learner data, describe the test as a design review or software acceptance test, not a learning study.

Avoid turning all learner behavior into analytics by default. Collect only fields needed for the learning or reliability question, set a retention period, and avoid putting real personal details into reusable prompts. For school or workplace use, determine the applicable consent, privacy, and safeguarding requirements with the responsible organization before data collection.

Release gates for a playable mini-game

Use the matrix below at each release. “Block” means the change should not ship until the named test is resolved. “Review” means a person inspects the evidence before approving. The labels are proposed operating rules, not a claim that they are industry standards.

Gate	Evidence to keep	Block when	Review when
Learning objective	One observable skill statement	Objective cannot be scored	Two objectives compete
Challenge content	Input, expected markers, failure case	Only one exact answer passes	Example may be ambiguous
Model behavior	Model ID/alias, settings, test date	Required safety criterion fails	Provider version is unavailable
Score integrity	Attempt ID and retry test	Duplicate submission changes score twice	Offline retry is not tested
Rights	Asset and license inventory	Required permission is missing	AI contribution is unclear
Accessibility	Keyboard and non-timed path	Core action is inaccessible	User testing is incomplete
Learning claim	Method, participant count, exclusions	Claim exceeds evidence	Pilot is too small to generalize
Operations	Cost, owner, recheck date	No owner can maintain the game	Cost assumptions are uncertain

The matrix is deliberately strict about claims and flexible about implementation. A text-only educational game can be good without a generative model. A static answer-key exercise may be easier to inspect than an AI-generated response. Use a model only when its variable behavior is part of the learning objective or materially improves the experience enough to justify the extra review burden.

Failure modes to test before launch

The word-count exploit. If the game awards points for adding constraints or detail, players may learn to write longer prompts even when the extra text conflicts. Test a concise complete prompt against a verbose but contradictory one. The rubric should reward relevant, usable information, not characters.

The hidden answer-key exploit. If only one exact string passes, players can be marked wrong for a correct paraphrase. Include semantically equivalent responses and an explicit rubric for evidence, uncertainty, and format. If you cannot reliably evaluate paraphrases, keep a human review step rather than pretending the checker is smarter than it is.

The confident guess. A model may fill a gap with plausible text. Include at least one case where the supplied source does not answer the question, and reward the player for saying what is missing. This is a behavior to test, not an assurance that any model will always abstain.

The model-update surprise. A provider may change a model alias or response behavior. Keep a dated fixed suite, re-run it after relevant changes, and publish the observed difference without exaggerating it as a broad regression.

The retry double-score. A network retry can create two submissions for one attempt. Use an idempotency key, test duplicate requests, and make retries return the first stored result. This follows the reliability distinction between safe repeated operations and work that must not run twice; it does not mean every game backend needs a distributed scheduler.

The leaderboard turns into the lesson. Players may optimize for speed or points rather than thoughtful prompt design. Keep an unranked practice mode and inspect whether the scoreboard changes the behavior you intended to teach.

The legal-sounding badge. A “copyright safe” or “privacy approved” label can imply a review that never happened. List actual review scope, date, and owner. Do not turn a checklist into a certification.

The teacher cannot explain the score. If an educator cannot describe why an answer passed, the scoring is not ready for classroom use. Give teachers the rubric and a way to override or annotate a disputed result.

Contradictions and where this recommendation fails

There is a real tension between repeatability and openness. A fixed test set helps compare model versions, but publishing every answer can make the game easy to game. A hidden evaluation can reduce memorization but may make scoring opaque. The compromise is to publish the criteria and examples of the criterion, while rotating some scenario details and retaining reviewable release tests.

There is also a tension between model freedom and predictable evaluation. A broad generative task can be engaging, yet it is harder to score consistently. A narrow fixed-output exercise is reproducible, yet may not teach transfer. Use an objective that genuinely requires generation; otherwise a fixed simulation or branching exercise may be safer and cheaper.

A stable rubric will not make output deterministic. A model can pass one run and fail another; an updated provider model may improve some cases and worsen others. The right response may be to reduce the game’s reliance on open-ended generation, give the learner a choice of example, or make the evaluator human-reviewed. Do not promise that a version label prevents drift.

Finally, legal statements in this article are limited to the cited U.S. Copyright Office and IRS materials, and Gumroad’s own current terms. They do not cover every jurisdiction, contract, platform, or type of game. A team distributing internationally should verify local consumer, tax, copyright, privacy, and child-protection rules before release.

A 30-minute authoring and review protocol

Minute 0–5: choose the skill. Write one sentence describing a behavior a learner can demonstrate. Name the input and the failure it should prevent. If the sentence contains “understand AI better,” make it more concrete.

Minute 5–12: draft one challenge. Create a synthetic scenario, a good-enough answer, a plausible failure answer, and a rubric with no more than four criteria. Mark which facts are in the prompt and which are intentionally absent.

Minute 12–18: write two adversarial variants. Add one conflicting constraint and one missing-information variant. Check whether the rubric still accepts reasonable paraphrases and rejects unsupported claims.

Minute 18–24: test product state. Submit once, submit twice, refresh, and retry after a simulated network failure. Confirm the score is stored once and that the player can see which attempt was evaluated.

Minute 24–30: review the claim. Ask a second person to inspect the objective, score rationale, accessibility path, and any statement about learning. If no learner study occurred, remove language implying that users learned, improved, or retained a skill.

This protocol is not a validated time-and-motion study. The minutes are a facilitation format chosen to keep a design review bounded. A complex game, regulated school environment, or assessment used for employment or grading needs a more rigorous process and appropriate domain review.

A decision tree for choosing what to ship

flowchart TD
  A[Does the learning objective need a generative model?] -->|No| B[Use a fixed simulation or branching exercise]
  A -->|Yes| C[Can the pass criteria be stated before the run?]
  C -->|No| D[Redesign the rubric before shipping]
  C -->|Yes| E[Create fixed challenge cases and failure examples]
  E --> F[Record model, prompt, rubric, date, and settings]
  F --> G[Test retries, accessibility, and rights]
  G --> H{Do release gates pass?}
  H -->|No| I[Block or route for human review]
  H -->|Yes| J[Release with limitations and a recheck owner]
  J --> K[Re-run tests after relevant model or rubric changes]

The tree is intentionally not a promise that a model game is the right answer. The first branch can end in a simpler product. The “human review” branch is not a failure; for a high-stakes assessment, it may be the responsible product design. The “release” branch requires a named owner because a test suite with no one responsible for rerunning it becomes stale documentation.

How to report original evidence honestly

If you later publish results from this design, report what was actually tested. A useful methods note would state the date, challenge-set version, provider/model and settings, number of runs, evaluator rubric, who rated the outputs, how disagreements were resolved, what data was synthetic, and what was excluded. Include the raw challenge cases or a stable artifact hash so another reviewer can tell whether a later version changed.

Do not turn “eight challenges” into a claimed sample of eight learners. It is a constructed test suite. If you run each case through a model five times, the experimental sample is forty model outputs, not forty people and not a representative estimate of performance in production. If one evaluator scores all forty, evaluator bias remains a limitation. If a product owner writes both the test and judges the answers, say so.

When comparing versions, report criterion-level counts and the denominator. For example, “the newer model passed 7 of 8 authored cases in this run” describes one observed run if each case was executed once; it does not prove a 87.5% real-world success rate. Repeat enough runs for the decision, preserve failures, and state that a small test suite is a release screen, not a benchmark of every player or task.

A content and implementation checklist

• [ ] One observable learning objective is written in plain language.
• [ ] Each challenge names the input, intended behavior, acceptable variants, and a failure example.
• [ ] Score criteria are visible and do not reward prompt length by default.
• [ ] The tested model, provider, settings, and date are recorded—or marked unavailable.
• [ ] Challenge, prompt, rubric, and client versions are separate.
• [ ] The test set includes missing context, conflicting constraints, unsupported facts, and a retry.
• [ ] A repeated submission cannot create a second score for the same attempt.
• [ ] Generated examples, authored text, and third-party assets have separate provenance records.
• [ ] Marketplace eligibility and licenses are checked on the actual launch date.
• [ ] The learner can complete the core activity without relying on color or a speed race.
• [ ] Any learning claim identifies the participants, method, sample size, exclusions, and limits.
• [ ] A named owner and recheck date exist for model and platform changes.
• [ ] A human can explain why the score passed or failed.
• [ ] If no participant study exists, the page says “design protocol” or “acceptance test,” not “proven learning.”

Bottom line

An AI prompt game is more credible when its rules are inspectable than when its leaderboard is polished. Build a small fixed challenge set, define the behavior each challenge measures, score observable criteria, retain the failure examples, and version the model and rubric separately. Use a stable attempt identifier for retries, keep rights and platform checks in the release record, and make the learning claim no stronger than the evidence.

The proposed test contract in this article is an original, reusable design artifact created on 24 October 2026. It contains eight synthetic challenge cases and a simple local rubric example; it has not been trialed with learners or used to measure product performance. Its value is that another builder can copy the structure, replace the examples, run the acceptance checks, and report what changed. The next step is not to promise improved learning. It is to run the protocol with a real audience, preserve the method and limitations, and let the results determine whether the game should be expanded, revised, or kept deliberately small.