The problem we are solving
We search the official version with all five fixed clue pieces. A board receives one point for each matching internal edge. The solver must place every piece exactly once, in one orientation, while respecting the border and clues.
Official board coordinates
139 @ (8,7), rot 2
181 @ (13,2), rot 3 · 249 @ (13,13), rot 0
Internal 90° clockwise search frame
139 @ (7,7), rot 3
249 @ (13,2), rot 1 · 255 @ (13,13), rot 0
Coordinates shown above are zero-based, exactly as stored in the solver assets. For ordinary one-based reading, add 1 to row and column. Every harvested board is inverse-rotated by 270° before official validation and publication.
Why we do not simply enumerate everything
- The raw arrangement space is astronomically larger than the number of distributed tickets.
- A ticket is a reproducible slice of the search, not a promise that the slice will be exhausted.
- Production tickets are capped at 2 billion DFS nodes. The current corpus shows virtually all of them hit that cap.
- The practical problem is therefore allocation: spend finite compute on branches with the best measured chance of reaching 463–466.
From a ticket to a validated board
The public apps are thin native workers. Cloudflare coordinates unique work; the CPU does the expensive search locally.
Campaign
A root family and a unique sharded ticket are assigned.
Integrity
Solver, pieces, clues, roots and ledger are SHA-256 checked.
Native DFS
Optimised lookup tables generate only edge-compatible candidates.
Pruning
Mismatch budget, clues, MRV demand and proven lower bounds cut branches.
Exact tail
Promising deep states receive progressively larger rewind budgets.
Validate
Boards ≥463 are independently checked, canonicalised and credited once.
What is active in production
The production configuration is intentionally conservative: only sound cuts and measured search policies are promoted.
Blackwood-style candidate tables
Precomputed lists indexed by the two already-constrained edge colours and mismatch count. This removes most candidate scanning from the hot loop.
Five-clue fixed ordering
A clue-aware cell order and forced root families expose constraints early while keeping the search reproducible.
Three-colour prioritisation
Three empirically useful colours are quota-ramped by depth. It changes candidate order, not correctness.
Progressive break release
The allowed mismatch budget is released at depths 192, 197, 201, 206, 211, 216, 221, 225, 229, 233, 237, 241, 246 and 250.
MRV demand + NCON2 direct
Incremental remaining-demand checks and a direct two-constraint lookup reduce late candidate work.
Exact endgame ladder
Deep near-record states trigger probes and rewinds: 1B nodes from depth 236, 6B from 230, 64B from 224, and 80B from 216 as the score gap narrows.
Campaign root portfolio
A remotely reloadable allowlist controls which legal 3×3 roots receive work. The separate shallow selector is research evidence (AUC ≈0.70), used as a soft allocation clue rather than a hard pruning gate.
Distributed ledger
Completed ticket identities are never reassigned. A physical board may be reached by different paths, but canonical SHA deduplication publishes and credits it only once.
Production configuration snapshot
This is the concrete search recipe launched by the current Windows and Linux workers. It is shown as behaviour rather than as a copy-paste command, because paths and thread counts vary by machine.
| Component | Production value | Purpose |
|---|---|---|
| Instance | 256pieces.txt + hints_rot90.txt | Five official clues, searched in the verified 90° frame |
| Roots | surv2.txt + remotely reloadable allowlist | Choose legal 3×3 campaign territory without rebuilding the app |
| Distribution | 4096 shards + per-ticket jitter 3M–100M | Separate machines and diversify candidate ordering |
| Main cap | 2,000,000,000 nodes per ticket | Bound each reproducible slice before moving to another ticket |
| Endgame | probe 4; exact 244:50M | Spend exact work only after a promising deep prefix |
| Rewind ladder | gap4 r236 1B · gap3 r230 6B · gap2 r224 64B · gap1 r216 80B | Escalate work as a board approaches 466 |
| Parity | sigma-tail ON · sigma-main OFF | Use LBσ where it pays; avoid its hot-loop overhead |
| Candidate work | NCON2 direct · MRV demand incremental | Reduce late candidate generation and demand recomputation |
| Break schedule | release depths 192…250; ring-breaks 236 | Keep early prefixes clean and spend mismatches late |
| Harvest | save and upload every independently valid score ≥463 | Preserve useful discoveries while continuing the ticket |
| Accounting | tourney + ticket log + completed ledger | Measure depth/yield and avoid reassignment of finished tickets |
The home-grown “615” technique
This project designed and implemented a residual colour-parity lower bound, called LBσ. The underlying parity mathematics is general; its constant-time representation and placement in this five-clue solver are our own engineering.
As free edges disappear, the engine tracks which of the 22 internal colours have odd residual demand. One future mismatch can repair at most two odd colours. If mismatches already spent plus LBσ exceeds the target budget, the branch is impossible and can be cut immediately.
Soundness: it cannot discard a valid board within the selected mismatch budget.
Almost all nodes are reached before the bound becomes informative.
node reduction in isolated r230/r236 tail benchmarks
What the data says about today’s search
437,931 real tickets audited
hit the 2-billion-node cap; none exhausted its full assigned subtree in this ticket-log corpus.
- Median maximum depth: 243
- 88.1% reached at least depth 240
- 84.4% stopped at exactly depth 243
Interpretation
This is not evidence that the solver is broken. It shows a heavy endgame sink: many branches get very deep, yet the last placements remain combinatorially expensive. It also means nodes/second alone is insufficient; a useful improvement must increase deep-board yield per unit of time.
Finds are harvested through a separate validation channel, so “zero completions” in this ticket-log sample does not mean the project found zero boards.
Territory and allocation findings
The probability of a high score is strongly non-stationary. Where the engine searches has mattered at least as much as small changes to how it searches.
The 465 burst
All 11 canonical 465s in the audited timeline arrived between 11 and 21 August. Before that window, 36 new 464s produced no 465; after it, another 92 new 464s also produced no 465. This supports a fertile-territory burst, not a stable “one 465 per N 464s” rate.
Not a 465 upload filter
463, 464 and 465 use the same harvest, validation and upload path. Continued 464 flow after the drought is strong evidence against a score-465-specific detection failure.
Root coverage
An earlier audit found only 247 of 3,029 candidate roots receiving deep work (8.2%, Gini 0.54). This motivated wider root portfolios and hot-reloadable campaigns without replaying completed global tickets.
Root motif clustering
Adding frontier-family motifs to the stable shallow score changed AUC only from 0.710 to 0.716: ΔAUC +0.006, 95% CI [−0.004,+0.017]. The apparent 0.97 result disappeared when related roots were kept in the same holdout group.
Experiment ledger — including the failures
A technique is not promoted because it sounds clever. We require soundness, replay integrity and a net gain on representative search states.
Residual odd-colour lower bound in tight endgames.
Shallow statistics prioritise historically fertile root families.
All-different feasibility and matching checks.
Matching feasibility on selected hot frontiers.
Minimum assignment cost as a stronger bound.
Conflict and capacity bounds on small remaining regions.
Global deficits, GF(q), broader sigma and colour conservation.
Corollas, local pattern databases and proof-learning reuse.
Alternative exact formulations.
Massively parallel search and record-neighbour climbs.
Improve known high-scoring boards by neighbourhood moves.
AVX2/x86-64-v3 and AVX-512/x86-64-v4 builds.
Choose Blackwood priority colours and quotas per root family.
Expanded research registry
The summary above is not the whole history. The registry below records the other major measured experiments, including optimisations, allocation work, failed cuts, alternative search architectures and results that were positive only in a narrow regime.
A. Deployed engine and measured speed work
Compile out production-disabled branches, then profile-guide the real hot path.
Free-piece list, pre-rotated faces, placement bitmap and thread-local telemetry counters.
Probe at 244, then rewind at 236/230/224/216 as the score gap tightens.
Blackwood two-edge tables, fixed clue-aware order, three-colour HSC, NCON2 direct and incremental MRV demand.
SHA-256 assets, 4096-way sharding, completed-ticket ledger, harvest validation and canonical board deduplication.
B. Positive signals whose 465/466 value remains limited or unproved
Millions of short attempts estimate which legal 3×3 roots tend to penetrate deeply.
Prioritise roots that historically produced useful boards.
A demand-plus-parity bound called only behind a cheap trigger.
250M rather than 2B nodes increases the number of independent attempts.
An in-place sort made a ticket depend on the history of earlier tickets on that thread.
GPU exact search for the zero-break macro problem, not production q14 DFS.
C. Sound pruning ideas that failed economically
Check whether remaining pieces can still be assigned to remaining cells.
Matching and assignment lower bounds on constrained frontiers.
A stronger minimum-cost assignment bound.
Exact lower bounds on disjoint local regions.
Finite-field conservation stronger than parity on tiny remainders.
Use geometry to strengthen the parity cost.
Bipartite checker and min-plus band certificates.
Exact two-ply singleton consistency in the only tight depth band.
Turn a proved impossible perfect placement into a local break clause.
D. Search architecture, repair and alternative solvers
Delay defect regions or switch away from the clue-corner-first sequence.
Reuse repeated frontiers or dead states.
Store certified UNSAT local cores and reuse them elsewhere.
Pre-solve blocks, use dirty macros or combine record boards.
CP-SAT repair around mismatch cells of known boards.
Improve complete boards through swaps, windows and crossovers.
Port the actual 14-break Blackwood traversal to CUDA warps.
Single, multi-parent and crossover annealing around known 463/464 boards.
Climbability, relational backbones, good-groups and macro lineages.
Exact global formulations and proof engines.
AVX2/x86-64-v3 and AVX-512/x86-64-v4 builds.
Select HSC priority colours and quotas per root family.
A recent null result: E555 structural features
Concentration, demand imbalance and Mahalanobis-style features were tested as possible new branch selectors. None crossed the pre-registered AUC gate of 0.73.
| Depth | Samples | Baseline | Colour concentration | Demand | Mahalanobis |
|---|---|---|---|---|---|
| 32 | 100 | .55 | .542 | .556 | .521 |
| 64 | 92 | .60 | .546 | .544 | .517 |
| 96 | 84 | .66 | .613 | .596 | .508 |
| 128 | 82 | .67 | .540 | .578 | .500 |
At root depth 9, the same family was essentially random: concentration AUC .505, demand/Mahalanobis around .52, and Spearman correlation .047 (p=.34). We did not deploy it.
What we do not claim
- We have not exhaustively searched Eternity II or every ticket.
- We have not proved that no better pruning rule exists. Only the documented families and tested regimes are closed.
- A higher node rate does not automatically mean a higher probability of 466.
- Historical board counts are probabilistic outcomes, not deterministic hardware benchmarks.
- The five clue values, campaign roots and full operational datasets are validated assets; this page explains the method without publishing contributor credentials or infrastructure secrets.
Public foundations
Our engine builds on ideas documented by the Eternity II community, especially Joshua Blackwood’s fast DFS design. “Home-grown” identifies our additional implementation and experiment, not ownership of the puzzle or of basic parity theory.