Using a source map to verify Verity Mod Java, Bedrock, and modpack routes

Players searching for Verity Mod are often looking for very different things with the same two words. One person wants a Java JAR. Another wants a Bedrock MCADDON. Someone else found a modpack, a copied filename, or an old video link. Treating all of those results as the same file is how users end up with wrong installs, stale beta links, or support questions that have nothing to do with the file they actually downloaded.

I maintain an independent route checker for this problem. The useful part is not that it says "download here". It does not mirror files. The useful part is a small source map that keeps the public project records separate and machine-readable:

https://veritymodchecker.online/source-map/

The JSON version is here:

https://veritymodchecker.online/data/verity-source-map.json

The structure is intentionally boring. Each row keeps the route name, edition, host, owner, project ID, project URL, package type, filename, file record, Minecraft version, loader, publication date, displayed size, point-in-time project downloads, point-in-time file downloads, status, and the local checker page that explains the route. For a trend-driven search term, that beats a single copied file name.

At the July 30 check, for example, these were separate records:

• Modrinth Verity JE project on1Y0osD, current version CXsEzVwJ, file verity-6.jar, Forge 1.20.1.
• CurseForge Verity JE Project ID 1591438, visible stable file record 8461257, file verity-5.7.3.jar.
• CurseForge Verity BE Project ID 1574632, Bedrock file record 8506198, file Verity (Stable) (1.1.0)-(26.3).mcaddon.
• PnTMC's Verity - Bedrock Edition Project ID 1575941, current V26.30 file record 8517480.
• VERITY.exe Project ID 1585389, which is a separate modpack route, not the same artifact as a standalone Java JAR.

The practical rule is simple: match the platform before the filename. A Java route should resolve to a JAR and a Java loader such as Forge. A Bedrock route should resolve to MCADDON or MCPACK context. A modpack should be treated as a profile route, not as proof that a standalone Verity file is present. If the page does not expose a project ID, file record, owner, version, or checksum context, the title alone is weak evidence.

For exact Java checks, the current Modrinth route is tracked here:

https://veritymodchecker.online/verity-6-jar/

For Bedrock/PnTMC confusion, the route notes are here:

https://veritymodchecker.online/bedrock/

This is also why I keep download counters separated. A platform counter is not a unique player count, a malware verdict, or an install guarantee. It is still useful as a freshness and popularity signal when it is tied to the exact project page. Combining counters without labels creates more confusion than it solves.

If you are building a small verifier for a fast-moving game keyword, the pattern is reusable:

1. Store source routes as data, not just prose.
2. Keep project-level and file-level counters separate.
3. Preserve source host, owner, project ID, file record, and package type.
4. Link users back to the maintainer/project page instead of mirroring binaries.
5. Publish a CSV or JSON asset so other writers, support replies, or LLMs can cite the same facts.

That is the goal of the Verity Mod source map: less guessing, fewer stale links, and a clearer path from a search query to the correct official project route.