Atlas Scout Preview 24 · Official release · August 1, 2026

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

Preview 24 rebuilds the path between extracted code and Atlas Scout’s local SQLite map. On locked Linux and Firefox campaigns, complete fresh-index readiness fell by 57.72% and 54.44%—with the same logical records, the same full-text-search results, and the same transaction and durability boundaries.

Linux and Firefox · fresh database · complete readiness

Two large repositories. More than half the wait removed.

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.

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

Complete readiness and serialized writer time

  • p50 of 3 runs per arm
  • fresh isolated database
  • locked corpus and host policy
  • same complete-readiness boundary
  • lower is better
Complete readiness and serialized writer timePaired bars compare a scalar reference writer with Preview 24 on Linux and Firefox. Complete readiness falls from 282.777 to 119.559 seconds on Linux and from 380.907 to 173.524 seconds on Firefox. SQLite writer time falls from 250.027 to 82.188 seconds on Linux and from 289.097 to 113.153 seconds on Firefox.Scalar referencePreview 24Seconds · one linear scaleLinux · complete readiness282.777s119.559s · −57.72%Firefox · complete readiness380.907s173.524s · −54.44%Linux · SQLite writer250.027s82.188s · −67.13%Firefox · SQLite writer289.097s113.153s · −60.86%
Nearest-rank p50 from three locked runs per arm and corpus. The scalar control and selected Preview 24 binary used the same source behavior outside the writer strategy.
Measured phaseScalar p50Preview 24 p50Change
Linux · complete readiness282.777s119.559s57.72%
Firefox · complete readiness380.907s173.524s54.44%
Linux · SQLite writer250.027s82.188s67.13%
Firefox · SQLite writer289.097s113.153s60.86%

Measured bottleneck · focused changes · no schema shortcut

The writer stopped paying one statement at a time.

Profiling showed that source extraction 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. 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.

Where the serialized time went

  • p50 of 3 runs per arm
  • fresh isolated database
  • locked corpus and host policy
  • same complete-readiness boundary
  • lower is better
Where the serialized time wentSymbol and identifier-term work falls by 73.73 percent on Linux and 70.88 percent on Firefox. Relationship insertion falls by 37.64 percent on Linux and 32.77 percent on Firefox.Scalar referencePreview 24Seconds · one linear scaleLinux · symbols + terms221.406s58.159s · −73.73%Firefox · symbols + terms232.600s67.736s · −70.88%Linux · relationships18.565s11.577s · −37.64%Firefox · relationships30.275s20.355s · −32.77%
The two phases use the same final 256-row production default, clamped at runtime to SQLite’s active variable limit.
Measured phaseScalar p50Preview 24 p50Change
Linux · symbols + terms221.406s58.159s73.73%
Firefox · symbols + terms232.600s67.736s70.88%
Linux · relationships18.565s11.577s37.64%
Firefox · relationships30.275s20.355s32.77%

Prepare before serialization

Keep safe CPU work off the narrow path.

Validation, count projection, identifier-term preparation, and fallible conversions happen before writer entry, where they can overlap other indexing work.

Use known ownership

Stop looking up what Scout already knows.

Relationship sources bind directly to symbol rows captured during the same atomic write. Missing or conflicting ownership fails before the transaction begins.

Batch the dominant rows

Fewer crossings into SQLite.

Symbols, identifier terms, and relationships use fixed-shape multi-row statements while preserving order, replacement behavior, row identities, and rollback.

Keep the safe foundation

No durability theatre.

Scout retains one SQLite writer, WAL readers, normal synchronization, the existing transaction boundary, FTS5, and atomic publication. No data is sampled or omitted.

The fastest candidate did not automatically win

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

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. That candidate was not promoted and the budget was not relaxed after seeing the result.

Revise

1,000 rows

Large speed gain, exact results, but +2.14% direct-device write bytes on Linux. The implementation stayed unpromoted.

Promote

256 rows

Retained the large readiness gain while Linux NVMe bytes moved only +0.15% and Firefox NVMe bytes fell 2.50%. This is the production default.

Lower-volume tables were also 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.

Same facts · same search · same recovery model

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

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.

8 + 10logical and FTS projections matched
425workspace tests passed, zero failed
10/10frozen MCP replay cases matched
44msno-change median before and after
  • 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.

CPU utilization

More CPU while the job is active.

Median process CPU rose from 206.35% to 348.56% on Linux and from 188.67% to 316.06% on Firefox. The job occupies more available cores for much less wall time.

Peak memory

Small increases, within budget.

Peak RSS rose 1.51% on Linux and 0.51% on Firefox. Both remain below the predefined 5% ceiling; no memory improvement is claimed for this release.

Tiny updates

Batching has a small fixed cost.

The two-symbol statement itself became slower in the incremental fixture, even though whole-update time changed only +0.43% and database-write time improved by 1ms.

Firefox device counter

One I/O metric moved the wrong way.

Accumulated NVMe write time rose 13.95% even as bytes, operations, flushes, and end-to-end duration fell. It was not a release gate, but it is not hidden.

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.

Preview 24 is the current public preview

Upgrade the complete managed installation.

The native updater verifies the signed release contract, stages the complete runtime and integration payload, and atomically moves the managed installation to Preview 24.

atlas-scout upgrade --check
atlas-scout upgrade