v0.1.0 to v0.1.0

---

name: balance-data-change-review

description: Use when numeric game tuning data such as damage, price, cooldown, drop rate, or progression has a before/after diff that must stay within approved min/max bounds.

version: 0.1.0

author: GameStudio-CodexKIT

license: MIT

compatibility:

engines: [engine-agnostic]

versions: [any]

platforms: [any]

metadata:

studio:

type: workflow

lifecycle_stage: review

risk_level: read-only

packs: [production-design-liveops]

side_effects: none

artifact: balance-change-review.json

required_evidence: [baseline-data, proposed-data, declared-bounds, design-intent]

owner: HoaTV Studio

reviewer: null

last_reviewed: 2026-08-08

provenance:

derived_from: none

patterns_from: [registry/capabilities.yaml production catalog, review-swarm]

copied_text: none

---

# Balance Data Change Review

## Overview

Review balance changes as data contracts with intent, bounds, dependencies, and rollback conditions rather than approving isolated numbers by feel.

## When to use

Use for stat tables, abilities, cooldowns, drop rates, XP curves, encounter tuning, rewards, crafting values, and configuration-driven balance patches.

## When NOT to use

Do not use to write generated tables directly, deploy live configuration, or replace playtest and telemetry evidence.

## Required inputs and context discovery

Collect source-of-truth path, generated outputs, baseline and proposed rows, design intent, allowed bounds, formulas, dependent systems, segment impact, test evidence, rollout scope, and rollback owner.

## Safety and risk level

Read-only review. Source data may be changed only by its named owner through the project generation pipeline; generated outputs are never hand-edited.

## Workflow

1. Verify source ownership, generation path, schema, and baseline snapshot.

Completion criterion: the canonical editable source and generated consumers are identified.

2. Compute field-level deltas and compare them with declared bounds.

Completion criterion: every changed value has old, new, absolute, relative, and bound status.

3. Trace formulas, dependencies, breakpoints, and player-segment effects.

Completion criterion: hidden multipliers and downstream consumers are documented or `BLOCKED`.

4. Review design evidence, exploit risk, and rollback conditions.

Completion criterion: intent is testable and rollback restores the exact baseline.

5. Issue a review verdict and required validation plan.

Completion criterion: approval is withheld for unexplained, out-of-bound, or untestable changes.

## Evidence and output contract

Produce `balance-change-review.json` with source identity, deltas, bound violations, dependency impacts, evidence, risks, rollback data, verdict, and required tests.

## Handoff contract

Record canonical source, generation command, affected systems, unresolved dependencies, review owner, validation build, rollout scope, and rollback snapshot.

## Pitfalls and anti-rationalization

- A small scalar change can cross a systemic breakpoint.

- Percentage deltas need context for zero or tiny baselines.

- Generated data is not the source of truth.

- Design intent without a measurable criterion is not sufficient evidence.

## Verification checklist

- [ ] Canonical source and baseline are exact.

- [ ] Every delta is normalized and bounded.

- [ ] Dependencies and formulas are traced.

- [ ] Validation and rollback are concrete.

- [ ] No generated or live data was modified during review.

## References and scripts

Use the bundled [scripts/balance_review.py](scripts/balance_review.py) for normalized data-delta and bound checks. Use project-specific generators only after owner approval.