Build a release gate

1495. Lesson identity

Module

4.1 — Release engineering

Lesson

Build a release gate

Academic type

Workflow

Order

2 of the module

Estimated time

40–55 minutes, including practice

This lesson converts product requirements into a release checklist that another person can execute and audit. Each check must define what is being tested, what counts as passing, what evidence must be retained, who owns the check, and which candidate revision was tested.

The final ship/no-ship decision belongs to the next lesson. Here, you produce gate records that can support that decision without hiding failures or inventing confidence.

1496. Learning objective

After this lesson, you can create a five-to-seven-check release checklist for a small game build. Every check will include an explicit acceptance criterion, an evidence standard, an owner, a candidate revision, an execution result, an evidence-sufficiency state, a gate disposition, and a review-readiness state.

1497. Why an acceptance criterion is essential

Evidence records what happened. An acceptance criterion defines what must happen for the requirement to pass. These are not interchangeable.

• Evidence without a criterion: “The frame time was recorded.” This does not say whether the observed value was acceptable.
• Criterion without evidence: “The frame time must meet the target.” This does not show whether the candidate met it.
• Criterion plus evidence: “Acceptance criterion: p95 frame time is no more than the supplied 20 ms target during the defined encounter. Evidence: the recorded p95 was 18.6 ms on candidate abc1234 under the specified conditions.”

A phrase such as “sufficient contrast,” “good performance,” or “input works” is not repeatable unless the supplied product requirement defines the standard, target, tolerance, supported behavior, or expected state.

1498. Core model

Use this model for every release check:

SCOPE → ACCEPTANCE CRITERION → PROCEDURE → EVIDENCE STANDARD → OWNER → REVISION → STATES

Use this compact row format:

ID | Risk area | Scope | Acceptance criterion | Procedure | Evidence standard | Owner | Revision/build | Severity | Execution result | Evidence sufficiency | Gate disposition | Review readiness

A row is incomplete if it omits the acceptance criterion, even when it contains screenshots, logs, or observations.

1499. Four distinct decisions

Do not compress evidence and outcome into one status. Record these dimensions separately.

1. Execution result

• Not run: execution has not started.
• Pass: the observed behavior met the acceptance criterion.
• Fail: the observed behavior did not meet the acceptance criterion.
• Blocked: the procedure could not produce a valid pass-or-fail result because a prerequisite, environment, build, or required test path was unavailable.

2. Evidence sufficiency

• Sufficient: the retained evidence meets the row's evidence standard and can be connected to the tested candidate and conditions.
• Insufficient: required evidence is absent, incomplete, ambiguous, or cannot be tied to the tested candidate.

3. Gate disposition

• Satisfied: execution result is Pass and evidence is Sufficient.
• Failed criterion: execution result is Fail and evidence is Sufficient.
• Unable to evaluate: the result is Not run or Blocked, or the evidence is Insufficient.

A failed check can have excellent evidence. It is therefore wrong to describe every evidenced row as satisfied. Evidence sufficiency establishes whether the result is defensible; it does not turn a failure into a pass.

4. Review readiness

• Review-ready: a Pass or Fail is supported by sufficient evidence, so the result can be reviewed in the next lesson.
• Not review-ready: the row is unable to evaluate because execution or evidence is incomplete.

Both an evidenced pass and an evidenced failure can be review-ready. Review-ready does not mean approved, releasable, or shipped.

1500. Severity and the prior finding taxonomy

Classifying an earlier finding does not automatically determine a gate's severity. Use judgment and the supplied product requirements.

• A blocker finding normally informs a must-pass criterion because violating it prevents the candidate from satisfying a required condition.
• A risk may inform an advisory gate when the result must be carried into release review but is not itself defined as a mandatory condition.
• A follow-up does not become a pass. It remains separate work unless a product requirement makes it part of the current candidate's acceptance criteria.
• An unsupported claim requires valid evidence. Until that evidence exists, the corresponding gate remains unable to evaluate.

This mapping is not automatic. For example, a performance risk becomes must-pass if the supplied product requirement defines a mandatory frame-time limit.

1501. Worked example

Assume the supplied requirements for a small game candidate state the following:

