Inspect, then decide

174. Lesson identity

Module

1.ai-partner — Directing the AI Partner

Lesson title

Inspect, then decide

Academic type

Debugging Lab

Schema type

Practical

Order

Lesson 2 in the module

Estimated content and practice

25–40 minutes

175. Learning objective

After this lesson, you can use the 1.3 rules artifact as a checkpoint, inspect a proposed diff, and accept, refuse, or request a narrower revision using evidence from the artifact, the brief, and the diff.

176. Why this matters

An AI explanation is a claim about a change, not proof that the change is correct. The 1.3 rules artifact establishes a project-specific boundary. The bounded brief defines the requested result and exclusions. The visible diff shows what the AI proposes to change.

You need all three before making a decision. A plausible explanation cannot excuse an out-of-scope file, changed value, removed guard, renamed symbol, or unrequested side effect.

This lesson stops at the inspection decision. You will not apply the edit or test runtime behavior here. The next lesson covers validation after an approved change has been applied.

177. Prior knowledge

You should have completed 1.ai-partner Lesson 1, The brief is the job, and module 1.3, including its rules artifact. You should be able to locate the artifact and identify the rules, permitted areas or files, and prohibited areas that apply to a proposed change. No programming-language expertise is required; you will inspect small annotated patches.

178. Core concept

Explanation is not evidence.

Use three sources when inspecting a proposal:

1. The 1.3 rules artifact establishes the applicable project boundary.
2. The brief states the requested result, permitted scope, and exclusions.
3. The diff reveals the files, conditions, values, and behaviors the AI proposes to change.

A diff shows a before-and-after boundary:

• Added lines may introduce behavior, data, or side effects.
• Removed lines may delete behavior or a safety guard.
• Modified lines may alter conditions, timing, values, or ownership.
• Unrelated edits are evidence of excess scope, even when they look harmless.

The decision must be tied to visible evidence. Use one of three outcomes:

• Accept when the proposal stays within the permitted scope and represents the requested result.
• Refuse when the proposal violates a rule or an explicit boundary.
• Request a narrower revision when a valid part can be separated from out-of-scope edits or when the requested result is not specific enough to judge the proposed behavior.

179. Mental model

Use Rules checkpoint → Claim → Diff → Decision:

Establish the rules checkpoint before treating the AI explanation as justification. This reduces confirmation bias: define the boundary first, then compare the claim and diff with it.

For this module, keep the working loop visible:

ACT → RESPOND → CHANGE → AGAIN

You act by giving a bounded brief. The AI responds with a proposal. Inspection determines whether the proposed change may proceed. If the evidence reveals a problem, you run the loop again with a refusal, clarification request, or narrower brief.

Inspection is the decision point between RESPOND and CHANGE. Runtime behavior and action-delivery checks belong to the next lesson.

180. Concrete example

Suppose the applicable 1.3 rule permits a response in an existing action handler but prohibits changes to input bindings, movement constants, and UI presentation. The brief narrows that boundary:

Add a dash response to the existing action handler. Change only PlayerController.js. Do not rename actions, alter movement speed, or modify UI behavior. Move the player 10 units once when the dash action is received.

The AI says:

I added dash support and kept the existing movement behavior unchanged.

The proposed diff is:

--- a/PlayerController.js
+++ b/PlayerController.js
@@
 function handleAction(action) {
+  if (action === "dash") {
+    player.position.x += 10;
+  }
   if (action === "move-left") {
     player.position.x -= player.speed;
   }
 }

The diff changes only the named file, checks the requested action, and represents the requested one-time movement. If the rules artifact permits that controller edit, accepting the proposal is reasonable on the evidence shown.

That decision does not prove that the running game delivers the action or that the applied result works. Those checks belong to L3.

Now consider a proposal divided into groups:

--- a/PlayerController.js
+++ b/PlayerController.js
@@
 function handleAction(action) {
+  if (action === "dash") {
+    player.position.x += 10;
+  }
 }
--- a/InputMap.js
+++ b/InputMap.js
@@
-  dash: "Shift",
+  dash: "Space",
--- a/HUD.js
+++ b/HUD.js
@@
-  drawActionLabel(currentAction);
+  drawActionLabel("DASH READY");

