# Run 001 — exhaustive descent verification of `[3, 2^40]`

**Agent:** 數學戰士「墜衡」, Claude Opus 5, AMRAL Research Lab
**Date:** 2026-08-14 (Asia/Taipei)
**Tag:** `t40`
**Machine:** Windows 10 x64, 16 logical CPUs, rustc 1.96.0, Python 3.14.5

## Result

Every integer `n` with `1 ≤ n ≤ 1099511627776 = 2^40` has a Collatz trajectory
that reaches 1, relative to the archived implementation.

As a free corollary at the same bound: no nontrivial Collatz cycle has all of
its elements `≤ 2^40`. A cycle's least element would be some `n ≤ 2^40` that
never reaches 1, and there is none.

**This bears on the conjecture not at all.** The published frontier is at least
`2^71` — some two billion times further — and this run is not a record attempt.
(This report originally said `2^68`; the frontier was corrected to `2^71.02` on
2026-08-14 after verifying the citation. See `RUN-002-OT-SERIES.md` §9.)
Its purpose is an instrument whose behaviour is known. See `CHARTER.md`.

## Method

For each odd `n` in the interval the engine shows some `T^j(n) < n` under the
shortcut map `T`. Walking the interval upward from 1, strong induction turns
that into "reaches 1": every value below `n` has already been shown to reach 1,
so `n` does too.

Even starts are excluded by argument rather than by computation: `T(n) = n/2 < n`
holds for every even `n ≥ 2` directly from the definition of the map, so
checking them would add cost and no information. Half of the interval is
therefore genuinely not iterated, and that is a deliberate, stated reduction —
not a sampling.

The `2^k` congruence sieve is used **only as a filter**. When `T^k(n) < n` the
start is settled; otherwise the trajectory is re-walked from `n` itself rather
than continued from the jump, because a trajectory may dip below `n` and rise
again within the first `k` steps. Every quantity reported below is consequently
a property of the Collatz map with no dependence on `k`.

## Numbers

| | |
|---|---|
| Interval | `[3, 1099511627776]`, tiled by 16 chunks, no gap, no overlap |
| Odd starts checked | 549,755,813,887 (= exactly the count the interval contains) |
| Settled by one `k`-step jump | 450,996,731,903 (82.0%) |
| Required explicit iteration | 98,759,081,984 (18.0%) |
| Sieve exponent | `k = 20` throughout |
| Engine time | 981.5 s summed over chunks (~62 s each, 16 threads) |
| Failures, guard trips, non-empty stderr | none |

Extremal statistics over the interval:

| Quantity | Value | At |
|---|---|---|
| `max σ(n)`, first descent below `n` under `T` | 550 steps | `n = 898696369947` |
| `max peak(n)/n` before first descent | peak `200279370410625061016864`, ratio ≈ `2.2976 × 10^11` | `n = 871673828443` |

## How this was checked

Four gates, of deliberately different kinds. All artefacts are in
`../data/gate-logs/`.

**1. Internal self-test** — hand-checkable trajectories, the `k`-step
congruence identity against direct simulation, invariance of every reported
quantity across `k ∈ {1, 3, 7, 11, 16}`, and a live demonstration that the
overflow guard still trips. Passed.

**2. Independent-implementation cross-check** — `collatz_ref.py`, a Python walk
with arbitrary-precision integers and no sieve, against the Rust `u128` engine
on `[3, 300000]` at `k ∈ {1, 6, 14, 20, 24}`. All five quantities agree at every
`k`, while the iterative-path workload varies from 149,999 down to 15,663 —
so the two are agreeing about the answer, not about the amount of work. The
gate also asserts the interval is non-trivial and exercises the iterative path
at every `k`, because a comparison of two empty observations would agree for
the wrong reason.

**3. External anchors** — exact two-sided comparison against OEIS
A006877/A006878 (record delays) and A006884/A006885 (record trajectory peaks),
snapshotted byte-exact with digests. To `10^8`: **60 published delay records and
41 published peak records reproduced exactly**, largest compared starts
`63728127` and `80049391`; nothing missing from the engine, nothing produced
that the published lists lack. This is the only gate whose expectations this
agent did not author.

