diff --git a/wiki/faq.md b/wiki/faq.md
index bf99d1b2..4b49fc77 100644
--- a/wiki/faq.md
+++ b/wiki/faq.md
@@ -93,9 +93,11 @@ Different platforms use different hash types for verification. Batocera uses MD5
 
 ## Why does my verification report say UNTESTED?
 
-UNTESTED means the file exists on disk but its hash was not confirmed against a known value. This happens on existence-mode platforms (RetroArch, Lakka, RetroPie) where the platform only checks that the file is present, without verifying its contents.
+UNTESTED means the file exists on disk but its hash does not match the expected value. This happens on MD5/SHA1-mode platforms (Batocera, Recalbox, BizHawk, etc.) when the file is present but contains different data than what the platform declares.
 
-The file may still be correct. Running `verify.py --emulator <core> --verbose` shows the emulator-level ground truth, which can confirm whether the file's hash matches what the source code expects.
+On existence-mode platforms (RetroArch, Lakka, RetroPie), files are never UNTESTED because the platform only checks presence, not content. Those files show as OK if present.
+
+Running `verify.py --emulator <core> --verbose` shows the emulator-level ground truth, which can confirm whether the file's hash matches what the source code expects.
 
 ## Can I use BIOS from one platform on another?
 
diff --git a/wiki/index.md b/wiki/index.md
index 5761e29a..fcab95c0 100644
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -33,7 +33,7 @@ See [contributing](../CONTRIBUTING.md) for submission guidelines.
 - **BIOS** - firmware burned into console hardware, needed by emulators that rely on original boot code
 - **firmware** - system software loaded by a console at boot; used interchangeably with BIOS in this project
 - **HLE** - High-Level Emulation; software reimplementation of BIOS functions, avoids needing the original file
-- **hash** - fixed-length fingerprint of a file's contents; this project uses MD5, SHA1, SHA256, and CRC32
+- **hash** - fixed-length fingerprint of a file's contents; this project uses MD5, SHA1, SHA256, CRC32, and Adler-32
 - **platform** - a distribution that packages emulators (RetroArch, Batocera, Recalbox, EmuDeck, etc.)
 - **core** - an emulator packaged as a libretro plugin, loaded by RetroArch or compatible frontends
 - **profile** - a YAML file in `emulators/` documenting one core's BIOS requirements, verified against source code
diff --git a/wiki/profiling.md b/wiki/profiling.md
index 9543248c..825da7f8 100644
--- a/wiki/profiling.md
+++ b/wiki/profiling.md
@@ -275,7 +275,8 @@ even if documentation mentions it.
 | `system` | system ID this file belongs to (for multi-system profiles) |
 | `size` | expected size in bytes |
 | `min_size`, `max_size` | size range when the code accepts a range |
-| `md5`, `sha1`, `crc32`, `sha256`, `adler32` | expected hashes from source code |
+| `md5`, `sha1`, `crc32`, `sha256` | expected hashes from source code |
+| `known_hash_adler32` | expected Adler-32 hash (used by Dolphin IPL files) |
 | `validation` | checks the code performs: `size`, `crc32`, `md5`, `sha1`, `adler32`, `signature`, `crypto`. Can be a list or dict `{core: [...], upstream: [...]}` for divergent checks |
 | `aliases` | alternate filenames for the same file |
 | `mode` | `libretro`, `standalone`, or `both` |
@@ -288,4 +289,7 @@ even if documentation mentions it.
 | `note` | additional context |
 | `contents` | structure of files inside a BIOS ZIP (`name`, `description`, `size`, `crc32`) |
 | `storage` | `large_file` for files > 50 MB stored as release assets |
+| `agnostic` | true if any file under the system path within size constraints satisfies the requirement |
+| `unsourceable` | reason why the file cannot be sourced (acknowledged gap) |
+| `destination` | target path within the BIOS directory |
 
diff --git a/wiki/troubleshooting.md b/wiki/troubleshooting.md
index aa2ca5ab..2c895fe6 100644
--- a/wiki/troubleshooting.md
+++ b/wiki/troubleshooting.md
@@ -18,8 +18,8 @@ cannot start games for that system at all.
 
 **Check if the hash matches:**
 
-Look for `HASH_MISMATCH` in the verify output. This means the file exists but
-contains different data than expected. Common causes:
+Look for `untested` entries in the verify output. This means the file exists but
+its hash does not match the expected value. Common causes:
 
 - Wrong region (a PAL BIOS instead of NTSC, or vice versa)
 - Wrong hardware revision (e.g. SCPH-5501 vs SCPH-1001 for PlayStation)