Validate what changed

191. Learning objective

After this lesson, you can test one bounded AI-assisted edit against acceptance criteria, record observable evidence, and make a traceable keep-or-revert decision. If the edit fails, you can restore a known-good baseline and verify that the failed behavior is no longer active.

192. Start from either valid Lesson 2 outcome

In Inspect, then decide, either accepting or refusing a proposal was valid.

• If you accepted a bounded proposal: use that inspected edit for this validation task.
• If you refused the proposal: do not apply it merely to complete this lesson. Instead, use a bounded fixture supplied for practice, or obtain a revised bounded proposal and inspect it before applying it. Record that you changed test subjects because the original proposal was correctly refused.

In either branch, validate only one inspected, bounded edit.

193. Core concept

Acceptance criteria turn an impression into a decision.

A useful criterion identifies:

• Trigger: the action or condition that starts the test.
• Expected result: the observable result that must occur.
• Boundary: a relevant result that must not occur or a system that must remain unchanged.

Example: “When the interaction is activated inside the intended area, it responds once. When activated outside that area, it does not respond. Unrelated movement remains unchanged.”

The running game is the primary evidence surface for player-facing behavior, but it is not the only possible evidence. A criterion may also require an observable build result, console message, state inspection, or rule check. The AI's explanation is never proof that a criterion passed.

194. Validation model: ACT → RESPOND → CHECK → DECIDE

Each step has one purpose:

Repeating a key test checks reliability; it remains part of the current validation. Beginning a correction after a failure is a separate bounded cycle and is not required for this lesson.

195. Decision rule

• Keep: every required criterion passes, including applicable boundary checks, and the evidence is sufficient.
• Revert: any required criterion fails or remains untested.

Do not remove a failed criterion merely to justify keeping the edit.

196. What restoration and safe isolation mean

Use the checkpoint or restoration mechanism already taught in the course. Restoration means returning to the known-good checkpoint created before the edit.

After restoring:

1. Relaunch or rerun the relevant test surface.
2. Repeat the trigger that exposed the failure.
3. Run one baseline check that should still work.
4. Record evidence that the failed behavior is absent and the baseline behavior remains available.

Safe isolation is acceptable only when a course-taught mechanism can exclude the edit from the loaded test state without altering the known-good baseline. You must relaunch or rerun the checks and record that the failed behavior can no longer affect them. Merely hiding an object, closing the chat, leaving a changed file unused by assumption, or promising to fix it later is not verified isolation.

If you do not have a reliable, taught isolation mechanism, restore the checkpoint. Do not present isolation as an equivalent guess.

197. Worked example

Suppose an inspected edit is intended to allow a response only inside a defined area.

The edit must be reverted because a required boundary failed. Return to the known-good checkpoint, relaunch the test, and activate the interaction outside the area again. Record that the failed outside-area response is no longer active. A future correction may use this evidence, but that correction begins a new cycle.

198. Guided practice

Work in your selected course language. Producing a second-language version is optional localization practice and is not required evidence.

1. Prepare the compact checkpoint

Before testing, complete this template:

• Test subject: accepted Lesson 2 edit / supplied bounded fixture / revised and inspected proposal
• Intended change:
• Outside scope:
• Criterion 1: trigger, expected result, boundary if applicable
• Criterion 2: trigger, expected result, boundary if applicable
• Evidence source: running behavior, build result, console output, state inspection, rule check, or supplied recording
• Known-good checkpoint: the checkpoint or restoration point you will use if a criterion fails

Use two criteria unless a third is necessary to represent an important boundary. Do not reconstruct the complete conversation from the previous lesson.

2. Run ACT → RESPOND → CHECK

For each criterion:

1. Perform the defined trigger.
2. Record what actually happened.
3. Mark pass, fail, or not tested.
4. Note any relevant side effect.

Repeat the most important trigger once to check reliability. Record both observations rather than replacing the first result.

3. DECIDE

• Keep only if all required criteria pass on the available evidence.
• Otherwise, revert to the known-good checkpoint.
• After restoration, relaunch or rerun the failed trigger and one baseline check. Record whether the failed behavior is absent.

A correction brief is optional and should be written only when a failure occurred. Label it as a separate next cycle; do not apply it as part of this validation record.

199. Accessible ways to produce evidence

The capability being assessed is validation reasoning, not use of a specific control device. You may gather equivalent evidence through:

• remapped controls, keyboard-only operation, or another alternative-input setup;
• an observer-assisted protocol in which you direct the test while another person performs the input and reports or records the result;
• analysis of a supplied recording that shows the trigger, result, and relevant boundary;
• other observable evidence required by the criterion, such as a build result, console output, state inspection, or rule check.

State which method you used. The evidence must still distinguish the trigger, observed response, criterion comparison, and decision.

200. Submission template

Submit one compact record in your selected course language:

1. Test subject and scope:
2. Known-good checkpoint:
3. Criterion 1 — trigger / expected result / boundary:
4. Observation and result: pass / fail / not tested
5. Criterion 2 — trigger / expected result / boundary:
6. Observation and result: pass / fail / not tested
7. Repeated key test and observation:
8. Decision: keep / revert
9. Reason linked to evidence:
10. If reverted, restoration verification: failed trigger after restoration, baseline check, and observed result
11. Optional next-cycle correction brief: only if a failure occurred

201. Practical assessment rubric

A record is incomplete if it keeps an edit with a failed or untested required criterion, relies only on the AI's summary, or claims restoration without rerunning the relevant checks.

202. Key takeaways

• Use ACT → RESPOND → CHECK → DECIDE to separate testing from judgment.
• Treat running behavior and other criterion-relevant observations as evidence; do not treat the AI's explanation as proof.
• Keep only when every required criterion passes.
• After failure, restore the known-good checkpoint unless you can verify isolation with a course-taught mechanism.
• Repetition checks reliability. A correction begins a separate bounded cycle.

203. Next lesson

The next lesson examines which mode owns mouse and keyboard input. Your validated scope and boundary records will help distinguish intended input behavior from unrelated changes.

204. Knowledge check