balance-tuninglisted

# Balance Tuning Measure balance against an intended experience. Establish that intent, model the relevant system, and close the measured gap. ## 1. Inspect the project and request Identify the engine or runtime, entry point, run and test commands, design documents, and where tunable values live. Determine whether the user asked for an audit or for changes: an audit ends with proposals; a tuning request may apply numerical changes. ## 2. Establish the target Read the target from design documents or ask the user. If it remains unspecified, read [deriving-targets.md](references/deriving-targets.md) and take the strongest source it offers. Name that source in the report, and withhold the verdict rather than inventing a threshold when no source is available. Capture only the targets relevant to the request: | Target | Example | |---|---| | Session | one run lasts 3–5 minutes | | Audience | first-time player, no genre experience | | Difficulty | gentle opening, one late spike | | Failure budget | two losses before a win is expected | | Choice | each build has a situation where it is useful | | Economy | a core upgrade is affordable every two runs | ## 3. Select and scope the model Choose the model that matches the reported problem: - **Progression or difficulty** — outcomes across time, levels, waves, or encounters. - **Options or strategies** — benefit, cost, risk, and opportunity cost across representative situations. - **Economy** — resource sources, sinks, balances