Confirmed mechanics
The experience contains a Sound System, lets players make their own sound arrangement, supports sound battles with other players and describes a defeated sound as becoming less powerful. These are the confirmed relationships that explain the current guide structure: system, arrangement, battle and outcome.
Not currently documented by the developer
A public battle formula, exact scoring weights, full component-stat tables, drop rates and economy formulas are not disclosed in the official description. The absence of a published value is not evidence that a value does not exist in-game; it means this wiki should not present one as confirmed.
Why this matters
This distinction prevents strategy pages and future tools from turning speculation into fake game data. It also keeps advice useful: players can test visible behavior and record observations without mistaking a temporary result for a permanent rule.
Evidence levels
Confirmed means the developer or a stable public listing states it. Observed means a current in-game behavior has been recorded but may change. Unverified means a community claim lacks reproducible support. Awaiting verification means the question is worth tracking but should not be filled with an invented answer.
How the relationships connect
The Sound System provides the named workspace, the arrangement is the player-created object inside that workspace, and the battle is the interaction in which the object is tested. Data Testing changes the confidence and freshness of every observation. This relationship is confirmed at a high level even though its internal calculations are not public.
What a mechanic claim needs
A strong mechanic claim needs a clear source or a repeatable current observation with version context. A single result can show that something happened, but not necessarily why it happened. Exact formulas, hidden weights, economy rules, and component tables should remain unverified until the evidence supports them.
Why the distinction matters
Separating confirmed, observed, unverified, and awaiting-verification information prevents the wiki from turning a plausible explanation into a fake rule. It also gives players a practical next step: reproduce visible behavior, record the conditions, and update the conclusion only when the evidence survives comparison.
Mechanic relationship map
The named Sound System is the context in which a player creates a Sound Arrangement. The arrangement is refined through observation and then carried into Sound Battle, where the public description says a sound can be covered up and become less powerful after defeat. Data Testing affects the reliability and lifetime of all of these observations.
What the relationship does not prove
Knowing that two systems are related does not reveal their internal implementation. The relationship does not prove a component table, a damage model, a rarity system, a numeric clarity threshold, or a battle formula. Those details need their own evidence and should not be smuggled into the mechanics explanation.
How to reason about a new observation
When a new behavior appears, ask which layer owns it. If a control changes an arrangement, it is an arrangement observation. If an arrangement is challenged, it is a battle observation. If the same action changes after an update, it is a data-testing or update observation. This classification makes later verification more precise.
Mechanics questions still open
The open questions include exact scoring, hidden weights, reward behavior, ranking, matchmaking, and detailed recovery after defeat. Listing them does not imply that every answer is discoverable from public play. It records the boundary between a useful confirmed model and claims that remain awaiting verification.
How this Wiki defines mechanics
Mechanics are the documented relationships between player actions, named systems, and observable outcomes. In this Wiki, a mechanics explanation connects those elements without pretending to expose the game’s internal implementation. The useful confirmed model is a chain: the Sound System provides the context, the player creates a Sound Arrangement, testing helps evaluate it, and Sound Battle produces an outcome that may lead back to refinement. This definition keeps the page focused on how the parts relate. Detailed setup steps belong in guides, while claims about hidden calculations require evidence that is not currently available.
Arrangement, testing, and battle
A Sound Arrangement turns the broader Sound System into a player-controlled configuration. Testing then connects that configuration with observable behavior by preserving a baseline, introducing a controlled change, and comparing the result. The relationship is methodological: testing helps players understand what they changed even when the internal values remain unknown. Sound Battle extends the loop into an interaction with another player’s sound. A prepared arrangement enters battle, the player observes the outcome, and that feedback can define the next refinement question. Battle therefore does not sit apart from testing; it returns evidence to the arrangement process without revealing a full scoring formula.
A connected loop, not isolated features
Viewing each feature alone makes observations easier to misread. An arrangement result has meaning only in the context of the Sound System, test conditions, and current version. A battle result is easier to evaluate when the incoming arrangement is known. A later refinement is easier to judge when the prior outcome and baseline were preserved. The loop supports useful decisions without claiming certainty that the evidence cannot provide. Players can move from system understanding to arrangement, from arrangement to testing, from testing to battle, and from battle back to refinement. Data Testing affects the confidence and freshness of every connection.