• Completing the first encounter must award one reward before the next decision point appears.
• Keyboard and controller are supported input paths; focus loss must not leave movement input stuck after focus returns.
• Normal-size interface text must meet the supplied minimum contrast ratio of 4.5:1.
• The defined encounter must remain at or below the supplied p95 frame-time target of 20 ms under the recorded test conditions.
• After an interrupted run, selecting Continue must restore the player at the last confirmed checkpoint with the recorded reward state intact.

These values belong to this supplied example. For a real project, use its actual requirements rather than copying these targets without review.

RG-01 | Functionality | First-encounter completion and reward | Exactly one reward appears before the next decision point | Start a new run and complete the encounter | Build ID, steps, observed reward count, and screenshot or event record | Release tester | abc1234 / build-17 | Must-pass | Pass | Sufficient | Satisfied | Review-ready
RG-02 | Platform behavior | Supported keyboard and controller behavior across focus loss | After focus returns, neither input path leaves movement stuck; both can resume supported navigation | Test both input paths, remove focus during movement, restore focus, and release input | Platform, device, steps, and observed post-focus state | Platform tester | abc1234 / build-17 | Must-pass | Fail | Sufficient | Failed criterion | Review-ready
RG-03 | Accessibility | Contrast of normal-size interface text | Every sampled in-scope text/background pair is at least 4.5:1 | Measure the listed interface states with the approved method | State list, measured ratios, method, and captures | Accessibility tester | abc1234 / build-17 | Must-pass | Blocked | Insufficient | Unable to evaluate | Not review-ready
RG-04 | Performance | Defined encounter under target workload | Recorded p95 frame time is no more than 20 ms under the specified conditions | Run the defined capture three times using the stated device and settings | Raw captures, conditions, tool version, and calculated p95 | Performance owner | abc1234 / build-17 | Must-pass | Pass | Sufficient | Satisfied | Review-ready
RG-05 | Content completeness | Required level, reward, interface text, and presentation assets | Every item in the supplied candidate inventory is present and references resolve | Compare the build against the approved inventory | Completed inventory with missing or mismatched items identified | Content owner | abc1234 / build-17 | Must-pass | Not run | Insufficient | Unable to evaluate | Not review-ready
RG-06 | Recovery | Continue after an interrupted run | Continue restores the last confirmed checkpoint and preserves the recorded reward state | Interrupt after checkpoint confirmation, restart, and select Continue | Interruption point, restart steps, restored checkpoint, and reward state | Release tester | abc1234 / build-17 | Must-pass | Pass | Sufficient | Satisfied | Review-ready

RG-02 is review-ready even though it failed. The evidence is sufficient for the next lesson to consider the failed must-pass criterion. RG-03 is not review-ready because the required measurement could not be completed and its evidence standard was not met.

1502. Building the checklist

Keep the checklist bounded at five to seven checks while covering:

• functionality;
• platform behavior;
• accessibility;
• performance;
• content completeness; and
• recovery.

One check may cover more than one risk area only when its acceptance criteria and evidence remain unambiguous. Do not add vague rows merely to claim coverage.

For each row:

1. Trace the row to a supplied product requirement or explicitly identified risk.
2. Write a bounded scope.
3. Define the passing threshold, supported behavior, tolerance, or expected state.
4. Write a procedure that another tester can repeat.
5. Specify the evidence required before execution.
6. Assign a human owner.
7. Record the candidate commit and build identifier.
8. Classify the row as must-pass or advisory and justify that classification.
9. Execute the procedure without changing the criterion after seeing the result.
10. Record execution result, evidence sufficiency, gate disposition, and review readiness separately.

If a supplied requirement is ambiguous, do not invent a threshold. Record a question and leave the gate unable to evaluate until the requirement owner clarifies the criterion.

1503. AI-native workflow

AI may help organize supplied requirements and identify missing coverage, but it cannot execute the test, invent an acceptance threshold, validate evidence it cannot inspect, or make the final ship/no-ship decision.

A useful prompt is:

Using only the supplied product requirements, target platform, supported inputs, accessibility requirements, performance targets, recovery behavior, and candidate revision, propose five to seven release checks.
For each check, include scope, an explicit acceptance criterion, procedure, evidence standard, owner role, severity, and the four state fields.
Quote or reference the supplied requirement behind each criterion. Mark missing thresholds or ambiguous requirements as questions. Do not invent targets, mark unexecuted checks as passes, or make a ship/no-ship decision.