The controller group represents the requested behavior, but the other groups change an input binding and UI presentation. Refuse the broad proposal or request a revision containing only the permitted PlayerController.js edit. A valid first group does not authorize the rest.

181. AI-native workflow

1. Read the applicable section of the 1.3 rules artifact. Record the relevant permitted and forbidden areas or files.
2. Read the bounded brief. Identify the requested result, permitted scope, and explicit exclusions.
3. Record the AI's claim without treating it as proof.
4. Inspect every changed file and every group in the proposed diff.
5. Check added and removed conditions, changed values, renamed symbols, and unrelated edits.
6. Mark each observed change in scope, out of scope, or uncertain.
7. Decide:
   • Accept only when the represented behavior and every edit satisfy the rules and brief.
   • Refuse when any edit violates a rule or explicit boundary.
   • Request a narrower revision when permitted edits can be separated from prohibited ones.
   • Request clarification when the brief does not define the result precisely enough to determine whether the proposed behavior is correct.
8. Cite the evidence for the decision before allowing any change.
9. Do not apply the edit or perform runtime, input-delivery, or post-application checks in this lesson.

182. Common mistakes

Letting the explanation define the boundary

A confident explanation can make an unrequested behavior appear acceptable. The rules artifact and brief define the boundary; the explanation does not.

Accepting a behavior the brief never specified

A brief such as “add a response to interact” does not identify whether the response should open, highlight, collect, or inspect the target. If the diff calls target.open() under that ambiguous brief, the correct decision is uncertain—request clarification or a more precise brief. Do not infer the requested outcome from the proposed implementation.

Inspecting only the first valid group

Each file and group requires inspection. A permitted controller edit does not authorize changes to input bindings, movement, dialogue, or UI presentation.

Treating a proposed diff as runtime proof

This lesson determines whether the proposal should be allowed by inspection. L3 validates the applied result and runtime behavior.

183. Guided practice

Use the 1.3 rules artifact from your project or course materials. Do not edit a project or test runtime behavior. Make each decision from the evidence shown.

1. Establish the checkpoint

Before reading the AI explanation, write a short checkpoint:

1. Name the applicable rule or rule group.
2. State the permitted file or area.
3. State at least one prohibited area or change.
4. Mark any boundary the artifact leaves uncertain. Do not replace uncertainty with an assumption.

Then compare the checkpoint with this bounded brief:

When InteractionController receives the interact action and a current interaction target exists, open that target exactly once. Change only InteractionController.js. Do not change the action name, player speed, dialogue text, input bindings, or input polling. If no interaction target exists, do nothing.

The acceptance criteria are therefore:

• Only InteractionController.js changes.
• The condition requires both action === "interact" and an existing target.
• The current target receives exactly one open() call for that handler invocation.
• No input, movement, or dialogue behavior changes.

2. Inspect the small proposal

AI explanation:

I added the interaction response without affecting existing controls.

Proposed diff:

--- a/InteractionController.js
+++ b/InteractionController.js
@@
 function handleAction(action, target) {
+  if (action === "interact" && target) {
+    target.open();
+  }
 }

Write three notes:

1. Boundary: connect the applicable rule and brief to the permitted file and requested result.
2. Evidence: identify the changed file, condition, and behavior. Mark each as in scope, out of scope, or uncertain.
3. Decision: explicitly accept, refuse, or request a narrower revision. Cite the inspected line and applicable boundary.

On the evidence shown, acceptance is appropriate only if the 1.3 rules artifact permits this controller edit. The diff is limited to InteractionController.js, requires the interact action and an existing target, and contains one target.open() call. Those facts match the brief's defined result and acceptance criteria.

Do not use assumptions about runtime action delivery as evidence here.

3. Inspect the broad proposal

Now inspect this separate proposal without applying it:

--- a/InteractionController.js
+++ b/InteractionController.js
@@
 function handleAction(action, target) {
+  if (action === "interact" && target) {
+    target.open();
+  }
 }
--- a/InputMap.js
+++ b/InputMap.js
@@
-  interact: "E",
+  interact: "F",
--- a/DialogueBox.js
+++ b/DialogueBox.js
@@
-  show(text);
+  show(text.toUpperCase());

Treat each file as a separate group and record a decision for it:

