How We Verify Answers

1. Data Sourcing

Every answer in this archive originates from an automated scraper, not from human data entry. The scraper accesses game data directly from the mobile app or from a structured API feed that the game exposes. It does not read screenshots, forum posts, or third-party databases.

For most of the 45 games in this archive, the scraper produces a JSON file keyed by level identifier. For games with pack-and-level structures (such as Word Cookies or Word Crush), it produces a PHP array file with nested pack and level identifiers. For games with date-keyed daily puzzles (such as Jumble or Word Salad), it produces a PHP or JSON file keyed by calendar date in YYYY-MM-DD format.

The scraper is maintained by the editorial team. When a game adds new levels or packs, the scraper is updated to cover the new structure. When a scrape path is blocked, the team evaluates whether the cost of a bypass justifies the attempt. Games where the path is blocked and bypass is not justified are marked as having a coverage gap, not silently listed as complete.

2. Structured Data Files

Each game's answers are stored in a structured data file in the satellite site docroot. JSON files are flat or nested objects where each key is a level identifier and each value contains the answer string and optional metadata such as pack name, category, and letter count. PHP array files return a multi-dimensional array keyed by pack name or number, with inner arrays mapping level numbers to answer strings.

A third format, the date-keyed archive, is used for daily games. The file is a PHP array keyed by YYYY-MM-DD date string, where each value is the answer or answer set for that date's puzzle. Multilingual games use locale directories: the top-level data directory contains subdirectories named by two-letter locale code. Words of Wonders has 28 locale directories, one per supported language.

3. What Populated and Total Mean

Total item count is the number of levels, clues, or puzzles that the data file structure defines as existing. For a game with packs 1 through 100 and 20 levels per pack, the total is 2,000 even if not all 2,000 have been scraped yet.

Populated count is the number of those items where the answer field is a non-empty, non-null string in the data file. A populated count of 1,800 on a total of 2,000 means 1,800 levels have verified answers and 200 do not. This archive always displays the populated count on game tiles, not the total. Displaying the total would suggest the archive contains answers it does not actually have. A game showing 1,800 verified answers is more useful than one claiming 2,000 answers where 200 are blank. The coverage percentage is computed as populated divided by total multiplied by 100, rounded to the nearest integer.

4. The Nightly Rebuild at 05:10 UTC

The registry rebuild is a Python script called build_registry_v2.py that runs on the VPS via cron at 05:10 UTC every day. The rebuild walks each satellite docroot, opens the primary data file, and counts the populated answers using the format-appropriate parser. It then compares the new count to the previous count, logs any delta with a timestamp, and rewrites games.php with updated item_count, populated_count, coverage_pct, and last_data_mtime fields for every game. It also rewrites site_counts.php with the aggregate totals.

After the rebuild, every statistic on puzzlesolved.info reflects the live state of the data files. The rebuild date shown on the homepage is the date of the most recent successful run. The current registry was last rebuilt on 2026-08-01, covering 1,026,796 total items and 932,305 populated answers across 45 games.

5. Validation and Gap Marking

The rebuild script validates each data file before counting. Validation checks: the file parses without error (no JSON decode failure, no PHP fatal); the answer field for each populated entry is a non-empty string with at least one alphabetic character; for daily-keyed files, dates are well-formed YYYY-MM-DD strings with no duplicate keys; for locale-dir games, each locale directory contains the expected file and it parses cleanly.

When validation fails for a specific entry, that entry is excluded from the populated count without adjusting the total. When an entire file fails validation, the game's counts are set to zero populated and a build error is logged. The satellite site is not taken offline - it continues serving whatever answers it has - but the hub count for that game shows zero populated until the file is fixed and the next rebuild runs. A coverage gap is always visible in the percentage without requiring a manual flag.

6. The Satellite Network and Hub Relationship

Puzzle Solved and the linked game-specific answer sites (such as wordscapesanswers.info, codycross-answers.net, and the others listed in the game directory) are operated by the same team. The satellite sites each host the full answer archive for a single game. The hub reads their populated counts and presents a cross-game index.

For most games, the satellite is the canonical location for individual level answers. The hub provides the index, the statistics, and the category browsing layer. An answer correction on a satellite propagates to the hub count on the next rebuild. The hub does not store a separate copy of the answer data - it only stores the counts and registry metadata.

7. How to Report an Error

If you find an answer on this archive or on one of the satellite sites that is incorrect, incomplete, or missing, report it through the contact form. Include the game name, the level number or pack name or date, the answer shown in the archive, and the answer you believe is correct. A screenshot of the game showing the correct answer is helpful but not required.

The editorial team reviews every report. Corrections that are confirmed go into the data file. The satellite site picks up the correction on next deploy. The hub reflects the corrected populated count on the next nightly rebuild at 05:10 UTC.

Frequently Asked Questions