**4. Mutation drill** — ten deliberate defects planted in the engine one at a
time, plus two controls. **10 of 10 defects caught, 0 survived; both controls
undisturbed.**

| Mutation | Caught by |
|---|---|
| `M01` descent computes `3x+3` | self-test, reference |
| `M02` standard map halves twice | self-test, anchors (timeout) |
| `M03` descent accepts equality, not strictly below `n` | self-test, reference |
| `M04` `k`-step table shifts by 2 on odd steps | self-test, reference |
| `M05` `k`-step table stores `2^a` instead of `3^a` | **self-test only** |
| `M06` the overflow guard can no longer trip | **self-test only** |
| `M07` delay counter increments by 2 | self-test, anchors |
| `M08` verification walks even starts | self-test, reference |
| `M09` verification steps by 4, silently covering half the odd starts | **reference only** |
| `M10` record scan stops nominating peak candidates | **anchors only** |
| `NULL-01` a comment is added | nothing (correct) |
| `NULL-02` 8-wide chunks instead of `2^22`, reordering thread interleaving | nothing (correct) |

The bolded rows are the point of the exercise: each of the three gates is the
sole catcher of at least one defect, so none is redundant. `M09` — a silent
halving of coverage — is invisible to the engine's own self-test, because the
self-test compares the engine against itself at different `k` and all `k` would
skip the same starts. Only the independent Python walk notices. `M10` is
invisible to both, and only the published OEIS sequences catch it.

`NULL-02` is worth its place: shrinking chunks from `2^22` to 8 changes how
threads interleave and merge on every run, and every reported quantity stayed
identical — evidence that the parallel merge is order-independent rather than
merely usually-right.

**5. Coverage-refusal drill** — `coverage-refusal-drill.json`. The aggregator
was shown a run with a chunk deleted, and a run with one chunk's count reduced
by one. It refused both, naming the gap and the count mismatch, and exited
non-zero. The tampered log was restored byte-identical afterwards.

## What went wrong, and what is still weak

Three real defects were found in the drill harness rather than in the engine.
The first two would have quietly weakened the evidence; the third would have
destroyed it after it had already been earned:

- The harness named each mutant source file after the mutation id, and ids like
  `M01-descent-3x+3` contain `+`. rustc derives a crate name from the file stem,
  so the build failed and the harness recorded "rejected by compiler" — which
  would have been read as *caught*, when in fact that mutation had never been
  tested at all. Fixed with an explicit `--crate-name`.
- Gate calls had no timeout. A mutation that breaks the map makes trajectories
  stop descending, so the engine runs to its internal step guard on every start
  and returns no verdict for hours. Gates are now bounded, and a timeout is
  recorded as a distinct catch reason rather than as a pass.
- The harness ran every mutation correctly and then lost the report on the way
  out: a mutant killed by a gate timeout still held a lock on its own `.exe`,
  the scratch-directory cleanup raised `PermissionError`, and the exception
  escaped before the assembled JSON was printed. A complete, passing drill
  produced no artefact. Cleanup errors are now ignored, on the principle that
  failing to delete a scratch file must not discard evidence already obtained.

Remaining known weaknesses, stated rather than left to be discovered:

- **`STEP_GUARD` is never exercised.** The self-test proves `VALUE_GUARD` can
  still trip; there is no test that reaches the step guard, because no natural
  input gets near `2^20` steps. It is an unverified backstop.
- **One machine, one architecture, one compiler.** Everything here ran on a
  single x86-64 Windows host. Nothing rules out a fault shared by that whole
  stack, and the external anchors are the only defence against it.
- **`k = 20` for the whole production run.** Sieve-independence is checked on a
  small interval, not at `2^40` scale.
- **The 82%/18% split is not itself verified**, only self-consistent. It is
  reported as engine bookkeeping, and no claim rests on it.

## Reproducing

```bash
rustc -O --edition 2021 code/collatz_verify.rs -o build/collatz_verify.exe
./build/collatz_verify.exe --self-test
bash code/run_verification.sh 1099511627776 16 20 16 t40
python code/verify_run_logs.py --tag t40 --expect-to 1099511627776
```

The full run takes about 16 minutes of wall clock on 16 threads. The gates are
cheap except the mutation drill, which rebuilds the engine twelve times.