Balance Policy
Forward-only tuning rules for stability, exploit resistance, and immutable gameplay records.
Overview
Balance Policy defines how gameplay parameters may change and what must never be rewritten. It does not contain canonical numeric tables. Exact values belong to SSOT. This page defines boundaries, versioning rules, operational constraints, and interpretation rules so tuning remains predictable, audit-friendly, and resistant to exploit-driven chaos.
In PVERSE, balance is not treated as casual designer preference. It is treated as a governed system surface. If tuning is too loose, scarcity collapses. If tuning is silent, trust collapses. If tuning rewrites history, the world loses integrity. Balance Policy exists to prevent all three by defining what may change, how those changes are published, and how old records remain valid under old parameter versions.
Scope
This page defines the forward-only tuning policy for Game Lane and the boundaries that preserve world integrity while allowing future balance changes.
- what gameplay parameters may change and what must remain historically immutable
- how SSOT, docs, and code divide responsibility for balance governance
- why tuning may occur, including exploit mitigation, economy stabilization, and technical constraints
- how versioned parameter changes are applied without retroactively rewriting world history
Core Model
The core model is simple: tuning is allowed, rewriting history is not. Balance changes are prospective, versioned, and attributable. World outcomes remain durable once validly recorded. This lets PVERSE respond to exploits, scarcity drift, or technical pressure without destroying trust in prior results.
- future gameplay outcomes may change when a new parameter version becomes active
- historical mining, refining, forging, and ownership records remain preserved
- SSOT owns numeric parameters, while docs define meaning and boundaries
- code enforces transitions and should emit version-aware records for auditability
Operational Behavior
In normal operation, Game Lane runs under an active parameter set defined by SSOT. When a change is needed, a new parameter version is created, given an effective-from boundary, and applied to future evaluations only. New mining results, refining rolls, forging outcomes, cooldown behavior, or rate limits follow the new version. Prior records remain valid under the version that produced them.
Under abnormal conditions, such as an exploit loop, tier collapse, or technical reliability issue, balance changes may be applied more urgently. Even then, the rules remain the same: contain the future, preserve the past. Mitigation can tighten future output, costs, or gating. It cannot silently erase already-recorded valid world history.
Constraints
- this page is not the numeric source of truth; exact values such as tables, caps, thresholds, and durations remain in SSOT
- Balance Policy does not define protocol guarantees, participation administration, token allocation, vesting, or market activation behavior
- UI and read-side surfaces may lag or degrade without changing authoritative balance truth
- if a rule concerns infrastructure, payments, wallet custody, or DEX launch operations, it belongs outside Game Lane balance policy
Integrity Considerations
Balance policy is part of world integrity, not just tuning convenience. Players can accept future changes more easily than they can accept rewritten past outcomes. The system therefore protects trust by preserving historical records, versioning future changes clearly, and separating parameter ownership from descriptive documentation.
- recorded outcomes remain durable and auditable once created
- parameter changes are attributable to a version and effective-from boundary
- historical interpretation remains possible because old records can still be read under old parameter versions
Core Principles
Forward-only updates
Gameplay tuning may be required to mitigate exploits, stabilize the economy, or respond to technical constraints. Updates apply prospectively: future outcomes follow the new parameters, while past outcomes remain recorded history.
Records are immutable
Mining outputs, refining results, forging outcomes, and inventory ownership are treated as durable records once produced under the system rules. If a correction is required, it is represented as a new forward-only entry that references prior records rather than silently mutating them.
SSOT separation
- Docs describe meaning, constraints, and operational boundaries.
- SSOT defines numeric parameters: tables, distributions, caps, thresholds, and durations.
- Code enforces transitions and emits auditable records with version references.
Change Boundaries
Tuning is allowed only within explicit boundaries. The goal is clarity: what can evolve, what remains fixed, and how to interpret old records under old rules.
May change (forward-only)
- drop tables and outcome distributions for future mining results only
- refining and forging success distributions and yield models for future conversions only
- conversion costs such as material requirements, time, fees, and batch constraints for future executions only
- tool efficiency curves including tier behavior, durability, and effectiveness for future outcomes only
- rate limits, cooldowns, and gating thresholds for future attempts only
- UI and UX presentation, descriptive copy, and documentation structure
- non-critical heuristics used to reduce abuse and preserve scarcity going forward
Must not be rewritten retroactively
- recorded mining outputs already produced as authoritative world records
- past refining and forging outcomes, including failures and partial yields
- inventory ownership history and world transfer history once recorded
- finalized world records and append-only game-lane economic entries
Reasons to Tune
Exploit mitigation
If an exploit path is discovered, such as frictionless compounding, unintended loops, duplication routes, or outlier abuse, tuning may be applied to close the path going forward. Exploit outcomes are not “erased” as narrative cleanup. Where policy allows a correction, it should appear as an additive forward-only record.
Economy stabilization
If a tier collapses through oversupply or becomes unreachable through undersupply, tuning may adjust future distributions, costs, or constraints to restore progression viability and scarcity gradients.
Technical constraints
Performance, indexing, storage cost, and reliability constraints may require tuning of cadence limits, batch mechanics, or non-critical friction layers to preserve system stability without weakening record integrity.
Player experience boundaries
Tuning may address dead tiers, excessive grind walls, or unintended dominance of a single strategy, as long as outcomes remain rule-defined and forward-only.
How Changes Are Applied
Versioned parameters
Balance changes are represented as versioned parameter sets. Each recorded outcome may reference the parameter version used for evaluation, so older records remain interpretable without ambiguity.
- balance_version: semantic identifier for the active gameplay parameter set
- effective_from: when the new parameters begin applying, such as a season boundary or timestamp
- readability: older versions remain readable for audit and explanation
Deterministic evaluation
Outcomes are produced by system-defined rules and constraints, not by discretionary edits. UI is informational only. The authoritative record is the recorded outcome plus its version reference.
Publication rule
When balance changes occur, the system should publish a change note and expose the current active version through status or changelog surfaces. This preserves predictability and prevents silent rule drift.
Economic Safety Mechanisms
Safety mechanisms exist to prevent runaway loops and preserve scarcity. They are structural constraints applied by SSOT-defined parameters and enforced by code.
Caps and throttles
- per-action and per-window limits such as rate limiting and cooldowns
- outlier clamps for extreme results where policy defines them
- bounded distributions to prevent uncontrolled tail outcomes
Loss model and friction
- failure and partial-yield outcomes are first-class results, not errors to be erased
- conversion costs and time gates create real opportunity cost
- no frictionless compounding: conversion remains constrained by design
Replay and duplicate resistance
Systems that record outcomes must be replay-safe. Duplicates, retries, and partial failures must not produce double outcomes. State transitions should remain atomic where authoritative records are created.
Failure Boundaries
May degrade safely
- UI delays and stale views
- search or index lag
- read-only limitations and non-critical cache issues
Must not fail
- record integrity: world history must remain preserved and explainable
- atomicity: no double-crediting and no duplicate authoritative record creation
- determinism: outcomes must follow the active rule set and remain auditable under that version
FAQ
Can you nerf my past drops?
No. Past outcomes are recorded history and are not rewritten retroactively.
Can you change drop tables?
Yes, under forward-only rules. New parameters apply to future outcomes only.
Where are the exact numbers?
Exact numeric parameters belong to SSOT. This page defines boundaries, versioning, and interpretation rules.
Future Expansion
This page may expand over time as PVERSE formalizes season-specific balance windows, parameter-publication surfaces, emergency tuning classifications, and richer versioning references for world outcomes. As the Game Lane section matures, Balance Policy should remain the canonical rulebook for how change is allowed without breaking historical integrity.
Summary
- Balance tuning is forward-only: future outcomes may change, past records do not.
- Gameplay records are durable and auditable once created under valid system rules.
- SSOT owns numbers; this page owns boundaries, versioning, and policy constraints.
- Safety mechanisms such as caps, loss, cooldowns, and replay resistance preserve scarcity and prevent runaway loops.