The same index. Ready in less than half the time.

Linux and Firefox · fresh database · complete readiness

Two large repositories. More than half the wait removed.

Six minutes is long enough to give up. It is long enough for an agent—or the person supervising one—to abandon the index and fall back to grepping, which is exactly the habit Atlas Scout exists to replace. So the number this release chased was not a flattering internal phase. It was the whole wait.

The product boundary is the moment Atlas Scout has finished indexing, resolved the structural map, passed its integrity checks, and can answer the asserted MCP readiness query. Preview 24 improved that complete boundary—not one isolated phase presented as though it were the whole experience. On Firefox, the largest corpus in the campaign, that boundary moved from six minutes twenty-one seconds to two minutes fifty-four.

Swipe the chart and exact-value table sideways to inspect every value.

Measured bottleneck · focused changes · no schema shortcut

The writer stopped paying one statement at a time.

Profiling told an uncomfortable story: the bottleneck had moved. Source extraction—the part that reads and understands your code—was no longer the dominant cost. The serialized SQLite writer was, spending most of its time preparing and executing millions of symbol, identifier-term, and relationship statements, one crossing into the database at a time. Preview 24 moves deterministic validation and preparation ahead of that single-file writer, binds relationship sources to already known symbol rows, and inserts the highest-volume records in bounded batches. None of it changes what the writer produces—only what producing it costs.

The fastest candidate did not automatically win

A 1,000-row batch was faster. It still failed the gate.

This is the part of the release most teams would not publish. The first large symbol batch preserved correctness and delivered the speedup, but the locked Linux device campaign measured 2.14% more NVMe bytes written—over the predefined 1% budget. Speed that quietly costs your SSD more writes is not free speed. That candidate was not promoted, and the budget was not relaxed after seeing the result.

Restraint ran the other direction too. Lower-volume tables were left alone after attribution showed they consumed less than 0.3 seconds in a 391-second diagnostic run. Higher-risk transaction regrouping and FTS redesign were not started: the measured target had already been reached without changing those boundaries. The rule this project runs on is that budgets are set before the measurement, and the measurement does not get to renegotiate them.

Same facts · same search · same recovery model

“Faster” was not accepted until “identical” was mechanically proved.

Every indexing speedup invites the same suspicion: what did it skip? Preview 24’s answer is mechanical, not rhetorical. The reference and optimized writers were fed the same prepared records, then compared through deterministic logical digests that resolve internal row IDs back to stable symbol identities. Ordinary tables and FTS5 search contents were checked independently. A speedup that changed a single answer would have been a bug, not a release.

• Every final selected-source run passed quick_check; the first pair on each corpus also passed full integrity_check and exact digest equality.
• Normalized MCP response streams were byte-identical after removing only one explicitly nondeterministic scan-timing field.
• Fault injection, rollback, cancellation, concurrent-reader, duplicate, FTS update, no-change, and one-file incremental behavior remained covered.
• A changed one-file Ollama update moved from 817.5ms to 821.0ms (+0.43%), inside the predefined 2% budget; it replaced the same file and two symbols.

The release is faster because it uses available compute differently

The costs remain beside the wins.

None of this speed appeared out of nowhere. Preview 24 spends something to get it, and the bill is printed here, next to the numbers it paid for.

These are medians from one documented host, two frozen repositories, and three runs per arm. They demonstrate the scoped writer improvement under those conditions, not a universal percentage for every repository or machine.

Signed release · four native targets · independently verified

The measured work and the public release are bound to exact identities.

Signed tag

v1.0.0-preview.24

Release commit

ff23b3e52fd19b2c23ff8c94c9986dfc1e6f0d07

Release manifest SHA-256

493fd64433f03513a552802f87ec03d8eb45be50b4fe512e3995dbbaa88056ee

Selected writer binary SHA-256

fd01a3c93e432f9f2da8d1426dbb178f08c4e838cae68f8bdedb3d853fae1b83

Frozen Linux commit

248951ddc14de84de3910f9b13f51491a8cd91df

Frozen Firefox commit

f4e6e71e9c4deb3818880f2c8a22de09a92955ce

All four native packages passed tests, release builds, offline smoke tests, SBOM generation, Sigstore provenance, OpenPGP certification, private staging, production promotion, and public verification. All 24 public versioned objects were independently downloaded and matched for size and SHA-256. The stable channel remains untouched.