Establish a safe change boundary

2113. Lesson identity

Module

5.5 — Change safety

Lesson

Establish a safe change boundary

Academic type

Workflow

Schema type

Mixed

Order

1

Estimated time

30–40 minutes, including practice

This lesson establishes a repeatable preparation step before asking an AI system to modify a game project. The goal is not to eliminate risk. The goal is to make the intended change, its limits, its verified baseline reference, and the evidence needed to decide whether an edit is ready to authorize explicit.

2114. Learning objective

After this lesson, you can produce a change-safety plan for a bounded project task that identifies a verified baseline and stable Git reference, evaluates impact and likelihood, defines in-scope and out-of-scope work, specifies validation evidence, and selects a state-appropriate recovery plan before any edit is authorized.

2115. Why this matters

An AI-assisted change can be locally correct and still damage unrelated behavior, scene setup, data, or project configuration. A safe boundary gives you a comparison point before the change and a decision rule after it. A recorded commit identifier or another stable repository-approved reference makes that baseline addressable rather than merely remembered. It also gives the AI a narrower task to execute and makes review more objective.

2116. Prior knowledge

You should already be able to inspect project context, identify stale or misleading sources, and describe uncertainty before requesting a modification. This lesson follows 5.4 L2 — Detect stale or misleading context. You should also know how to inspect repository status and use the project's approved Git procedures for recording a baseline and handling tracked, staged, untracked, or generated files.

2117. Core concept

A safe change boundary is a written contract around one modification. Its five conceptual parts are:

1. Baseline: What is true and verified before the change.
2. Risk: What could be affected, and how severe or likely that effect is.
3. Scope: What the request may change and what it must not change.
4. Validation: What observable checks will determine whether the change is acceptable.
5. Rollback: How to return to the baseline if the result fails the checks or exceeds scope.

These five parts describe the decision structure. The BOUNDARY model below expands that structure into eight operational elements for preparing a change and deciding whether it is ready for authorization. The eight elements do not replace the five parts: Baseline maps to B, Risk to O, Scope to U and N, Validation to D and A, and Rollback to R. Y preserves the evidence supporting the pre-edit decision.

For this workflow, define the baseline with a commit identifier or another stable reference approved by the repository. Record evidence that the relevant baseline test passes and that the working tree is clean, or explain every expected status entry. A recovery plan must match the possible repository state: uncommitted tracked edits may require the approved discard procedure; staged edits may need to be unstaged before restoration; an accepted commit may require the approved revert procedure that creates an inverse commit; and untracked or generated files must be handled according to repository policy because reverting a commit does not remove them. Do not prescribe a destructive reset. Record the applicable repository-approved action and require the baseline test to be rerun after any recovery.

The boundary is useful only when each part is concrete enough for another person—or an AI agent—to act on and review. A baseline is more than a file copy or a commit message. Record the relevant behavior, the project state that supports it, the evidence used to verify it, and the commit identifier or other stable repository-approved reference that preserves it.

Risk is not a prediction that the change will fail. It is a reason to choose stronger controls. Rate impact and likelihood separately as low, medium, or high. Impact describes the consequence if the change causes a problem; likelihood describes how plausibly the proposed scope or dependencies could cause it. Use the higher dimension as the default overall rating unless you document another repository-approved rule, then name the control added because of that rating. For example, a medium-impact, low-likelihood change is medium overall and needs checks broad enough to cover the affected behavior and its nearest dependency. A change touching one isolated text value may need lighter checks than a change affecting shared gameplay code, scene references, save data, or project settings.

Scope is a boundary, not a suggestion. State both the allowed change and the prohibited expansion. “Adjust the cooldown value in this ability” is bounded. “Improve the ability” invites unrelated redesign.

2118. Mental model

Use the BOUNDARY model before requesting a project change. Treat it as an operational expansion of the five-part boundary, not as a second competing checklist:

The five parts help you reason about the safety decision. The eight BOUNDARY elements turn that reasoning into preparation evidence. BOUNDARY is an English mnemonic; keep the five-part boundary as the primary structure and treat the letters as a memory aid, not as a second competing checklist. You do not ask the AI to “make it better” and hope later review catches the cost. You define the boundary, verify the baseline reference and repository state, and decide whether the request is ready to authorize. Implementation evidence and the final accept, revise, or recover decision belong to the next lesson.

2119. Concrete example

Suppose the bounded task is: reduce the cooldown of one dash ability from 2.0 seconds to 1.5 seconds.

A weak request is:

Make the dash feel more responsive.

This leaves the affected value, related systems, and acceptance criteria unclear.

A safer plan is:

• Baseline: The dash activates, enters its cooldown, and becomes available again after 2.0 seconds in the existing movement test. Record the current value, one successful test run, and a commit identifier or other stable repository-approved reference, plus evidence that the working tree is clean or fully explained.
• Risk: Impact is medium because an error could alter repeated activation, resource use, UI feedback, or shared ability configuration. Likelihood is medium because the value may be shared or referenced outside the visible ability. The overall rating is therefore medium. Added controls: inspect the relevant configuration references and plan checks for repeated activation, resource cost, UI feedback, and one unrelated ability.
• In scope: Change the cooldown value for this dash ability only.
• Out of scope: Do not change movement speed, invulnerability duration, stamina cost, UI wording, other abilities, or input handling.
• Validation: Confirm the dash still activates correctly, the measured cooldown is 1.5 seconds, repeated activation is blocked during cooldown, unrelated movement behavior is unchanged, and the diff contains only the allowed change.
• Recovery plan: Record the baseline commit identifier or approved stable reference and the clean working-tree evidence. If later work must be abandoned, select the repository-approved action for its actual state: discard uncommitted tracked edits, unstage and restore staged edits, revert an accepted commit with an inverse commit, and handle untracked or generated files under repository policy. After recovery, rerun the baseline test.