• InteractionController.js represents the requested response and may be accepted if the rules artifact permits it.
• InputMap.js changes an input binding explicitly excluded by the brief.
• DialogueBox.js changes dialogue presentation explicitly excluded by the brief.

Refuse the broad proposal or request a narrower revision containing only the permitted controller group. Do not accept the entire proposal because one group is valid.

4. Inspect a removed guard

Suppose a revision instead contains this diff:

 function handleAction(action, target) {
-  if (action === "interact" && target) {
+  if (action === "interact") {
     target.open();
   }
 }

The removed && target condition contradicts the criterion “if no interaction target exists, do nothing.” Refuse this proposal or request restoration of the guard. The exact evidence is the removed condition, not a prediction about what might happen during a runtime test.

184. Validation and evidence

Your practical check is complete when you submit, in this order:

• A checkpoint from the applicable 1.3 rules artifact.
• The brief, including its permitted file, requested result, and exclusions.
• The AI's stated claim.
• Every file and group shown in each proposed diff.
• At least one specific line, condition, value, removed guard, or behavior supporting each decision.
• An explicit decision for the small proposal.
• A separate decision for the broad proposal, identifying both out-of-scope groups.
• A decision for the removed-guard proposal, citing && target as the relevant evidence.
• A reason connecting the rules artifact and brief to the inspected diff.

A passing response:

• establishes the applicable boundary before using the AI explanation as justification;
• accepts the small controller proposal only when the artifact permits it and because it matches the explicit open() acceptance criteria;
• refuses the broad proposal or requests a revision limited to InteractionController.js;
• identifies InputMap.js and DialogueBox.js as conflicting edits;
• refuses or requests correction of the proposal that removes the target guard; and
• does not use runtime behavior, input delivery, or post-application results as inspection evidence.

This checkpoint assesses inspection judgment. It does not assess whether an applied change works in the running project.

185. Knowledge check

186. Key takeaways

• Establish the boundary from the rules artifact and brief before treating the AI explanation as justification.
• The explanation is a claim; the diff is inspectable evidence.
• The brief must define the requested result precisely enough to judge the implementation.
• Inspect every file, group, condition, value, renamed symbol, and removed guard.
• A valid edit does not authorize unrelated edits.
• Inspection belongs between RESPOND and CHANGE.
• L2 decides whether a proposal may proceed; L3 validates the applied result and runtime behavior.

187. Next lesson

Continue to 1.ai-partner L3 — Validate what changed.

188. Debugging lab — Broken input (fix-broken-input)

Open academy-fixtures/labs/broken-input. Run node diagnose.mjs. Predict pulse-on-beat-0. Restore simulation mutation in your Pulse Loop copy; do not fake presentation. Evidence: diagnose JSON + later validate. Git: checkpoint before the fix.

189. AI independence (fix-ai-bounded-change)

Open academy-fixtures/labs/ai-bounded-change. Run node run.mjs. Bound the task, inspect the proposal, run an independent oracle, REJECT removing the dash energy check. AI is a constrained collaborator, not the decision-maker.

190. Knowledge check

- if (action === "interact" && target) {
+ if (action === "interact") {
    target.open();
  }
```**

A. Accept, because the action name is unchanged
B. Accept, because `open()` still appears exactly once in the source
C. Refuse or request correction because removing `&& target` violates the no-target criterion
D. Request clarification because the brief does not specify the no-target behavior

<details>
<summary>Show answer and feedback</summary>

*Answer:* Refuse or request correction because removing `&& target` violates the no-target criterion

*Why:* The removed `&& target` guard is exact evidence that the proposal contradicts an explicit acceptance criterion. Runtime testing is not needed to make this inspection decision.

</details>

**A brief says only, “Add a response when `interact` is received.” The proposed diff calls `target.open()`, but no requested outcome is defined. What should you do?**

A. Refuse permanently because `open()` is never a valid interaction
B. Apply it first and let the runtime result define the requirement
C. Accept because opening is a common interaction
D. Request clarification or a more precise brief before accepting the behavior

<details>
<summary>Show answer and feedback</summary>

*Answer:* Request clarification or a more precise brief before accepting the behavior

*Why:* The proposed implementation cannot define the requirement. Without a specified result, `open()` is uncertain rather than proven correct, so the learner should request clarification.

</details>