Don't take the number. Run it.
Below is the ΑΔΩ engine, shipped to your browser as the same file the repository holds. Press start and it feeds a corpus on your machine, builds the address cascade, measures its own poles, and streams every probe as it computes — several configurations at once, one worker thread each.
Every figure in the runner is produced in this tab, in this session, on your own CPU. Nothing there is stored, replayed, or fetched. The recorded figures further down are kept in their own band and labelled with the run that produced them.
Set it up
the comparison is the productThese are the axes the engine actually has — each one is a real branch in Ω.js, not a preset. Tick more than one on any axis and the runner builds every combination and runs them side by side, because these numbers only mean something next to each other: the same question genuinely has different answers under different settings, and a number without its configuration is not a number.
This browser has no Web Worker support, so the runner cannot start. The battery is thousands of synchronous calls and would freeze the tab if it ran on the main thread. Everything below is still readable, and engine/verify.node.js runs the identical battery under Node.
Corpus
What gets fed. The field holds exactly this and nothing else — there is no pretraining underneath it.
Encoder
Where each byte's 256-dimensional position comes from. This axis asks whether the encoder is doing the work or the geometry is.
Delimiters in the trie key
Whether whitespace stays in the address key. It looks like a bug that level one of the trie has a single branch; it is what makes the key encode word boundaries.
Fusion
How ten directional proposals become one word. This axis moves the reading measures and leaves the claim measures untouched, which is itself worth seeing.
Context length
How many bytes of context each probe carries. Applied to every configuration, and every result is reported per length as well as pooled.
Draws, and the material never fed
The unseen set is used for the ceiling measures. If it is the same file as the corpus the runner drops it rather than pretending.
200 is ⊕ parity: at that setting the four original measures draw exactly the probes ⊕.js draws, from the same seed, in the same order, and reproduce it cell for cell.
The time above is an estimate: per-byte and per-probe coefficients measured on this code, inflated by half for a browser, then divided by an effective parallelism of two fifths of the cores your browser reports rather than by the worker count — because eleven threads on twelve logical cores do not finish eleven times sooner. It is rough, and it is stated before the run rather than after. The moment probes start, each card shows its real rate and a measured estimate replaces this one.
Running
Side by side
engine, and the two-line baseline on the same probesEach configuration is a column and each measure is a row. Under every engine figure is the same probe judged by corpus.includes(probe.slice(-11)) — eleven bytes of exact substring matching, no field, no addresses. It runs on the identical draws, so this is a genuine head-to-head rather than two benchmarks reported next to each other. On verbatim material it ties, and that is kept in deliberately.
| Nothing measured yet. Press Start the run above and this table fills in, column by column, as each configuration finishes. |
A cell reading baseline ahead is one where the trivial matcher beats the engine. Those cells exist and they are not hidden; which ones, and why, is set out under the ceiling.
The three verdicts
from the probes you just ranThe field answers in three, not two. Mine, in order — it holds this material, in this order. My words, not my order — the vocabulary is its own, the arrangement is not. Not mine — nothing to land on. The only one of the three that is a failure on material never fed is the first, which is why it is separated out rather than folded into a single accuracy number.
What each measure actually tests
read this before reading the tableThese descriptions are generated from the same file that produces the numbers, so the page cannot drift from the code. The distinction that matters most: a needle-recall figure on material the field was fed is a retrieval result. It is not a long-context reasoning result and it must not be read as one.
The ceiling
in the body, at body sizeΑΔΩ does not generalise. On material it was never fed it reads about 2% of the next words correctly — 1–3% depending on how the probes are sampled — measured on 828 probes across the three shipped held-out books at 400 bytes of context, on shipped defaults. The same engine, after being fed those books, scores about 92% on the same probes. The distance between 2% and 92% is the whole story: this is a memory, and a memory knows only what it ate.
Everything the runner measures well is a property of having been fed the material. Verbatim recall at 1.000 across every depth of a 5.94 MB haystack is real, and it is the easy direction for a prefix-addressed memory — the address is an index rather than an attention window, so recall does not decay from the front of the corpus to the back. That absence of decay is a genuine result about the architecture. It is not evidence of understanding.
Run the unseen measures and watch where they land. Feed Frankenstein, probe Moby-Dick, and the reading figure sits near zero while the field still recognises a great deal of English prose as vocabulary it holds — the my words, not my order verdict. That middle verdict is the honest answer for foreign prose, and it is also where a system with only two answers would have had to lie.
The ceiling also moves with ledger size, and not in the direction that flatters. A full false claim on unseen prose is far rarer on a 5.94 MB ledger than on the 15 KB one shipped with this page. Run both and the two numbers will not agree; neither is the other's headline.
Where the engine beats the trivial baseline, and where it does not. The figures in this column were measured on the shipped 15 KB ledger at contexts 200/380/800 with roughly three hundred draws per cell. They are here so the prose can be checked against the table; your own run will differ, and every cell in the runner prints its N.
On recognition it beats exact substring matching — delete one word in seven and it still claims the passage 0.990 of the time against 0.853; corrupt one character in twelve and it is 0.689 against 0.410. Refusing random junk is a tie at 1.000.
But exact substring matching is the wrong opponent, and beating it establishes very little. A forty-line baseline — character 5-gram overlap scored over a linear scan of the corpus — was calibrated to the same false-claim rate on 449 negatives and then measured against the engine. It recognises 1.000 of every damage mode against the engine's 0.783–0.913, and locates the true continuation on 1.000 of deletion, substitution and typo probes against the engine's 0.032–0.042. It wins on both axes. No claim about fuzzy matching is made anywhere on this site, and none should be: the only defensible statement is that exact substring search returns nothing, and that comparison flatters the engine against a method nobody would choose for the job.
On reading stored material it beats the trivial baseline. 1.000 against 0.884 — eleven bytes are ambiguous often enough that the trivial reader takes the wrong continuation about one time in nine.
On reading damaged material it loses, and by a long way. Across word deletions, 0.115 against 0.700. Under character corruption, 0.065 against 0.355. This is the largest gap in the table and it runs against the engine. The reason is in the architecture rather than in tuning: the claim reads four hundred bytes through ten directions and survives damage, while the word is selected on a twelve-trit key and scored by byte offset, so a deletion shifts every position behind it and a corrupted byte near the tail derails the branch. Recognition is robust here; emission is not.
On abstaining from its own shuffled bytes it is marginally behind — 0.993 against a baseline that cannot match a shuffled tail at all and therefore refuses everything.
The axes themselves are quieter than they look. On this ledger the derived encoder and the model-free byte hash separate by a percentage point or two on every measure, which is the point the recorded run makes at scale — the geometry does the work. Delimiters and fusion move the reading measures by roughly the same amount. At the default three hundred draws those differences are inside the noise, and the runner will show them as ties; raising the draws is the only honest way to tell them apart.
The ten-book run
Everything in this band was measured once, elsewhere, on a corpus that is not shipped with the page — ten pre-1919 Project Gutenberg books, nine fed and one held out, roughly 7 MB of source text. It is here because it is the only run at that scale, and it sits in its own band, on its own ground, so it cannot be mistaken for something the runner above produced.
| Population | N | Mine, in order | My words, not my order | Not mine |
|---|---|---|---|---|
| In the haystack | 300 | 299 | 1 | 0 |
| A book never seen | 300 | 1 | 267 | 32 |
| Random junk | 150 | 0 | 0 | 150 |
Needle recall by depth, across ten equal slices of the haystack: 1.00 for every slice. Junk refused 1.000. The single error in three hundred was inspected — a Dickens query never fed and a ledger passage from a different book produced identical trit sequences at eleven levels. Different bytes, same address.
Same benchmark with the encoder replaced by a deterministic byte hash: derived − hash → recall 0.000 · absent-needle 0.010 · junk 0.000. The geometry does the work; the encoder need only assign distinct vectors to distinct bytes. The encoder axis in the runner reproduces the shape of that result on a corpus you can download.
Check the runner instead of trusting it
same battery, no browserThe page loads three files: the engine, the τ codec, and the battery. The first two are byte-identical copies of the repository's Ω.js and τ.js — not ports, not minified, not adapted, loaded behind a two-line shim rather than edited. The third is the measurement logic, and it runs unchanged under Node against the same corpus files this page serves.
# the identical battery, outside the browser node engine/verify.node.js node engine/verify.node.js --encoder hash --skip-delims --fusion centroid node engine/verify.node.js --corpus corpus/84.txt --unseen corpus/2701.txt # and the engine's own harness, which the above reproduces cell for cell node ⊕.js
At the default 200 draws per measure per length, the four measures ⊕.js also runs — recall, junk refused, shuffled bytes refused, order flag — draw from the same seeded stream in the same order and produce the same numbers, per context length and pooled. The measures added here continue that stream after the four rather than interleaving with it, so their existence cannot perturb the originals.
A different kind of evidence
LongMemEval-V2 · self-reported · official scorerThe runner demonstrates a mechanism on material you choose. The result below is the opposite kind of evidence: an external public benchmark with its own official scorer, measured once and frozen with digests. Neither replaces the other. A live demonstration cannot tell you how a system ranks against published baselines, and a leaderboard number cannot be watched being computed.
| System | Accuracy | Latency | Note |
|---|---|---|---|
| RAG (query → slice + notes) | 51.0% | 0.2 s | released baseline |
| UDI v0.3.1 — ours | 56.76% | 0.187 s | sub-second frontier · self-reported |
| AgentRunbook-R | 58.6% | 26.9 s | released baseline |
| Codex (coding agent) | 69.9% | 177.2 s | released baseline |
| AgentRunbook-C | 74.9% | 108.3 s | released baseline |
Recompute it offline
The sealed adapter produced its 451 answers and the official scorer judged each one. This bundle recomputes 256/451 = 56.76% and the 0.187 s latency straight from those frozen judgments — offline, no API key, no access to the protected mechanism.
# download, extract, run — prints PASS with the exact numbers
curl -LO /results//repro/udi-lmev2-small-reproduce-v0.3.1.tar.gz
tar xzf udi-lmev2-small-reproduce-v0.3.1.tar.gz
python3 reproduce.py
Come falsify us.
The runner is the invitation. Drop in your own corpus, tick every axis at once, and look for the rows where the two-line baseline wins — there are three, they are named above, and if you find another we would rather hear it from you than not hear it. The full method, matched baselines, and the negative results we keep live in the Lab.