2355. Lesson identity
2356. Learning objective
After this lesson, you can select and justify an action by comparing diagnostic information gain or corrective leverage, evidence, reversibility, and invariant risk across interacting game systems.
2357. Why this matters
A visible problem rarely has only one cause. A player may appear to be losing too much currency, for example, while the actual interaction involves rewards, costs, progression thresholds, and difficulty pressure. Acting on the most visible system can create a second failure elsewhere. A systems-oriented developer chooses an intervention that tests a useful hypothesis while protecting the facts the game must preserve.
2358. Prior knowledge
You should be able to map system interactions, identify state owners, distinguish inputs from outputs, and record the invariants that must remain true. These capabilities come from the previous lesson, Map interactions, not isolated features. You should also be familiar with the course practice of asking AI to restate or challenge a design decision before you implement it.
2359. Core concept
When several systems contribute to a problem, first decide whether you need a diagnostic action or a corrective intervention.
- Information gain: How much decision-relevant uncertainty could a diagnostic action remove? Instrumentation generates observations; those observations, not the instrumentation itself, become evidence.
- Corrective leverage: How many relevant outcomes can a corrective intervention influence through one authoritative point?
- Evidence: How directly do the available observations support the causal hypothesis and proposed correction?
- Safety: How reversible is the action, and how likely is it to violate an invariant or create an untested dependency?
High information gain can justify a diagnostic action when the cause is uncertain. High corrective leverage can justify a targeted intervention when evidence supports the cause. Neither is automatically the right first move: a broad correction with weak evidence can damage more systems than it improves, while instrumentation that cannot distinguish among hypotheses adds little value.
2360. Mental model
The SAFE sequence
Use this sequence to rank candidate actions:
| Step | Question | Evidence to record |
|---|---|---|
| S — State the symptom | What outcome is wrong, and for whom? | Observable example, not an assumed cause |
| A — Assign the authority | Which system owns the relevant fact? | State owner and read/write path |
| F — Find the decision value and risk | Would diagnosis provide useful information gain, or does the evidence support a correction with useful corrective leverage? | Uncertainty reduced or outcomes affected, reversibility, invariant exposure |
| E — Evaluate the result | What observation would support or reject the hypothesis? | Expected result and rollback or reassessment condition |
Rank candidate actions using this judgment rule:
When causal evidence is weak, prefer a safe diagnostic action with useful information gain. When evidence supports a cause, prefer a reversible corrective intervention at an authoritative point with useful leverage and protected invariants.
Do not confuse “smallest code change” with “safest action.” A tiny presentation patch may hide the cause. A small corrective change at the state owner can be safer because it preserves one source of truth.
2361. Concrete example
Consider an invented economy-and-progression scenario. Testers report that new players reach the first upgrade threshold too slowly. The interaction map shows:
- A mission system awards credits.
- A transaction system subtracts credits for supplies.
- A progression system checks the saved credit total against an upgrade threshold.
- The HUD displays the current credit total and the distance to the threshold.
- Difficulty pressure increases supply usage during longer missions.
The team proposes four interventions:
| Candidate | Type and decision value | Current support | Safety risk |
|---|---|---|---|
| Increase the number shown in the HUD | Corrective; low leverage because it changes presentation only | Weak; the HUD may be accurate | Low, but it may conceal the problem |
| Lower the progression threshold | Corrective; medium leverage because it changes advancement for all players | Medium; the threshold is involved, but the cause is unclear | Medium; it changes the progression contract |
| Add more mission credits | Corrective; medium leverage because it changes one reward source | Medium; reward flow may contribute | Medium; economy balance changes across missions |
| Log and compare mission rewards, supply costs, and threshold checks for one controlled scenario | Diagnostic; high expected information gain with no economy change | Not evidence by itself; the resulting observations can distinguish among hypotheses | Low; reversible instrumentation |
The fourth option is the safest first action because causal evidence is weak and the controlled observations can reveal whether rewards, costs, or threshold checks dominate the outcome. The logging does not itself prove that any system is wrong. It gathers evidence at the interaction points while protecting the progression invariant: a player should advance only when the authoritative progression rule confirms that the threshold is met. After the observations support a causal hypothesis, the team can choose a targeted corrective intervention, evaluate its corrective leverage, and define a new validation check.
2362. AI-native workflow
Use AI as a challenger and comparison tool, not as the decision owner.
- Write the symptom, state owner, relevant interactions, invariants, and candidate interventions yourself.
- Ask AI to produce a causal reading of the map and to identify assumptions in your ranking.
- Ask it to argue for the second-best intervention, including what evidence would make that option safer.
- Compare its response with your map. Reject suggestions that invent dependencies, bypass the state owner, or weaken an invariant.
- Record the selected intervention, expected observation, and rollback condition before making any project change.
A useful prompt is:
Given this interaction map, symptom, and invariant list, classify each candidate as diagnostic, corrective, or both. Rank diagnostic actions by expected information gain and corrective interventions by evidence, corrective leverage, reversibility, and invariant risk. Separate observed facts from assumptions. Do not propose a presentation-only fix unless the evidence identifies presentation as the owner of the problem.
The quality test is not whether AI produces a confident ranking. The quality test is whether you can explain which parts of the ranking are supported by evidence and which require investigation.
2363. Git workflow
Use project history and the current diff as evidence about scope, ownership, and unintended coupling before treating an intervention as safe.
- Identify the relevant files or systems that would be affected by each candidate intervention.
- Review their recent history, when available, for the reason the current rule or boundary exists. Treat history as context, not as proof that the current behavior is correct.
- Inspect the current diff or establish a clean baseline before making the change. Separate pre-existing work from the intervention under evaluation.
- Compare the intended intervention with the resulting diff: does it touch the authoritative point, alter unrelated systems, or weaken an invariant?
- Record the history or diff evidence that supports the choice, plus the rollback or reassessment condition.
A small diff is not automatically a safe diff. The useful Git evidence is the relationship between the proposed change, the state owner, the affected systems, and the invariant—not the line count alone.
2364. Common mistake
The common mistake is choosing the most visible or most powerful intervention first. Changing a global reward, threshold, or difficulty value may appear efficient, but it can alter several player experiences before the cause is established. Another mistake is treating a reversible change as safe even when it bypasses an invariant. Reversibility lowers risk; it does not remove the need for a causal hypothesis.
2365. Guided practice
Use the following case. A prototype has three interacting systems:
- Encounter system: determines how often a player is exposed to a hazard.
- Supply system: consumes one supply unit when the player uses a protective action.
- Survival progression system: unlocks the next protective upgrade after the player completes a threshold of successful encounters.
The symptom is: “Players abandon the run before reaching the next protective upgrade.” The interaction map shows that the encounter system increases hazard exposure after each completed encounter, while the supply system has a fixed cost per protective action. The progression system counts successful encounters correctly. The invariant is: “An upgrade unlocks only after the authoritative progression counter reaches its threshold.”
Evaluate these interventions:
- Reduce hazard exposure after each encounter.
- Reduce the supply cost of the protective action.
- Lower the upgrade threshold.
- Add a temporary log comparing hazard exposure, protective actions, supply consumption, and progression count in one controlled run.
Then complete the following decision record:
- State the symptom without naming a cause.
- Identify the authoritative state owner for progression and the likely owners for exposure and supply consumption.
- Classify each candidate as a diagnostic action or a corrective intervention, then rank the four from safest first to riskiest first.
- Select one first action. For a diagnostic action, justify its expected information gain; for a corrective intervention, justify its evidence and corrective leverage. In either case, assess reversibility and invariant risk.
- Review the relevant history and current diff, or define the baseline you would inspect, and record how that evidence affects your confidence in the selected action.
- Define the observation that would support your hypothesis and the condition that would trigger rollback or a different investigation.
Your ranking may differ from another learner's ranking if your evidence assumptions are explicit and coherent. The required decision is not “always add logging.” It is to show why diagnosis is warranted by uncertainty or correction is warranted by evidence, and why the first action protects the system contract.
2366. Validation / evidence
Your work is sufficient when it contains a decision record that:
- distinguishes the symptom from at least one hypothesis;
- names the relevant state owners and interactions;
- compares all four candidates rather than selecting by intuition alone;
- identifies one invariant and explains how the selected intervention protects it;
- uses relevant history, a current diff, or an explicitly documented baseline to assess scope and unintended coupling;
- states an expected observation and a rollback or reassessment condition;
- explains why at least one tempting alternative should not be the first action.
A strong answer chooses a diagnostic intervention first when the causal evidence is weak, or chooses a targeted authoritative change when the evidence clearly supports it. It does not use “smallest change” or “largest impact” as the only justification.
2367. Key takeaways
- Treat intervention selection as a systems decision, not a single-feature decision.
- Evaluate diagnostic information gain or corrective leverage together with evidence and reversibility.
- Use history and diffs to test whether the proposed scope matches the system boundary.
- Preserve invariants even when a broader change appears faster.
- AI can challenge the ranking, but the developer must defend the evidence and system boundaries.
2368. Next lesson
This is the final lesson in 5.13 — Systems thinking. The next module is 5.14 — Technical direction, where these intervention choices become technical priorities and constraints. Technical direction should establish the implementation boundaries and sequencing that 5.15 — Creative direction can use to shape the player-facing expression; it does not replace or dictate the creative direction.
2369. Knowledge check
Answer these items for yourself before reading the answers.
When evidence about the cause is still weak, why is a reversible diagnostic action usually the safest first move?
Show answer and feedback
Answer: It can generate discriminating observations with limited downside; those observations may become evidence after interpretation.
Why: A diagnostic action is valuable because it can generate observations with high information value while limiting downside. Those observations may later become evidence after interpretation and validation; they are not evidence by themselves. Broad corrections made on weak causal evidence can change the economy, the progression contract, or the player experience too soon.
Why is a presentation-only fix often a weak first intervention for a systems problem?
Show answer and feedback
Answer: It may hide the symptom without changing the authoritative state or cause.
Why: If the presentation is not the owner of the faulty fact, changing it can make the result look different while leaving the underlying interaction unchanged.
Reward payout, supply cost, and a progression threshold all participate in a failure, but you still lack a supported causal hypothesis. Which first action is justified?
Show answer and feedback
Answer: Add reversible instrumentation that can distinguish the competing hypotheses before changing the economy.
Why: Diagnostic first actions are justified by expected information gain and limited downside. Corrective interventions need a supported causal hypothesis, corrective leverage at an authoritative point, reversibility, and protected invariants. High corrective leverage is not a reason to act first while the cause is still uncertain.
What must a useful intervention record include after the choice is made?
Show answer and feedback
Answer: The expected observation and the condition for rollback or reassessment.
Why: An intervention is testable only when the developer defines what result would support the hypothesis and when to reverse or reconsider the decision.