Build a Sudoku Solver That Checks Uniqueness, Not Just Finds an Answer

A Sudoku solver uniqueness check asks a stronger question than “Can I fill the board?” A valid completion proves that at least one answer exists. To establish uniqueness, your program must also rule out every different valid completion under its stated rules.

We built an original local Python exercise with eight fixtures and nine runs. The selected runs cover unique, multiple, unsatisfiable, inconsistent, malformed and unresolved outcomes. All nine matched their independently stated expectations, and all six returned solution boards passed separate rule-and-clue checks. This is a teaching fixture, not an accuracy estimate or a fastest-solver benchmark.

What the new Sudoku preprint contributes

Aled Williams’s preprint submitted on 27 October 2026 compares completion and uniqueness certification across formulations and solvers. It uses 32,000 uniquely solvable puzzles, with 500 at each clue count from 17 through 80, plus 64 harder instances. The paper treats fresh certification separately from finding the reference completion.

The versioned methods section explains that construction differs between groups up to 23 clues and those from 24 onwards. Neither procedure uniformly samples all uniquely solvable puzzles. A clue-count curve can therefore reflect construction as well as the number of givens. This newly posted preprint is not verified peer-reviewed consensus.

Our much smaller exercise does not reproduce that research. We use our own constructed puzzles and a simple Python backtracking implementation. We ran no integer-programming or CP-SAT solver. The connection is the learning question: what evidence supports the result label your program returns?

Give the Sudoku solver uniqueness check a result contract

First, separate input problems from search outcomes. A string with the wrong length is malformed. Duplicate fixed digits in a unit produce inconsistent clues. By contrast, a well-formed board can have no immediate duplicate and still admit no completion. Treating all three as the same error discards useful diagnostic evidence.

For valid search inputs, keep four states available. An exhausted search with no completion supports “no solution.” Two distinct valid boards support “multiple solutions.” One board followed by a fully exhausted search that excludes it supports “unique under the completed check.” A stopped follow-up search leaves uniqueness unresolved.

These labels remain conditional on correct implementation. A bug that skips a branch can create a false uniqueness claim. Therefore, validate the completed board independently of the search routine and document the termination conditions. A green test badge cannot replace a clear account of what your tests cover.

Build fixtures with known expected outcomes

We constructed a completed standard 9-by-9 board from a deterministic row pattern. The three unique fixtures remove one cell, one diagonal or the first row. Their expected uniqueness has a simple independent basis: the missing value is forced by each affected row or column. We did not assume arbitrary clue deletion preserves uniqueness.

For ambiguous fixture A1, we removed every 1 and 2 from that board. The original completion and a global swap of 1 and 2 provide two distinct valid witnesses. Both preserve every remaining clue. This establishes multiplicity independently of which alternative our search happens to return.

Our negative cases include a duplicate-clue board, a board with consistent initial units but an impossible required cell, an 80-character input and a nondigit input. Finally, we rerun one unique fixture with a zero-node certification budget. That deliberate interruption tests the unresolved state; it is not an observed natural timeout.

Run completion and fresh certification separately

Our search chooses an empty cell with the fewest allowed digits, breaking ties by cell order. It tries candidate digits in ascending order. The first task stops at one completion. We check that board against the original clues and every row, column and block before using it as the reference.

The second task starts afresh from the original clues. At a completed board, it rejects exact equality with the reference. It then looks for another completion. A second valid board establishes multiplicity. If the entire permitted search ends without another board, the result supports uniqueness under this implementation.

The three completed unique cases used 2, 10 and 10 recursive calls for completion and the same counts for fresh certification. Ambiguous A1 used 19 calls to find its first board and 37 in the fresh search for an alternative. These are implementation-specific counters, not general complexity estimates or comparisons with the preprint’s solver counters.

Run R9 found a completion in 10 calls, then allowed zero certification calls. Its zero counter means the follow-up search was deliberately prevented from starting. It does not mean uniqueness was proved with no work. The final status correctly remains unresolved despite the fixture’s independently known uniqueness.

Inspect the actual alternative boards

Figure 5 shows the two boards returned for A1. Gray digits are original clues. The colored digits fill its original blanks. Our separate validator checks that each completed unit contains digits 1 through 9 exactly once and that every clue remains unchanged. It also confirms the two boards differ.

The witness file retains all six returned boards across the selected runs. All six passed these checks. That result describes this fixture suite only. It does not certify the implementation for every possible puzzle, establish a representative success rate or show that a different algorithm is slower.

Download and reproduce the local experiment

Download the eight original fixtures and expected classifications (CSV), nine local run results (CSV), validated solution witnesses (CSV) and blank experiment ledger (CSV). The complete reproducible Python script (TXT) contains the fixture construction, solver and separate validation checks.

Read the script, save it as experiment.py in an empty working folder and run it with Python 3. It uses the standard library, makes no network requests and creates local data and output folders. Our run used Python 3.9.6 on arm64. The implementation is versioned LCA-MRV-1.0 and uses a 100,000-call budget, except for R9’s explicit zero-call certification budget.

The results file includes separate elapsed times and node counts for the two tasks. Timings come from one local run per selected configuration and will vary across machines. Rejected inputs have blank search fields, not zero-duration solver measurements. We use node counts in the comparison figure to expose the search boundaries without presenting a timing race.

When importing a CSV into a spreadsheet, set each grid column to text. Its 81-character string is an encoded board, not a large number. Automatic numeric conversion can remove leading zeros or change digits through rounding. Use the retained text values when feeding fixtures back into a solver.

Limits and extension exercises

This small constructed suite serves algorithm learners, including US coding students. It is not a sample of human puzzle difficulty or interview outcomes. Future work could add independently certified puzzles, predeclare a selection rule and repeat timed comparisons. Preserve interrupted runs visibly rather than dropping them or relabelling them unique.

For testing structure, see our unit-testing introduction. For another measurement pitfall, read the Web Vitals population audit. First published and experiment executed on 1 November 2026. Suggested citation: Learn Coding USA, “Build a Sudoku Solver That Checks Uniqueness,” 1 November 2026. The paper summary cites Williams’s version 1 under CC BY 4.0; our fixtures and implementation are original.