Before battle
The observable battle flow starts with a player-created Sound Arrangement already in place. That arrangement provides the state carried into the interaction. Another player's invitation is the visible entry point described for a sound battle. This page begins there instead of repeating the broader preparation process covered by Sound Battle Preparation. Record the arrangement and current version before accepting. These details establish context, but they do not prove that the game checks a hidden readiness value or requires an undocumented entry condition.
Battle begins
After the invitation is accepted, the prepared sound is compared with the opponent's sound. The developer describes the goal in terms of avoiding being covered up or cancelled. This confirms a high-level relationship between the arrangement and battle outcome without revealing an internal scoring formula, turn order, or component calculation. Follow the sequence the interface presents. If the current version shows stages, prompts, or feedback, record them as visible events. Do not add intermediate mechanics simply to complete a theory of how the comparison works.
What the player can observe
During the interaction, the reliable evidence is what the game visibly displays: the invitation, the arrangement state taken into battle, the feedback shown during comparison, and any stated consequence afterward. Keep each observation tied to the setup and version in which it appeared. Visible feedback can show that something happened without explaining why. A sound being covered up is an observable event; the exact weight of one arrangement choice is a separate claim. One battle also cannot establish that the same feedback will appear under every opponent or condition.
Outcome appears
The official description states that a defeated sound becomes less powerful. Record the outcome exactly as it appears and preserve any visible before-and-after state that can be compared. This gives the result a clear factual boundary. The outcome may support a later test, but it does not document the size of a power change, a reward table, ranking movement, matchmaking behavior, or a complete recovery process. Those details remain unverified unless the game or a supported source exposes them directly.
What the outcome does not prove
A win or loss is evidence for one interaction, not proof of a hidden formula. It cannot identify which component caused the result when several conditions may differ. It also does not guarantee the next outcome, demonstrate a universal winning arrangement, or confirm consequences the interface did not show. Separate three statements in your notes: what was visible, what consequence was explicitly stated, and what explanation you are considering. Keeping the explanation separate prevents an assumption from entering the battle flow as though it were an observed step.
Return to testing or refinement
After the outcome, compare it with the prepared baseline and choose the next page according to the evidence. Use Sound System Testing when the comparison needs to be repeated or narrowed. Return to Sound Arrangement when the setup needs broader refinement, and use Arrangement Troubleshooting when a specific weakness repeats. Change one relevant element when practical, preserve both versions, and observe whether the result repeats. A consistent result can strengthen a limited conclusion. A conflicting result should remain inconclusive until the conditions are understood. The flow ends with a focused next question, not an assumed explanation.