Refining

Overview

Refining is the first formal conversion gate in the PVERSE gameplay loop. It transforms raw ore into its canonical refined output under explicit execution rules, bounded processing behavior, and forward-only record integrity.

This page defines the meaning and structure of refining rather than final live balance values. Exact batch sizes, rates, loss amounts, fees, and success parameters remain SSOT-owned and enforced by code.

Scope

Refining defines the ore-to-refined conversion layer inside the Game Systems section.

• canonical two-stage resource transformation from ore into refined form
• accepted input identity, ownership checks, and bounded execution rules
• explicit rejection behavior when a refining attempt is invalid
• forward-only records for successful or terminal refining outcomes

Core Model

The core model is that refining converts a valid ore input into its single canonical refined counterpart. This page no longer treats refining as an intermediate step in a three-stage chain. Instead, refining is the definitive conversion from ore into the final refined identity used by the current resource naming system.

• refining is a two-stage conversion: ore in, refined output out
• each ore type has one canonical refined output name
• execution remains bounded and must resolve under valid runtime rules
• future changes apply forward-only and do not silently rewrite historical records

Canonical Resource Mapping

The table below defines the currently locked ore-to-refined naming standard for the refining layer.

Operational Behavior

A refining attempt is accepted only when all current runtime rules are satisfied. The system validates the submitted ore, checks ownership and execution eligibility, reserves the input, resolves the refining result, and then commits the outcome as durable forward-only history.

Refining does not imply partial execution by default. If the attempt is invalid under current rules, it is rejected as a whole rather than partially processed. Where randomness, yield shaping, or loss handling exists, those values are controlled by SSOT and enforced through code rather than defined in this page.

Constraints

• this page does not hard-code final batch sizes, rates, fees, or loss tables
• refining is limited to the canonical ore-to-refined mapping defined here
• invalid refining attempts are rejected explicitly rather than silently reinterpreted
• future refining policy changes apply forward-only and do not rewrite prior refining history

Integrity Considerations

Refining integrity depends on clear separation between system meaning, configurable values, and execution truth. Documentation defines the canonical conversion model, SSOT owns mutable numeric parameters, and code enforces validation, reservation, resolution, and record creation.

• the committed server record is authoritative, not the client display
• refining records should remain append-only after successful commit
• historical refining outcomes remain auditable even if future balance rules evolve

Future Expansion

As PVERSE expands, refining may connect to richer visibility rules, stronger material-family identity, and separate balance-oriented references. The conceptual model should remain stable: refining is the canonical ore-to-refined conversion layer, and its naming plus historical records remain forward-only.

Summary

• Refining now follows a canonical two-stage model: Ore → Refined Output.
• Each ore type maps to one locked refined identity under the current naming standard.
• Execution remains bounded, validated, and explicitly recorded.
• All refining updates follow forward-only interpretation and preserve auditable history.