8Z Research Program · AIM³ Institute · DEV2.3 Cycle 3 P4 · Live Checkpoint · Independently Verified
nu3496 96,928 P4 Live
Nicaragua · 3,496 real locations
DEV2.3 cycle 3 branch P4 produced an independently verified live route of 96,928 — 0.828028% above the certified optimum. The branch was still active at capture; 96,934 remains the latest completed branch.
The live branch began from the completed 96,934 P5 seed and improved it by 6 tour units. The record was found at move 43,442, after 13 h 25 min 59 s. At the 19:47:15 CEST capture, P4 was 87.5% through its 16-hour budget with 45,078 moves. It used k=30, the ratchet law, controlled threshold acceptance and the established 2-opt, Or-opt, double-bridge, 3-opt-type-4 and segment-flip operator family.
A second compression result · verified raw file sizes
51 KB of general solver.97 KB of one instance.
The TSPTS v0.1 source file is only 51,038 bytes—nearly half the 96,982-byte nu3496.tsp input file. TSPTS is a reusable solver for compatible TSPLIB EUC_2D instances; nu3496 is only one map it can process.
The coordinate data alone is 1.90× the source size.
47.4% smaller source. A compact general program describes a search over a problem file almost twice its size.
The independently verified live 96,928 / 0.828028% route documented below comes from DEV2.3 cycle 3 P4; 96,934 / 0.834270% remains the latest completed P5 branch result. The TSPTS size fact is separately verified and illustrates the product family’s quality-per-byte direction without conflating the evidence lineages.
Precision note: raw source and input text files are being compared—not interpreter size, runtime memory or proof of optimality. A direct public claim that TSPTS itself crossed 1% should carry its own cold-start log, command, tour and verifier hash.
DEV2.3 cycle 3 · live P4 record · independently verified 19 July 2026
96,928 / 0.828028% — A New Live Record from k30 Threshold Acceptance
Cycle 3 branch P4 started from the completed 96,934 P5 champion and ran the factory-best role with LZ_binary + ratchet, candidate width k=30 and controlled threshold acceptance. Its operator set was 2opt, oropt1/2/3, double_bridge, 3opt_type4, seg_flip. The branch description is explicit: controlled valley crossing while the incumbent remains protected.
The branch found 96,928 at move 43,442 after 48,358.88 seconds (13 h 25 min 59 s), improving the completed seed by six units. At the extract's 19:47:15 CEST status point it had reached 45,078 moves, 87.5% of its 16-hour budget, with 1,636 moves since the record. The branch had not yet emitted a completed result row, so this page labels 96,928 as a verified live checkpoint, not a finished branch.
96,928
Verified live route
DEV2.3 cycle 3 · branch P4
0.828028%
Live gap to optimum
optimum = 96,132
−6
Gain vs completed seed
96,934 → 96,928
43,442
Move of live record
13 h 25 min 59 s
87.5%
Branch progress at capture
14:00:00 / 16:00:00
76
Units to 0.75% milestone
target = 96,852
Open interactive route ↗Live DEV2.3 cycle-3 P4 checkpoint over the original planar TSPLIB coordinates. The full legal cycle was independently recomputed; click for the standalone interactive viewer.
Evidence boundary: 96,928 is independently valid and was the campaign's live record at the 19 July 2026 capture, but cycle-3 P4 had not yet completed. The final branch result may remain 96,928 or improve again. The latest completed branch remains cycle-1 P5 at 96,934 / 0.834270%.
Long-horizon governance lets early/interleaved TEP reach its intended macrocycle.
The 96,928 route above is a DEV2.3 arena result. In parallel, the product family now has TSPES v0.1.4: a campaign control plane around the byte-identical v0.1.3 V4 core. It preserves direct checkpoint identity and converts the old 24-hour instance stop into repeatable 24-hour control windows.
Exact continuity
Real resume, no restart label
Search moves, RNG stream, elite memory, active representation, scheduler state and transactional TEP state remain byte-compatible with the adopted v0.1.3 core.
Full science
5,000,000 proposals before parking
The first complete V4 macrocycle is mandatory. Wall time does not cut a TEP generation simply because a calendar day ended.
Instance RDE
Park, revisit, review
Stagnated instances are checkpointed as dormant and revisited after a campaign pass. A 30-day cumulative boundary requests manual review rather than silent endless compute.
Verified package boundary
Package hash c72225274e55286322ce3281eb2b4e5f0715335b531a6c3f07cb62c68c34e593; 106 manifest entries verified; eight governor self-tests and the inherited v0.1.3 regression suite pass. This is a reachability/governance release, not a claim that v0.1.4 itself produced the DEV2.3 nu3496 record.
Falsifiable future target · updated 19 July 2026
Hypothesis — not measured 8Z-RP capability
After the verified 96,928 live record: the million-city hypothesis.
The independently verified live checkpoint 96,928 / 0.828028% is measured evidence; the latest completed branch remains 96,934 / 0.834270%. The numbers below are a separate engineering hypothesis for a purpose-built C++23 / CUDA / MPI TSPES redesign: sparse candidate graphs, a spatial pyramid, GPU-batched local moves, Tour-Enriched-Pyramid feedback and distributed elite exchange—rather than a line-by-line port of the present Python code.
Seven-day workstation target
1–2 million
Within approximately 1% of an optimum or credible lower bound
Assumed hardware: about 10 CPU workers plus one modern GPU. A favorable Euclidean/geographic stretch envelope of 1–5 million cities is worth testing, but is not yet demonstrated.
plausible engineering hypothesis
Seven-day supercomputer target
50–100 million
Within approximately 1% of an optimum or credible lower bound
Assumed allocation: roughly 256–1,000 GPUs with asynchronous MPI exchange of compact elite structures. This requires good locality, sparse memory behavior and useful parallel efficiency across the hierarchy.
high-risk stretch hypothesis
Do not quote these numbers as results. They concern near-optimal heuristic tours on favorable large geometric instances. Exact proof of optimality is a different computational regime; non-geometric, adversarial or badly partitionable instances may scale far worse.
1,904,711
World TSP anchor
The current best reported tour and the published lower bound imply a gap below 0.0471%, proving that excellent heuristic quality is possible at million-city scale.
1,437,195 / 1 h
Hard-clock anchor
The Santa Claus Challenge evaluated a 1.4-million-node Euclidean instance under a one-hour limit. Its central result: local-search localization through a neighborhood graph was decisive.
85,900 / 136 CPU-y
Exact-proof boundary
The literature’s cited exact record required about 136 CPU-years. Our hypothesis is explicitly about high-quality heuristic tours, not mathematical certificates of optimality.
Branch P4 began from the completed P3 winner at 97,036. It kept LZ_binary sensing, the ratchet law and candidate width k=20, but changed acceptance from improve-only to controlled threshold acceptance. Its operator family was 2opt, oropt1/2/3, double_bridge, 3opt_type4, seg_flip. CuPy/GPU and the Rust backend were active with one worker.
P4 improved by 89 units, reaching 96,947 after 50,312.41 seconds (about 13 h 58 min), at move 40,998 of 47,704. It completed the full 16-hour budget and crossed the 0.90% milestone. This was the decisive cycle-1 basin-opening branch from which the completed P5 result continued; the branch role later paid again in cycle 3 at k30.
96,947
Previous completed route
DEV2.3 cycle 1 · branch P4
0.847793%
Gap to certified optimum
optimum = 96,132
+815
Above optimum
completed raw arena result
146
Units inside sub-1%
threshold = 97,093
−89
Improvement vs P3
97,036 → 96,947
40,998
Best move
13 h 58 min 32 s
Cycle-1 P4 remains the largest single DEV2.3 jump, and P5 remains the latest completed branch. A later cycle-3 P4 has now produced the independently verified live 96,928 checkpoint shown above.
Why P4 matters: it delivered by far the largest DEV2.3 cycle-1 jump so far. P5 did not replace this result's role; it used the basin opened by P4 and polished it further under improve-only micro-surgery.
Milestone
Method / variant
Length
Gap
Role
Completed P4 winner
LZ_binary + ratchet + k20 + threshold acceptance
96,947
0.847793%
largest basin-opening jump
Completed P3
LZ_binary + ratchet + k20 + improve-only
97,036
0.940374%
wider candidate graph
Completed P2
LZ_binary + ratchet + k10 + base operators
97,042
0.946615%
simple-operator polishing
Completed P1
LZ_binary + ratchet + k10 + ext operators
97,050
0.954937%
first DEV2.3 branch
DEV2.1 focused winner
fusion seed + focused B1920 surgery
97,056
0.961178%
entry point to DEV2.3
Elite-fusion seed
edge-component fusion + deterministic Or-opt-1
97,110
1.017351%
pre-sub-1 seed
The scale of the problem
How Many Routes Exist?
For a Travelling Salesman Problem with n cities, the number of distinct possible routes is (n−1)! ÷ 2. For n = 3,496 that is (3,495)! ÷ 2. Here is what that number actually looks like — all 10,869 digits of it:
Possible routes for Nicaragua (nu3496) — (3,495)! ÷ 210,869 digits · scroll to see all · leading digits are exact
Brute force at 10¹² routes/sec
Would need 1010,856 years
The observable universe is ~14 billion years old. You would need that many more universes of time just to begin to sample the space.
Atoms in the universe
~1080 — 81 digits
Our search space is larger by a factor whose exponent has over 10,000 digits. There is no physical analogy adequate to close this gap.
What we actually do
Navigate, don't enumerate
We never look at most routes. Smart moves + adaptive DCC governance follow improvement gradients, escaping local optima without random thrashing.
Current verified live sub-1% record
0.828028% from optimal
Out of a 10,869-digit search space, the live verified route lands only 796 units above the certified optimum. On a laptop-scale local stack, with a small Python core, optional Rust acceleration, and evidence files published beside this page.
The algorithms
Built on Half-Century-Old Mathematics
Every optimization move in our solver was invented before 1980 — most before personal computers existed. We use no machine learning, no proprietary techniques, no black boxes. Pure classical combinatorial mathematics, directed by one new idea: the DCC governor.
1930s
TSP formally posed
The Travelling Salesman Problem is stated rigorously. No efficient algorithm is known. It will eventually become the defining NP-hard benchmark — the problem against which all solvers are judged. It remains unsolved in the general case to this day.
1954
Greedy construction (nearest-neighbour)
Build a tour by repeatedly visiting the closest unvisited city. Simple, fast, not optimal — but a strong starting point. This is our initialization strategy, and it beats every space-filling curve we tested on nu3496 (greedy: 103,064 after 2-opt vs hilbert best: 107,262).
1958
2-opt — Croes, 1958
Remove two edges from the tour, reconnect in the only other possible way. If shorter, keep it. Repeat until no improvement. Invented 67 years ago. Still the most effective local search primitive in practice. Our Rust-accelerated 2-opt inner loop runs ~100× faster — but the algorithm is bit-for-bit identical to Croes's original.
1973
Lin–Kernighan, Bell Labs, 1973
The theoretical framework for sequential k-opt moves. Published by Shen Lin and Brian Kernighan. Established the intellectual foundation for all modern TSP local search. Still cited in every serious TSP paper written today.
1976
Or-opt — I. Or, 1976
Relocate a chain of 1, 2, or 3 consecutive cities to a better position elsewhere in the tour. Finer-grained than 2-opt — makes surgical improvements where 2-opt cannot. In our nu3496 runs, or-opt-1 and or-opt-3 produce more wins than double-bridge by a wide margin. Published 49 years ago. Decisive in 2025.
2024–26
DCC — Digital Claustrum Controller (new)
One of the new orchestration layers we developed. An adaptive governor that decides which classical move to apply, when to escalate intensity, and how to escape stagnation without collapsing. The underlying moves are 50–70 years old. The DCC orchestrates them intelligently at scale, while the broader research program adds compression sensors, polyhedral/folded representations, targeted continuation and Rank-Don’t-Eliminate resurrection.
The punchline
We took algorithms invented between 1954 and 1976, added a new adaptive governor inspired by neuroscience, wrapped the whole thing in ~100 KB of Python with zero external dependencies, and achieved results on a 3,496-city instance that would have required a supercomputer and months of runtime in the 1990s — if it had been attempted at all. The math is older than most personal computers. The results are state-of-the-art for our hardware class.
Context
Us vs. The Field
The gold standard for TSP is Concorde — a solver built over decades by world-class research teams at Princeton, Waterloo, and Rice. Here is what separates us:
Concorde & commercial solvers
Codebase: millions of lines of C, developed over 30+ years
Output: independently verified live 96,928 route, 0.828028% above optimum; latest completed branch 96,934; complete .tour and audit artifacts for the live checkpoint
What this comparison means for P vs NP research
Concorde proves optimality — but needs an entire mathematical edifice to do it. We don't prove optimality. We show something different: that a lightweight adaptive system, built from mathematical primitives invented before the moon landing, can navigate a 10,869-digit search space and produce an independently verified live route within 0.828028% of optimal. The efficiency of navigation is the empirical signal. How does a small system find good solutions so reliably in a space this large? That question is the research.
Perspective
50 Hours Is Not Slow. It Is Extraordinary.
Before 1990
This problem was science fiction
In the 1980s, solving a 3,496-city TSP instance to within 2% of optimal was not a research goal — it was outside the conceptual horizon. The computational theory for large-scale heuristic TSP didn't exist. Available hardware was millions of times slower than a modern laptop.
1990s — with supercomputers
Still not realistic
Early 1990s supercomputers ran at megahertz clock speeds. Instances above n=1,000 were considered "large." Researchers published papers celebrating solutions for n=500. A 3,496-city instance with a sub-2% gap bound was years away even for the best-funded teams in the world.
Today — consumer hardware
96,928 / 0.828028% · DEV2.3 live and verified
A consumer workstation, Python available for free, optional Rust/CuPy acceleration, and a compact locally reproducible workflow. The route, hash, verification report and interactive map are published with this page.
"The 50 hours are not a measure of slowness. They are a measure of the problem's true depth — and our ability to navigate it with almost nothing."
For full context: Concorde on very large instances
Concorde — the most powerful TSP solver ever built, backed by decades of research and requiring commercial LP solver licenses — needed over 136 CPU-years to prove the optimal solution for the 85,900-city pla85900 instance (2006). That is the best team in the world, unlimited compute, decades of work. We are not Concorde. We are not trying to be. We are a 100 KB Python file finding near-optimal solutions to a 3,496-city instance in 50 hours on a single laptop. This comparison is not embarrassing. It is extraordinary.
Historical v2.5 snapshot · t = 61h
Earlier Page Leader: 97,325 / 1.241%
Third checkpoint. t≈61h (March 18 08:50 → March 20 22:03). Fleet of 14 workers, all active. Meta-DCC: 1,030 snapshots, 34 meta-steps. Fleet convergence reached — all workers within 0.022% of each other. Tightest spread since the run began.
61h
Elapsed
168h budget · 36.3% used
1.241%
Best gap
W13 · 97,325 / 96,132
14/14
Workers active
all improving
1.253%
Fleet avg gap
W13–W12 spread: 0.022%
~15%
Move budget used
~26,000–28,000/worker
~1.10–1.15%
Projected gap t=168h
sub-1% needs 3-opt/LK
Worker
Gap bar
Gap %
Best tour
Status
Fleet convergence — shared basin found
All 14 workers converged to within 0.022% (21 tour units) of each other — the tightest spread since the run began. Previous spread at t=50.6h was >1.2%. The fleet has found a shared local basin. DCC v2 self-healing and Meta-DCC fleet monitoring both contributed.
Timeline: 0.379% improvement in 10h
t≈50.6h: W5 at 1.620% (previous leader).
t≈61h: W13 at 1.241% — improvement of 0.379% in ~10h. W13 was not even in top-3 at t=50.6h. A new worker emerged as leader through sustained DCC-governed search.
Fleet convergence diagnosis — what comes next
The fleet has found a shared local basin. Further improvement to t=168h likely reaches ~1.10–1.15%. Sub-1% is unlikely without:
Algorithmic lever: 3-opt or Lin-Kernighan moves (not yet implemented). These can escape basins that 2-opt and or-opt cannot.
Better governance:Arena Lab shows gravity+ADSR and LZ_dual+PI outperform the current LZ_binary+BB on uy734 (n=734). At n=3496, the classic sensor is even more limited — the binary improvement stream is too sparse at this scale.
Hierarchical DCC: Partition 3,496 cities into ~17 clusters of ~200. Govern each cluster with geometric sensors (their optimal scale, where they find exact optimal). Stitch cluster solutions into a global tour.
16 CPU cores (14 in use for workers). Consumer RTX GPU. Windows 11. Standard off-the-shelf hardware. Nothing purpose-built, nothing rented from a cloud provider.
The Rust acceleration
Speed without new math
The 2-opt inner loop is accelerated via a small Rust extension (~200 lines, PyO3/maturin). ~100× speedup for that one loop. The algorithm itself — the logic, the moves, the math — is identical to Croes 1958. We added speed. The intelligence remains in the DCC.