Review the proposal manually. Reject rows that duplicate another check, lack a criterion, use subjective wording, or exceed the lesson's scope. AI may summarize existing records only after you compare the summary with the source evidence.

1504. Git and candidate revisions

Treat the candidate revision as part of the evidence record.

1. Inspect the working tree and identify the candidate commit before building.
2. Record the commit identifier and build identifier in every applicable row.
3. Run checks against that build, not against uncommitted changes or an unknown local state.
4. If a check fails, preserve the failed candidate, its evidence, and its disposition.
5. Record a new candidate revision separately after a correction.
6. Re-run affected checks and justified regression checks against the new candidate.
7. Do not copy a prior pass to a new candidate without executing the required test.

A revised candidate does not erase the earlier failure. The evidence history must show which state produced each result.

1505. Common mistakes

Describing evidence as the criterion

“Record a screenshot” is an evidence instruction, not a passing condition. State what the screenshot must demonstrate.

Treating sufficient evidence as a pass

A well-recorded failure has sufficient evidence but a disposition of Failed criterion.

Using Blocked for any failure

Use Fail when execution completed and the observed behavior missed the criterion. Use Blocked only when execution could not produce a valid pass-or-fail result.

Changing the threshold after execution

Acceptance criteria must come from supplied requirements or approved clarification. Do not weaken a criterion because the candidate missed it.

Turning a follow-up into approval

Future work does not establish that the current candidate passed. Keep the current result and evidence intact.

1506. Guided practice

Use this product scope: the player must launch the game, start a run, complete one encounter, receive one reward, and reach the next decision point. Add only platform, accessibility, performance, content, and recovery requirements that are supplied by your project or instructor.

1. Record one candidate Git revision and build identifier. For a described scenario, use a clearly labeled placeholder such as candidate-01.
2. Write five to seven rows covering all six risk areas.
3. Add an explicit acceptance criterion to every row. If a requirement lacks a threshold or expected state, record the unresolved question instead of inventing one.
4. Define the procedure and evidence standard before execution.
5. Assign an owner and classify each row as must-pass or advisory. Justify the classification in one sentence.
6. Initialize execution as Not run, evidence as Insufficient, disposition as Unable to evaluate, and readiness as Not review-ready.
7. Execute available checks and preserve the required evidence.
8. Determine the four state fields independently.
9. Repair one deliberately weak row by adding its missing criterion, evidence standard, owner, revision, severity, and defensible states.
10. If a new candidate is produced, preserve the old record and identify affected and regression checks.

Do not make the overall ship/no-ship decision.

1507. Validation and evidence

Submit the checklist through the practical assessment attached to this lesson. It must include:

• five to seven checks covering the six required risk areas;
• a traceable scope and explicit acceptance criterion for every row;
• a repeatable procedure and defined evidence standard;
• an owner, candidate revision, and build identifier;
• justified must-pass or advisory severity;
• separate execution result, evidence sufficiency, gate disposition, and review-readiness fields;
• at least one repaired weak row with a short justification;
• preserved failure and retest history when a revision changes; and
• no final ship/no-ship conclusion.

1508. Key takeaways

• Evidence records what happened; an acceptance criterion defines what counts as passing.
• Execution result, evidence sufficiency, gate disposition, and review readiness are separate dimensions.
• An evidenced failure can be review-ready without being satisfied.
• Missing or ambiguous requirements remain unable to evaluate; they are not provisional passes.
• Git connects evidence to a specific candidate state.
• AI can propose structure and identify questions, but humans own criteria, execution, evidence, and release judgment.

1509. Next lesson

4.1 L3 — Write the ship/no-ship memo will use the acceptance criteria, results, evidence states, dispositions, accepted-risk candidates, and missing-evidence statements produced here.

1510. Local release rehearsal (fix-release-candidate)

Open academy-fixtures/labs/release-candidate. Run node run.mjs. Collect clean run, versioned artifact, smoke, localization probe, persistence probe, packaging, rollback note, release notes, known issues, go/no-go. This is a local release candidate, not Steam publication.

1511. Knowledge check