1480. Learning objective
After this lesson, you can classify a release finding as a blocker, accepted risk, follow-up, or unsupported claim by relating it to a predefined release control and bounded evidence.
1481. Prior knowledge
You need the course prerequisites and the development foundations introduced before this stage: a playable loop, basic debugging judgment, and the ability to report a test result precisely. You do not need to have written a release checklist; the next lesson teaches that task.
1482. A build answers only one question
A build is an artifact produced from a particular source state. A successful local build shows that the artifact could be produced in that environment. It does not establish that the artifact starts on a required target, satisfies accessibility requirements, stays within a performance threshold, includes all required content, or recovers state correctly.
A release candidate is an artifact evaluated against the required release controls. Its remaining limitations must be classified, supported by evidence, and handled through an explicit decision. The artifact alone is not a release decision.
AI may organize supplied notes or identify unanswered questions. It cannot convert an assumption into evidence or make the ship decision for the responsible person or role.
1483. Finding classification and control status are different
Use one classification for each finding:
| Classification | Meaning | Required response |
|---|---|---|
| Blocker | A required release condition has failed, or a necessary condition is absent. | Stop the release decision until the issue is resolved or the scope is formally changed. |
| Accepted risk | A known limitation is permitted by the applicable control, with its impact, scope, and responsible decision-maker documented. | Record the authorization and the limits of the exception. |
| Follow-up | Work remains, but it does not prevent the current release under the applicable policy. | Assign a responsible person or role, next action, and review point. |
| Unsupported claim | Available evidence does not support the stated conclusion. | Narrow the claim or collect the missing evidence. |
A control status reports the outcome of a gate or policy rule. For this lesson:
- passed: the stated criterion is met by sufficient evidence;
- blocked: the criterion fails and no permitted exception applies;
- waived: the criterion is not fully met, but the control explicitly permits an authorized exception and the required exception record exists;
- unsupported: evidence is insufficient to determine whether the gate passed;
- follow-up: used for policy rule D1 when optional documentation improvement remains assigned for later work.
Do not confuse the two fields. A finding may be classified as accepted risk while its related gate has waived status. A claim may be unsupported while its gate also has unsupported status.
1484. Predefined controls for this lesson
These controls are supplied for classification practice. You will learn to author criteria and decision rules in the next lesson.
| ID | Control | Passing evidence | Exception or other status rule |
|---|---|---|---|
| G1 | Core functionality | The primary interaction completes under the stated test conditions. | Failure is blocked; missing target evidence is unsupported. |
| G2 | Required platform behavior | The artifact starts and the required interaction works in every declared target environment. | A missing target test is unsupported; a demonstrated target failure is blocked. |
| G3 | Declared accessibility requirements | Every accessibility feature promised for this release is present and verified. | An unmet declared requirement is blocked unless the release scope is formally changed before the decision. |
| G4 | Performance threshold | The defined scenario remains within the project’s stated threshold under target conditions. | A measured threshold failure is blocked; absent measurement is unsupported. |
| G5 | Content completeness | All scenes, controls, text, assets, and completion states required by the release scope are packaged and reachable. | Missing required content is blocked. |
| G6 | Recovery | The defined save, restore, resume, or interruption scenario succeeds under the stated conditions. | An untested recovery claim is unsupported; an observed required-path failure is blocked. |
| G7 | Nonessential presentation quality | No unresolved nonessential presentation defect remains in the reviewed release scope. | A reproduced cosmetic defect may produce waived status only when its impact and scope are documented and the responsible release decision-maker explicitly authorizes the exception. Without that authorization, G7 is blocked. |
| D1 | Optional release-documentation improvement | Optional wording improvements outside required release information are either complete or accurately assigned. | Use follow-up when the current information is not misleading, the improvement is outside required release information, and a responsible person or role plus review point is recorded. If required information is absent or misleading, map the finding to the applicable required gate instead of D1. |
G7 therefore cannot pass merely because a cosmetic defect has a reproduction note. A reproduction note supplies evidence that the defect exists. The gate is waived, not passed, only when the permitted exception is documented and authorized.
D1 is a policy rule rather than a release gate. A finding mapped to D1 does not need an invented G1–G7 identifier.
1485. Decision method
For each finding, record:
- Control ID: G1–G7 or D1.
- Evidence boundary: what was observed, where, and under which conditions.
- Control status: passed, blocked, waived, unsupported, or follow-up as permitted by that control.
- Finding classification: blocker, accepted risk, follow-up, or unsupported claim.
- Decision: fix, test, authorize an exception, or schedule follow-up.
- Responsible person or role: required for an exception or follow-up.
Use this sequence:
Finding → predefined control → bounded evidence → control status
→ finding classification → decision and responsible person or role
1486. Worked examples
Example A: cosmetic defect
A rare flicker appears during a nonessential transition. It has been reproduced and its impact is limited to that transition.
- Control: G7
- Evidence boundary: reproduced twice at one supported resolution; other resolutions remain untested
- Status before authorization: blocked
- Classification before authorization: blocker
- If the responsible release decision-maker documents the scope, impact, and authorization: G7 becomes waived and the finding becomes an accepted risk
The reproduction note alone does not pass or waive G7.
Example B: optional wording improvement
The release notes already identify a non-blocking control limitation accurately, but the wording could be clearer.
- Control: D1
- Evidence boundary: the limitation is present and accurate; only clarity could improve
- Status: follow-up
- Classification: follow-up
- Decision: assign the revision and a review point
No G1–G7 mapping is needed because the work is outside required release information.
Example C: untested restoration
The team says save restoration is stable, but it has only tested creating a save.
- Control: G6
- Evidence boundary: save creation was observed once; restart and restoration were not tested
- Status: unsupported
- Classification: unsupported claim
- Decision: run the missing restore test or narrow the claim
1487. Git as an evidence trace
Connect the artifact to the existing source state using:
Source: <existing commit hash> on <branch>
Artifact: <build identifier>
Environment: <target and relevant conditions>
Evidence: <test record, log, or screenshot reference>
Finding: <bounded observation>
Control: <G1–G7 or D1>
Status: <passed | blocked | waived | unsupported | follow-up>
Classification: <blocker | accepted risk | follow-up | unsupported claim>
Decision: <next action and responsible person or role>
Git identifies which source state produced the artifact. It does not prove runtime behavior or establish that a release control passed.
1488. Practical assessment
Complete Release finding classification record. Classify all seven supplied cases against G1–G7 or D1. Each row must contain a predefined control ID, evidence boundary, permitted control status, canonical finding classification, decision, and responsible person or role when required.
The assessment checks whether you can apply supplied controls. It does not ask you to design a new release checklist; that capability belongs to the next lesson.
1489. Common mistakes
- Marking G7 passed because a cosmetic defect is documented. Documentation proves the defect exists; an authorized exception makes G7 waived.
- Forcing optional documentation work into an unrelated gate. Use D1 when its stated conditions apply.
- Treating missing evidence as proof of failure or success. Record unsupported status and an unsupported claim.
- Calling a known defect an accepted risk without documented scope, impact, and authorization.
- Using a commit hash as proof that runtime testing succeeded.
1490. Completion evidence
You are ready to continue when your assessment:
- maps every case to G1–G7 or D1 without inventing a control;
- records G7 as waived, not passed, for the authorized cosmetic exception;
- maps the optional wording improvement to D1 with follow-up status;
- separates control status from finding classification;
- states what the evidence does and does not prove;
- names the next action and responsible person or role where required.
1491. Key takeaways
- A build is an artifact; a release is a decision supported by controls and evidence.
- Finding classification and control status are separate fields.
- A permitted cosmetic exception makes G7 waived, not passed.
- D1 governs optional documentation improvements that do not affect required release information.
- Unsupported claims must be narrowed or tested.
- The next lesson teaches you to author gate criteria, evidence requirements, decision rules, and a release checklist.
1492. Next lesson
Continue to 4.1 L2 — Build a release gate.
1493. 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.
1494. Knowledge check
Answer these items for yourself before reading the answers.
What distinguishes a release candidate from a locally successful build?
Show answer and feedback
Answer: It has been evaluated against required controls, with remaining limitations explicitly handled.
Why: Release readiness depends on required controls, bounded evidence, and explicit treatment of remaining limitations—not artifact size, tooling, or an absence of known defects.
A team claims save restoration works but has never tested restoration after restarting the application. Which pair is correct?
Show answer and feedback
Answer: G6 unsupported; unsupported claim
Why: The available evidence does not determine whether the G6 restoration criterion passed, and the broader restoration statement is an unsupported claim.
A nonessential visual defect remains unresolved. Its impact and scope are documented, and the responsible release decision-maker explicitly authorizes the permitted exception. What is the correct result?
Show answer and feedback
Answer: G7 waived; accepted risk
Why: G7 passes only when no unresolved nonessential presentation defect remains. A documented and authorized exception makes the gate waived and the finding an accepted risk.
Release notes accurately identify a non-blocking control limitation, but their optional wording could be clearer. Which control and status apply?
Show answer and feedback
Answer: D1 follow-up
Why: D1 covers optional wording improvements outside required release information, provided the current text is accurate and the improvement has a responsible person or role and review point.
Which records are required before a known cosmetic defect can be classified as an accepted risk under G7?
Show answer and feedback
Answer: Documented impact; Documented scope; Explicit authorization by the responsible release decision-maker
Why: The exception requires documented impact and scope plus explicit authorization. Git can trace source state but cannot prove that a defect is harmless or authorize its acceptance.