Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The lesson of hidetzu’s verigen project is not that smarter generators are useless. It is that, when a requirement is mechanically decidable and checking it is affordable, a simple generator paired with a strict verifier can be more reliable than an increasingly elaborate generator. In one reported seed-7 run, verigen kept only five puzzles from 1,947 attempts in 84 ms—an acceptance rate of 0.2568%, or roughly 99.7% rejected—because the verifier, not the generator, carried the correctness guarantees.
What the 99.7% rejection figure actually means
The number comes from a specific run reported by hidetzu, the author of verigen, and in the project’s README. It is not a benchmark across computers, puzzle families or operating systems. The program used random generation, then asked a verifier whether each candidate met the project’s explicit requirements.
| Outcome in the seed-7 run | Count | Share of 1,947 attempts | What it means |
|---|---|---|---|
| Accepted puzzles | 5 | 0.2568% | The verifier found exactly one valid solution and the candidate passed the configured checks. |
| Non-unique | 770 | 39.55% | More than one solution existed, so the candidate failed the uniqueness requirement. |
| No solution | 695 | 35.70% | The puzzle had no assignment satisfying its constraints. |
| More than ten distinct letters | 477 | 24.50% | At least eleven symbols required distinct decimal digits, which is impossible. |
The categories account for the reported attempts. The headline rounds the complement of the 0.2568% acceptance rate; it should not be read as a universal rejection rate for every configuration.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhen the author added an “easy” difficulty filter, the reported acceptance rate fell to 0.03%, or about 3,200 generations for each accepted puzzle. That is another result from the project’s run, not a promise about throughput on a different machine or with a different generator.
#1 Best Overall
Why separate generation from guarantees?
A generator is good at producing possibilities. A verifier is good at deciding whether a possibility satisfies rules. Combining both jobs in the generator encourages increasingly complicated heuristics: avoid repeated letters, estimate whether a puzzle looks unique, or predict whether a human will find it easy. Those heuristics can improve the odds, but they do not prove the result.
Hidetzu summarizes the architecture this way: “The generator guarantees nothing. Every guarantee lives in the verifier.” In this design, a candidate may be implausible, redundant or mathematically impossible. It is simply discarded. The generator can therefore remain small while the verifier becomes the carefully tested component.
This strategy is appropriate only when the desired properties can be tested mechanically. “Has exactly one solution” is decidable for a finite alphametic. “Is enjoyable for a human” is not established by the same computation. The distinction prevents a verifier from being credited with guarantees it never checks.
How the alphametic verifier works
1. Reject impossible symbol counts early
Decimal alphametics assign a different digit from 0 through 9 to each distinct letter. A candidate containing eleven different letters cannot work, regardless of the words or arithmetic. The verifier can reject it before starting an exhaustive search. In the cited run, this inexpensive prefilter handled 477 attempts.
2. Enforce the leading-zero rule
A letter at the beginning of a multi-character word cannot represent zero. This is an explicit constraint, not a visual judgment about whether a result “looks right.” Enforcing it during search removes assignments that would otherwise appear arithmetically valid but would not represent legal numbers.
3. Search column by column with carries
The solver works from the least significant column toward the most significant one, assigning digits and tracking the carry into the next column. A partial assignment is abandoned as soon as a column cannot balance. This pruning is more efficient than evaluating every possible digit permutation blindly, while still remaining exhaustive over the assignments that survive the constraints.
4. Continue after the first solution
Finding one solution is insufficient because the project treats uniqueness as part of a valid puzzle. The verifier keeps searching after the first solution. A second solution changes the result from accepted to non-unique. This is the critical difference between checking “solvable” and checking “has exactly one solution.”
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
5. Test the verifier against known edge cases
The author reports testing the implementation with known puzzles such as SEND + MORE = MONEY and CROSS + ROADS = DANGER, along with explicit no-solution, non-unique and eleven-letter cases. These tests exercise both positive and negative paths. They are reported test design, not an independent audit of the code.
Rank #3
What passing the verifier proves—and what it does not
A passing candidate has the properties encoded in the verifier: a legal digit assignment exists, the arithmetic works, leading-zero rules are respected, and no second assignment was found by the search. Those are meaningful guarantees because each can be stated as a precise predicate.
Passing does not prove that the puzzle is entertaining, elegant, educational or appropriately difficult. The project can reject a malformed or ambiguous puzzle, but it cannot reject a solvable puzzle merely because it is boring. Quality remains a separate measurement problem. If your application needs a subjective standard, you need an additional human evaluation process or a separately validated proxy.
The same scope rule applies to any generated artifact. A schema validator can establish that fields exist and have the right types; it does not establish that the prose is true. A compiler can establish that code parses and type-checks; it does not establish that the business logic is correct. A theorem checker can establish that a formal proof follows its rules; it does not decide whether the theorem was the one a researcher intended.
Why “easy” is only a proxy in this project
verigen labels difficulty using search branch points. Fewer branches generally mean less work for the solver, while more branches indicate a larger search space. That is useful for controlling generation and comparing candidates under the same algorithm.
It is not a validated measure of human difficulty. People use pattern recognition, arithmetic fluency and strategic insight that do not match the verifier’s branching behavior. The author explicitly says the label has not been measured against human solvers. Treat it as an engineering proxy, not a claim about how long a person will take.
How to decide whether a generator–verifier loop fits your project
- Write the acceptance contract. List properties as executable predicates: syntax, bounds, uniqueness, conservation laws, security rules or semantic equivalence where a dependable checker exists.
- Estimate verification cost. Measure the checker on representative candidates, including worst cases. Rejection is useful only when checking and retrying cost less than making the generator perfect.
- Separate hard constraints from quality goals. Put objective requirements in the verifier. Track subjective goals—readability, novelty, usefulness or fun—as scores or review criteria instead of pretending they are proven.
- Instrument rejection reasons. Count failures by category. The 477-letter prefilter and the non-unique/no-solution split show why this matters: rejection data tells you which generator changes could reduce wasted work.
- Test the checker independently. Include known-valid examples, known-invalid examples, boundary conditions and cases that should have multiple solutions. A bug in the verifier can turn every later guarantee into a false one.
- Stop at the required guarantee. If the contract is uniqueness, stop after proving that a second solution does or does not exist. Do not add speculative heuristics to the generator unless they improve cost or a measured quality target.
When rejection is economically sensible
The loop works best when candidate generation is cheap and verification is cheaper than generating a fully optimized candidate. In the reported verigen run, five accepted puzzles emerged from 1,947 attempts in 84 ms, demonstrating that a high rejection rate can still produce useful throughput in a small computational domain.
The economics change when generation itself is expensive. Hidetzu notes that a language-model call can take hundreds of milliseconds to seconds. If every candidate requires a slower verifier—or an external service, simulation or human review—the retry loop may cost more than a smarter generator. The right comparison is total cost per accepted artifact, not rejection percentage by itself.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Condition | Likely design choice |
|---|---|
| Requirements are precise and mechanically decidable | Keep generation simple and put guarantees in a verifier. |
| Checking is cheap relative to another generation attempt | Accept a high rejection rate if throughput and cost remain acceptable. |
| Quality is mostly subjective | Use verification for hard constraints, then add scoring or human review. |
| Verification is slower than generation | Optimize or narrow the verifier, improve candidate generation, or reconsider the retry architecture. |
| No reliable referee or reference answer exists | State the limits clearly; a verifier cannot prove what it cannot observe. |
Where the pattern appears beyond alphametics
The article connects the same separation to generated code, text-to-SQL, constrained structured output and theorem proving. The transferable idea is to make the generator propose and let an independent mechanism decide whether the proposal is admissible. For code, that might include parsing, type checks and tests. For structured data, it might include schema and range validation. For a theorem, it can include a proof checker.
Best Value
These examples require careful qualification. A parser or schema check proves structural validity, not factual or semantic correctness. A test suite covers only the cases it exercises. A theorem prover can verify a formal statement while the formalization itself may omit an intended assumption. The verifier’s specification is therefore part of the product, not an implementation detail.
What the IMO results do—and do not—show
Google DeepMind’s official account of the 2024 International Mathematical Olympiad says AlphaProof and AlphaGeometry 2 solved four of six problems and scored 28 out of 42 points, with formalization into systems such as Lean and up to two to three days of computation. See Google DeepMind’s 2024 report.
Its 2025 report says Gemini Deep Think scored 35 out of 42, solved five of six problems and reached a gold-medal score under the competition setting, with solutions graded by IMO coordinators. See Google DeepMind’s 2025 report.
Those results use different systems and conditions: one emphasizes formalization and extended computation, while the other worked in natural language within the 4.5-hour contest limit. They do not demonstrate that mechanical verification is obsolete. Contest problems have answer keys and human graders; open-ended research often lacks either. Verification remains valuable wherever a precise, checkable contract can be defined.
Practical failure modes to watch for
- Checking only solvability: accepting the first solution allows ambiguous puzzles. Continue until a second solution is ruled out.
- Forgetting domain rules: arithmetic may pass while a leading word begins with zero. Encode every stated rule explicitly.
- Confusing a proxy with the goal: search branches are not the same as human difficulty; syntax validity is not truth.
- Ignoring rejection economics: a retry loop can become wasteful when generation or verification uses expensive model calls or external services.
- Trusting an untested verifier: test known positives, negatives and boundary cases before interpreting acceptance statistics.
- Overgeneralizing one run: the 84 ms result and rejection percentages describe the reported seed-7 configuration, not every workload.
The central engineering lesson
Stopping the generator from becoming smarter was a deliberate boundary decision. In a finite puzzle domain, the generator only needs to produce candidates; the verifier can enforce solvability, uniqueness and formal rules with far greater confidence. The approach is strongest when requirements are decidable, checking is affordable and the limits of the contract are stated plainly. It is not a universal replacement for better generation, especially when success includes qualities no program currently measures.
For the project details, domain list and current usage information, see the author’s explanation and the verigen repository. The repository describes alphametics, polyomino tilings, Apollonian circle configurations and Slitherlink, using exhaustive or algebraic checks depending on the domain; because the repository changes, confirm its present feature list before relying on it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
