The research uses four confidence labels. Confirmed means the bytes, instructions or original code were checked within the stated test conditions. Strongly inferred means several observations support the explanation. Tentative means it still needs a test, and unknown means the available evidence does not answer the question. [1]
Addresses need context
An address should name its release and processor module, for example a US V2 ARM9 virtual address. A ROM file offset, a loaded address and a copied ARM9i runtime address are different things. Function names in reconstructed code are analyst labels unless a ROM string or symbol independently establishes the name. [1]
Reproducing a finding
Start with the exact ROM hash and module, then follow the extraction steps to find the original instructions. Check the callers, memory changes and test conditions before marking an interpretation as confirmed. Decompiled pseudocode does not by itself reveal the original source structure or prove that the whole reconstructed program behaves identically. The guide also records what was searched for but not found, and what still needs checking; an absent result is not always conclusive. [1][2]
Trace a claim back to an observation
Record the ROM release, executable module, address space, input bytes and output with each finding. Loaded ARM9 addresses differ from positions in the ROM file. Addresses in a copied ARM9i module can also differ between builds. Include the address type in bug reports. [1]
Check rewritten functions against the original machine instructions. Matching results for a set of test inputs confirm those cases only. They do not prove that every possible input behaves identically, or that recovered variable names match Nintendo's names. [1][2]
Negative evidence has limits
If a particular ROM routine does not set a header, that supports a claim about that routine and path. It does not prove no other path sets it. Similarly, a named string in a binary proves the string exists; it does not prove a live server used the corresponding endpoint. The guides state these limits beside the positive findings. [1][2]
Suggested verification sequence
- Record an exact ROM hash and region.
- Find the function responsible and its callers in the correct module.
- Check the data sources and callbacks involved.
- Use a small fixture that exercises both an ordinary and an edge case.
- Compare memory writes, returned values and call order, not just a rendered screenshot.