The example does not guarantee that 1.5 seconds is good design. It demonstrates how to make the decision testable, reviewable, and reversible.

2120. AI-native workflow

Use AI to clarify the plan without allowing it to modify the project in this lesson:

1. Prepare the boundary yourself. Write the verified baseline, separate impact and likelihood ratings, overall risk, added control, scope, non-goals, planned checks, stop criteria, and recovery scenarios.
2. Verify the baseline reference. Run the relevant baseline test, record a commit identifier or another stable repository-approved reference, and capture evidence that the working tree is clean or that every expected status entry is understood.
3. Provide only relevant context. Include the named task, affected location, known constraints, baseline reference, repository-state evidence, and baseline test result. Do not provide broad permission to redesign.
4. Ask the AI to restate the boundary. Require it to list the proposed files or systems, assumptions, risks, checks, and ambiguities without editing any file.
5. Compare its restatement with your plan. Reject invented scope, unsupported assumptions, missing controls, or a recovery proposal that does not account for tracked, staged, committed, untracked, and generated states.
6. Make the pre-edit decision. Record ready to authorize only if the boundary is complete, the baseline reference is verified, the proposed checks match the risk, and the recovery plan is state-appropriate. Otherwise record not ready and identify what must be corrected.

Stop here. In 5.5 L2 — Inspect, validate, and recover, you will implement or inspect the change, examine its diff, run the checks, choose accept, revise, or recover, execute an approved recovery action when necessary, and verify restoration by rerunning the baseline test. The human remains responsible for both the pre-edit authorization decision and the later evidence-based outcome.

2121. Common mistake

The common mistake is treating a backup, an unnamed “checkpoint,” or any commit as the complete safety plan. A baseline needs a recorded commit identifier or another stable repository-approved reference, a passing baseline test, and evidence of a clean or fully explained working tree. Another mistake is using “revert” as a universal synonym for undo. Uncommitted tracked edits, staged edits, accepted commits, and untracked or generated files require different repository-approved handling. Plan for the relevant states, use observable stop criteria, avoid prescribing destructive reset behavior, and require the baseline test to pass again after recovery.

2122. Guided practice

Create a change-safety plan for this bounded task:

Change the text shown when the player has insufficient currency to use an item. The message should become clearer. Do not change the currency calculation, item cost, purchase result, or other messages.

Complete the following steps:

1. Write one verified baseline statement. Include the current message, the behavior that must continue to work, and the result of the baseline test.
2. Rate impact and likelihood separately as low, medium, or high. Derive the overall rating by using the higher dimension, or justify another repository-approved rule.
3. Name at least one system that could be affected accidentally and one control added because of the overall rating.
4. Define the in-scope change in one sentence.
5. List at least three non-goals.
6. Write three planned pass/fail checks, including one that protects unrelated behavior. Explain why their breadth matches the risk rating.
7. State the exact scope or validation result that would require work to stop.
8. Record the commit identifier or other stable repository-approved reference for the verified baseline. Include evidence that the working tree is clean or explain every expected status entry.
9. Plan recovery for each relevant state: uncommitted tracked edits, staged edits, an accepted commit, and untracked or generated files. Refer to repository-approved actions, avoid destructive reset instructions, and require the baseline test to be rerun after recovery.
10. Draft a short AI request that includes the boundary and baseline reference and asks the AI to restate the plan without editing.
11. Record a pre-edit decision of ready to authorize or not ready, supported by the baseline evidence, risk controls, scope, checks, stop criteria, and recovery plan.

Two decisions are mandatory: determine the overall risk from impact and likelihood, then decide whether the request is ready for authorization. Defend both decisions by connecting the identified risk to the breadth of the planned checks and recovery controls.

2123. Validation / evidence

Your completed plan is sufficient when another developer can answer all of these questions without guessing:

• What behavior and project state were verified before the change?
• What baseline test passed?
• Which commit identifier or stable repository-approved reference represents that baseline?
• Is the working tree clean, or is every expected status entry explained?
• What may the AI modify, and what must it leave alone?
• What are the separate impact and likelihood ratings, the overall risk, and the control added because of that rating?
• Which planned checks match the breadth of the identified risk?
• What exact result would require work to stop?
• What approved recovery action is planned for uncommitted tracked edits, staged edits, an accepted commit, and untracked or generated files?
• Does the recovery plan require the baseline test to be rerun?
• Is the request ready to authorize, and what evidence supports that decision?

Preserve the boundary plan, baseline test evidence, stable Git reference, repository-status evidence, AI restatement, and justified pre-edit go/no-go decision. If the AI's restatement adds scope, leaves an assumption unresolved, weakens the checks, or proposes recovery that does not match the possible repository state, record not ready and correct the boundary. Diff inspection, post-change validation, acceptance, correction, recovery execution, and final decision documentation are performed in the next lesson.

2124. Key takeaways

• The five-part boundary gives the safety decision its structure; BOUNDARY expands it into eight preparation elements.
• A safe change begins with a passing baseline test, a commit identifier or stable approved reference, and a clean or fully explained working tree.
• Rate impact and likelihood separately, derive the overall risk, and add controls whose breadth matches that rating.
• Scope must include explicit non-goals to prevent accidental redesign.
• Recovery planning must distinguish uncommitted, staged, committed, untracked, and generated states and must require the baseline test to be rerun.
• This lesson ends with a justified pre-edit go/no-go decision; implementation, diff inspection, validation, and recovery execution belong to the next lesson.

2125. Next lesson

Continue to 5.5 L2 — Inspect, validate, and recover.

2126. Knowledge check