UOR-R4 documentation

Read online (planned; live once the site workflow deploys): https://uor-foundation.github.io/uor-r4/. The earlier Studio web app moves to https://uor-foundation.github.io/uor-r4/studio/.

In one paragraph. This is the map of the UOR-R4 documentation. UOR-R4 is an open research project building a language model that predicts text with geometry and whole-number arithmetic instead of a transformer's large grids of decimal multiplications, so that it can run fast on a laptop or in a browser. It is pre-alpha: 0 of its 8 milestones are complete, and no model built under its rules holds a useful conversation yet (where we are). The pages here explain what the project is, where it stands and where it is going in plain words first, then give the evidence for every claim so an expert can check it. Use the table below to jump to the page that answers your question. The same pages build into a book site, whose table of contents is SUMMARY.md.

flowchart LR
  S["Start here<br/>what, where, where next"] --> P["Products<br/>model, web, desktop"]
  S --> M["The model<br/>end to end"]
  M --> MB["Mechanism board<br/>27 parts, one page each"]
  MB --> G["Geometry<br/>the mathematics"]
  M --> R["Research<br/>findings, open questions,<br/>history, lines, notebooks"]
  R --> A["Archive<br/>every dated record"]
  S --> RU["Rules<br/>the charter explained"]
  RU --> REF["Reference<br/>vocabulary, configuration"]

How the sections connect. Read left to right for more depth; every section links back to its sources.

Find your way

How the sections are organised

• Start (start/): six short pages for newcomers. Each opens in plain words and ends with sources.
• Products (products/): the three things the project means to ship, and the release format.
• The model (model/): the current model path, stage by stage, with what is built and what is missing.
• Mechanisms (mechanisms/): the board and 27 mechanism pages, each with the same template: the idea, how it works, where it stands, and what would reopen it if PARKED.
• Geometry (geometry/): the mathematics behind the mechanisms, illustrated.
• Research (research/): how research is done now, findings, open questions, the history, 17 research-line pages and the notebooks.
• Rules (rules/): the charter explained, where each old decision went, and the change log.

Three directories stay at their old paths because code and tooling read them, and they are not part of the book: integration/ (the live plan NOW.md and the decision index), harness/ (the research harness) and labs/ (governance files and records dated 18 or 19 October 2026). Records dated before 18 October 2026 have moved, unchanged, to archive/.

Conventions used on every page

The labels follow formal_vocabulary.md, section 2. A passing test shows that code does what it says; it is not a trained capability. There is no "retired" mechanism status: a failed run closes one configuration, never a mechanism (charter §4.1).

Where it stands

Go deeper

• The repository front page: README.
• The rules: CHARTER.
• The live one-page plan: NOW.md; live tracker #2028.
• Code: the active model crate crates/uor-r4-discrete and the integer serving crate crates/uor-r4-integer.

What UOR-R4 is

In one paragraph. UOR-R4 is an attempt to build a language model, the kind of program behind chat assistants, that is cheap enough to train and run on an ordinary laptop or inside a web browser. Today's language models are transformers. They spend most of their effort multiplying very large grids of decimal numbers. UOR-R4 bets that a different toolkit can do the same job for far less: rotations of a geometric object, exact whole-number addresses built from primes, small lookup tables, and an exact memory. This page explains that bet in about five minutes. It is a research project and it is pre-alpha. None of its 8 milestones is complete, and no model built under its rules holds a useful conversation yet (STATUS, NOW).

How UOR-R4 predicts the next word. Each step uses only whole numbers. The picture shows the design; it does not show a model that already works well.

Words in bold are defined in the glossary. Claims are labelled proof (follows from definitions or code), measurement (from a recorded run) or hypothesis (an untested idea), as in docs/formal_vocabulary.md.

What a language model does

A language model reads text and guesses what comes next. First a tokenizer cuts the text into numbered pieces called tokens. A token is a word or part of a word. UOR-R4's tokenizer has 4,096 pieces (tokenizer). The model then looks at the pieces so far and predicts the next one. Given "the cat sat on the", a good model puts "mat" near the top of its list. It appends its guess and repeats.

Everything a chat assistant does, answering, summarising, writing code, comes from running this one loop many times. So a model is only as good as its next-piece guesses, and only as fast as one turn of the loop.

What a transformer is, and where its cost goes

A transformer is the design behind almost every modern language model (background: Vaswani et al., "Attention Is All You Need", 2017, arXiv:1706.03762). One turn of its loop looks like this:

flowchart LR
  t["Token"] --> e["Embedding:<br/>a long list of decimals"]
  e --> a["Attention:<br/>compare with EVERY earlier token<br/>(softmax)"]
  a --> m["Feed-forward:<br/>multiply by large learned grids<br/>(matrix multiplication)"]
  m --> o["Output:<br/>score EVERY word in the vocabulary<br/>(softmax)"]
  o --> n["Next token"]
  m -. "repeat for many layers" .-> a

One turn of a transformer. The three expensive operations are named in brackets.

Three operations carry most of the cost:

1. Matrix multiplication. Each token is carried as a long list of decimal numbers. Every layer multiplies that list by large learned grids of numbers. Nearly all of the arithmetic is here.
2. Attention. To decide what matters, the newest token is compared with every earlier token. The work grows with the length of the text, and the model keeps a stored copy of every earlier position.
3. Softmax. Scores are turned into probabilities with exponentials and a sum over everything, once inside attention and once over the whole vocabulary to choose the next word.

The project bans two of the three outright, softmax-like squashing functions and matrix multiplication, anywhere: training, evaluation, tools and serving (charter, sections 3.2 and 3.3). All-pairs attention is not banned as an idea; it is replaced by bounded reads of a few nearby tokens. The reason, in the owner's words: "my goal with all of these bans is to ban expensive operations" (charter, section 1).

The bet: geometry and exact memory instead

UOR-R4 replaces each expensive part with something cheaper:

The finished model is meant to run with whole numbers only: adds, subtractions, comparisons and table look-ups, with no multiply instruction at all. This rule is called D11 (charter, section 3.6). The lead measure of success is tokens per second on ordinary hardware (charter, section 1).

Whether these replacements can match a transformer's quality is the open question. It is a hypothesis. No measurement so far shows it, and the next page says which parts are built and which are missing: transformer vs geometry.

What "geometry" means here

"Geometry" in this project means a few concrete objects, each chosen because it can be computed exactly with whole numbers. The geometry section has one illustrated chapter for each.

A token's address is built from fixed points. Each of the 4,096 tokens owns 4 blocks of 8 whole numbers. Each block is always one of 16 fixed points of a famous eight-dimensional lattice called E8. Every such point is a signed rearrangement of (2, 2, 0, 0, 0, 0, 0, 0): two of the eight places hold 2 or −2 and the rest are zero. There are \(16^4 = 65{,}536\) possible addresses, more than the 4,096 tokens, so every token can have its own (proof, by counting; see the model page). The model does not yet use all 240 points of E8 (E8, H4 and the 600-cell).

Moving means rotating. Changing a block means swapping one fixed point for another, which is a rotation from a finite set. Nothing is rounded, so a rotation can always be undone exactly (quaternions and rotation).

Names come from primes; starting places from zeta phases. Each token can be named exactly by a prime number, and that name never collides with another. Separately, angles taken from the zeros of the Riemann zeta function (a fixed, reproducible set of numbers from mathematics) scatter the tokens' starting addresses. One such construction, PrimeZeta, gives all 4,096 tokens distinct starting addresses (measurement, construction record). The distinctness comes from a cell-balancing step, not from the zeta angles; whether the angles help at all is untested (primes and zeta phases).

Near means few steps apart. Distance between two addresses is the sum of the differences between their numbers, which needs only subtraction and addition. "Nearby earlier tokens" and "the nearest word" both use this distance (the model page).

Learning means trying the legal moves. The current model does not use calculus. To learn, it tries all 16 legal values of one block on the graphics card and keeps a change only if a whole-number score strictly improves (training, discrete learning).

Where it stands

The model is currently worse than two simple tables of word counts, and the cause is not established. Where we are explains the numbers.

Go deeper

• Transformer vs geometry: each transformer part beside its replacement, with status.
• Where we are: what works, what does not, and the measured results.
• Where we're going: the eight milestones, the shortest path and the products.
• The model, end to end: one piece of text through the real pipeline.
• Mechanism board: all 27 mechanisms and their status.
• Charter: the mission and the rules.

Transformer parts and their geometric replacements

In one paragraph. A transformer is built from a handful of standard parts: a tokenizer, an embedding table, a position signal, attention, feed-forward layers, normalization, an output layer, a loss and an optimizer. UOR-R4 tries to replace each part with a geometric or exact mechanism that avoids softmax and matrix multiplication. This page puts each transformer part beside the project's replacement and says how far that replacement has got. The short version: most parts have a candidate, and several candidates are built and tested. Two parts have no candidate at all: position and normalization. No two replacements have yet been trained together into a model that beats simple word-count tables (audit synthesis, section 1).

Each transformer part beside its replacement. Colour gives the status. The two dashed boxes are the gaps.

Terms are in the glossary. Labels follow docs/formal_vocabulary.md: proof, measurement or hypothesis.

How to read the status

Every mechanism has exactly one of three statuses, set on the mechanism board:

• ACTIVE: on the current model path, crates/uor-r4-discrete.
• READY: built and tested, but never trained into a model.
• PARKED: the forms tried so far failed or broke a rule. The mechanism stays open, and its page lists what would reopen it.

There is no "retired" or "dead" status. A failed run closes one configuration, never a mechanism (charter, section 4.1). Today the board has 10 ACTIVE, 4 READY and 13 PARKED mechanisms.

A passing test shows that code does what it claims. It is not a trained capability, and a test marked NOT_RUN is not a pass.

Part by part

Sources: the mechanism board slot map and the audit's stitching map (synthesis, section 1), which cite each record. The move counts are from the K16 outcome (130, 129, 407 and 410 accepted moves).

One status is disputed. The board keeps D11 integer serving as ACTIVE, as its own page says, but the audit would call it READY, because no lawful model has been exported through it yet (mechanism board, contradictions).

The two gaps

Gap 1: position. A transformer adds a signal that says where each token sits in the sequence. No UOR-R4 mechanism is assigned to this job, and no lawful evidence exists for one. The current model keeps the most recent tokens in order at the leaves of a small tree, so order is present in its layout, but nothing is learned about it (the model page). The nearest result is about carrying a running state by quaternion rotation. It beat no rotation by 0.071 and 0.077 nats (a nat is a unit of prediction error; lower is better), but in a model that still used softmax attention, a sigmoid gate and dense layers, with 332,928 fewer parameters in the comparison arm (transport record). So "rotation can carry order" is a hypothesis.

Gap 2: normalization. A transformer rescales its signals between layers so they stay in a workable range. UOR-R4 has no designed mechanism for this. Snapping each block back to one of its fixed lattice points might play that role, but no record says so or tests it (mechanism board). This is also a hypothesis.

What "replaces" does not mean yet

Having a replacement on paper is not the same as having a working model:

• No replacement has matched its transformer part on quality. Every attention-style read that learned well in the older decimal experiments had help from softmax during training, and the best softmax-free read was rejected (softmax-free read; audit synthesis (docs/labs/repo-renormalization-2026-10-19/audit/synthesis.md), section 1).
• No two parts have been trained together except on the current discrete path. That path has no feed-forward layer and no position mechanism, and it scores below a table of word counts (measurement, K16 outcome).
• Several other things are not built: using an exact address as the read, any consumer of the object store, an exporter that turns a trained model into a D11 file, and an output step that avoids scanning the whole vocabulary (audit synthesis, section 1).

The project does not compare its models against transformers. It compares them against count tables and earlier geometric models, and grades them with fixed, deterministic checks (charter, sections 3.10 and 4.4).

Where it stands

Go deeper

• What UOR-R4 is and where we are.
• The model, end to end: the current pipeline stage by stage.
• Mechanism board: one page per mechanism, with reopen conditions for PARKED ones.
• Geometry: the mathematics behind the replacements.
• Open questions and the history of how each part was tried.

Where UOR-R4 is today

In one paragraph. UOR-R4 is pre-alpha. None of its 8 milestones is complete, and no model built under its rules holds a conversation (STATUS, NOW). Many of the parts work on their own: a whole-number model path on the graphics card, three ways of reading earlier text, one shared word table, a whole-number engine that runs in a browser, and an exact storage system. But the best model trained so far guesses the next piece of text correctly far less often than two very simple tables of word counts. Nobody yet knows why. This page lists what works, what does not, and the measured numbers, each with its source.

Correct first guesses out of 14,287 test positions. The trained model is far below both count tables, and the new M1 bar sits at the higher table.

Terms are in the glossary. Claims are labelled proof, measurement or hypothesis (docs/formal_vocabulary.md). A passing check shows that code does what it says. It is not a trained capability, and NOT_RUN never means passed.

How the model is scored

The test set is 14,287 positions in 400 held-out documents, called the DEV panel (count tables record). At each position the model makes one guess for the next token. A top-1 score counts how many of those guesses are right.

Two plain tables, built from the same training text the model sees, set the floor:

• The unigram table always guesses the single most common token. It scores 1,226 (measurement).
• The next-word table (called T2) looks only at the previous token and guesses the token that most often followed it in training. It scores 6,300 (measurement).

Both come from the count tables record. A model that cannot beat them has not yet learned anything a lookup table cannot do. The project compares against these tables, not against transformers (charter, section 3.10).

What works

These parts are built and pass their checks. None of them is a language result. (A read is the step that looks back at earlier text; reach is how many test positions have the right answer among the candidates the model opens at all.)

What does not work yet

No model holds a conversation (STATUS). The detail:

The best trained model is below both count tables. The last full experiment (called K16) trained two variants of the model, each on two random seeds, for 16,404 batches (K16 outcome; all measurement):

Variant A is the one the record selects. Its reach fell below the required 4,894 positions on both seeds. Variant R kept a high reach only by collapsing into 19 or 20 cells, so that each guess was drawn from about 3,400 of the 4,096 tokens, nearly the whole vocabulary; that reach is not real discrimination. The registered verdict was an occupancy collapse (record code OCCUPANCY_COLLAPSE_TRIGGERED), and no run was kept. All four miss the run's own top-1 bar of 1,941 and are far below the next-word table's 6,300. The large gap between seeds (65 against 463) also shows how noisy one run is.

The cause is not established. The first guess was that too few distinct starting vectors were to blame. That is ruled out as the main cause: in variant A, training raised the distinct vectors from 16 to about 275, yet top-1 stayed low (K16 outcome, census section). The candidates still open are:

• The address key may be too coarse. The key is the distance that orders the drawers. It uses only the first and last block and takes only 5 values (0, 4, 8, 12 or 16) to order up to 256 cells (proof, from the kernel source), so which drawers open is largely decided by their arbitrary numbering (the model page, chief architect's review §3.2). Whether this causes the low score is a hypothesis.
• The read, the ranking capacity, or the training schedule. One full run sees fewer than half of the training targets: 1,049,856 of 2,425,925 (measurement, audit dossier). These remain hypotheses.

The newest run stopped early. The address-cell run (A8) began with the better reach above, but training eroded it. At its first checkpoint the Relation read held 551 reachable positions, below half its starting 1,351, which triggered the registered stop (the control held 857; measurement, A8 dose). A version that protects the reach is built; its GPU qualification is NOT_RUN (controller record).

No model trained under today's rules has been exported or timed. No exporter turns a trained discrete model into a D11 file (the older float stacks were exported and served in October), and tokens per second for this model have never been measured (lut-serving).

Parts are missing. The current model has no position mechanism, no normalization and no feed-forward layer (transformer vs geometry).

Training is on hold. Each training run needs a reviewed one-page plan and a release typed by the owner personally (charter, section 5).

What about the older models?

Before October, the project trained a decimal-number model called the geometric stack, from 7 million to 214 million parameters. Four 214-million-parameter checkpoints are published on Hugging Face as historical evidence. Their chat versions (which predate today's rules) could rewrite and summarise, while code and arithmetic were wrong (audit dossier, from the model card). That stack used softmax, the SiLU activation (a smooth squashing curve) and matrix multiplication; geometry was about 0.05% of its arithmetic. Served through the integer engine, its best version (19.9 million parameters) reached 0.933 bits per byte and the charted versions 1.20 to 1.24, all missing the old M1 bar of 0.90 (D11 serving record; audit dossier). It breaks today's rules and is PARKED (geometric stack). It shows the project can train a model that writes text. It does not show that the geometric replacements can.

How the project got here

Between 12 and 19 October the owner (project lead Casey Allard) made 19 decisions, several of which rebuilt the model's foundations: no softmax anywhere, no matrix multiplication, GPU-only research compute, whole numbers on the active path. Much of that week went into rebuilding and checking rather than learning. In the week of 12 to 18 October, 34 of 309 records were results; the rest were tooling, plans and reviews, part of it ordered by those decisions. Five training runs on the new discrete path followed, and none produced a kept result (audit synthesis, section 3). The history has the long story.

Where it stands

Go deeper

• Where we're going: the milestones and the shortest path from here.
• The model, end to end and training.
• Open questions: what is unknown and what would settle it.
• Records: K16 outcome, A8 dose, count tables.
• The live plan: NOW.

Where UOR-R4 is going

In one paragraph. The goal is a fast language model that runs on your own laptop or in your browser, holds a conversation with a durable memory, and later reasons and writes code, all on the geometric path with no transformer. The project marks progress with eight milestones, M1 to M8. None is complete yet. On 19 October 2026 the owner set a plain first bar: the model must beat two simple word-count tables, on each of two seeds, through its whole-number export. This page explains the milestones in plain words, the shortest credible path from today to a first simple conversation, and the three products at the end. The path is a plan, not a promise. Every training step still needs the owner's release, and the central question, whether a softmax-free model can learn to rank words well, is unanswered.

The road from today to the products. Stage 0 is where the project stands. Each gate needs an owner release.

Terms are in the glossary. Labels are proof, measurement or hypothesis (docs/formal_vocabulary.md).

The eight milestones in plain words

Statuses are from the ROADMAP table, which states each bar in full. A milestone closes only when its bar is met on a saved model.

The new M1 bar

M1 closes when one saved discrete model passes five conditions (charter, section 4.8; D39, item 1):

• (a) Starting reach. Before training, the right answer is among the candidates the model opens (its "reach") at no fewer than 4,894 of the 14,287 test positions (the gate called G-Pre; the "G-" names are gate codes from D39).
• (b) Reach kept. That reach survives training, on both seeds (G-Adm).
• (c) Real spread. More than 16 of the 256 word cells (the "drawers" of words) are in use, plus the further occupancy condition in D39 (G-Occ).
• (d) Beat the count tables (new, 19 October). Whole-number top-1, measured through the D11 export, beats both the unigram table (1,226 of 14,287) and the next-word table (6,300 of 14,287) on the same test panel, on each of two seeds, with tokens per second reported. This replaces the earlier bar of 0.90 bits per byte, which the current model cannot be scored on because its loss gives no probabilities. Bits per byte returns at a later milestone.
• (e) Fresh transfer. The gain holds on a fresh, sealed test panel registered in advance.

For scale: the best trained model today scores 65 and 463 (measurement, where we are). The gap to 6,300 is large.

The shortest path to a first conversation

The audit of 19 October laid out the shortest credible path as six stages (audit synthesis, section 4). It is a proposal. The stage order follows the owner's fixed sequence in D39 item 4; changing it is the owner's decision.

Stage 0. Run what is already FIT'd. A capacity test (called W2, about $0.91) is FIT-reviewed and queued, awaiting an owner release (NOW, row 6). "Capacity" here means how many different words the addresses can tell apart. W2 decides whether the shortfall comes from the representation (the addresses cannot tell enough words apart) or the learning law (the training method cannot find good addresses). Next comes the rerun of the address-cell model with its reach protected (controller record). Decides: fix the addresses, or move on to Stage 2.

Stage 1. Make the capacity measurable. Replace the coarse address key (today it can take only 5 different values, so it barely separates the drawers) with one that uses the whole vector, and measure it before any training. A wider code is optional and needs new GPU code. Bar: enough distinct vectors that the number of positions still winnable clears the run bar of 1,941, and a starting reach above the address-cell model's 1,351 of 3,847.

Stage 2. Pick the learning law. First a faster discrete method that scores 16 coordinates at once (called BVG-K; its first stage is qualified), at about $12 for two seeds. Only if Stage 0 blames the learning law and BVG-K fails: one decimal-training run in a separate module, at about $5 to $10 plus build work. Decimal numbers are allowed in offline training only; the shipped file stays whole-number (charter, section 3.7). Bar: beat the unigram table, then the admission-matched next-word table (the version W2 produces, not the 6,300 full-panel table), on two seeds.

Stage 3. Add the missing parts. Build a trunk with a feed-forward layer (the Hamilton gate), a recurrence with quaternion rotation, and the Flock and Relation reads. None of these has been trained together, and the only supporting evidence is weak, so this stage is a hypothesis test, not reuse of proven parts. Scale and data are also open: no trained stack has used the 1.39-billion-token chat corpus the project assembled (UOR-Foundation/uor-r4#1660). Bar: beat Stage 2's best by more than the seed-to-seed noise, with a fresh-panel number.

Stage 4. Export and serve. Write the missing exporter that turns a trained model into a D11 file, then measure the export gap and tokens per second on a laptop. Bar: the integer audits stay green, the gap stays within the noise band, and tokens per second is reported for both reading the prompt and writing the reply. This is where M1's bar (d) and M4 are tested.

Stage 5. First simple conversation. Train on fixed example answers produced once by a donor model (not yet generated), as the owner's one-time exception D41 allows: the student sees only the answers, never the donor's probabilities. Ground replies in the exact memory and the object store. Bar: M2's bar, at least 256 of 512 saved questions and at least 40% of fresh ones, graded by fixed deterministic checks.

Binding conditions on every stage. Training is held until the owner releases each reviewed plan, and the owner types each release personally (charter, section 5). M1 can only be closed by a whole-number-trained ("discrete") model, so if Stages 3 and 4 use a trunk (the main body of the network) trained with decimals, the owner must first redefine the milestone. Under D41, the Stage 5 student stays on the discrete path unless the owner decides otherwise (audit synthesis, section 4).

What the audit proposes to stop: rerunning the old starting table (built from a fixed random seed) that gives at most 16 distinct vectors; tuning admission objectives on the 5-value key; and reading much into any run that loses to the two count tables.

After the first conversation

Stages 0 to 5 aim at M1, M4 and M2; M3 is not yet staged. The rest of the road is:

• M5: measure the real cost on an M1-class laptop: energy per token, memory and tokens per second. An integer path is not an efficiency result until it is measured (charter, section 3.9, "Efficiency is measured").
• M6: add reasoning and coding to the same model. Exact arithmetic is the visible gap.
• M7: make the browser worker, the command line and the Rust library give identical tokens.
• M8: the owner declares an alpha release.

The products at the end

The owner defined three products on 19 October (charter, section 2; products):

Nothing ships until a trained model passes M1 to M8. Running the finished model on your own computer or in your browser is the product, and the rule that research compute must use a GPU does not apply to it (charter, section 3.6).

The biggest unknown

Every read that learned well in the older experiments had help from softmax during training, and the best softmax-free read was rejected (softmax-free read). Whether a lawful read can learn to rank words without it is a hypothesis, and no amount of assembly answers it before Stage 2 runs (open questions).

Where it stands

Go deeper

• Where we are: the measured starting point.
• Transformer vs geometry: which parts exist and which are missing.
• NOW: the live one-page plan, and ROADMAP for milestone detail.
• Products: the model, the web client and the desktop client.
• Charter: the rules every stage must follow.

Frequently asked questions

In one paragraph. These are the questions newcomers and would-be contributors ask most often, answered plainly. The short version: UOR-R4 is a pre-alpha research project that tries to build a fast language model out of geometry instead of a transformer's expensive arithmetic. Parts of it are built and tested. No model it has trained holds a useful conversation yet, and the best one so far predicts the next word worse than a simple table of word counts (STATUS). Words in the answers are defined in the glossary.

flowchart TD
  S["You arrive"] --> Q{"What do you want?"}
  Q -- "Understand it" --> U["What is UOR-R4<br/>Transformer vs geometry"]
  Q -- "See how far it got" --> W["Where we are<br/>Where we're going"]
  Q -- "Run or chat with it" --> R["Section: Running it<br/>(no chat model yet)"]
  Q -- "Help build it" --> C["Section: Contributing<br/>CONTRIBUTING.md and NOW.md"]
  Q -- "Read the old work" --> A["Section: Records<br/>archive/ and the catalog"]

Which section of this page to read first.

Claims are labelled proof (follows from definitions or code), measurement (from a recorded run) or hypothesis (untested), as in docs/formal_vocabulary.md. NOT_RUN means a test was planned and never executed. It is not a pass.

The basics

1. What is UOR-R4, in plain words?

It is an open research project that asks one question: can a language model run on an ordinary laptop or in a browser if its core arithmetic is geometry (rotations, exact whole-number addresses built from primes, lookup tables) instead of the huge decimal multiplications inside today's chat AIs? The project is pre-alpha and the answer is not known yet. See what UOR-R4 is and the charter, section 1.

2. Is this a transformer?

No, by design. The charter says the project is "not a transformer" (section 1), bans matrix multiplication (section 3.3) and excludes "a dense model disguised as lookup tables" from serving (section 3.6) (charter). The current model (crates/uor-r4-discrete) reads earlier words with three bounded reads (Route, Flock, Relation) and has no feed-forward block at all. But be careful with the history: the project's older float models (7 million to 214 million parameters) used softmax, matrix multiplication and a SiLU activation (a smooth squashing curve), so they did not follow today's rules (measurement, geometric stack). The comparison page is transformer vs geometry.

3. Does it work yet?

No. Zero of the eight milestones are complete (STATUS). What works is the parts: for example the integer substrate passes 25 of 25 admitted GPU construction controls (measurement, K16 qualification), and the whole-number serving engine runs in a browser and contains no multiply, divide or decimal instruction in 7 of 7 serving functions (measurement, WASM record). Passing a control is not a language result. No two replacements have been trained together into a model that beats the count tables (open questions).

4. How good is the best model so far?

Not good. On 14,287 development rows, the best trained arm (K16-A) got its first guess right 65 and 463 times on its two seeds. A table of overall word counts gets 1,226, and a table that looks up the last word and returns its most common successor gets 6,300 (measurement, K16 outcome, count tables). The model has to beat both tables before the first milestone can close (charter, section 4.8).

5. Why does it lose to a count table? Do you know the cause?

The cause is not established. One early suspect, that too few distinct starting vectors capped the score, was tested and did not explain it: training broke much of the aliasing and the score stayed low (K16 outcome). The open candidates are how well the output step can rank, the read, the address key (it takes only 5 values to order up to 256 cells, a proof from the kernel source in the architect's audit; whether that causes the low score is a hypothesis) and the training schedule (one pass sees under half the training targets). The next test, W2 (FIT-reviewed and queued, awaiting an owner release), decides whether the wall is the representation or the learning law (open questions).

6. Will it reach frontier capability?

That is the goal, in the owner's words "almost frontier level capability" on a laptop (charter, section 1). It is a hypothesis. Nothing measured so far supports or refutes it, and the data and model scale needed are not established. The shortest planned path is in where we're going.

The rules

7. Why no softmax?

The owner's reason is cost, not taste: "to ban expensive operations" (charter, section 1). Softmax turns scores into probabilities with exponentials and a sum over everything, and it hides a dense global normalisation. The charter bans it, and every softmax-like function, in the model, its training, its comparators and any renamed or table form (section 3.2). The price is real: every earlier read that learned a ranking had softmax helping it somewhere in training, and the best softmax-free read was a recorded REJECT, 0.0172 bits per byte worse and 15% slower (measurement, open questions, record). Whether a softmax-free read can learn ranking at all is the project's biggest open question.

8. Why no matrix multiplication?

Matrix multiplication is nearly all of a transformer's arithmetic, so removing it is the point of the project (charter, section 3.3). A geometric feed-forward block, such as the Hamilton gate, is allowed. A dense one is not. One mechanism, spin-native weights, matched a dense model's score but only by running a dense block multiplication, so it is PARKED.

9. Why use GPUs for research but laptops for serving?

They are different jobs. Research compute (training, evaluation, qualification) must run on the GPU, because host runs gave wrong timing and wrong evidence, and spending GPU only where a run can change a decision keeps costs down (charter, section 3.5). The finished model, though, is meant to run on the user's own device: serving the exported integer file on a laptop CPU, in a browser or on Apple silicon is the product, and the GPU-only rule does not apply to it (section 3.6). Scoring an exported model for a milestone still counts as research compute.

10. Why can training use decimals when serving cannot?

Decimals train faster, and only the shipped file has to be integer (charter, section 3.7, from decision D37). Any float-trained candidate must report its export gap, the quality lost when it is snapped to whole numbers, and a gap above the noise band disqualifies it. The current discrete model avoids the question because it is integer from end to end. See serving and export.

11. Why primes, zeta zeros, E8 and quaternions? Do they actually help?

The owner's rule is "use geometry", because the bet is that exact geometry can replace dense arithmetic (charter, section 1). What has been shown is narrow. An injective code is possible by counting (\(16^4 = 65{,}536 \ge 4{,}096\), proof), and the PrimeZeta construction gives all 4,096 tokens distinct vectors (measurement). The address-structured table reached 1,351 of 3,847 targets at zero training, against 127 for the plain PrimeZeta start (measurement). But no run has shown that any geometric choice beats a plain alternative on language. Architectural priority is not measured advantage. See the geometry chapters.

12. Why so much process? What is a FIT sheet?

A pre-registration sheet is a one-page plan written before a run: the bar, the noise, the controls, the seeds, the cost and what each outcome decides. A FIT review is a check by someone other than the author that the test can answer its question. The project added this because early results kept turning out to be measurement artefacts (what the project knows). It also overdid it: in the week of 12 to 18 October only 11% of recorded lab work was a model result (measurement, history). Since 19 October a sheet is required only before GPU training or evaluation and before any run a milestone claim rests on (the rules).

Running it

13. Can I run it?

You can build it and run its checks, but you cannot chat with it, because no model trained under today's rules has been exported to the serving engine. From a clone, with the pinned Rust toolchain, the README's commands are cargo check --locked -p uor-r4-discrete --lib and cargo test --locked -p uor-r4-discrete --lib. These execute no model (README). Training needs CUDA GPUs rented through the project's tools and a personal release by the owner for each run (training).

14. Is there a web or desktop app?

Not one you can use. The web client is meant to be a local model in a browser tab, and the desktop client a Tauri app with durable memory. Today the Studio interface and a WebAssembly build of the engine exist separately, the Studio still imports an older engine, and the desktop app is a specification only (products, web client, desktop client).

15. What about the models on Hugging Face?

Four 214 million parameter checkpoints are public, but they are historical: trained before the no-softmax and no-matrix-multiplication rules, in the float form, and not the served model. Their chat variants rewrite and summarise usably, while code and arithmetic are wrong (data and tokenizer, README).

16. How fast is it? How much does it cost to train?

Tokens per second is the project's lead metric, and it has never been measured for the current model (charter, section 1; lut-serving). For cost, the audit quotes the K16 runs at "1.2 h ($2)", the chief architect's figure (section 7 of the architect audit), that is about 1.2 hours and $2 for all four K16 runs together. Spending is capped at 4 rented pods and $8 an hour across all labs (charter, section 5.4). These are estimates, not invoices.

Contributing

17. How can I contribute?

Start with the one-page plan, NOW.md, then CONTRIBUTING.md. Model work on the first four milestones is gated and owned by the labs. Work that is genuinely open to outsiders includes documentation and claim-wording fixes, reproducing a published negative result, and tooling that does not touch the model path. Post a short comment on the owning issue saying what you will do, work on a short branch, and open a pull request that says References #N. A maintainer runs the project's gates for you (CONTRIBUTING).

18. What are the labs, and who decides?

A lab is any contributor, human or AI, working under the charter. Labs so far include Claude, Codex and DeepSeek, with Kimi in the project-manager seat. The owner, Casey, decides the charter, the constraints, holds, spending, milestone bars and exceptions, and types every run release personally. The project manager sequences work, and labs choose tasks from NOW.md. Subagents review and test but never make critical decisions. See the rules.

19. What do ACTIVE, READY and PARKED mean? Is PARKED dead?

The three statuses describe how far a mechanism has got. ACTIVE is on the current model path, READY is built and tested but not yet trained in, and PARKED means the tested forms failed or broke a rule. PARKED is not dead: owner decision D22 says a negative closes one tested configuration, never a mechanism, and each PARKED page lists what would reopen it. Of 27 mechanisms, 10 are ACTIVE, 4 READY and 13 PARKED. See the mechanism board.

Records

20. Where is the old research?

Nothing was deleted. Dated records from before 18 October moved unchanged into archive/, and a generated catalog lists them: archive/CATALOG.md. The story of what was tried is in how the project got here, the distilled lessons in what the project knows, and one page per research line in the notebooks and lines. The pre-charter rulebook is preserved in archive/integration/DECISIONS-2026-10-19.md.

21. What happened to the 437 of 512 and the 0.877 results I may have seen?

Both are old and narrow. The 437 of 512 replies were later judged to be panel fitting, and they fell to 0 of 128 on opened transfer rows (a genuinely fresh test has not run) (native geometric engine). The 0.877 bits per byte was a float score on one 19.9 million parameter stack that used softmax and matrix multiplication; served through the integer engine it scored 0.933 against a 0.90 bar, and the two numbers were not measured on the same windows (serving and export). Neither is a result of the current model.

22. What is in projects/?

Seven side projects that are related to UOR-R4 but are not on the model's training or serving path, such as the SpiralCore network transport and a Lean proof scaffold. None of them is evidence that the model works. See projects/README.md.

23. Who is behind it, and what is the licence?

The citation file names Casey Allard and the UOR Foundation as authors, and the project is released under the MIT licence (CITATION.cff, LICENSE).

24. How do I know the claims in these pages are honest?

Every number on a page is linked to a repository path, a pull request or an audit file. Each claim is labelled proof, measurement or hypothesis, and the repository runs a claim-wording check (cargo run -q --locked -p uor-r4-claim-wording -- .) that rejects strong proof wording unless the same line links a proof or certificate. If you find a claim that is wrong or unsourced, open an issue; that is a welcome contribution.

Go deeper

• What is UOR-R4 and transformer vs geometry.
• Where we are and where we're going.
• Glossary: every term used here.
• The rules in plain language and the charter.
• Open questions: what is still unknown.

Glossary

In one paragraph. UOR-R4 uses a lot of words that come from three places: language models (token, softmax, BPB), geometry (quaternion, E8, icosian) and the project's own rulebook (FIT, KEEP, PARKED). This page defines each one in a sentence or two and links to the page that explains it properly. Words are in alphabetical order. If you meet a code name such as K16 or A8 in a record, look for it here too. The project is pre-alpha: 0 of its 8 milestones are complete and no model holds a useful conversation yet (STATUS).

flowchart LR
  subgraph model["The model, in the order text flows through it"]
    direction LR
    T["Text"] --> TK["Tokens<br/>(tokenizer, BPE)"]
    TK --> AD["Address<br/>(codebook, E8, prime)"]
    AD --> RD["Read<br/>(Route, Flock, Relation)"]
    RD --> AM["Admission<br/>and writer"]
    AM --> NX["Next token<br/>(top-1)"]
    LS["Loss and learning<br/>(hinge, counterfactual move)"] -.-> AD
    NX --> EX["Export<br/>(UORLUT01, export gap)"]
    EX --> SV["Serving<br/>(D11, WASM, tokens/s)"]
  end
  subgraph rules["How the work is judged"]
    direction LR
    CH["Charter and D-entries"] --> FT["FIT sheet"]
    FT --> RL["Owner release"]
    RL --> NB["Notebook row<br/>(KEEP, PARKED)"]
  end

Where each family of terms sits. The top row is the path of one prediction. The bottom row is how a piece of work is approved, run and recorded.

How to read this page

• A word in bold at the start of an entry is the term. "See" points to the entry that holds the definition.
• Claims are labelled proof (follows from definitions or code), measurement (from a recorded run) or hypothesis (an untested idea), as in docs/formal_vocabulary.md.
• Numbers come from the linked page, which cites its own source. NOT_RUN means a test was planned and never executed. It is not a pass.

Jump to: A · B · C · D · E · F · H · I · K · L · M · N · O · P · Q · R · S · T · U · V · W · Z

A

A8. The nickname of the address-structured cells table, the starting table of the current model, and of the training run that began from it. At zero training it let the reader reach 1,351 of 3,847 copy-successor targets, against 127 for the plain PrimeZeta start (measurement). Learning then eroded that gain, and the first training run stopped at its first checkpoint. See address cells.

ACTIVE. A mechanism status: the mechanism is on the current model path. See mechanism status.

Address. A token's place in the model. It is 4 blocks of 8 whole numbers, and each block is one of 16 fixed points of the E8 lattice. Exact token identity is kept separately from this geometric address. (A token's prime address, defined below, is a different thing: its exact name as a prime number.) See the model, end to end.

Admission. The shortlist step before the model picks a word. The 4,096 words sit in 256 cells, and the model opens only the few cells nearest to what its read points at. A word in an unopened cell can never be chosen, so admission caps everything before it (proof, by construction). See admission.

Artifact. A saved model file together with the data, seed, settings and parameters that made it. The charter requires every artifact to bind all of these. See charter, section 3.12.

Attention. The step in which a language model decides which earlier words matter. A transformer compares the newest word with every earlier word. UOR-R4 replaces it with three cheaper reads: Route, Flock and Relation. See transformer vs geometry.

B

Bar. A pass line that is fixed before a run, so the result cannot be bent to fit afterwards. Bars are never narrower than the measured noise. See the rules.

BPB (bits per byte). A score of how well a model predicts text: the average number of bits it needs for each byte. Lower is better. The older milestone bars use it (M4 asks for 0.90 or less). The current discrete model has no probabilities, so it cannot produce BPB, and on 19 October the owner replaced M1's BPB bar with a top-1 comparison. See rank-margin and charter, section 4.8.

BPE (byte-pair encoding). The way the tokenizer builds its pieces. It starts from the 256 single bytes and repeatedly glues the most common neighbouring pair into a new piece. The pinned tokenizer has 4,096 pieces: 3 special ones, 256 bytes and 3,837 merges. See tokenizer and data and tokenizer.

BVG-K (batched verified coordinates). A faster version of the learning step. It scores K table entries in one GPU launch and commits them together only if their joint loss beats the best single move. Scoring was about 16 times faster at K=16 (measurement), but it has never run as a learning law. See training.

C

Carrier. The small integer block the model passes along: 8 whole numbers drawn from a 16-root orbit of E8, moved by 64 exact signed actions. Four carriers make one token's vector. See SpiralCore and architecture.

Cell. One of the 256 drawers that admission opens. A word's cell is the pair of roots of its first and last block, so the grid is 16 by 16 and each cell starts with 16 words (training can move words between cells). See admission.

Charter. The project's short rulebook, adopted by the owner on 19 October 2026. It replaced the older stack of instructions and numbered decisions. Only the owner changes it. See CHARTER.md and the rules in plain language.

Codebook. The table that gives each of the 4,096 tokens its starting vector. In the current model it is built by a fixed recipe, not drawn at random: see PrimeZeta and A8. See data and tokenizer and architecture.

Control. A run identical to the one being tested except for the one thing under test. Controls here must be lawful non-neural baselines, such as count tables. See the rules.

Counterfactual move. One step of learning. The machine picks one table entry and tries all 16 of its legal states (staying put plus 15 rotations), counts the mistakes after each on a batch of 64 examples, and keeps the best only if it strictly beats staying put. There are no gradients. See discrete learning and training.

D

D-entries (D11, D22, D37 and the rest). Numbered owner decisions, from D0 to D41, that used to be the project's rulebook. The charter now holds the rules that still bind, and the decision map says what became of each decision. The ones you will meet most are D11, D22 and D37.

D11. The serving contract: the finished model runs with whole numbers only. It has five rules. Two of them are that the served program uses no floating point and no multiply or divide instruction. See serving and export.

D19 object store. A store that keeps bytes exactly, in a tree of fingerprinted pieces, so repeats are stored once and any range can be checked. It is built and tested (20 integration tests pass in the delivery record, 60 after later work), but no model uses it yet. See object store.

D22. The owner's rule that a negative result closes one tested configuration, never a mechanism. Stopping a mechanism needs the owner. This is why no mechanism has a "retired" status. See the rules and decision map.

D24. The owner's rule of 12 October 2026 that no model compute runs on the CPU: training, evaluation and every research measurement of the model are GPU work. Serving the exported D11 integer artifact on a client device is the product, not research compute (charter 3.6). See the rules.

D37. The owner's rule of 18 October that floating point is legal in offline training. Softmax-like functions and matrix multiplication stay banned, and every float-trained candidate must report its export gap. See training.

DEV panel. The set of 14,287 development rows used to score models while they are being designed. A model's first guess is right on some number of them (see top-1). The "fresh" panel is a separate sealed set, scored once after the design is chosen. See K16 outcome.

Diagnostic stop. A run ended early on purpose, by a stop rule written down beforehand, so the cause can be found. It is not a negative result and not a failure of the mechanism. See research notebooks.

E

E8. A famous lattice in eight dimensions with 240 "root" points. The project builds a pairing of the 120 icosians with a golden-ratio-scaled copy of themselves and gets these 240 roots. The current model uses only a 16-root piece of E8, not all 240. See E8, H4 and the 600-cell.

Embedding. In a transformer, the learned list of decimals that stands for each token. UOR-R4's counterpart is the constructed integer codebook. See PrimeZeta.

Exact memory. The idea of writing a fact once under an exact name (a prime-based address) and reading it back exactly, instead of smearing it across weights. The trained forms tested so far missed their bars, so the mechanism is PARKED. See exact memory.

Export gap. The quality lost when a model trained with decimals is snapped into the whole-number file that ships. It is the served score minus the float score on the same evaluator. A float candidate whose gap exceeds the two-seed noise band is disqualified. Nobody has measured it for a model built under today's rules, because none has been exported. See serving and export.

F

FBS. The project's name for the three-branch tree that holds earlier words in order. The tree is built by SpiralCore and gives the context at most 243 positions (\(3^5\)). See SpiralCore and SpiralCore/FBS projection.

FIT (TEST FITNESS: FIT). The verdict of a review, by someone other than the author, that a pre-registered test is fit to answer its question. A fresh-context subagent counts as a non-author. A FIT releases nothing by itself: the owner still has to release the run. See the rules and training.

Float. Decimal (floating-point) arithmetic. Allowed in offline training under D37, never in the served model. See serving and export.

Flock read. An attention replacement modelled on a starling flock. The model picks about seven of the nearest earlier positions, rotates what each knows into its own point of view, and moves toward their consensus. Nothing is normalised and no weight is multiplied. It runs inside every Relation run, but its own value has never been isolated. See Flock read.

Fresh panel. Rows that were never seen during design and stay sealed until a run is registered to score them. Every development gain must also report a fresh number. See the rules.

H

H4. The symmetry group of the 600-cell, a regular solid in four dimensions. Its 120 roots are the icosians. See E8, H4 and the 600-cell.

Hamilton gate. A gate for a feed-forward layer that turns the gate signal into a rotation in four dimensions and rotates the value by it, so no sigmoid is needed. A rotation keeps a vector's length, so the gate steers a signal rather than switching it off. It is built and tested (READY), and has never been trained. See Hamilton gate.

Hamming distance. The number of positions at which two bit strings differ. It costs one XOR and one bit count. The model uses it as a tie-break inside its reads. See VSA and Hamming distance.

Hinge loss. A loss that asks only whether the right answer beats its strongest rivals by a fixed gap. If it does, the loss is zero. If not, the loss is the shortfall. It needs no probabilities. The live version is an integer hinge. See rank-margin.

Hold. An owner order that stops a kind of work until the owner lifts it. Training, the second milestone's training and rental, and Stage B are all on hold. A FIT review lifts none of them. See charter, section 5.1.

Hopf map. A map that takes a point on a four-dimensional sphere (a unit quaternion) to a point on an ordinary sphere. It forgets one angle, called the fibre, so many states cast the same shadow. The kept-fibre idea is built as a helper but is not part of the current read, and the mechanism is PARKED. See the Hopf map and the kept fibre.

I

Icosian. One of 120 unit quaternions that form the binary icosahedral group, a double cover of the icosahedron's 60 rotations (the icosahedron is a 20-sided solid). They are the vertices of the 600-cell, and their coordinates need the golden ratio, which is why exact golden-integer arithmetic is used (see Z[φ] below). See E8, H4 and the 600-cell.

Instrument. A measuring tool, such as a test panel or a checker. If an instrument is faulty, that is a fix, not a negative result about the mechanism. See what the project knows.

Integer serving. Running the finished model with whole numbers only: adds, shifts, comparisons and table look-ups. This is D11. Zero-multiply audits are green on 44 native symbol ranges and 7 of 7 WebAssembly functions (measurement), but no trained model has been served this way. See serving and export.

K

K16. The runs of 18 October that opened a shortlist of K=16 cells. Four runs finished (two training objectives, A and R, with two seeds each). None was a KEEP. The two seeds of objective A got 65 and 463 of 14,287 first guesses right (measurement). See K16 outcome.

KEEP. The verdict for a run that meets its own pre-registered mechanism target without a significant loss on the headline number. The work then iterates. It is not a final proof. See the rules.

L

Lab. Any contributor, human or AI, working under the charter. Labs so far include Claude, Codex and DeepSeek, with Kimi in the project-manager seat. Labs choose work from NOW.md and may not type an owner release. See the rules.

M

M1 to M8 (milestones). The eight GitHub milestones that define the road to an alpha release. None is complete. In plain words:

Source: language model and where we're going.

Matmul (matrix multiplication, GEMM). Multiplying a long list of numbers by a large grid of learned numbers. It is nearly all the arithmetic of a transformer, and the project bans it everywhere: training, tests, tools and serving. A geometric feed-forward block is allowed. A dense one is not. See charter, section 3.3.

Mechanism. One geometric replacement for one part of a transformer, such as the read, the loss or the optimiser. The project tracks 27, each with its own page. See the mechanism board.

Mechanism status (ACTIVE, READY, PARKED). The only three statuses a mechanism can have:

• ACTIVE: on the current model path (10 mechanisms).
• READY: built and tested but not yet trained into a model (4).
• PARKED: the tested forms failed or broke a rule, and the page lists what would reopen it (13).

There is no "retired" status, by D22. Source: mechanism board.

MLP (feed-forward layer). The block in a transformer that processes each token after attention, usually with big grids of multiplications and a gate. UOR-R4's candidates are the Hamilton gate and the SpiralCore/FBS projection; neither has been trained.

N

Nat. A unit of prediction error: the natural logarithm of how surprised the model was. Lower is better; bits per byte is a related score.

Notebook. One page per line of research, with one row per result: date, what ran, the number, the bar, the verdict and an artifact link. Notebooks plus NOW.md replaced the old running log. See research notebooks.

NOT_RUN. A record that a planned test was never executed. It is not a pass and it is not a failure. See what the project knows.

O

Orbit. A set of points that one group of moves carries into one another. The model uses a single orbit of 16 E8 roots, each a signed rearrangement of (2, 2, 0, 0, 0, 0, 0, 0). See E8, H4 and the 600-cell.

Owner. Casey Allard, the project lead. He sets the charter, the holds, the spending and the milestone bars, and personally types each run release.

Owner release. The typed phrase by which the owner personally lets one pre-registered run start. One release covers all arms and seeds of one sheet. No lab types it. See charter, section 5.1.

P

PARKED. A mechanism status. See mechanism status.

PM seat. The project-manager role: it sequences work and keeps NOW.md. Kimi holds it, with a cover lab named by the owner. See the rules.

Pre-alpha. The project's honest stage. Parts are built and tested, but 0 of 8 milestones are complete and no model holds a useful conversation. See STATUS.

Pre-registration (sheet). A one-page plan, written before a run, that states the bar, the noise, the controls, the seeds, the cost and what each outcome would decide. It is needed only before GPU training or evaluation and before any run a milestone claim rests on. See the rules.

Prime address. The exact name of a token: the (id + 1)-th prime number, so no two tokens collide. For example the 4,096th prime is 38,873. It is kept separate from the geometric address. See primes and zeta phases.

PrimeZeta codebook. The table that turns each token's prime into eight angles taken from the Riemann zeta zeros, and the angles into a starting vector. It gives all 4,096 tokens distinct vectors (measurement). The distinctness comes from a cell-balancing step, not from the angles; whether the zeta angles help at all has not been tested. See prime-zeta codebook.

Q

Q1. The first checkpoint of a full-length run, at 4,096 of its 16,404 batches; Q4 is the last. The 18 October dose with Relation was stopped at Q1 when admission collapsed. See admission.

Quaternion. A four-part number \(w + xi + yj + zk\). Multiplying by a length-1 quaternion turns a point in four dimensions without stretching it, and every such turn can be undone. Quaternions of length 1 form the 3-sphere. See quaternions and rotation.

R

Rank-margin. The project's loss: the right token must outrank its strongest rivals by a fixed margin. See hinge loss and rank-margin.

Read. The step in which the model looks back at earlier text to decide what matters for the next token: the project's bounded replacement for attention. There are three: Route, Flock and Relation.

Reach. For one test position, whether the right next token is among the candidates the model opens at all; counted over the 14,287 positions of the DEV panel. A model cannot guess a token it never opens, so a low reach caps the top-1 score, but a high reach alone is not skill (variant R of K16 reached 12,000 positions by opening almost the whole vocabulary).

READY. A mechanism status. See mechanism status.

Relation read. A Flock read plus the ability to follow simple links between positions, such as "the word right after the earlier copy of this word". This is how copying is meant to work. It has trained twice, and both runs stopped before a verdict. See Relation read.

Root. One of the fixed points of E8 used as a block value. See orbit.

Route read. An attention replacement that walks a small tree of addresses, stepping toward the nearest branch at each level, and picks up one earlier word at the end. It never scores the whole history. It is the base read of every trained discrete model, but its own contribution is unattributed. See Route read.

Rung 0. The first full-length run on the discrete path (seed 1, 16,404 updates, scored on the 14,287 development rows). Its bars were unreachable because only 1,920 targets were admitted, which pointed the work at admission. See route read.

S

Seed. The starting number of a random draw. A decisive run uses at least two seeds, so a result is not one lucky draw. See the rules.

SiLU. A smooth squashing curve used as an activation in the older decimal stack. It is built from a sigmoid, so it falls under the ban on squashing functions.

Softmax. A function that turns a list of scores into probabilities with exponentials and a sum over everything. Transformers use it inside attention and again to pick the next word. The project bans it, and every softmax-like squashing function, anywhere in the model, its training or its comparators. See charter, section 3.2.

SpiralCore. An exact-geometry source credited to Matthew. From the octonion multiplication table it yields moves that shuffle the eight coordinates and flip some signs. Each move can be undone exactly. The integer form is the core of the current model. See SpiralCore.

Studio. The single-page interface meant to be the shell of both the web and desktop clients. It is not yet connected to the new engine. See web client.

T

T2. A table built from the training text. It looks up the last word and returns the next word seen most often after it. It gets 6,300 of the 14,287 DEV first guesses right, and it is one of the two count tables a trained model must beat (measurement). See host diagnostics.

Ternary. Used in two ways here. A ternary weight or gate takes one of three values: −1, 0 or +1. A ternary tree has three branches per node. Dense ternary weights are PARKED because every weight is still touched for every word. See ternary and XOR.

Token. One numbered piece of text, a word or part of a word. The model never sees letters. See tokenizer.

Tokenizer. The component that cuts text into tokens and turns tokens back into text. The pinned one has 4,096 pieces (identity d36d3e87). See tokenizer.

Tokens/s (tokens per second). How many tokens the model reads or writes per second. It is the project's lead metric, with decode speed and context speed reported separately. It has never been measured for the current model. See charter, section 1.

Tauri. A toolkit that wraps a web page as a desktop app. The planned desktop client would use it to share the web interface.

Top-1 (and top-8). The number of DEV rows on which the model's first guess (or any of its first eight) is the right next token, out of 14,287. M1 requires the top-1 of the model, through the integer export, to beat the unigram and T2 tables. See charter, section 4.8.

Transformer. The design behind almost every modern language model. Its cost sits in three operations: matrix multiplication, attention against every earlier token, and softmax. UOR-R4 is not a transformer. See what is UOR-R4 and transformer vs geometry.

U

Unigram. A table of word counts that ignores context and always guesses by overall frequency. It gets 1,226 of the 14,287 DEV first guesses right. The best trained discrete model got 65 and 463 (measurement). See K16 outcome.

UOR. Short for Universal Object Reference, the foundation named as copyright holder in the project's MIT licence (LICENSE). A "UOR address" in this project is the prime-based name described under prime address.

UORLUT01. The container format for the finished model: one file of 4-bit codes and small integer tables, pinned by checksum. It is what the engine serves. See serving and export and releases and artifacts.

V

VSA (vector-symbolic architecture). A memory idea using long bit strings (4,096 bits per token) glued by XOR and compared by counting differing bits. It improved bits per byte by 0.014 to 0.023 on a banned CPU learner, so it is PARKED. See VSA and VSA and Hamming distance.

W

W2. The next queued test: FIT-reviewed and awaiting an owner release (cost about $0.91, estimated). It decides whether the wall is the model's representation or its learning law, and includes count-table arms the headline bars lack. See open questions.

WASM (WebAssembly). A compact, sandboxed machine code that browsers run. The integer serving engine is built for it, with 7 of 7 serving functions free of multiply, divide and float instructions (measurement). See web client.

Writer (shared vector writer). The one component that handles a token's vector on the way in, along the carry and on the way out, using the same format everywhere. It builds the cells and picks the nearest token among the admitted ones. See architecture.

Z

Z[φ]. Pairs of whole numbers (a, b) standing for a + bφ, where φ is the golden ratio. They add and multiply with no rounding, so icosian coordinates can be kept exact. See golden integers.

Zeta zero. A point where the Riemann zeta function is zero. The project uses a few fixed zeros as clock speeds: for a prime \(p\) the angle on channel \(k\) is \(\gamma_k \ln p\). It uses the numbers only and makes no claim about the Riemann hypothesis. See primes and zeta phases.

Go deeper

• FAQ: the questions newcomers ask most, answered with links.
• What is UOR-R4: the five-minute explanation.
• Mechanism board: all 27 mechanisms and their status.
• Geometry chapters: one illustrated page per geometric idea.
• docs/formal_vocabulary.md: the rules for proof, measurement and hypothesis.

The three products

UOR-R4 aims to ship one thing people can use: a small, fast language model that runs on your own laptop or in your own browser, with nothing sent to a server. The owner defined three products around it on 19 October 2026. The first is the model itself, saved as one file of whole numbers. The second is a web client that runs that file inside a browser tab. The third is a desktop client, an installable app that runs the same file natively and remembers your conversations. None of the three ships today. The project is pre-alpha: 0 of its 8 milestones are complete and no model holds a useful conversation yet (STATUS, NOW). Nothing is released until a trained model passes milestones M1 to M8.

Labels used below: proof means derived from definitions or code, measurement means a recorded run with its artifact, hypothesis means an untested idea (docs/formal_vocabulary.md, glossary).

One model file feeds two clients that share one interface. Everything inside the dashed line runs on the user's own device.

The three at a glance

A fourth page, Releases and artifacts, covers the model file format, how a release would be cut, the Hugging Face repositories and how checksums tie them together.

Why the products look like this

Local by design. The mission is "fast local AI": a model that trains fast, runs fast and approaches frontier capability on ordinary hardware (charter, section 1). The lead metric is tokens per second. A product that needs a data centre would defeat the point.

One file, many hosts. The served model obeys one contract, called D11: no decimal (floating-point) arithmetic, no multiply or divide instruction and no transcendental functions, only adds, shifts and table look-ups (D11). A file that needs nothing more exotic than integer adds can run the same way in a browser, on a laptop processor or on Apple silicon. The charter says serving this file on the user's device is the product and is allowed. The rule that research compute must run on a GPU (D24) does not apply to it (charter, section 3.6).

One interface, two shells. The Studio, a single-page interface already in the repository, is the shell for both clients. The browser runs the engine as WebAssembly. The desktop app wraps the same page and runs the engine as native code, which should be faster (a hypothesis; no side-by-side timing exists).

Where each product stands

A passing audit shows that a forbidden instruction is absent. It is not a trained capability, and it says nothing about how well a model answers.

The order things must happen in

The products depend on the model, and the model depends on milestones. Roughly:

1. M1 to M3 give a model that predicts text, answers from exact memory, and keeps memory across sessions.
2. M4 exports that model through D11 and serves it from the command line.
3. M5 measures its cost on a laptop, and M6 adds reasoning and coding on the same model.
4. M7 makes the browser worker, the command line and the Rust library produce bit-identical tokens. That is the web client's gate.
5. M8 is the alpha release: one versioned, checksum-pinned model file that meets every earlier bar.

The desktop client has no milestone of its own yet. It rides on M3 for memory, M5 for laptop cost and M7 for the shared interface. The full definitions are in the project track.

Go deeper

• Language model: what the model is and the M1 to M8 path in plain words.
• Web client and desktop client: architectures, what exists and what is missing.
• Releases and artifacts: UORLUT01, the release workflow, Hugging Face, checksums.
• Serving and export: how the integer engine computes without a multiply.
• Mechanism dossiers: integer table serving, exact object store.
• The charter, sections 2 (products) and 3.6 (serving on the user's device).

The language model

The core product is a language model: a program that reads text and predicts what comes next, and so can hold a conversation. Most language models today are transformers that do billions of decimal multiplications per word. UOR-R4 tries a different route. It predicts text with geometry (prime-number addresses, rotations in four dimensions, exact look-up memory), and it ships as one file of whole numbers that an ordinary laptop or browser can run without a single multiply instruction. That file is meant to be the one thing every client loads. It does not exist yet. No trained model has been exported in that form, training is on hold pending review, and 0 of the 8 milestones are complete (NOW). Nothing ships until a trained model passes M1 to M8.

Labels used below: proof (derived from definitions or code), measurement (a recorded run with its artifact), hypothesis (untested). See docs/formal_vocabulary.md and the glossary.

flowchart LR
  T["Train on rented GPUs<br/>(crates/uor-r4-discrete)"] --> X["Export to one integer file<br/>UORLUT01"]
  X --> A["Audit: 0 multiply,<br/>0 divide, 0 float"]
  A --> S["Serve on the device<br/>(crates/uor-r4-integer)"]
  S --> C1["Command line<br/>uor-chat"]
  S --> C2["Web client<br/>WebAssembly"]
  S --> C3["Desktop client<br/>native"]

The model's life in one line. Training happens once, offline, on a GPU. Everything after the export runs on the user's machine using whole numbers only.

What the model is meant to be

A geometric model, not a transformer. The project calls it the UOR-R4 Geometric Language Model. Technically it is an autoregressive geometric state model with exact addressed memory: it keeps a running state, updates it with each token through rotations and table look-ups, and reads facts from an exact memory by address (architecture). The charter forbids the expensive parts of a transformer outright: no softmax or other squashing functions and no dense matrix multiplication, anywhere: training, evaluation, tooling and serving (charter, sections 3.2 and 3.3).

One model for every job. Conversation with durable memory comes first, then coding and reasoning, all on the same model (charter, section 1).

Fast and local. The lead metric is tokens per second on an ordinary machine, with decode and context reported separately. A small quality gap is acceptable if the model is much cheaper to run.

How it will be delivered

The deliverable is one checksum-pinned D11 integer artifact in the UORLUT01 format, released at milestone M8 (project track, M8).

• D11 is the serving contract. Its five rules are: no floating point or maths library (R1); no multiply or divide instruction (R2); reading every weight for every token is an interim stage, not the end state (R3; the charter no longer treats dense table maps as an allowed stepping stone for new exports); no transformer backbone (R4); energy claimed only when measured (R5) (D11).
• UORLUT01 is the file format. It holds an 8-byte magic string, a JSON header, 4-bit weight codes in groups with one scale byte each, and small integer tables for the few nonlinear steps (format.rs; proof by reading the code). The reader computes the SHA-256 hash of the whole file as it loads it, so a release can pin that hash. Details are on the releases page.
• Training may use decimals; serving may not. Since 18 October, offline training may use floating point, but the shipped file is integer, and every float-trained candidate must report its export gap: its served score minus its float score on the same evaluator (D37, charter section 3.7).
• The engine is crates/uor-r4-integer. It runs the file natively (the uor-chat and uor-r4-stack command-line programs) and as WebAssembly (UOR-Foundation/uor-r4#2654). The serving page shows how it multiplies without a multiply instruction.

Status today

For scale, the M1 closing bar asks the exported model's integer top-1 to beat two simple count tables on the same panel, the unigram table (1,226 of 14,287) and the successor table (6,300 of 14,287), on two seeds (charter, section 4.8). The K16 run was graded on the model's own evaluator, not through the export, so the comparison is a rough guide only.

What about the models on Hugging Face? The four 214M-parameter checkpoints in caseyallard/uor-r4-geometric-214m are historical. They are float models trained before the softmax and matmul bans. Their measured results were TinyStories validation NLL 1.032 and FineWeb development NLL 2.90 → 2.073; the chat versions could rewrite and summarize but got code and arithmetic wrong (model card, the Hugging Face model card). They are not the D11 product.

An earlier export of a float stack missed its bar. On 10 October three 29M-parameter float models were exported and served exactly by D11, at 1.20 to 1.24 bits per byte, far from the 0.90 target. The record puts the gap in the model, not the engine (D11 serving record; measurement).

The eight milestones in plain words

Each milestone is a GitHub milestone with an issue. The bars are frozen there; the project track still shows the old M1 bar (0.90 BPB through the D11 export) and has not yet been updated, so charter section 4.8 governs. Changing any bar is the owner's decision.

Two notes. First, M4's quality bar is still written in bits per byte (≤ 0.90), while M1's was changed on 19 October to a top-1 comparison; the charter says BPB returns as a later bar once the model has a lawful likelihood (charter, section 4.8). Second, M4's audit criterion is already green, but it is a check on the engine, not on a model, so it cannot close M4 by itself (project track, M4).

Open questions

• What is the export gap of the discrete model through UORLUT01, and does the format need a new schema for table-native models rather than 4-bit dense groups? Never measured (lut-serving dossier).
• How many of the roughly 30.2M parameters read per token in the older 29M stack can addressed reads remove before tokens per second moves? This is the D5 end state, unmeasured until M5 (D5).
• The engine cannot yet serve a product-key or addressed memory read; the exporter refuses it (lut-serving dossier).

Go deeper

• Model architecture, training, serving and export.
• Releases and artifacts for the file format and checksums.
• Code: crates/uor-r4-discrete/ (the model being trained), crates/uor-r4-integer/ (the serving engine).
• NOW for this week's work; project track for the milestone definitions.

The web client

The web client is meant to be a language model that lives in a browser tab. You open a web page once, it downloads the model file, and from then on the model runs on your own computer, inside the browser, in a sandboxed form of machine code called WebAssembly. Your prompts and the model's replies never leave the device, because there is no model server to send them to. The page you would use is the Studio, an editor-and-chat interface already in the repository. Today the pieces exist separately and are not joined: the browser engine works on a synthetic test model, the Studio still points at an older engine that was retired, the public site is frozen, and there is no trained model to download. Until milestones M7 and M8 pass, the web client is a geometry explorer and demonstration, not a product.

Labels used below: proof (derived from definitions or code), measurement (a recorded run with its artifact), hypothesis (untested). See docs/formal_vocabulary.md and the glossary.

One download, then everything runs in the tab. The only network traffic is fetching the static page and the model file.

How it is meant to work

1. Load the page. The Studio is static HTML, JavaScript and CSS. The charter places it at /studio on the project's documentation site (charter, section 2).
2. Download the model once. The page fetches one UORLUT01 file and checks its SHA-256 against the hash published with the release (releases). It then keeps the file in browser storage so later visits work offline. This cache is planned, not built (from reading the repository).
3. Start the engine in a Web Worker. A worker is a background thread of the page, so typing stays smooth while the model computes. The worker loads the WebAssembly build of crates/uor-r4-integer and calls init, then loadStack on the model bytes.
4. Generate. For each token the worker calls step. The engine uses only integer adds, shifts and table look-ups (the D11 contract), so the same file gives the same tokens in every browser. That is a design property; M7 has to measure it.
5. Save and resume. saveSession writes the conversation state as a UR4SESS1 snapshot, and restoreSession brings it back byte for byte.

These function names are the real exports of the WebAssembly build: init, tickClock, loadStack, step, saveSession, restoreSession, weightsPerToken, allocEvents, leakedModels (record; proof by reading wasm_bindgen_exports.rs).

Why serving in the browser is allowed. Research compute must run on a GPU (D24). On 15 October that rule paused the browser engine, because serving in a browser runs on the user's processor (D36). The owner resolved this on 19 October: serving the exported D11 file on client devices, including browser WebAssembly, is the product, and D24 does not apply to it (charter, section 3.6).

What exists today

Three limits from the engine's own record matter for a reader. The WebAssembly SIMD kernels are test fixtures that nothing calls yet; the engine still runs its scalar table kernel. The demo needs a local build first. And the serving-wasm build compiles some modules unconditionally, so its compliance with the "presence counts" rule (D29) rests on an interpretation that DECISIONS.md does not record (record, maintainer annotation).

What is missing

The M7 bar sums it up: the qualified model "produces bit-identical token completions and session snapshots across the Rust library, the uor-chat CLI and the browser serving-wasm worker", and the Studio "runs entirely client-side in a Web Worker with truthful capability reporting and zero remote model calls" (project track, M7). The .wasm audit criterion is green and will be re-run on the shipped bundle; the rest of M7 (rewiring the Studio, three-host parity, client-side Studio) is open.

Until then: an explorer, honestly labelled

Until M7 and M8 pass, the web page should present itself as what it is: a geometry explorer and a demonstration of the serving engine on a synthetic model. It must not offer a chat box that implies a working assistant. The Studio's engine-status banner already says so. Showing the engine's real exports (weightsPerToken, allocEvents) on a synthetic model is fair. Showing chat replies is not, until there is a trained model behind them.

Privacy model

• The model computes only on the device. No prompt or reply is sent anywhere by the engine. That is the M7 bar, and today it holds trivially, because there is no remote model to call.
• Network use is not yet limited to static files. The target is the page and the model file only. Today the Studio also loads third-party code and fonts from CDNs (Monaco, pdf.js and three.js from cdnjs; marked, KaTeX and the three.js controls from jsDelivr; fonts from Google Fonts), and its search feature sends the typed query to en.wikipedia.org and api.duckduckgo.com. Features that open files from GitHub talk to GitHub. None of that is model compute, but a privacy claim must not hide it: the requirement is to self-host every asset and make web search opt-in, or remove it, before M7 (index.html, lines 11 to 25 and 5845 to 5906).
• Integrity, not secrecy, of the model file. The SHA-256 check proves the file is the released one. The model is public, so there is nothing to hide in it.

Open questions

• How large will the model file be, and is a one-time download of that size acceptable on a phone? Unknown until a model exists.
• How fast is WebAssembly against native on the same file? No tokens-per-second figure for the browser has been recorded. The only native figures are from older float models: 68 to 80 tokens per second on 8 threads for a 29M model, which is evaluation throughput over 64 scored windows, not free-running decode (D11 serving record). No decode tokens per second exists for any D11 artifact.
• Should the Studio's provenance be settled first? Its source is an import from a companion repository, Casey-allard/uor-r4-wasm-chat, which this audit did not inspect.

Go deeper

• Desktop client, which shares this interface.
• Serving and export and the integer serving dossier.
• The WebAssembly runtime record (UOR-Foundation/uor-r4#2654, tracking issue #1172).
• D36 and the charter, section 3.6.

The desktop client (specification)

The desktop client is a planned app you install on your laptop. It shows the same interface as the web client, but it runs the model as native code rather than inside a browser, which should make it faster. It can open your project folders, it remembers your conversations between sessions in a durable local store, and it works with no internet connection. The target machine is an M1-class laptop. This page is a specification, not a description of working software. No desktop app project exists in the repository yet, and there is no trained model for it to run. The owner asked for a spec only in this round (decision 8, 19 October 2026). Nothing ships until a trained model passes milestones M1 to M8.

Labels used below: proof (derived from definitions or code), measurement (a recorded run with its artifact), hypothesis (untested). Words in this spec such as must are requirements, not claims about existing code. See the glossary.

Same interface as the web client; the engine, the memory and the file access run as native Rust inside the app. Only an optional update check uses the network.

Goals and non-goals

Goals.

1. Run the released UORLUT01 model natively, under the D11 integer contract, on an M1-class laptop.
2. Share the web client's interface, so there is one interface to maintain.
3. Give the model access to the user's chosen project folders, for coding help.
4. Keep durable conversation memory on disk (the D19 line), so a conversation can be closed and resumed exactly.
5. Work fully offline after install.

Non-goals. No cloud model, no account, no telemetry, no server component, and no second model format. Training and evaluation stay on GPUs (charter, section 3.5).

Architecture

The app is built with Tauri: a small native shell that shows a web page in the system's own webview and runs a Rust backend beside it. The page calls the backend through named commands. Rust is the project's default language (charter, section 3.11), so the backend can link the project's crates directly.

Sources: reading index.html and the repository tree, and the object-store dossier.

Data flow

1. Install. The installer carries the app and, optionally, the model file. If the model is not bundled, the first run downloads it once (update and download).
2. Load. The model manager reads the file, checks its SHA-256 against the release pin, and passes the bytes to the engine. The UORLUT01 reader checks every offset and length and returns an error rather than crashing on a malformed file (format.rs; proof by reading the code).
3. Chat. The interface sends the user's text to a Rust command. The engine steps token by token with integer adds, shifts and table look-ups and streams tokens back to the page.
4. Remember. At the end of a turn, the app saves the session state as a UR4SESS1 snapshot and stores conversation bytes in the object store. The store cuts bytes into 32-byte pieces arranged in a hashed three-way tree, so repeated content is stored once and any byte range can be read back and checked (object-store dossier). Storing session snapshots in the store is a design note, not yet done.
5. Resume. On reopening, the app restores the snapshot, and the conversation continues token for token. That is the M3 restore bar (project track, M3).
6. Work on files. When the user asks about code, the app reads files only from granted folders and passes their text to the model as context.

Why native, and how fast

The browser runs the engine as WebAssembly in one worker. A native build can use the processor's vector units (NEON on Apple silicon) and several threads. The project already has native table kernels for NEON and AVX2, though they belong to an older, frozen engine (crates/uor-r4-simd). That native will be faster is a hypothesis. Nobody has timed WebAssembly against native on the same file. No decode speed exists for any D11 artifact. The only native D11 speeds on record are from older float models served exactly by the integer engine: 68 to 80 tokens per second on 8 threads for a 29M model, which is evaluation throughput over 64 scored windows rather than decode (D11 serving record), and 184.58 tokens per second on one thread for input-driven forward passes, which is not free-running generation either (lut-serving dossier). M5 is the milestone that measures laptop cost: ms per token, peak memory, mJ per token and weights read per token (project track, M5).

Serving on the user's laptop is allowed. The charter says serving the exported D11 file on client devices, including Apple silicon, is the product, and D24's GPU-only rule does not apply (charter, section 3.6).

Durable memory (D19)

D19 makes grounded conversation and durable memory the first priority (D19). The object store was split out as its own crate for this purpose on 14 October (D34). What it has shown, all on test data (measurement):

• 60 tests pass, and a pure-Python client pulled a 256 KiB object byte-identically from the Rust server (conformance record).
• A 23-byte read of a 32,768-byte object touched 8 authenticated nodes, 384 bytes (object-store dossier).
• Repeated content compresses well (7,776 bytes stored in 380), but unique content expands about 2.17 times (32,768 bytes become 70,972) (D19 store record).

Never tested: any model reading from the store, the M3 memory bars on a real model, and storage cost on real chat logs (object-store dossier). The store keeps exact identity (what was said, where, in which version) separate from any geometric address, as the charter requires (section 3.12).

Security model: local only

Update and model download

• Model files are versioned releases. Each is one UORLUT01 file with a published SHA-256 (releases). The app never runs an unpinned file.
• First download. Fetch the file once, verify the hash, store it locally. After that the app needs no network.
• App updates. Use Tauri's signed updater, or manual install. Signing keys and the hosting choice are open questions.
• Delta updates for models (hypothesis). The object store can send only the pieces that changed. In one test a receiver holding a slightly older 1 MiB object fetched 22 records, 1,014 bytes, in 3 rounds. But a cold pull of unique content through the store is far larger than a compressed download (5,725,408 bytes against 39,920 for a 2 MiB artifact), so the supported recipe is a compressed download first, then deltas (object-store dossier). Whether deltas help for real model files is untested.

Milestones it depends on

Open questions

1. Superseding the old plan. archive/integration/frontend-port-plan.md (historical, 4 September) says Tauri should not be the main client. The owner's 19 October decision replaces it, and that file needs a supersession note.
2. Sharing one interface. The Studio is one 7,107-line HTML file with inline scripts. Does it need to be split into modules before two shells can share it cleanly?
3. The terminal command. Keep it (with consent and folder limits) or drop it from the first release?
4. Where memory meets the model. Which comes first: storing session snapshots in the object store, or exact quotations from the store feeding the model's output? This is the object store's open path to ACTIVE status (object-store dossier).
5. Threads and D11. The five D11 rules say nothing about threads. Whatever kernels the app ships, threaded or vectorized, must still pass the zero-multiply audit.
6. Engine format. The legacy Studio also calls native_list_local_models, written for an older model format. The model manager must accept only UORLUT01.

Go deeper

• Web client, which shares the interface; products overview.
• Exact object store dossier and its protocol.
• Serving and export; integer serving dossier.
• Charter, sections 2 and 3.6.

Releases and artifacts

A release is how a finished model reaches people: a numbered version, a file you can download, and a fingerprint (a checksum) that proves the file is exactly the one that was tested. For UOR-R4 the file is meant to be one integer-only model file in a format called UORLUT01, released at milestone M8. That release does not exist. Two old software releases are on GitHub from the summer, plus one pinned-corpus data release, but both software releases belong to an earlier engine and neither is a qualified model. The release automation still targets that older engine too. This page explains the file format, the release machinery as it is, the Hugging Face repositories, and how checksums bind them together. Nothing ships until a trained model passes M1 to M8.

Labels used below: proof (derived from definitions or code), measurement (a recorded run with its artifact), hypothesis (untested). See the glossary.

flowchart LR
  P["Trained model<br/>(GPU, offline)"] --> E["Export to UORLUT01<br/>+ export gap"]
  E --> H["SHA-256 of the file"]
  H --> R["Versioned release<br/>vX.Y, notes bind scores"]
  R --> W["Web client<br/>verifies, caches"]
  R --> D["Desktop client<br/>verifies, stores"]
  R --> C["uor-chat CLI"]
  S[("Private HF store<br/>MD5SUMS / SHA256SUMS")] -.inputs and results.-> P

The planned path from a trained model to the clients. Every hop carries a checksum. The release box exists only as a plan for this model; the old pipeline served a different engine.

The model file: UORLUT01

UORLUT01 is the container the integer engine reads. Its layout, from the reader format.rs (proof by reading the code):

• The 8-byte magic string UORLUT01, then the header length as a little-endian 64-bit integer.
• A JSON header with the schema name, the model's shape, the group size, numeric settings, a list of matrices and tables, the exporter's provenance (never read by the serving arithmetic), and an optional record of a trained-in rotation snap, with the SHA-256 of its root set.
• Zero padding to a 64-byte boundary, then the data sections at 64-byte-aligned offsets.
• Each weight matrix stored as 4-bit codes, two per byte, with one scale byte per row and group. The scale byte holds a 4-bit mantissa \(m\) and a 4-bit exponent step \(d_e\), meaning a group scale of \((16+m)\,2^{\,e_{\text{base}}+d_e-4}\).
• Small integer tables (16-bit or 32-bit) for the few nonlinear steps.

Three schemas exist: lut-stack/1 (a softmax attention read), /2 (adds a pointer head) and /3 (a softmax-free flock rank read). The first two serve exp-table softmax reads, which the no-squashing rule bans. No schema fits today's rules as it stands: all three also carry SiLU and GELU tables and stream dense 4-bit weight maps through a table-based product, which the charter excludes, so a new table-native schema is likely needed (lut-serving dossier).

A built-in fingerprint. When the reader parses a file, it computes the SHA-256 of all its bytes and keeps it with the parsed model (format.rs, line 557). A release can therefore pin that hash, and a client can refuse any file that does not match.

Safe loading. Every offset, length and product of sizes is checked, so a malformed file returns an error rather than crashing. A file that declares a product-key memory is refused outright, because the integer kernel for it is not built (format.rs).

Saved sessions use a separate format, UR4SESS1, which records a conversation's state so it can be restored byte for byte (session_codec.rs).

The release pipeline as it is

Source: reading release.yml and the repository tree. This audit did not confirm that a tag build passes today.

The two software releases on GitHub are historical. v0.1 (19 August 2026) attached r4 binaries, a WebAssembly frontend and a model bundle compiled from a pinned SmolLM2-360M-Instruct snapshot, a converted transformer that the current serving rules exclude. v0.1.0-alpha (8 September 2026) is marked a pre-release: its notes say the alpha qualification was withdrawn after a recovery audit found the claims unsupported, and it is kept only for historical reproducibility. Neither is a release of the geometric model. A third GitHub release, "D3 pinned corpus: simple-wiki-20231101-sample" (29 July 2026), is a data release, not a model (release pages on UOR-Foundation/uor-r4, read 19 October 2026).

The owner has decided to repair the legacy crates, not archive them. The root crate and four others are to be repaired so that they build on the current core. Repairing restores the build only; their old mechanisms stay parked (charter, section 2.4). A repaired build would let release.yml run again, but it would still package the wrong format until it is changed.

What an M8 release must contain

The M8 bar is "one versioned, checksum-pinned UORLUT01 artifact" that meets the frozen bars of M1 to M7, with "reproducible installation, release notes binding the exact measured scores and known limitations, and independent verification on consumer hardware" (project track, M8; issue #2036). Read as a checklist, it is a plan, not existing work:

1. The model file with its SHA-256, plus the tokenizer it was trained with.
2. Release notes that bind the code SHA, the file hash, the tokenizer, the training data and seed, every measured score with its panel, the export gap, and the known limits. The charter requires every artifact to bind its data, seed, configuration, parameters and format (section 3.12).
3. Binaries: uor-chat for each platform and the WebAssembly bundle, each with a .sha256, and each re-passing the zero-multiply audit (native 44 symbol ranges, WebAssembly 7 of 7 at last count; project track, M4).
4. The Studio, published to /studio on the documentation site (charter, section 2).
5. Independent verification on consumer hardware.

Missing today: a release workflow for UORLUT01, WebAssembly and desktop packaging of the integer engine in that workflow, and one inference contract. Two contracts still coexist: docs/inference_contract.md for the older R4G1 runtime, and D11 rules R1 to R5 for the product (D11).

Hugging Face repositories

Both public repositories were published on 9 October 2026. Sources: the two Hugging Face repository pages; compute guide. The public model repository's visibility is inferred from the listing, which showed no private flag.

How checksums tie it together

A checksum proves integrity: the bytes are the ones that were pinned. It does not prove who made them, and it says nothing about model quality.

Go deeper

• Language model for the M1 to M8 path; products overview.
• Serving and export for the engine and the export gap.
• Integer serving dossier.
• Compute guide for the private store and uor-store.
• Charter, sections 2, 3.6 and 3.12.

The model, end to end

UOR-R4 turns text into a short list of whole numbers per word, looks back at a few earlier words by walking a small tree of addresses, and picks the stored word nearest to what it found. It never turns scores into probabilities and never multiplies large grids of numbers. This page follows one piece of text through that whole chain and marks each stage as built, trained, or missing. The honest summary is short. Most stages exist and pass small fixed tests. None of them has learned language yet: the best trained model so far is worse than a plain table of word counts (K16 outcome). The project is pre-alpha, and 0 of its 8 milestones are complete (STATUS.md).

The current pipeline. Solid boxes exist in crates/uor-r4-discrete. Dashed boxes are slots a transformer fills that this model has not filled.

How to read the status labels

• Built means the source exists and passes its finite construction controls. These are small, fixed GPU tests that show the code does what it says. A control is not a language result.
• Trained in means the stage took part in at least one learning run with a recorded result. It does not mean the run helped.
• Missing means no code exists, or no mechanism has been assigned.

Labels follow docs/formal_vocabulary.md. Proof means derived from definitions or code. Measurement means a recorded run. Hypothesis means an untested idea. NOT_RUN is never a pass.

One piece of text, stage by stage

The current model lives in crates/uor-r4-discrete. The code-level map is docs/architecture.md.

1. Tokenizer (built; fixed before training). Text is cut into numbered pieces by a byte-level BPE tokenizer with 4,096 pieces, identity d36d3e87. Every corpus, test panel and trained artifact is pinned to it (tokenizer). A 16,384-piece trainer exists as tooling only, and no model has used it.

2. Token table (built; trained in). Each of the \(V=4096\) tokens owns \(B=4\) blocks of 8 whole numbers, so its vector has width 32. Each block is always one of 16 roots from a single orbit of the E8 lattice; each root is a signed rearrangement of \((2,2,0,0,0,0,0,0)\). The model does not use all 240 E8 roots. The same table encodes a token as input, carries it as memory, and ranks it as output; that is the shared vector writer. Exact token identity is kept separately from this geometric address.

There are three ways to fill the table at the start, and they matter a great deal:

An injective code is possible in principle, because \(16^4=65{,}536\ge 4{,}096\) (proof, from the block and root counts). See prime-zeta-codebook and address-cells.

3. Ordered context (built; not learned). The most recent tokens form a window of at most 243 positions (\(3^5\)). Recorded runs used 192. A ternary tree built by SpiralCore, the project's exact-arithmetic geometry library, puts those positions at its leaves in order (spiralcore-fbs). Which position a read lands on is decided by address, not by a score over all positions.

4. Reads (built; trained in, but no read's own value is isolated). A read turns the window into one integer vector \(q\) of width 32. There are three, each a hard selection with no softmax:

• Route walks the tree, one nearest port per level, and returns one earlier position's vector rotated along the path.
• Flock keeps a few nearest earlier positions, rotates each into the current frame, sums them and snaps to a root. It was trained only inside the Relation runs.
• Relation is Flock plus a rerank along link types such as "the word after the earlier copy". It has trained twice, and both runs stopped before a verdict.

Route is the base read of every trained artifact, yet it received only 20 learning proposals in 16,404 updates (attention state). Nobody has switched a read off to see what it adds.

5. Shared writer and admission (built; trained in). The writer gives each token a cell from the root numbers of its first and last block: \(c(t)=(\rho_{\text{first}}(t),\rho_{\text{last}}(t))\), so there are \(16\times16=256\) cells. It opens the \(K\) occupied cells nearest to \(q\) by L1 distance (8 in the lineage of record, at most 16), then picks the nearest token inside them. Ties go to the lowest id. No probabilities are formed. This shortlist is admission.

Proof. A target outside the opened cells can never be chosen, whatever the read did. So admission caps everything upstream. Rung 0's top-1 bar was 1,941 rows, but only 1,920 targets were admitted at the end, so the bar was unreachable (Stage A sweep).

6. Loss (built; trained in). The score is an integer rank-margin hinge: the right token must beat its strongest rival by a fixed gap, and the loss is the shortfall. It has no likelihood, so it yields no bits per byte.

7. Discrete learning (built; trained in). One table entry is tried in all 16 legal states on the GPU, and the best is kept only if it strictly lowers the loss. See training.

8. Export (missing for any trained model). The learned table is already integers, so there is no float to round. But no exporter turns a trained snapshot into a D11 artifact, and no export gap has been measured. The existing table engine's schemas /1 and /2 serve softmax through exponent tables, and all three schemas stream dense 4-bit maps with SiLU and GELU tables, so a new table-native schema is likely needed (audit reading, lut-serving dossier; hypothesis).

9. Serving (engine built; never used for this model). The D11 engine runs integer artifacts with no multiply instruction. Its audits pass: 44 native symbol ranges (project track, M4) and 7 of 7 WebAssembly serving functions (WASM runtime record) are free of multiplies. It has served only older models, which missed the milestone bar (the 19.9M-parameter stack reached 0.933 bits per byte against 0.90, "NOT MET by 0.033"). Tokens per second for the discrete model has never been measured (lut-serving).

The missing slots

A transformer has parts this model does not. The board lists them as gaps, and no record fills them:

Two further things are also not built: using an address as the read (memory by exact name), and a writer cheaper than a scan of the whole vocabulary. The writer's own count is about 5×10⁶ vocabulary-cell comparisons per row (chief architect's review, docs/labs/course-correction-2026-10-18/audits/d37-reactivation-architect.md §3.5), which breaks the per-token sparsity rule D5-b at larger sizes. A bounded \(K\) limits the shortlist, not the work to build it.

Where it stands

The measured result. On the 14,287-row development panel, a count of the most common next token scores 1,226 top-1 hits and a context-free successor table scores 6,300 (host diagnostics). The best trained discrete model scored 65 and 463 on its two seeds, with admission of 2,237 and 3,167, and both fail the admission gate (measurement, K16 outcome). The cause is not established. A census showed that training had broken much of the early aliasing, yet top-1 stayed low, so ranking capacity, the read and the schedule all remain open, as does the address key (the architect review, section 3.2, shows it takes only five values).

Proof (address key). The address distance uses only the first and last block, and after snapping each endpoint distance takes one of three values, so the sum takes at most five values: 0, 4, 8, 12 or 16. That key must order up to 256 cells, so which cells sit just inside \(K\) is largely decided by the arbitrary cell number (chief architect §3.2, read from discrete.cu).

Go deeper

• Training: how the model learns.
• Mechanism pages: discrete-learning, admission, the mechanism board.
• Code: discrete.cu holds the reads, the writer and the learning kernels. metadata.rs builds the context plans. device.rs is the GPU boundary.
• Audit: the renormalization audit record, which holds the stitching map and the code inventory.
• Terms: glossary.

How the model learns

Most language models learn by working out a smooth slope for every number inside them and nudging all the numbers a little. This model does not. It takes one entry of its table, tries every legal turn that entry can make, counts the mistakes after each turn using whole numbers, and keeps the best turn only if it beats leaving the entry alone. The method is exact, cheap per step and runs on the GPU. So far it has moved some counts but has not produced better language, and every new training run needs the owner's personal release.

One batch of discrete learning: score every legal move on 64 rows, choose the lowest integer loss, commit only a strict gain, then verify the stored result.

Labels follow docs/formal_vocabulary.md: proof is derived from definitions or code, measurement is a recorded run, hypothesis is untested. The mechanism page, discrete-learning, is the short form of this page and carries the full run history.

How it works

What is learned. The model holds three kinds of coordinate. A vector block is one of the four 8-number blocks of one token's vector. A route frame is one of 64 signed-axis rotations of 8-dimensional space, one per routing stage. A gate is a switch that takes the values \(-1\), \(0\) or \(+1\). A vector block is always one of 16 roots of an E8 orbit, so it has 16 legal states, counting "stay as it is" (architecture).

The learning step (definition). Training visits one coordinate \(\theta\) per batch. A batch is 64 rows of training text, and which rows can count is fixed by the baseline. For each candidate move \(m\) among the identity and 15 rotations, the machine replays the read and the writer and adds up the integer rank-margin loss:

\[L(m)=\sum_{x\in\mathcal R}\ell\big(x;\ \theta\leftarrow m\big),\qquad m\in\{\mathrm{id},m_1,\dots,m_{15}\}.\]

It chooses \(m^*=\arg\min_m L(m)\). Ties go to the identity, then to the lowest resulting port number, then to the lowest move index. It applies \(m^*\) only if \(L(m^*)<L(\mathrm{id})\), and then re-checks the stored table on the GPU. Nothing is sampled, and no floating-point number appears in the step.

Consequence (proof, from the definition). Every committed move strictly lowers the loss on its own batch, and the new state is always a legal state. The rule says nothing about rows outside the batch. A move that helps its 64 rows can push other targets out of the shortlist, and that is the failure behind the early stops in the table below.

Coverage (proof, by arithmetic). One pass is 16,404 batches of 64 rows, which is 1,049,856 target rows. The training split has 2,425,925 targets, so one pass sees 43.3% of them. Each coordinate is visited about once per pass, with about 64 rows of evidence (chief architect's review §3.4).

The GPU kernels

All model compute is GPU-only; a host fallback is a defect to fix (charter §3.5). The kernels live in discrete.cu and its generated siblings. The build checks the emitted GPU code and rejects any floating-point type, tensor-core instruction or approximate exponent (crates/uor-r4-discrete/build.rs, PTX admission audit).

1. Ordinary counterfactual. One block of 16 threads, one thread per move. Each thread walks every row in turn and recomputes the baseline. A route proposal took 3.903 s against 37.8 ms for a plain forward pass, which projected to about 17.8 hours for one 16,404-batch pass (measurement and projection, unverified, driver cost). A later diagnostic put this kernel at 99.99% of a proposal (sub-phase diagnostic).
2. Row-parallel counterfactual (rows_v1). It computes the baseline once per row and each virtual move once per (row, lane), then a reducer replays the ordinary loop over those records in row order. So 64 rows by 16 lanes run as 1,024 threads. It is opt-in, and it matched the ordinary kernel's losses on every finite case checked (72, 108 and 288 cases in the three tables of the rows parity record; 1,085 in all across the attempt files, per the documentation reconciliation).
3. Speed (measurement). At vocabulary 4096, 4 blocks, context 192, \(K=8\), 64 rows, on one RTX 5090, the median of five proposals:

This is the "56 times" figure. The timing is non-gating and was not qualified (qualified=false). The A8 control arm later completed 16,404 batches in 1,967 s, or 0.12 s per batch (A8 dose). It used a different read, so treat that as a rough size of the gain.

BVG-K: several coordinates per launch

BVG-K means batched verified coordinates, with \(K\) the batch size. One row-parallel launch occupies at most 8 of an RTX 5090's 170 multiprocessors, so the card sits mostly idle. BVG-K scores \(K\) coordinates in one launch (1 to 64 are supported), chooses the best move for each, and commits the whole block only if its joint loss beats the best single move.

• Scoring (measurement, quoted). About 16 times faster at \(K=16\) than scoring one coordinate at a time, from the first qualifier (BVG-K scoring).
• Block apply (measurement, on fixtures). 259 ms at \(K=16\) with joint verification, about 8 times faster than 16 single proposals at roughly 130 ms each (qualifier).
• As a learning law, never run. BVG-K has passed construction tests only. It is the matched discrete competitor that any float method must beat.

Float training, offline only (D37)

On 18 October the owner revised the discrete-only rule: floating point is legal in offline training. A float forward pass, gradients and an optimizer may be used. Three things still hold (D37):

• The bans on expensive operations stand. No softmax or other squashing function, no dense matrix multiplication, GPU only, and the path must stay geometric.
• Float lives in a separate module. It gets its own scanned entry, added with its pre-registration. It never goes in the discrete crate or in crates/uor-r4-training.
• The integer artifact is the boundary. Every float candidate reports its export gap, the loss in quality when its weights become the integer file. A gap above the two-seed noise band disqualifies it, and a float score alone qualifies nothing (D39 item 5).

No float sheet is registered. The order set in D39 item 4 is the read-code capacity capture (W2), then BVG-K (W3), then a single float-credit sheet only if W2 points at the learning law and W3 fails. The chief architect expects the export gap to be structurally non-zero, because the table entries are exact roots with no continuous scale (hypothesis, docs/labs/course-correction-2026-10-18/audits/d37-reactivation-architect.md §3.3).

Holds and pre-registration

Training is held. The global training hold, the M2 hold and Stage B all stay in force, and a review that finds a plan fit releases nothing (charter §5.1; D37 item 6).

• Pre-registration. Before any GPU training or evaluation, and before any run a milestone claim rests on, a one-page sheet states the bar, the noise, the controls, the seeds, the cost and what each outcome decides. A non-author reviews it for TEST FITNESS: FIT. A fresh-context subagent counts as non-author. Builds, finite kernel tests and host checks need no sheet.
• Release. One typed owner release per sheet covers all its arms, seeds and stop rules. Casey types it personally with UOR_LAB unset. A lab stages the commands and verifies the records, and never types one itself (D40).
• Compute. Pods go through scripts/pod/uor-pod: at most 4 pods and $8 an hour across all labs. A healthy run is never cancelled for a self-set budget.
• Bar. The M1 closing bar is integer top-1 through the D11 export, on each of two seeds, beating the unigram table (1,226 of 14,287) and the successor table (6,300 of 14,287) on the same panel, with tokens per second reported (charter §4.8). The earlier 0.90 bits-per-byte bar was replaced for M1, since the hinge gives no likelihood.

Where it stands

No training run on this path has produced a KEEP. The table below lists six campaigns since 13 October: the pilot, the Stage A sweep, the Q1 diagnosis, the four K16 runs, the A8 dose and the controller run.

What the runs say. Only 0.8% to 2.5% of batches in the K16 runs were accepted (407, 130, 410 and 129 of 16,404), against 14.4% in the pilot. A negative closes a configuration, not the mechanism (D22). The next decisive step, W2, is already reviewed fit and queued. It separates a representation wall from a learning-law wall (renormalization audit record).

Never tested. Route-frame and gate learning at dose; a full corpus pass; BVG-K or the admission-preserving rule as a GPU training run; all 240 E8 roots; any generated text or tokens per second from a trained discrete model; fresh-slice transfer (sealed); any float credit sheet.

Go deeper

• Pipeline: the model, end to end.
• Mechanism pages: discrete-learning, rank-margin, admission, legal-construction (the older float attempt at the same goal).
• Code: device.rs, training.rs, rows_source.rs, bvgk_source.rs.
• Audit: the renormalization audit record and the discrete-learning mechanism page.

Data and tokenizer

The model never sees letters or words. It sees a stream of numbered pieces of text, and a small program called a tokenizer cuts text into those pieces and turns them back into text. The project's data is chat-shaped text, prepared into files of piece numbers with one fixed tokenizer of 4,096 pieces. Every prepared file carries a fingerprint of that tokenizer, so a result can never be quietly compared across two different ways of cutting text. The data is small: the training set for the current model path is about 7.5 million tokens. A larger corpus, written once by an open donor model under a narrow owner exception, is planned but has not been generated.

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea. See docs/formal_vocabulary.md and the glossary.

Bytes become pieces by repeated merging, and the tokenizer's fingerprint travels with every prepared file. A two-digit number is still two pieces.

flowchart LR
  T["text: chat and memory dialogues"] --> P["Rust corpus preparation"]
  TOK["tokenizer d36d3e87, 4,096 pieces"] --> P
  D["distill-d1: planned, one-time, not generated"] -.-> P
  P --> U["UORT v1 file: header, 16-bit ids, response mask"]
  U --> C{"driver checks file hash, token count, tokenizer"}
  C -->|all match| TR["training and evaluation on the GPU"]
  C -->|any mismatch| X["refuse to read"]

From text to a model run. The dotted arrow is a plan, not a file that exists.

The tokenizer

What it is (definition). A byte-level byte-pair-encoding (BPE) tokenizer. It starts from the 256 possible bytes, so any text can be encoded. It then learns the most frequent adjacent pairs and glues them into bigger pieces. This is a standard technique and is not novel here.

Layout of the pinned tokenizer. Pieces 0, 1 and 2 are start, end and unknown. Pieces 3 to 258 are the 256 single bytes. The rest are learned merges:

\[3+256+3837=4096 .\]

Training (definition). Count each adjacent pair over the unique pieces of text in the corpus (pre-tokens), weighted by how often each occurs. Merge the pair with the highest count into a new piece and recount only the words that contain it. Repeat until the vocabulary is full. Ties go to the pair whose left, then right, piece string sorts first, so the result is the same every time. Special tokens are atomic, and no merge crosses a special token, a pre-token boundary or an input file. Encoding then applies the merges in rank order: a table look-up with no learned arithmetic (training.rs, lib.rs).

Identity. The tokenizer crate computes a blake3 content address of the raw tokenizer.json bytes, and the discrete driver pins each file by SHA-256. The pinned tokenizer is written d36d3e87…; its full 64-hex SHA-256 is listed in the donor-corpus sheet. A different tokenizer is therefore a different corpus.

The 16,384-piece trainer. On 19 October a Rust command, train-bpe, landed for building a tokenizer of any size from 259 to 65,536 pieces (train-bpe.rs, record). It is deterministic, refuses to overwrite a file, and by default accepts 64 MiB of input. Checks compared its merge ranks and its segmentation with an independent exhaustive recount over 40 small test corpora, and a synthetic 8,192-document fixture reached exactly 16,384 pieces. Measurement, of the tool only. It changes no active file. No tokenizer has been swapped, and no model has been trained or scored on any tokenizer other than d36d3e87. Whether 16,384 pieces help the model is a hypothesis.

Numbers are split. The vocabulary has no multi-digit piece, so 84 is the pieces 8 and 4. In an older chat model's 9 October acceptance run, memory rows with a distractor and a number as the stored value passed 1 of 11, against 9 of 23 with a word as the value. A diagnosis found no multi-digit token, and that the right value was not emitted rather than confused with a distractor. An untrained probe showed the project's number codec already stores two-digit values in order, so storage is not the cause; the failure sits in the learned read and write path. Both are measurements, on an older float model (diagnosis, probe). Whether digit-split numbers still hurt once the discrete read can address an exact value is open.

The prepared files

Format (definition). A prepared corpus (UORT v1) is a 64-byte header followed by 16-bit piece numbers, with start-of-document markers and an optional one-byte-per-token response mask. The mask marks the reply tokens, the only ones scored as targets. Context resets at each start marker. Before reading, the discrete driver checks each file's SHA-256, the token count and the tokenizer file (corpus.rs). A DialogueProtocol object fixes how roles and turns are written out, so training, test panels and chat all use identical token segments (dialogue.rs).

Preparation is host-side Rust bookkeeping, not model compute (prepare-knowledge-corpus.rs, prepare-chat-parquet.rs, mix-chat-corpus.rs).

The corpora

"Historical" means trained before the no-softmax and no-matrix-multiplication rules (D23 to D25), in the float form. Source: the Hugging Face dataset card and the sheets above. The training data never includes the frozen test-panel rows.

Data against size (measurement, older float stack). With the model size held at 7,155,396 parameters, changing only the training data from a mixed set to chat-only lowered the held-out score from 1.1199 to 0.9607 bits per byte, a gain of 0.1592. Growing the model from 7.16M to 19.93M parameters at matched data gained 0.0837 more. Both come from one seed, one corpus and one held-out stream, and the record says a claim finer than about 0.01 bits per byte needs a clustered protocol (#1894). This is the reason the project keeps asking for data first, but it is not a result on the current model.

Where the files live

distill-d1: one planned donor corpus

What was decided. On 19 October the owner ratified a one-time exception (D41). One open-weight donor, openai/gpt-oss-120b, may run once, offline, on one declared rented GPU, to write one corpus named distill-d1 (D41, record). The exception covers generation only and expires when the corpus is sealed.

What stays fixed. The donor never runs in student preparation, training, evaluation, serving, grading or any panel. The student reads donor-chosen tokens as hard targets only, with no probabilities or logits. A generation receipt (donor revision, weight hashes, prompt-set hash, seeds, sampling settings, pod identity, per-shard SHA-256 and a Merkle root) is bound at generation and read back. The corpus is an input to experiments, not evidence of capability.

The registered plan (sheet, status TEST FITNESS: FIT, no compute run, $0 so far). The target is 30,000,000 student tokens, with a floor of 20 million and a ceiling of 50 million. Each document is at most 200 tokens. The mixture is conversation 35%, question answering 20%, short code 20%, short reasoning prose 15% and general prose 10%. A pilot of about 1 million tokens (about $2) comes first, and production at 30 million tokens is projected at about $52, or $63 with retries. These costs are planning estimates, not invoices. The sheet sizes the corpus to what the student can consume, about 490 target tokens per second, or roughly 17 hours per pass at 30 million tokens.

What it needs before it runs. The owner must type the release personally at dispatch time (D40), and the driver-speed work must finish first. A matched-control training sheet would be needed to learn whether distillation helps at all.

Where it stands

No model holds a useful conversation yet, and 0 of 8 milestones are complete (project track).

Go deeper

• Mechanism pages: tokenizer, prime-zeta codebook (assigns each piece an address), address cells (sized by the vocabulary), discrete learning.
• Code: uor-r4-tokenizer, corpus.rs, prepare-knowledge-corpus.rs.
• Records: numeric plan, consumer verifier for distill-d1, dialogue protocol contract.
• Next pages: serving and export, GPU and CUDA. Model pages: architecture, training.

Serving and export

A finished model has to leave the lab and run on an ordinary laptop or in a web browser. The project's rule is that the file it ships contains only whole numbers, and that the program running it uses only adds, shifts and table look-ups: no decimal (floating-point) arithmetic and no multiply instruction. The program that does this exists, and a checker has counted its machine instructions. But it has only ever run older models that fell short of their targets, plus a synthetic stand-in. No model built under today's rules has been exported to it yet, so nobody can chat with the project's model on a laptop today.

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea. See docs/formal_vocabulary.md and the glossary.

Training may use decimals; serving may not. The snap from one to the other is where quality can be lost, and that loss is the export gap.

Two halves with one hard border

Offline half. Training runs on rented GPUs and may use floating point. The owner's rule (D37, 18 October) allows float forward passes, gradients and optimizers offline, with two limits that stay: no matrix multiplication and no squashing functions such as softmax (D37). The project's active learning path, the discrete model in crates/uor-r4-discrete, is stricter still: it is integer from end to end (GPU and CUDA).

Served half. What ships is "D11", the project's serving contract (D11, 27 September). It has five rules:

Serving on the user's own device, including browser WebAssembly, is the product and is allowed (charter, section 3.6). The border between the halves is the export, and it is where a float-trained candidate is judged.

How the engine works

The container (definition). UORLUT01 stores weights as 4-bit codes in groups of 32. Each group has a one-byte scale, built from a 4-bit mantissa and a 4-bit exponent. A few small integer tables cover the nonlinear steps: square root, decay rates, exp, SiLU, GELU and arcosh (SiLU, GELU and exp are squashing-type tables; see the compliance note under "Where it stands") (format.rs).

A projection with no multiply (proof by construction). For a weight row \(w_{ij}=s_g\,q_{ij}\) with 4-bit code \(q_{ij}\) and group scale \(s_g\), the output is

\[y_i=\sum_j s_{g(j)}\,q_{ij}\,x_j .\]

Instead of multiplying \(q_{ij}\) by \(x_j\), the engine builds once per activation a 16-entry table \(T_j[q]=q\,x_j\) for \(q=0,\dots,15\). Each entry comes from the one before by adding \(x_j\). Each weight's code then selects an entry, and the group scale is applied with shifts and adds. Four output rows share each table (kernels.rs).

Two runtime values multiplied together (proof). A score, a gate or a value mix needs a true product of two numbers that only exist at run time. The engine reads it from a table of the sixteen multiples of one operand, built by repeated addition, indexed by the radix-16 digits (base-16 digits) of the other operand and summed with shifts (stack_mul_u64 and stack_mul_u128 in kernels.rs). Write \(b=\sum_k 16^k d_k\) with each digit \(d_k\in\{0,\dots,15\}\) and let \(T_a[q]=q\,a\), built as \(T_a[q+1]=T_a[q]+a\). Then

\[ab=\sum_k 16^k\,T_a[d_k(b)] ,\]

which is exact by the definition of base-16 digits, and each term is a table read followed by a shift. (An alternative that D11 rule R2 would also allow is the quarter-square identity \(ab=\lfloor (a+b)^2/4\rfloor-\lfloor (a-b)^2/4\rfloor\), which holds for all integers; the training crate uses it in addressing_arms.rs, but the serving engine does not.) Normalisation uses an integer square root, computed digit by digit, and the sampler is an integer min-p rule. That sampler filters on probability mass read from the exp tables, so it is part of the compliance gap described under "Where it stands".

Exact geometry as tables. Where the model uses geometry, the tables are exact: the Cayley table of the 120-element icosian group (about 14 KiB), a 1,025-entry arcosh table for Lorentz read scores, and the Q30 Hopf observation. The integer crate's native_geometry.rs provides the typed H4 geometry and checked integer arithmetic that the qualified native build uses; no discrete-model export uses it yet (native_geometry.rs).

A saved conversation (definition). The UR4SESS1 format saves a session's state and restores it byte for byte (session_codec.rs).

The zero-multiply audit

The audit disassembles the compiled release program and counts three kinds of instruction over the serving functions: Class I multiply, Class II divide, Class III floating point. The scripts are audit_zero_matmul_serving.py (native) and audit_zero_matmul_wasm.py (WebAssembly, with a call-graph mode). They are existing Python scripts; porting them to Rust is an open question.

• Native: 44 symbol ranges audited, none with a forbidden instruction (project track, milestone M4). Measurement.
• WebAssembly: 7 of 7 serving functions (not modules) with multiply, divide and float counts all 0, in the runtime merged as UOR-Foundation/uor-r4#2654 (record). It was written by an outside contributor and hardened in review before merge. Measurement.

What the audit proves is absence: those instructions are not in the audited functions. It says nothing about model quality, and it does not cover every function in the binary. The record also lists three limits. First, the WebAssembly SIMD kernels are fixtures that nothing calls; the serving path still uses the scalar table kernel. Second, the demo in docs/wasm-serving/ does not run from a clean clone until its bundle is built. Third, the serving-wasm build compiles the model, sampling and tables modules unconditionally. Compliance with the "presence counts" rule (D29) rests on the feature defaulting off plus link-time removal, an interpretation that DECISIONS.md does not record.

The export gap

Definition. The export gap of a candidate is its served score minus its float score, on the same evaluator and the same positions. It is the price of snapping. The charter says a float candidate whose gap is above the two-seed noise band is disqualified (charter, section 3.7).

Past gaps come from an older float model, the "geometric stack", not from today's discrete model. Bits per byte (BPB) and nats are different units, and lower is better in both.

Two readings follow, both measurements on those older models. The integer engine adds almost nothing of its own: it reproduces its reference to about a millionth. And the whole gap is weight rounding, with the output layer the largest share in the 28 September record. Two cautions apply. The 8 October pair 0.877 float and 0.933 served was never like-for-like, because it mixed 512 and 64 evaluation windows. And the export of a model built under today's rules has not been measured, because none has been exported.

Where it stands

Why reading every weight is not the end state. A dense model streamed through tables is still dense. The table-emulation energy test above is the evidence, and D5 asks instead for selected, addressed reads that touch few parameters per token. No existing schema fits today's rules as it stands. Schemas /1 and /2 carry softmax-style reads through exp-table masses, which the no-softmax rule (D23) names. A third schema serves a softmax-free flock read, but its trained arms missed their bar (record). All three carry SiLU and GELU tables, which the charter bans in renamed or table form (section 3.2), and all three stream dense 4-bit weight maps through a table-based matrix-vector product, which the charter excludes as a dense model disguised as lookup tables (sections 3.3 and 3.6). The min-p sampler also works on exp-table probability mass. D11 rule R3 ("reading every weight is an interim stage") is historical wording: dense table maps are no longer an allowed stepping stone for new exports. A new table-native schema, built on selected and addressed reads, is therefore likely required. These are the engine's known compliance gaps, and the serving mechanism page tracks them.

Next. Export one discrete model through the container and report its gap (milestone M4). Whether UORLUT01 needs a new schema for table-native models, rather than 4-bit dense groups, is an open question.

Go deeper

• Mechanism page: D11 integer table serving. Model and geometry: discrete learning.
• Code: crates/uor-r4-integer (engine, container, session codec, uor-chat and uor-r4-stack command-line programs behind the serving-wasm feature).
• Decisions: D11, D37, D38 (the two halves of D5).
• Records: context curve, stack port design.
• Next pages: data and tokenizer, GPU and CUDA. Model pages: architecture, training.

GPUs and CUDA

The project trains and tests its model on graphics cards (GPUs), not on the laptop's processor. The programs that run on a GPU are called kernels, and the project writes them in CUDA, NVIDIA's language for GPUs. Every kernel is compiled before it runs. For the active model, an audit reads the compiled result and refuses instructions the project has banned: decimal arithmetic, tensor-core matrix instructions and approximate exponentials. The cards are rented by the hour from a marketplace through one script, under hard limits on how many and how much. The rented GPUs are used for qualification runs and a few short training doses. No trained language model has come out of them yet.

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea. See docs/formal_vocabulary.md and the glossary.

flowchart LR
  subgraph K["What the active kernels compute"]
    READ["read and write one vector (forward)"]
    PROP["score candidate moves (counterfactual)"]
    PICK["choose and apply one move"]
    EVAL["evaluate: top-1 and top-8 hits"]
    CNT["count tokens: frequency baselines"]
  end
  subgraph B["How they reach the GPU"]
    NVCC["nvcc builds PTX ahead of time"]
    AUD{"PTX admission audit"}
    CUBIN["cubin and resource report"]
    LOAD["driver loads the prebuilt module"]
    STOP["build fails"]
  end
  K --> NVCC --> AUD
  AUD -->|admitted| CUBIN --> LOAD
  AUD -->|rejected| STOP

The kernel map. Source files compile to PTX before anything runs, and the audit sits between compiling and loading. There is no run-time compiler.

The kernels and what they compute

The active model is crates/uor-r4-discrete, and its kernels are integer only. The header of discrete.cu says model values use gather, sign, add and subtract, comparison and finite action-table look-ups, and that storage indexing uses integer products. It has 577 lines and 12 entry points:

Five more modules are generated from discrete.cu at build time, each its own source, PTX and cubin, so the earlier images stay byte for byte unchanged: a diagnostic decomposition, baseline reuse, row-parallel scoring (rows, 3 entry points), scoring several coordinates per launch (rowsk, 5) and selecting and committing a set of moves (bvgk, 8). The build also writes exact geometry tables from the core crate: AXES[512], COMPOSE[4096], INVERSE[64], 16 carrier roots, a breadth-first reachability map and 15 generators (build.rs).

Other CUDA code in the repository is not on the active path:

Line counts are raw counts of the files named.

How a kernel is admitted

Compile ahead of time (definition). The build script calls nvcc -ptx -std=c++17 -arch=compute_NN, where NN is the card's capability from the explicit UOR_NVCC_ARCH setting. NVIDIA's run-time compiler, NVRTC, is banned project-wide (D29, amended 13 October): what nvcc compiles at build time is exactly what the driver may load, and banned code present in a module counts even if never launched (D29). Two older pages, the CUDA training runbook and the pods quickstart, still describe NVRTC. They were written before the ban.

The admission audit (proof by inspection of the code). The audit reads the emitted PTX text, not the CUDA source, so a banned instruction cannot hide behind spelling. It strips comments, splits each line into tokens, and rejects the build if any token has a component named f16, f16x2, f32, f64, bf16, bf16x2, tf32, e4m3, e5m2, mma, wmma, wgmma, tcgen05, tensor or tensormap, or starts with ex2.approx. It also requires the set of .entry points to equal the declared inventory exactly: a missing, extra or duplicate entry fails. A self-test runs on every build. It must accept a clean module (floats inside comments are fine) and must reject add.f32, a .bf16 register, mma.sync, ex2.approx, an unexpected entry, a duplicate entry and missing entries. After admission, the same admitted PTX is assembled into a cubin for each of the six modules, and the build fails if the cubin is empty or its resource report is missing.

What it does not say. Integer multiplies are allowed in these kernels, for example to compute indexes. This is a different rule from the serving contract, where no multiply instruction may appear at all (serving and export). The float training crate has no equivalent PTX audit, since float is legal there, and uses precision flags instead (-ftz=false -prec-div=true -prec-sqrt=true, and --fmad=false for the flock selector). Passing the audit shows which instructions are present. It does not show that a kernel computes the right thing. Correctness comes from separate controls on a pod.

Not in continuous integration. No GitHub workflow mentions nvcc or CUDA. The standing checks compile without the cuda feature, and qualification runs on rented pods. For exact-head compile checks there is a recipe, scripts/pod/uor-cuda-check-remote. It rents one fresh RTX 5090 with CUDA 12.8 for 15 minutes (30 for the training crate), runs cargo check and then clippy, and tears the pod down (compute guide). It is compile and lint only, never a model run.

Renting the cards

The rules are written in docs/labs/compute.md and printed by uor-pod itself.

The laptop does non-model work: editing, compiling CPU-only builds, static checks and grading stored outputs. All model compute is GPU work (D24). Serving a finished model on the user's own device is a separate matter and is allowed (charter, section 3.6).

Measured costs.

• On 13 October a verified datacenter RTX 5090 on Vast cost $0.469 an hour, against $1.19 an hour on Runpod. A fresh Vast pod took its toolchain, crate cache and binaries from the private store and was ready in 57 seconds, with nothing built (measurement, compute guide).
• The 19 October A8 dose ran on a Vast pod with two RTX 5090s at $1.816 an hour for about 62 minutes: about $1.9. That is a resource estimate, not an invoice, and storage and transfer were not measured. The owner typed the release for each arm personally (record).
• Scoring 16 candidate moves in one launch took a median 123.57 ms, against 125.51 ms for scoring one. All 5,130 coordinates matched the reference exactly, and a deliberately broken copy failed as it should. The earlier launch used only 8 of the card's 170 multiprocessors (record). Measurement, at that one shape.
• One full pass over every parameter of the discrete model is projected at about 17.8 hours for the route read and 19.2 for the flock read, roughly $16 to $17. That is an unverified projection, not a run (record).
• A fused memory kernel claimed to be 12 times faster was never run on the pod, and its commit broke the build and was reverted. No measurement survives (record).

Where it stands

Go deeper

• Mechanism pages: discrete learning, SpiralCore and FBS, Hamilton gate.
• Code: discrete.cu, build.rs, scripts/pod/uor-pod.
• Guides: pod rules, CUDA training runbook (older, pre-dates the NVRTC ban), pods quickstart.
• Next pages: serving and export, data and tokenizer. Model pages: architecture, training.

The geometry of UOR-R4

Most chat AIs predict the next word by multiplying very large grids of decimal numbers. UOR-R4 is a bet that a different set of tools can do the same job more cheaply: rotations in a few dimensions, exact whole-number addresses built from primes, and lookup tables. This section explains those tools one chapter at a time, with pictures. It also says which ones the model uses today and which are research that has not yet been put to work. The project is pre-alpha: 0 of its 8 milestones are complete, and no model holds a useful conversation yet (STATUS.md).

How the geometric pieces connect. Each arrow is one correspondence, and the table below says whether the link is forced by the mathematics or was chosen.

Why geometry

The owner's rule for this project is that the core of the model is built from geometric mechanisms. The reason is a cost hypothesis. A transformer's expensive parts are dense matrix multiplication, a score for every possible next word, and storing every earlier position. Rotations, exact addresses and tables may be much cheaper on a laptop (a hypothesis: no efficiency has been measured yet). Whether they are also good enough to model language is the open question.

These rules shape how the geometry is used.

• No softmax or squashing, no matrix multiplication. Softmax, sigmoid, tanh and softplus are banned in every executed model path (D23, D25), and so is matrix multiplication in training and serving (D25, D30). Attention itself is not banned: bounded geometric reads replace it.
• Research compute is GPU-only (D24). Serving the exported D11 integer artifact on a client device (CPU, WASM, Apple silicon) is the product and is allowed. It uses no floating point and no multiplier instruction.
• Floating point is for offline training only (D37). Float never re-admits softmax, squashing or matrix multiplication. The active discrete path and the served model stay integer (D11), and every float-trained candidate must report its export gap, the quality lost when converting to the integer artifact.
• Geometry is a design priority, not a measured advantage. A failed experiment closes one configuration, never a whole mechanism (D22). A passing check on a piece of mathematics does not show that the piece helps a language model.

Labels on this page follow docs/formal_vocabulary.md: proof means derived from definitions or code, measurement means a recorded run, and hypothesis means an untested idea. Mechanism status is ACTIVE (on the current model path), READY (built and tested, not yet trained in) or PARKED (the tried forms failed or broke a rule, and the mechanism stays open). The mechanism board holds the full list. It replaces the older labels active, dormant and archived-negative.

The compliant next-token path

This is the path the current integer model (crates/uor-r4-discrete, called M1) follows for each token. Source for each step is in the architecture table.

flowchart LR
  tok["Token ID"] --> tab["Shared table:<br/>blocks of 8 integers"]
  tab --> ctx["Ordered context<br/>(ternary FBS plan)"]
  ctx --> read["Read:<br/>Route, Flock or Relation"]
  read --> wr["Shared writer:<br/>admission + exact distances"]
  wr --> out["Next token"]
  out -. "learning" .-> tab

The five steps of one token. The dotted arrow is learning, which changes the shared table by exact moves.

1. Input. A token ID selects blocks from Snapshot.table.
2. Context. Ordered ternary FBS plans (a three-branch tree over earlier tokens; see the glossary) preserve context order for the read.
3. Read. Route selects one carrier per block and transports it without summing or snapping. Flock ranks eligible nodes, transports them, sums and snaps. Relation adds finite relational reranking before the Flock selection. See route read, flock read and relation read.
4. Shared writer. Product-address admission and exact distances select a token using the same table. The writer is implemented (admission).
5. Learning. The learner compares virtual exact moves on a fixed batch and accepts objective improvements through the admitted driver. rows_v1 parallelizes proposal work (discrete learning).

Each block is 8D, and four blocks give width32. The carrier has 16 roots, acted on by 64 signed transport actions (build.rs). These three counts describe different objects. The orbit is not full E8 coverage.

The earlier float operator path is preserved as evidence and is not the current token path. It includes the Hamilton gates (G2), the geometric recurrence and the delivered head (OP3a). See the operator record, the head record and the historical geometry tour. Its earlier sheets are inactive until they are re-registered and reviewed under D37. The dated operator diagram illustrates those retained operators.

Reading order

Each chapter opens in plain words, shows its figure, gives the mathematics, and ends with where the model uses the idea.

Read them in that order if the mathematics is new. The first two build the vocabulary, and the last two are closest to the running code.

How the pieces connect

The figure above has fifteen links. Each has its own metric, convention or labelling assumption, and the chapter named in the last column gives the full statement. Every link is investigated by finite exact enumerations and sampled numerical consistency checks in verify_connections.py, which runs 29 checks with differing evidence scopes. These checks support the stated identities within their enumerated or sampled domains. They are not 29 general mathematical proofs, and they do not establish predictive value. Whether any link helps the model is the subject of the pre-registered experiments on M1 (#2029). The SpiralCore material is credited to Matthew (SpiralCore v63/v69). The octonion and Fano material is credited to Mark (N3mesis, NEMESIS-Theory).

Two cautions for anyone building on this.

1. Half-turns do not compose like bivectors. Two half-turns whose K6 edges share a vertex multiply to an order-5 rotation, never a half-turn. The match between primes and half-turns is a correspondence of sets, not of products.
2. Labelling primes to axes is a choice. A design that routes primes through icosian rotations must say which of the 12 inequivalent labellings it uses.

Serving without multiplication

Under D11 a served kernel has no floating point and no multiplier instruction. A product of two runtime values is read from a table instead. Build the sixteen multiples (0 to 15) of one operand by repeated addition, index that table with the radix-16 digits of the other operand, and combine the results with shifts and adds. For example, to compute \(37 \times 43\), the table holds 0, 37, 74, …, 555. Write 43 as hex 0x2B, with digits 2 and 11. Then

\[37 \times 43 = (T[2] \ll 4) + T[11] = (74 \ll 4) + 407 = 1184 + 407 = 1591.\]

A 4-bit weight is a single digit, so one product is one table read. Division is restoring long division, square root is digit-by-digit, and the kernels are kept opaque to the optimiser so that an add chain is not folded back into a multiply. Products are taken modulo \(2^{64}\) or \(2^{128}\) to match the earlier integer engine. The code is in crates/uor-r4-integer/src/stack/kernels.rs (stack_mul_u64, stack_div_u64, stack_isqrt), and the ARM64 audit is scripts/audit_zero_matmul_serving.py --stack. The numbers in the example are illustrative and are not taken from the code. The serving contract is described on the D11 integer serving page. It is ACTIVE as the export boundary, but no lawful trained model has been exported through it yet.

Reproduce the figures

The status diagrams (architecture, milestones, pipelines, the geometry stack, the compliant path and the operators) are generated in Rust, and CI-style checks confirm that they are current:

cargo run -p xtask -- figures            # check
cargo run -p xtask -- figures --write    # regenerate

The mathematical figures in the chapters are drawn by a standard-library script. Porting it to Rust (D27) is a recorded follow-up:

python3 docs/figures/geometry/generate.py

Go deeper

• Architecture source map and the mechanism board.
• Checks for the maths: verify_connections.py.
• The previous single-page version of this guide, with the retained float designs: historical geometry tour.
• Live numbers: STATUS.md.

Quaternions and rotation

A quaternion is a number with four parts. Multiplying by a unit quaternion (one of length 1) turns a point in four dimensions without stretching it, and a sandwich of two multiplications turns a point in ordinary three-dimensional space. That makes quaternions a natural way to say "turn this state" with exact, reversible steps instead of a grid of learned decimals. This chapter explains what a quaternion does, and why turning a state keeps its length while adding a new input to it does not. Terms are also defined in the glossary.

Two different actions of the same quaternion. Conjugation turns 3D space, and left multiplication turns the whole 4D state.

Rotation: conjugation and left multiplication

A quaternion has four real components, \(q = w + xi + yj + zk\), with \(i^2=j^2=k^2=ijk=-1\). Quaternions of length 1 form the 3-sphere \(S^3\). Multiplication does not commute: in general \(qh \neq hq\).

For a pure imaginary vector \(v\) (a point in \(\mathbb{R}^3\)), the map \(v \mapsto q\,v\,q^{-1}\) is a rotation of \(\mathbb{R}^3\). A unit quaternion \(q=\cos\tfrac{\theta}{2}+\sin\tfrac{\theta}{2}\,n\) turns space by the angle \(\theta\) about the unit axis \(n\) (proof, a standard identity). The quaternions \(q\) and \(-q\) give the same 3D rotation.

Left multiplication \(q\,h\) is a different thing. It is a norm-preserving linear action on the full quaternion space \(\mathbb{R}^4\), because \(|qh| = |q|\,|h|\). It does not identify \(q\) and \(-q\) as the same action: the map for \(-q\) is the negative of the map for \(q\).

The retained float stack's quaternion_scan (the geometric stack, PARKED) uses left multiplication, then additive input injection (geometric_stack.rs). The current M1 model instead executes signed actions on 8D carrier blocks. The quaternion picture explains part of the research lineage. It is not a literal 4D state for the M1 kernel.

Rotation preserves length; additive recurrence need not

Pure repeated quaternion transport stays on \(S^3\). The historical additive recurrence generally does not.

The figure's pure transport orbit stays on \(S^3\) when its initial state and its transport quaternion are unit. The retained float recurrence is

\[h_t = \lambda_t\,(u_t\cdot h_{t-1}) + \sqrt{1-\lambda_t^2}\;a_t .\]

Here \(u_t\) is a unit quaternion that turns the old state, \(a_t\) is the new input and \(\lambda_t \in [0,1]\) is a fade rate. Take \(h_{t-1}\) and \(a_t\) to be unit. Then \(|u_t h_{t-1}| = 1\), and expanding the squared norm gives

\[|h_t|^2 = \lambda_t^2 + (1-\lambda_t^2) + 2\lambda_t\sqrt{1-\lambda_t^2}\;\langle u_t h_{t-1},\,a_t\rangle = 1 + 2\lambda_t\sqrt{1-\lambda_t^2}\;\langle u_t h_{t-1},\,a_t\rangle .\]

The cross term is generally nonzero, so the sum need not lie on \(S^3\) (proof, by expanding the norm). The identity \(\lambda^2 + (1-\lambda^2) = 1\) alone does not normalise it. The rotation preserves the norm of the transported term. Any unit-state claim for the combined state needs an explicit normalisation or further conditions.

The same split shows up in the current reads. Flock and Relation reads sum transported vectors and snap the result back to the finite carrier. Route instead transports one selected carrier per block, without summing or snapping, in discrete.cu.

Where the model uses this

Octonions and quaternions. Each of the seven Fano lines of the octonions spans a copy of the quaternions. The octonions are alternative and norm-multiplicative, and 168 of the 210 ordered unit triples are non-associative (exactly the non-collinear ones). This link is forced (cd_space.rs); see SpiralCore for the table. The stack transport that relies on it is current in uor-r4-discrete, and it also appears in the float geometric_stack.rs, whose mechanism is PARKED.

Where it stands

Go deeper

• Next chapter: E8, H4 and the 600-cell, where the 120 unit quaternions of the icosian group appear.
• Code: geometric_stack.rs, cd_space.rs, discrete.cu.
• Mechanism pages: Hamilton gate, recurrence gates, spin-native weights.
• Generator for the figures: generate.py.
• Back to the overview.

E8, H4 and the 600-cell

There is a special set of 120 unit quaternions (each one a rotation) that are the corners of a regular solid in four dimensions called the 600-cell. Pairing that set with a golden-ratio-scaled copy of itself gives 240 points in eight dimensions, the roots of a famous lattice called E8. The project uses this structure because every rotation in it can be written with exact whole-number arithmetic, so a state can be turned and turned back with no rounding. The current model uses only a small, 16-root piece of E8, and this chapter is careful about the difference.

The 120 unit icosians as the vertices of the 600-cell, seen from a plane chosen to show the symmetry. Four rings of 30 points, 12 neighbours per vertex, 720 edges.

The 120 icosians and the 600-cell

The binary icosahedral group \(2I\) contains 120 unit quaternions, closed under multiplication. These are the H4 roots and the vertices of the 600-cell. They are, with coordinates in order \((w,x,y,z)\):

• 8 quaternions \(\pm1,\pm i,\pm j,\pm k\);
• 16 of the form \(\tfrac12(\pm1\pm i\pm j\pm k)\);
• 96 from the even permutations of \(\tfrac12(\pm\varphi,\ \pm1,\ \pm\varphi^{-1},\ 0)\).

That is \(8+16+96=120\) (proof, by direct count). Each has length 1: for the last family, \(\tfrac14(\varphi^2+1+\varphi^{-2})=\tfrac14\cdot 4=1\) because \(\varphi^2+\varphi^{-2}=3\).

Viewed from any one vertex, all 120 vertices, counting the vertex itself, fall into shells of 1, 12, 20, 12, 30, 12, 20, 12 and 1 vertices. The first shell has 12 neighbours at angle 36°, so there are \(120\cdot12/2=720\) edges. The figure above retains the historical icosian-snap construction. Its 120 vertices form four projected rings of 30. Snapping a learned rotation to this 120-element codebook describes a retained experiment, not the current M1 read or learning path.

Icosahedral rotations. Dividing by \(\pm1\) gives \(2I/\{\pm1\}=A_5\), the 60 rotations of the icosahedron. It acts two-transitively on the six five-fold axes (proof; checked in verify_connections.py). Each of the 15 half-turns fixes exactly one pair of the six five-fold axes. So the 15 edges of the complete graph K6 on those axes match the 15 half-turn axes. This is forced once the six axes carry the six labels. A further fact is that the icosahedron's five orthogonal frames of two-fold axes form a synthematic total of K6: five perfect matchings that together cover all 15 edges.

Primes and axes. The six registered primes {5, 7, 11, 13, 17, 19} give 15 semiprime products, one per K6 edge (see SpiralCore). Attaching the six primes to the six five-fold axes is a labelling choice. There are 720 labellings, and 12 of them are inequivalent under rotation. A design that routes primes through icosian rotations must say which one it uses. Half-turns also do not compose like bivectors: two half-turns whose K6 edges share a vertex multiply to an order-5 rotation, never a half-turn. The prime-to-half-turn match is a correspondence of sets, not of products.

E8 as H4 plus a golden copy

The 240 roots of E8 seen in the same kind of plane. Two sets of 120 meet in one picture: the icosians and a copy scaled by \(\varphi\).

The shorthand E8 = H4 ⊕ φH4 means, here, an icosian construction with a specified reduced metric. It is not an independent Cartesian product of two H4 states. Let \(x\cdot y = a + b\varphi\) in the quaternion coordinates. The construction uses

\[\langle x,y\rangle = 2a ,\]

the rational-part bilinear form, on the 240 elements \(2I \cup \varphi\cdot 2I\). In the eight rational coefficient coordinates these have rank 8, norm 2, the E8 inner-product counts (from any root, 1 root at inner product 2, 56 at 1, 126 at 0, 56 at −1 and 1 at −2) and reflection closure. The executable finite checks are in verify_connections.py (check E2). The primary construction paper explains the reduced inner product. The standard picture of E8's roots in a Coxeter plane has 30-fold symmetry and 240 points in eight rings of 30, which is the natural companion to the four rings of 30 above.

Check E1 verifies something else: that the specified signed 8×8 matrices (all 15 Cl(0,6) bivector matrices and the six generator matrices) preserve the 240 roots in the standard coordinates of E8. E2 verifies the reduced-metric icosian root system. These checks do not supply a map between the two representations, so the claim that the action is preserved across that missing map is not established.

The retained anchors.rs stores \([a_0,\dots,a_3,b_0,\dots,b_3]\) and a Galois companion for one H4 root. Its header says that this invertible coefficient representation does not establish an orthogonal Euclidean E8 embedding or independent extra state. The present carrier has its own concrete basis and orbit, built in build.rs: 16 roots of one E8 orbit, each a signed permutation of \((2,2,0,0,0,0,0,0)\), acted on by 64 signed transport actions. No basis bridge from this standard-coordinate carrier to the icosian realization above is asserted.

A design off the current path: icosian holonomy lanes

A historical proposal for remembering order with exact group elements.

A lane state is a product in the 120-element group, updated by one read of a \(120\times120\) table: \(h_t = u_t h_{t-1}\). To read an earlier position \(j\), form the relative element \(h_j^{-1}h_t\) and use its shell index, 0 to 8, to rank that position. This design is not on the current path. It was pre-registered as the experiment called E1 (not the same thing as check E1 above), and it needs its own pre-registration and a TEST FITNESS: FIT review before any compute. An August recursive-attention configuration that kept one reusable summary state lost the order of earlier tokens (the August A1.0 record). Separately, the retrieval arms also called A1 were stopped on 1 October under D18 because every arm scored below 0.5 recall at distance 16. Under D22 that closes the configuration, not the mechanism.

Where the model uses this

Retained experiments such as these have results that concern those configurations. They do not settle the full geometry programme.

Where it stands

Go deeper

• Next: Golden integers, the exact arithmetic behind these coordinates.
• Code: anchors.rs, build.rs, verify_connections.py.
• The mechanism pages above, and the overview.

Golden integers

The coordinates of the 120 icosian rotations contain the golden ratio, an irrational number, so a computer would normally round them. There is a way to avoid rounding altogether: keep every coordinate as a pair of whole numbers \((a, b)\) that stands for \(a + b\varphi\). Adding and multiplying such pairs gives another pair, exactly. This chapter explains that arithmetic, called \(\mathbb{Z}[\varphi]\), and says where the project uses it. Terms are also defined in the glossary.

Exact arithmetic in \(\mathbb{Z}[\varphi]\), with the coordinates of unit icosians scaled by one half.

The arithmetic

The golden ratio \(\varphi = (1+\sqrt5)/2\) satisfies

\[\varphi^2 = \varphi + 1 .\]

The set \(\mathbb{Z}[\varphi] = \{a + b\varphi : a, b \text{ integers}\}\) is closed under addition and multiplication, so it supports exact pair arithmetic. Addition adds the pairs. Multiplication uses the rule above to remove \(\varphi^2\):

\[(a+b\varphi)(c+d\varphi) = (ac+bd) + (ad+bc+bd)\,\varphi .\]

This is a proof by expanding and substituting \(\varphi^2=\varphi+1\). Two worked examples:

• \(\varphi\cdot\varphi\) is \((0,1)\cdot(0,1) = (1,1)\), that is \(1+\varphi\).
• \(\varphi^{-1} = \varphi - 1\) is the pair \((-1,1)\), and \(\varphi\cdot(\varphi-1)=\varphi^2-\varphi=1\).

The other root of \(x^2=x+1\) is \(1-\varphi=-\varphi^{-1}\). Swapping \(\varphi\) for it is the Galois conjugate, \(a+b\varphi \mapsto (a+b)-b\varphi\). Multiplying a number by its conjugate gives the integer norm \(N(a+b\varphi)=a^2+ab-b^2\).

Icosian coordinates need the factor one half

The unit icosian coordinates are \((a+b\varphi)/2\), which lie in \(\tfrac12\mathbb{Z}[\varphi]\). The factor one half must be kept. Scaled integer pairs represent them without rounding. For example, the icosian \(\tfrac12(\varphi,\,1,\,\varphi^{-1},\,0)\) has doubled coordinates \((0,1)\), \((1,0)\), \((-1,1)\) and \((0,0)\), and its length checks out exactly: \(\varphi^2+1+\varphi^{-2}=4\).

anchors.rs documents this scale explicitly. Its norm numerators have denominator 4. The same file stores one H4 root as \([a_0,\dots,a_3,b_0,\dots,b_3]\) plus a Galois companion, and warns that this invertible coefficient representation does not by itself establish an orthogonal Euclidean E8 embedding or independent extra state.

Fixed ZPhi arithmetic and exact anchor orientation tables support the research. Chirality and polarity are exact signs on \(\mathbb{Z}[\varphi]\), held as fixed integer tables in anchors.rs. They are used by the retained native geometric learner, not by the current M1 path.

A caution about addresses: equality addresses for complete tuples are not semantic distances between class numbers. Two entries being exactly equal tells you they are the same entry. It does not tell you how alike two different entries are.

Where the model uses this

The two ends of the table matter. The exact golden arithmetic is real, tested code, but the current model's own carrier is built from ordinary integers. Whether exact golden coordinates help a language model has not been measured.

Where it stands

Go deeper

• Code: anchors.rs and prime_route_attention.rs.
• The forced link from the icosians to \(\mathbb{Z}[\varphi]\) is checked in verify_connections.py.
• Next: The Hopf map and the kept fibre. Back to the overview.

The Hopf map and the kept fibre

In the project's quaternion designs, a rotation state is a point on a four-dimensional sphere (the current model M1 carries 8D integer blocks instead). The Hopf map takes a three-dimensional shadow of that point. The shadow forgets one angle, so many different states cast the same shadow. This chapter explains what the map does, what the forgotten angle is, and what the project does and does not do with it. Short version: the idea is built and unit-tested as a helper, it is not part of the current model's read, and nothing yet shows that keeping the forgotten angle helps language. The mechanism's status is PARKED (mechanism page).

The Hopf map \(S^3\to S^2\) sends a whole circle of 4D points to one point of the 2-sphere. The shadow cannot tell them apart.

The map

Write a unit quaternion as \(q=(a,b,c,d)\) and set \(z_1=a+ib\) and \(z_2=c+id\). The Hopf map to the 2-sphere is

\[h(q)=\big(2(ac+bd),\ 2(bc-ad),\ a^2+b^2-c^2-d^2\big)=\big(2\,\mathrm{Re}(z_1\bar z_2),\ 2\,\mathrm{Im}(z_1\bar z_2),\ |z_1|^2-|z_2|^2\big).\]

Two facts follow by expanding the squares (proof).

1. It lands on the unit sphere. \(|h(q)|^2=4(a^2+b^2)(c^2+d^2)+\big((a^2+b^2)-(c^2+d^2)\big)^2=(a^2+b^2+c^2+d^2)^2=1\).
2. A common phase changes nothing in the shadow. Multiply both \(z_1\) and \(z_2\) by the same phase \(e^{i\vartheta}\). The product \(z_1\bar z_2\) and both moduli are unchanged, so \(h(q)\) stays put. But \(q\) moves around a circle, the fibre.

So the shadow alone cannot be inverted. Rebuilding \(q\) needs the base point on the 2-sphere, the fibre phase and a chart convention, because there is no global identification \(S^3=S^2\times S^1\). The image alone is not an invertible representation of the input, and the project does not assume a reversible universal \(S^3\to S^2\to S^1\) pipeline. Keeping the lost angle in a separate slot is what "the kept fibre" means.

How the code handles it

For a unit quaternion \((a,b,c,d)\), UnitS3Q30::hopf computes the formula above after decoding Q30 storage to f64, then normalises and requantises the result to Q30. Q30 names the storage representation here. It does not mean the Hopf map runs in integers.

prime_route_attention.rs provides rotate_common_fiber and SpinTorsionState { s3, fiber, torsion }, which keeps the S³ state, a fibre phase and a torsion term in separate fields. rotate_common_fiber also decodes to f64, uses libm::sin and cos, and normalises and requantises the rotated point. These are float-backed, offline, fixed-geometry utilities. They are not an integer model execution path.

Hopf fibre tracking is not wired into the current discrete M1 read. The retained M2 Hopf metric, which tracks a cumulative phase and a geodesic distance, is separate research and belongs to the held native learner.

The icosians under the map. The map sends the 120 icosians of the previous chapters onto one orbit of 30 points of the 2-sphere, every fibre of size 4 (finite enumeration in verify_connections.py). That orbit is of two-fold type; it is not literally the axes of the chosen frame. This link is forced.

What was tried

The full history is on the mechanism page. In brief, with the measurements it records:

Only the occupancy rows test the Hopf map itself, and they tested one projection of one state. The attention failures in that record used an additive summary, a heatmap readout and softmax constructions, and the records say Hopf is not refuted. Reading these honestly: the shadow was never tested with its fibre kept, at equal retained bytes, as a language feature. That is the test that would reopen the mechanism. Three of the conditions that would reopen it, as the mechanism page lists them: an integer multiplier-free Hopf map wired into a consumer, a Lorentz read re-registered as an offline float sheet, and the retained-fibre test itself.

Where the model uses this

Where it stands

Go deeper

• Code: hopf_metric.rs, prime_route_attention.rs.
• Next: Primes and zeta phases. Back to the overview.

Primes and zeta phases

Every prime number is a unique, indivisible building block, and every whole number is a product of primes in exactly one way. UOR-R4 uses that as an exact-identity idea: a word can be named by a prime (the current model M1 itself uses explicit token IDs). Separately, the project turns each prime into a set of angles using the known frequencies of the Riemann zeta zeros, as an optional input to the model's starting table; distinct starting vectors come from the allocation passes described below. This chapter explains both ideas and keeps them apart. The first is exact identity. The second is a way to scatter starting positions, and nobody has yet shown that its zeta angles help beyond simply keeping the words distinct. Terms are also defined in the glossary.

Fixed zeta-zero frequencies \(\gamma_k\) turn each prime \(p\) into one angle per zero, \(\theta_k=\gamma_k\ln p\). Think of a bank of clock hands, each turning at its own speed.

Zeta phases

The imaginary parts \(\gamma\) of the Riemann zeta zeros are fixed numbers. The first three are about 14.1347, 21.0220 and 25.0109. Each defines a phase frequency. For a prime \(p\) the phase on channel \(k\) is

\[\theta_k(p)=\gamma_k\ln p \pmod{2\pi},\qquad z_k(p)=\cos\theta_k+i\sin\theta_k .\]

A worked illustration (computed from the published value, not read from the code): for \(p=2\) and the first zero, \(\theta_1 = 14.1347\times\ln 2 \approx 9.797\), which is about \(3.514\) radians after subtracting \(2\pi\). Using a finite table of these constants does not require proving the Riemann hypothesis.

The optional offline prime_zeta.rs constructor uses four complex channels per block (\(\mathbb{C}^4\)) with \(\theta=\gamma\ln p\), and then:

1. Realifies them into two 4-real tuples, \((\mathrm{Re}_0,\mathrm{Im}_0,\mathrm{Re}_1,\mathrm{Im}_1)\) and \((\mathrm{Re}_2,\mathrm{Im}_2,\mathrm{Re}_3,\mathrm{Im}_3)\).
2. Normalises each with UnitS3Q30::from_r4 and quantises to Q30.
3. Applies the fixed coordinate permutation and exact integer alignment scores against the 16-root 8D carrier (see E8, H4 and the 600-cell).
4. Allocates under writer-cell quotas and, when capacity permits, full-vector uniqueness controls. The output is Snapshot.table.

So \(\mathbb{C}^4\) becomes \(\mathbb{R}^4+\mathbb{R}^4\) per block, not \(\mathbb{C}^8\) or \(\mathbb{R}^{16}\) per block. The allocation controls are part of the assignment. It is not simply an unconstrained nearest-root snap. Floating point appears only in this one-time offline step, under the October 14 zeta-zero exception, and the output is an integer table.

An honest caveat (proof, by reading the code). The quota and uniqueness passes also run on both matched control tables (one shifts every \(\gamma\) by 1.0, the other permutes the primes and scrambles phases and amplitudes). So the absence of collisions comes from those passes, not from prime phases. The record is prime-zeta construction; the mechanism page is prime-zeta codebook.

The retained M2 learner used the same fixed phases in a different way: it accumulated fixed phase bins as policy inputs (engine.rs). That historical use is distinct from the current codebook initialisation, and it does not establish learned M1 attribution to zeta phases.

Prime addressing

Distinct primes make shared factors exact. A product records which primes are present, not their order or how many times each appears.

Assign each token identity its own prime. Then shared factors are exact, by unique factorisation (proof). For example, with primes \(2,3,5,7\) standing for four tokens, the products \(42=2\cdot3\cdot7\) and \(105=3\cdot5\cdot7\) have \(\gcd=21=3\cdot7\), which says exactly that the two sets share tokens 3 and 7. A product of distinct primes records a set. Sequence order and multiplicity need explicit additional representation: \(2\cdot3=3\cdot2\), and \(12=2\cdot2\cdot3\) needs exponents to be told from \(6=2\cdot3\). Exact identity is not a semantic metric. Two different primes are different, and nothing more is learned from their size or product.

What the current model does with this

Current M1 uses explicit token IDs and an ordered BinderPlan context, plus the optional prime-addressed initialiser above. Flock and Relation reads rank finite context nodes and transport payloads before the shared writer.

A bounded kept-K list limits how many contributions are retained. It does not bound selection cost: the kernel scans eligible nodes, and Relation adds graph scans. The writer also scans vocabulary occupancy and admitted-cell tokens. See the cost and source discussion.

On 18 October the prime-zeta table was wired in as the model's starting table. Before that, a random start gave 4,096 words only 16 different starting vectors. The table gives all 4,096 distinct vectors (prime-zeta construction, wiring). The 19 October zero-update pre-flight then found that, at K=8, only about 8 of 256 target cells were opened, so admitted words were 127 of 3,847 against a gate of 500, and the run was not started (pre-flight). That closes the configuration "spread words evenly at K=8". It does not test whether zeta phases help.

Where the model uses this

The D19 object store preserves exact bytes separately. It is not silently integrated into the M1 token path. The retained native learner and the addressed-memory and pointer-identity mechanisms remain research foundations with their own artifact-bound evidence.

Where it stands

Go deeper

• Code: prime_zeta.rs, prime_route_attention.rs.
• Next: VSA and Hamming distance. Back to the overview.

VSA and Hamming distance

Give every word a very long string of 1s and 0s, 4,096 of them. To ask "are these two strings alike?", line them up and count the positions where they differ. That count is the Hamming distance, and it costs almost nothing on a computer: an exclusive-or (XOR) and a bit count. This chapter covers two uses of the idea. One is the older "hypervector" memory cue (VSA), which is research that was measured once and is not on the current path. The other is a Hamming tie-break that does run inside the current model's reads. In both cases the similarity is only a count of bits, and it is as meaningful as the way the codes were assigned. Terms are also defined in the glossary.

Two codes are compared with an XOR and a bit count. The result is a Hamming distance and the matching bipolar cosine.

What a hypervector is

Each token has a 4096-bit bipolar hypervector, stored as 64 u64 words. A set bit means \(+1\) and a clear bit means \(-1\). Two codes \(A\) and \(B\) are compared with an XOR and a popcount, which gives the Hamming distance \(d\). The bipolar cosine is

\[\cos(A,B) = 1 - \frac{2d}{4096} .\]

A context hypervector bundles the codes of the recent tokens by a bitwise majority vote. The similarity is a statistic of the code bits, and it is only as meaningful as the way the codes were assigned.

Two standard facts (proof, from the definition of XOR) are worth knowing. XOR is its own inverse, \((A\oplus B)\oplus B=A\), which is why it works as a "glue and unglue" operation. For a bundle of \(k\) random terms, unbinding returns the stored value plus noise of standard deviation about \(\sqrt{(k-1)/D}\) with \(D=4096\). That is the textbook estimate for random codes, not a measurement on this model.

What the older model did with it

In the older native prose learner (an offline float learner on a CPU, now barred by the GPU-only rule D24), the VSA term added vsa_scale · similarity to the root and leaf scores. Three code modes existed.

Measurement (9 October, two seeds, two held-out slices, 6,795,016 training tokens per run). With the VSA term trained in and fixed token-hash codes (mode 0), held-out bits per byte improved in all four seed-and-slice pairs, by 0.0144 to 0.0226 (for example 1.8366 against 1.8574). Icosian-root codes (mode 1) did not help: the change in bits per byte against VSA off (negative is better) was +0.0003 and +0.0001 on one seed and −0.0053 and −0.0054 on the other, all four under the 0.01 threshold, and with only 120 distinct codes, tokens that share a root cannot be told apart. The root-plus-residual codes (mode 2) were worse than fixed codes in all four cells, by +0.013 to +0.028 (native test record; a historical float-form measurement on a CPU learner). An earlier "closed" label for mode 0 applied to a frozen-artifact swap and a wiring fault, not to this trained-in run.

The link from the icosians to these bit codes is learned, not forced: the learned token-to-icosian-root assignment builds the mode 1 codes (vsa_codes.rs, since PR #2077).

Limits to keep in view: the seeds differ by about 0.015 bits per byte, the size of the effect, and the cross-arm comparison is a point estimate. The same model's exact-memory table was worth about 0.19 to 0.20 bits per byte, so VSA may duplicate evidence that other heads supply. VSA is not tied to SpiralCore (next chapter). The full tried-and-untested list is on the VSA mechanism page, and the mechanism's status is PARKED.

The Hamming-rank read, a tried configuration

A historical proposal to replace a softmax with a sort by Hamming distance and a fixed rank table.

The Hamming-rank read is a historical sign-bit and popcount design with fixed rank-table weights. Its historical float configuration, trained beside a softmax stack, measured +0.2585 bits per byte against the softmax stack (+0.259 in the older write-up). That result closes only that configuration. It is not the current discrete Flock or Relation algorithm (softmax-free read record).

Hamming in the current reads

On the current path, Hamming distance is one factor among several, not the whole read. The kernel flock_vector orders candidates by:

1. relation score, descending;
2. L1 displacement, ascending;
3. coordinate Hamming distance, ascending;
4. recency, descending;
5. node, ascending.

In Flock mode the relation scores are zero. The kernel then equally sums the selected transported roots and snaps the sum to a carrier root. It does not use the historical fixed rank-table weights. Relation adds its graph reranking before this same selection and aggregation path. The Route read also uses Hamming distance, as a tie-break between ports (route read).

Hamming distance on E8 labels is not the E8 lattice distance, and decision D32 treats XOR and Hamming comparison on ternary and E8 labels as one component of a model, not as a Hamming-only model (ternary and XOR).

Where the model uses this

Where it stands

Go deeper

• Code: vsa_codes.rs, discrete.cu.
• Mechanism pages: VSA, ternary and XOR, flock read.
• Next: SpiralCore. Back to the overview.

SpiralCore

SpiralCore is an exact-geometry source, credited to Matthew (versions v63 and v69). From the multiplication table of the octonions (an eight-part number system) it produces a small set of exact moves on eight numbers: each move shuffles the eight coordinates and flips some signs. Every move can be undone exactly. The model stores earlier words in a tree with three branches per node (the "ternary FBS" tree, the project's name for it; see the glossary), and it carries a chosen eight-number block along a short path of these moves. No learned multiplication is involved, only swaps and sign flips. This chapter explains the moves, the tree, and how they connect to the other geometry. The integer form is the core of the current model. Terms are also defined in the glossary.

A ternary tree picks one stored block. The block then travels along exact edges between the 16 roots of an E8 orbit.

The exact moves

The table. spiralcore_operator.rs reproduces the SpiralCore v63 octonion and Cl(0,6) convention exactly. The octonions' seven oriented Fano lines are

\[(124)(235)(346)(457)(561)(672)(713).\]

The Clifford algebra Cl(0,6) has six generators that each square to \(-1\). Products of two distinct generators give the 15 bivectors \(B_{ij}\) (one per pair of the six, \(\binom62=15\)), with \(B_{ij}B_{jk}=-B_{ik}\). They mirror the way the semiprimes \(p_ip_j\cdot p_jp_k\to p_ip_k\) combine. The \(B_{ij}\) generate a group of order 64 that maps onto the 32 square-free even prime products, with kernel \(\pm1\). Together this gives a 64-state composition table. Each \(B\) is a signed coordinate permutation of \(\mathbb{R}^8\) with \(B^2=-I\).

The orbit. One anchor orbit holds 16 roots and 64 signed operator states, and an output block's carrier is moved by the composed edge history. A breadth-first search (BFS) over the labelled edges gives an ordered history between any two roots, composed by left-composition.

Exact inverse (proof). From \(B^2=-I\) it follows that \(B^4=I\) and so \(B^3=B^{-1}\). The inverse of a history is therefore the reversed sequence with each step cubed.

A worked step. The projection chooses one input block \(x_{\sigma(j)}\) for each output block \(j\) and sets \(y_j=A_jx_{\sigma(j)}\), where \(A_j\) is the composed signed action. The forward pass is a gather and a sign flip. There is no learned coefficient for any input-output pair, and the adjoint is the exact inverse action \(A_j^{-1}\delta_j\) (SpiralCore/FBS projection, proof by construction).

How the tree and the moves connect to the rest

The code is in spiralcore_operator.rs and cd_space.rs. The remaining links (icosians, Z[φ], Hopf) are in the other chapters. The semiprime-to-axis step needs a labelling choice, covered in E8, H4 and the 600-cell.

What carries route history

Octonion-signed binding, a design

A historical proposal: bind with a signed XOR whose sign depends on operand order, unlike plain XOR.

On the Fano plane, \(e_a\cdot e_b=\pm e_{a\oplus b}\): a signed XOR whose sign depends on operand order, unlike plain XOR (which is commutative and associative, so it loses order and grouping). Incidence alone does not define coherent octonion signs. The design is not on the current path, and it needs its own pre-registration and a TEST FITNESS: FIT review before compute. The canonical v63 Fano table in spiralcore_operator.rs is the control for it. It has not been tested against plain XOR (VSA mechanism page).

The 9 October substrate review

Mark (N3mesis)'s supplied Octonian Substrate Architecture and discussion PDFs motivate separating state, algebra, routing and identity. The review of that draft found the following.

• Its literal positive cycles \((123)(145)(167)(246)(257)(347)(356)\) fail alternativity and quadratic norm multiplicativity. For example, \((e_1+e_2)(e_4+e_7)=0\) although each factor has squared length 2. Fano incidence is not a complete sign convention.
• For the draft's XOR labelling, an exhaustive search of all \(2^7=128\) orientations of those seven lines finds 16 that give a valid octonion algebra (the enumeration is in the historical geometry tour; the review record states only the counterexample). One of them reverses three of the draft's lines: \((123)(145)(167)(246)(527)(437)(536)\).
• The sample store route discards a coordinate after right multiplication and projection, and its packing function returns empty bytes. A pre-route embed/project inverse does not establish post-route preservation.
• Modular \(\mathbb{Z}/2^{256}\) coefficients are neither the real normed division algebra nor a replacement for exact \(\mathbb{Z}[\varphi]\) pairs.

These findings concern the supplied draft. They are not a negative language experiment and not a retirement of octonion binding. The canonical Rust table is unchanged, and any alternative convention needs a signed basis correspondence, not just the same seven lines. The orientation in the draft is inconsistent with the canonical table and must not replace it (full review).

Where the model uses this

Where it stands

Go deeper

• Code: spiralcore_operator.rs, discrete.cu, build.rs, spiralcore_fbs.rs.
• Back to the overview, or on to the mechanism board.

The mechanism board

Most chat AIs are built from a few standard parts: a way to look back at earlier words (attention), a block that processes each word (a feed-forward layer), big grids of multiplications, and a function that scores every possible next word. UOR-R4 is trying to replace each of those parts with something built from geometry, such as rotations, exact addresses and lookup tables. Each replacement is called a mechanism. This page lists all 27 of them and says where each one stands today. Status here means how far a mechanism has been built and tested. No mechanism has produced a useful conversation yet: the project is pre-alpha, and 0 of its 8 milestones are complete (STATUS.md).

The 22 mechanisms with a recorded parent or child, drawn as a family tree. Most of the live ones descend from earlier, parked attempts.

What the three statuses mean

There is no "retired" status. Owner decision D22 says a negative result closes one tested configuration, never the mechanism, and stopping a mechanism needs the owner (D22). This board replaces the 18 October labels (active, dormant, archived-negative), which did not map one to one onto these three and had no rows for ten mechanisms.

Every number in the tables is a measurement from a recorded run or test, linked in its row, unless the cell says otherwise. The "Next" column is a hypothesis about what would help, not a result. A passing test is not a trained capability, and NOT_RUN is not a pass. BPB means bits per byte of text (lower is better). "FIT" means a pre-registered test was reviewed and judged able to answer its question.

The family tree

An arrow means "came from" or "was replaced by". A solid arrow is a successor, a dotted arrow means the target is the integer form of the source, and a double arrow means the target is a specialisation of the source.

flowchart TD
  r4g1["R4G1 graph<br/>PARKED"]
  nat["Native geometric engine<br/>PARKED"]
  lut["D11 integer serving<br/>ACTIVE"]
  stack["Geometric stack<br/>PARKED"]
  disc["Discrete learning<br/>ACTIVE"]
  pz["Prime-zeta codebook<br/>ACTIVE"]
  rel["Relation read<br/>ACTIVE"]
  obj["Object store<br/>READY"]
  rank["Rank-margin hinge<br/>ACTIVE"]
  cc["Carrier credit<br/>PARKED"]
  lc["Legal construction<br/>PARKED"]
  sfbs["SpiralCore/FBS<br/>READY"]
  tx["Ternary/XOR<br/>PARKED"]
  spin["Spin-native weights<br/>PARKED"]
  ham["Hamilton gate<br/>READY"]
  rec["Recurrence gates<br/>READY"]
  flock["Flock read<br/>ACTIVE"]
  route["Routed read<br/>ACTIVE"]
  ptr["Pointer key<br/>PARKED"]
  cells["Address cells (A8)<br/>ACTIVE"]
  mem["Exact memory<br/>PARKED"]
  e8["E8 orbit memory<br/>PARKED"]

  r4g1 --> nat
  r4g1 --> lut
  nat --> stack
  nat --> disc
  nat --> pz
  nat --> rel
  nat --> obj
  nat --> rank
  cc -.-> disc
  lc --> disc
  sfbs -.-> disc
  tx --> disc
  spin --> sfbs
  stack --> ham
  stack --> rec
  stack -.-> flock
  route --> flock
  flock ==> rel
  ptr --> rel
  pz --> cells
  mem ==> e8

  classDef ACTIVE fill:#d7f0e0,stroke:#1a7f4b,color:#0b2e1a,stroke-width:2px
  classDef READY fill:#dbe8fb,stroke:#1d4ed8,color:#0b1f4d,stroke-width:2px,stroke-dasharray:6 3
  classDef PARKED fill:#e5e7eb,stroke:#4b5563,color:#111827,stroke-width:2px,stroke-dasharray:2 3
  class lut,disc,pz,rel,rank,flock,route,cells ACTIVE
  class obj,sfbs,ham,rec READY
  class r4g1,nat,stack,cc,lc,tx,spin,ptr,mem,e8 PARKED

Five mechanisms have no recorded parent or child, so they are not drawn: admission, the tokenizer, Hopf observation, read binding and VSA. Source for all edges: the family_tree field of the mechanism board (19 October 2026).

ACTIVE: on the current model path (10)

READY: built and tested, not yet trained in (4)

PARKED: tested forms failed or broke a rule, still open (13)

Which mechanism covers each part of a transformer

Each row names a part of a standard transformer, says what it does, and lists the mechanisms aimed at it (A = ACTIVE, R = READY, P = PARKED). Source: the slot_map of the mechanism board (19 October 2026).

The two gaps matter. The only position-related result is about recurrent state transport, not word order, and it was measured in a model that used banned parts. The live discrete model has no position mechanism, no normalization and no feed-forward block, and it scores below a unigram baseline (audit synthesis, section 1). Having a mechanism for a slot does not mean it works: a row can list four mechanisms and no trained result.

Where the audit questions a status

Statuses are left as the audit dossiers set them (docs/labs/repo-renormalization-2026-10-19/audit/mechanisms/). Two are open to challenge:

• D11 integer serving is ACTIVE as the end-of-pipeline contract, but no lawful model has ever been exported through it, so READY may be more accurate.
• Hopf observation is PARKED, but its kept-fibre map is built and unit-tested and its language test never ran. Only sector routing failed, so splitting the two forms may be more accurate.

How to read a mechanism page

Each page follows the same order:

1. In one paragraph: the idea and what it replaces, in plain words.
2. Figure: a picture of the mechanism at work.
3. How it works: the mechanism and its maths, labelled as definition, measurement or hypothesis.
4. Where it stands: its status, the evidence behind it with sources, and for a PARKED mechanism what would reopen it.
5. Go deeper: the code, the archived records and the nearest neighbours in the tree above.

Read the status first, then the "Where it stands" table. A claim there is a measurement only if it names a recorded run.

Go deeper

• Glossary for terms such as admission, FIT and export gap.
• The geometry page for pictures of the operators.
• Decisions log for D22 (nothing is closed for good), D37 (offline float training) and D11 (integer serving).
• Archived lab records for everything dated before 18 October 2026.

Routed read (address-routed context access)

Status: ACTIVE. It is the base read of the pilot, rung-0 (the first full-length run, 16,404 updates) and four K16 runs (the Flock and Relation arms build on its tree; see flock-read and relation-read), but its own contribution has never been isolated: it received only 20 learning proposals in 16,404 updates (attention-state record).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

A transformer decides what to read by comparing the current word with every earlier word. This model does something cheaper. It keeps the earlier words at the ends of a small tree of geometric addresses. To read, it starts at the top of the tree and, at each level, steps toward the branch whose address is nearest to where the current state points. After a few steps it arrives at one earlier word and picks up that word's information. By construction it never scores the whole history, so the work should not grow with the context (a design property; speed was never measured). Whether this single pick is useful is still unknown, because nobody has switched it off to see.

What it replaces in a transformer

Attention: the step that decides which earlier positions to read. There is no query-key score table and no softmax. The read makes one hard choice per step and returns one earlier position's carrier vector.

The routed read walks a ternary tree over the context: one nearest port per level, one leaf at the end.

How it works

The model width is split into 8-dimensional blocks. Per block, the query is an integer vector \(q\in\mathbb{Z}^8\) taken at the last position. A ternary tree (a "BinderPlan" built by SpiralCore, the project's exact-arithmetic geometry library) is built over the context. Its leaves are earlier positions, and the context cap is 243 positions, which is \(3^5\).

Definition. Let \(G\) be the group of 64 signed-axis permutations of \(\mathbb{Z}^8\). Coordinates are permuted and sign-flipped by table lookup, so no multiplication is involved. Let \(R=\{r_0,\dots,r_{15}\}\) be the 16 roots of one E8 orbit, each a signed permutation of \((2,2,0,0,0,0,0,0)\). At level \(\ell\) the model holds one learned element \(a_\ell\in G\) and chooses a port \(p\) by hard minimum, where \(r_p\) is the orbit root tied to that port (schematic):

\[c_\ell=\arg\min_{p}\ \big(\lVert a_\ell q-r_p\rVert_1,\ \operatorname{Ham}(a_\ell q,r_p),\ p\big)\]

At level 0 the candidates are up to 16 frontier roots; at later levels they are the 3 children. Each choice composes a precomputed transport action between orbit roots (\(\mathrm{BFS}\) is a table built by breadth-first search over exact moves), so \(T_\ell=\mathrm{BFS}[\rho_{\ell-1}\to\rho_\ell]\circ T_{\ell-1}\). The output is \(T_L\) applied to the carrier vector of the leaf reached. This is a schematic of the kernel route_vector; the exact comparator is in the code.

Cost (proof, by construction). The work per block is about levels \(\times\) 16 distance comparisons. It does not depend on how many earlier positions exist. The cost of building and updating the tree, and tokens per second, were never measured in the audited records.

Content-blindness (proof). Port selection never inspects which token a leaf holds. Content enters only through the geometry of the query. That is why the read cannot express "copy the word after the earlier match"; see relation-read.

Learning. Training is discrete. Each route parameter is tried against its 15 generator moves in a counterfactual forward pass. The best move that strictly lowers the integer loss is applied. Nothing is differentiated (discrete-learning). The output vector goes to the shared writer (admission).

Rule check. No softmax, sigmoid or tanh (D23); no matrix multiplication, because the 8x8 "rotation" is a table lookup (D30). The kernel uses gather, sign flip, compare and integer add (D11), but no D11 served export or export-gap measurement of a trained Route model exists in the records.

What has been tried

Verdicts follow the audit: positive, negative, inconclusive, diagnostic-stop. Many older rows tested other forms (prime routing, float readers) that share the idea, not the kernel.

Reading these honestly. On rung 0 the runs were first limited by admission: most targets never reached the read. After K16 the cause of the weak ranking is open (ranking capacity, the read and the schedule all remain candidates), so these rows do not show whether routing helps or hurts. Rung 0 and the K16 runs used a codebook with only 16 distinct vectors at the start, so the read could not be separated from codebook drift. None of the failures closes the mechanism (D22: a negative closes a configuration, never a mechanism). Trajectory routing was found inert in its product probe, and the product probe of prime-route attention (#958) was NOT_RUN, so it is neither a pass nor a negative. That says nothing about routing inside a trained integer read.

What has never been tested

• Route against no read (a read-off ablation), and Route against Flock on a codebook whose addresses are distinct.
• Route trained with a schedule that gives it more than 20 proposals in 16,404 updates.
• The tangent-null and normal-null controls (move the address along the manifold versus across a branch), which the addressed-read brief requires to show the geometry is load-bearing.
• Spanning-tree addressing as addressing. Earlier variants were measured only as scoring changes.
• Served tokens per second of a routed read against a scored read at long context.
• Content-aware port selection.

What comes next

1. Run a read-off versus read-on ablation with enough Route proposals (an interleaved schedule or a dedicated Route stage). This is the next step named on the mechanism board.
2. Fix the codebook first: a fair test needs distinct addresses (address-cells, prime-zeta-codebook).
3. The float-era forms (spanning-tree router, address-as-read) may be re-registered as an offline float sheet under D37, with a fresh fitness review, an integer export and a reported export gap (hypothesis).

Open questions: how much of the 149 top-1 comes from Route; whether a content-blind read can reach the 3,847 copy-successor targets (the relational-head design argues from the kernel code that it cannot, which is why relation-read exists); which invariant should serve as address; and whether one 16-root orbit is enough atlas.

Also known as

ReadSpec::Route; invariant-addressed read; spanning-tree router; route-native or prime-route attention; read lineage (phase bind, rotation, carrier); the legacy uor-r4-router prime router.

Code

• crates/uor-r4-discrete/src/discrete.cu: kernel route_vector (lines 41-79) and the shared counterfactual kernels.
• crates/uor-r4-discrete/src/lib.rs: ReadSpec::{Route,Flock,Relation} and Parameter::Route.
• qualification.rs: the 11 finite CUDA controls. rows_device.rs: row-parallel scoring, about 56 times faster with identical losses.
• Float-era, dormant: crates/uor-r4-training/src/stack_address.rs, geometric_address.rs. The legacy crates/uor-r4-router/ does not build against the current core (#2345) and is kept as evidence.

Related mechanisms

flock-read replaces the single leaf with a consensus of several neighbours. relation-read adds links Route cannot express. admission consumes the routed vector and is where rung 0 first hit a measured limit. address-cells and prime-zeta-codebook give positions their addresses. spiralcore-fbs supplies the transport table and the tree. discrete-learning trains the route parameters. exact-memory is the older idea of routing to an exact prime address.

Flock read (starling / murmuration neighbour read)

Status: ACTIVE. The integer Flock kernel passes its finite CUDA construction controls and runs inside every Relation and control arm. But no run has ever isolated what the Flock read itself contributes (attention-state record).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

A starling in a flock does not watch the whole flock. It watches about seven nearest neighbours and turns toward their average heading. The Flock read works the same way. At each step the model picks a handful of earlier positions that sit closest to the current one, rotates what each one knows into the current position's point of view, and takes their consensus. Then it nudges its own state toward that consensus. Nothing is normalised, no scores are exponentiated, and no weights are multiplied. Whether this beats simply reading one position is still untested on real text.

What it replaces in a transformer

Attention, both halves: choosing which earlier positions to read, and mixing what was read into the current state. A transformer weights every earlier position with a softmax and sums them. Flock keeps a few by hard integer ranking and adds their rotated consensus with a three-valued dial.

The flock read on the 600-cell: a query point, its seven nearest neighbours, their rotation into the query's frame, and the consensus they produce. The live integer version uses 16 frame roots in place of the 600-cell (inset).

How it works

The float-era picture (inactive evidence). The 600-cell is a four-dimensional solid with 120 vertices, and each vertex has 12 neighbours. Each token was given a home vertex. A query read only the tokens stored at its own vertex and the 12 adjacent ones, kept the nearest seven, and moved their values into its own frame using exact icosian transport. Those experiments ran in floating point, with the selection on the host and softmax helpers during training.

The live integer form. Per 8-dimensional block, context sits in a ternary tree whose leaves are earlier positions (route-read uses the same tree). Each interior node holds the snapped sum of its three transported children. For each tree level \(\ell\) there is one learned gate \(g_\ell\in\{-1,0,+1\}\).

1. Rank (Definition). Eligible nodes at level \(\ell\) end strictly before the query. Keep the best \(K\) (\(1\le K\le 8\)) under the lexicographic key \(\big(d_{L1}(f_n,f_q),\ d_{H}(f_n,f_q),\ -\mathrm{last}(n),\ n\big)\). Here \(f\) is a node's frame root among the 16 roots of one E8 orbit and \(d_H\) is coordinate Hamming distance.
2. Carry. Each kept payload \(p_n\) is moved into the query's frame by the precomputed transport action between the two roots: \(c_n=\mathrm{BFS}[f_n\to f_q]\,(p_n)\).
3. Consensus. \(m_\ell=\operatorname{snap}\big(\sum_{n\in\text{kept}}c_n\big)\), the nearest of the 16 roots.
4. Gated add. \(v\leftarrow v+g_\ell\,m_\ell\). Trit \(+1\) adds the consensus root, \(-1\) subtracts it, \(0\) skips the level. The output is \(v\) snapped back to a root.

This is built as an integer form of the Vicsek/Kuramoto alignment rule \(\Delta=K_h(\text{mean}-v_t)\) with \(K_h\in\{-1,0,+1\}\): align with the local flock, with no weights, no normalisation and no division. That correspondence is the design intent; the page makes no equivalence claim.

Rule check. Hard rank by integer keys, so no softmax (D23). No matrix multiplication (D30). The kernel uses gather, compare, add and subtract, and the snap is built by repeated addition (D11). No D11 export of a trained Flock model has been built or measured.

Cost (hypothesis). The tree variant should read in about \(O(\log n)\) steps. That has not been measured in the integer form.

What has been tried

Almost all evidence below is from the float era, on a synthetic 512-to-1,536-token recall task or a small language-model recipe, with host-side selection and softmax helpers. It is inactive evidence under the no-softmax rule (D23). It shows what that recipe did, and it cannot judge a hinge-credited integer flock. "Recall" means the share of queries whose stored value was read back correctly.

Reading these honestly. The M4 stack and the starling rungs were softmax-tuned, short-context and host-side. The ring-store collapse is eviction, which the tree fixed. The two October control runs lost admission to learning moves first (admission), so the read was never the thing being measured. SoftSort was closed by owner decision, not by a measured negative. D22 applies: these close configurations, not the mechanism.

What has never been tested

• Flock as a stand-alone integer read trained on the corpus and compared with Route. No arm tests the transported-consensus read against Route.
• A read-off versus read-on ablation of Flock inside the control arm.
• The lawful no-softmax decisive run (in-context recall on copyable development targets).
• Flock on a codebook whose addresses are distinct and stay admitted.
• K and M at long context, and the sink and local-window variants in integer form.
• A float-trained coupling magnitude, rank-consistent soft-to-hard selection, and the tree read in integer form.
• A chirality sign on the coupling.
• Served tokens per second of a flock read against a scored read at long context.

A fair test needs

From the earlier brief, archive/mechanisms/starling-read.md.

• A training signal for the addresses: soft-to-hard annealing works (rung 2).
• A readout that keeps the right source's information: under the murmuration read this is the transported flock mean, scored by flock coherence and the source-in-flock rate.
• Recall measured by distance bucket (so eviction is distinguishable).
• More than one read layer before any multi-hop claim.

What comes next

The mechanism is ACTIVE, so this is a plan, not a reopening.

1. Coupling sheet (C1). Train a float coupling strength per head and level over the fixed integer Flock topology. Export it to a trit or small integer. Include zero-coupling and random-coupling controls, 2 seeds or 200 fresh rows, and a reported export gap. It is a draft (sheet) and is not registered.
2. Soft-to-hard selection (C2). Use a rank-consistent hinge and a linear anneal, with no temperature exponential, ending at the exact integer rank. Score it by how often the source is in the flock, and by rank-1-when-kept by distance bucket.
3. Tree read (C3). Use the tree for \(O(\log n)\) reads, only after C1 shows the coupling learns, and with tokens per second reported first.

Any retry of the float starling or rank-table forms needs a fresh fitness review, an owner release, a separately scanned float module, a D11 integer export and no softmax surrogate.

Also known as

ReadSpec::Flock; starling read; murmuration read; starling_native (rung 0b); flock or rank-table reads; softmax-free read; seven nearest neighbours on the 600-cell.

Code

• crates/uor-r4-discrete/src/discrete.cu: kernel flock_vector (lines 125-269) and snap (102-110).
• lib.rs: ReadSpec::Flock { kept }, the gate trit parameter, and ReadInitialization::ActiveLeafV1, which sets gates to +1 so the read is not causally dead at the start.
• flock_qualification.rs: six finite CUDA controls.
• Inactive evidence: crates/uor-r4-training/src/starling_native.{rs,cu}, flock.rs, geometric_stack.rs. The served integer selector for the older lookup stack is crates/uor-r4-integer/src/stack/flock.rs.

Related mechanisms

route-read: Flock replaces Route's single leaf with a transported consensus. relation-read: Flock plus a reranker; with all relation dials at zero it is bit-identical to Flock. admission: every Flock-equivalent run was limited by admission first. rank-margin: the hinge that replaced the softmax surrogate. spiralcore-fbs: the transport table and tree. hopf-observation: considered for neighbour keys. exact-memory: the persistent tree is an exact addressed store of the past.

Relation read (finite relational head)

Status: ACTIVE. It is built, passes 9 of 9 finite CUDA controls, and has trained twice. Both training runs were stopped by loss of admission before the read could be judged, so there is no verdict yet (A8 dose record).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

Much of language works by copying. When you meet a word you saw earlier, the next word is often the one that followed it last time. The Flock read finds earlier positions that look like the current one, but it cannot say "take the word right after that earlier copy." Relation adds that ability. It lets the read follow simple links between positions: the word right after, a sibling in the same phrase, the same word again. Each kind of link is controlled by one three-position dial: off, boost or penalise. With every dial off, the model behaves exactly like Flock. The dials have been trained twice, but never long enough to judge them.

What it replaces in a transformer

The scoring half of attention, which decides which earlier positions matter. In a transformer, copying the next word is done by "induction heads" that learn a query-key match pattern. Here the same habit is a bounded, exact rerank by link type. There is no learned score table and no softmax.

The copy-the-next-word read on "x A B y z A": the dial for "successor" passes the earlier A's score on to B.

How it works

Relation is Flock plus a reranker. The pool is every causally eligible node of the same ternary tree that Route and Flock use. Five link types come from retained structure only:

Definition. For a query with frame root \(f_q\), each node \(i\) starts with a match score \(m_i=8-d_{L1}(f_q,f_i)\in\{0,4,8\}\). Each (link type \(e\), tree level) has a learned trit \(g[e,\ell]\in\{-1,0,+1\}\), which makes 25 dials for five levels. For sweeps \(t=1,\dots,S\) (\(1\le S\le5\)):

\[r_i^{(t)}=r_i^{(t-1)}+\sum_{e=0}^{4}g[e,\ell(i)]\sum_{j\in\mathcal{N}_e(i)}s_j^{(t-1)},\qquad s^{(0)}=m,\ \ s^{(t-1)}=r^{(t-1)}\ (t\ge2)\]

Here \(\mathcal{N}_e(i)\) are node \(i\)'s neighbours under link type \(e\). Candidates are ranked by \(r_i^{(S)}\) first, then by the Flock keys (frame distance, Hamming distance, recency, node id). The top \(K\le8\) feed the unchanged Flock transport, consensus and gated add.

Worked example. In "x A B y z A" the query is the final A. The earlier A has the same frame, so \(m=8\). Set the level-0 successor trit to \(+1\) with one sweep. B receives \(r=+8\) and outranks every candidate with \(r=0\), whatever that candidate's own frame distance. B's payload is carried in. That is the copy-successor read.

Two facts that follow from the code (proof).

• With every trit at zero, all scores are zero and the ranking is bit-identical to Flock. This is the rollback identity, and it is the control used in training.
• Scores are integers bounded by \(8\cdot(1+8)^5=472{,}392\), far below \(2^{31}\), so plain integer addition suffices. No multiplier, no float, no clamp.

Why Route and Flock cannot do this (proof, from reading the kernel). Both rank each node by its own frame and carry that node's own payload. The successor's frame has no fixed relation to the query's frame, so neither read can promote a node because its predecessor matched. The design record makes this argument in full.

The target is large (measurement). On the pinned development panel (14,287 eligible rows, context 192), the query token recurs earlier in 8,648 rows, and the target is the word after the latest earlier copy in 3,847 rows (26.9%). This is the copy-successor sub-panel, called \(P_{succ}\) here. Its distance buckets 1-8, 9-32, 33-96 and 97-192 hold 50, 2,872, 900 and 25 rows.

Learning and the bar. The trits reuse the existing gate parameter kind and are learned by counterfactual moves (discrete-learning) on a schedule where every eighth batch is a read batch. To count, a trained Relation must beat a context-free successor table (called T2), which scores 6,300 of 14,287 top-1 in a host re-score, while the trained Route read scored 149.

Rule check. Hard top-K by integer keys (no softmax, D23); no matrix multiplication (D30); integer compare, gather, add and subtract (D11). No D11 export or export gap exists for a trained Relation artifact.

What has been tried

Reading these honestly. In the A8 dose, the Relation arm fell faster, which coincides with 87 accepted relation-trit updates. That is co-occurrence, not attribution. Both arms lost admission to learning moves, and the sheet named this risk before the run. Under the project's diagnostic-stop rule (D31) and the rule that a negative closes a configuration, never a mechanism (D22), these are diagnostic stops: not negatives, and not a KEEP. The fresh transfer slice has never been opened.

What has never been tested

• A full-dose Relation arm paired against its control with admission intact.
• Whether the level-0 successor trit is ever learned, and what it buys on the 3,847-row sub-panel.
• Relation against the T2 table and against Route in the matched discriminator.
• More than one sweep, the other four link types, and any level above 0.
• Whether the interleaved schedule gives the read enough proposals.
• Relation with admission-preserving acceptance, at K=16, or on a fully injective address-structured codebook together.
• Cost and tokens per second at serving shape.

What comes next

1. Admission-preserving A8 rerun. A guard audits a fixed anchor of 3,847 training rows every 64 batches and rejects any interval that erodes admission (margin 24). It stops as a no-op if the rejection rate exceeds 0.50. The sheet is FIT; the controller and verifier merged (UOR-Foundation/uor-r4#2782, #2783); finite qualification, project-manager dispatch and an owner-typed release are outstanding.
2. Stage M2 discriminator. A matched interleaved Relation against Route, with a zero-trit ablation. Still held and awaiting a fitness review.
3. Float extension (hypothesis). A float-trained version of the 25 trits (D37) only after a Relation KEEP, with an integer export and a reported export gap.

Open questions: whether the guard rejects so many intervals that learning does nothing; whether copying is better delivered by the read or by a successor table beside it; and which of the 25 dials matter beyond level 0.

Also known as

ReadSpec::Relation; finite relational head; bounded exact-relation reranker; D34 reranker-first; copy-successor or induction read; relation trits; the Dose 1 and A8 Relation arms. Some older notes call the row-parallel run "Dose 2" because its attempt id contains dose2-rows. This page follows the audit and calls it Dose 1.

Code

• discrete.cu: the Relation branch inside flock_vector (lines 164-212) and the comparator at line 236.
• lib.rs: ReadSpec::Relation { kept, sweeps }, RELATION_EDGE_TYPES = 5.
• relation_qualification.rs: the 9 controls. training.rs: the interleaved schedule and the frozen-zero control.
• attention_learning.rs, attention_preflight.rs, attention_transfer.rs, attention_audited.rs.
• Design record: finite-relational-head.md.

Related mechanisms

flock-read: relation-off equals Flock. route-read: cannot express copy-successor. admission: the ceiling that stopped both doses. address-cells: the codebook change that restored starting admission. prime-zeta-codebook: the injective constructor. object-store: the companion D34 line, not attention. discrete-learning: the move law and the speedup that train the trits.

Admission (cell shortlist before the token is chosen)

Status: ACTIVE. It is the output step of the current model and the first measured binding limit, seen on rung 0 and for the top-8 bar (after K16, the cause of the weak ranking is open): the correct word often is not in the shortlist at all (attention-state record).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

Before the model picks a word, it narrows its 4,096 possible words down to those stored in a few "drawers", the drawers nearest to where its read points. A word in a drawer that was not opened can never be chosen, however good the read was. So the number of correct words whose drawer gets opened sets a ceiling on everything upstream. This ceiling was the limit on rung 0; the later K16 runs show that a high admitted count alone does not give good ranking. In several runs, learning itself pushed correct words out of the opened drawers, so the number of reachable answers fell during training. The next registered run adds a guard against that.

What it replaces in a transformer

The output head: a transformer scores every word in the vocabulary and normalises with a softmax. This model never scores all 4,096 words. It makes a hard shortlist of cells, then picks the nearest word inside it. There is no softmax and no normalised distribution.

Admission: only words in the lit drawers can be chosen. In the A8 control run, the number of copy-successor targets in lit drawers fell from 1,351 to 857 of 3,847 within 4,096 batches.

How it works

The writer takes the read's integer vector \(q\) (\(B=4\) blocks of 8 numbers) and picks a token in two steps.

Definition (admission). Each token \(t\) has a codebook vector. Its cell is the pair \(c(t)=(\rho_{\text{first}}(t),\rho_{\text{last}}(t))\) of orbit-root labels of its first and last block, so there are \(16\times16=256\) cells. The address distance from \(q\) to a cell is the L1 distance of \(q\)'s first block to the cell's first root plus the same for the last block. The \(K\) nearest occupied cells are admitted, ties by cell number. \(K\) is 8 in the lineage of record and at most 16.

Definition (ranking). Among tokens in admitted cells, the nearest by total L1 over all blocks wins. Ties go to the lowest token id.

Consequence (proof). A target outside the admitted cells cannot be predicted whatever the read does. So top-1 hits \(\le\) top-8 hits \(\le\) \(N_{\text{adm}}\), the number of rows whose target cell is admitted. Rung 0 shows the force of this. Its top-1 bar was 1,941 rows, but only 1,920 targets were admitted at the end, so the bar was arithmetically unreachable.

Training hinge. Learning uses an integer hinge: \(8\times\) the token margin plus \(32\times\) a cell term. The two cell terms are objective A (the margin to the nearest rival cell) and objective R (how many occupied cells outrank the target beyond \(K\)). The weights are applied by shift-and-add, with no multiplier (rank-margin).

Why learning erodes it. Codebook moves change a token's cell. A move that improves the loss can eject a target from the shortlist. The admission-preserving rule audits a fixed anchor panel every 64 batches and rejects any interval that shrinks admission.

Rule check. Hard top-K and a hinge over declared rivals: no softmax (D23). Sums of absolute differences, no matrix multiplication (D30). Integer only (D11), but no served export of an admission artifact has been measured.

What has been tried

Terms: \(P_{succ}\) is the 3,847-row copy-successor sub-panel (see relation-read). Q1 and Q4 are the checkpoints at 4,096 and 16,404 batches. The full panel has 14,287 rows. "Gate" is a pre-registered pass line.

The K16-R pass is hollow. Objective R collapsed the codebook onto about 20 occupied cells. Each row then admitted about 3,400 of the 4,096 tokens, so "admission" was nearly pass-through. The registered occupancy check fired on both seeds, and the call was no KEEP. Objective A kept 192 to 209 cells but lost admission. Both are negatives for these exact configurations, and D22 says no mechanism family is closed by them. Widening \(K\) at evaluation time closes only that route for that codebook; lineages trained with \(K>8\) remain open.

What has never been tested

• Admission-preserving acceptance during learning (registered and fit, never run).
• A lineage trained at \(K>8\) with distinct, address-structured cells, to full dose.
• Ranking once admission is intact. No run has had admission intact and then succeeded or failed at ranking.
• An address that uses more than the first and last block of \(q\) (full-vector, interior-block or cell-envelope).
• An occupancy-regularised objective that does not collapse to about 20 cells.
• Fresh-slice transfer of any admission result. The sealed 2,000-row slice has never been opened.
• Whether admission capacity trained in at \(K=8\) can reach the 4,894 gate.

What comes next

1. Admission-preserving A8 rerun with the 64-batch anchor guard. The controller is merged (UOR-Foundation/uor-r4#2782). Finite qualification and an owner-typed release are outstanding.
2. Occupancy-regularised or load-balanced rank objective, the registered route after the K16 collapse.
3. A finer address metric if admission stays capped at \(K=16\).
4. \(K>8\) on an injective, address-structured codebook.

Open questions: why learning moves targets out of the cells that predecessor placement chose, and how fast; whether the guard's 24-row margin rejects so much that learning becomes a no-op; whether 256 cells are too coarse; and when ranking, not admission, becomes the bottleneck.

Also known as

Kept cells or \(K\) shortlist; target admission; Q1 admission collapse; the B3_init and G-Cap gates (starting and capacity checks on reachable targets); \(P_{succ}\) admission; G-Adm and G-Occ (the admission and occupancy gates); the admission-preserving guard.

Code

• discrete.cu: address_distance (line 274), token_cell (286), cell_precedes (301) and the writer (307-345).
• objective.rs: objectives A and R. coverage_census.rs, address_cells.rs, prime_zeta.rs: codebook census and placement.
• attention_anchor.rs, attention_audit.rs, attention_audited.rs: the guard.
• rows_device.rs: the row-parallel scoring, about 56 times faster, that made the K16 and A8 doses affordable.

Related mechanisms

address-cells sets which cell each token lives in. prime-zeta-codebook is the injective initialiser. route-read is the read whose output admission consumes. relation-read and flock-read had doses stopped by admission loss. rank-margin is the hinge family. discrete-learning is the move law that trains the table.

Prime-zeta codebook

Status: ACTIVE. The constructor is built and qualified, and its table is wired in as the start for new training lineages. No trained artifact has started from it yet: rung 0 and K16 began from a seeded 16-vector table. It is the baseline arm of the 19 October pre-flights and the fallback cell inside the address-structured table. No run has yet trained it against its two matched controls. That comparison is NOT_RUN and held (construction record).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

A language model has to start every word somewhere. The usual start is random numbers. In this project the random start gave 4,096 words only 16 different starting positions, so many words were indistinguishable. This mechanism gives every word its own fixed address instead. A word's place in the vocabulary picks a prime (2, 3, 5, and so on), and the prime is turned into a set of angles using the known frequencies of the Riemann zeta zeros. Everything is computed once, offline, and stored as a table of small whole numbers. Whether the zeta angles help beyond simply keeping words distinct has not been tested.

What it replaces in a transformer

The token embedding table. A transformer starts each token with a random vector and learns it. Here the starting table is constructed, fixed and made of integers. The model can still change it later through its learning moves (discrete learning).

A word's prime sets eight dial angles, and the angles pick a cell on a 16 by 16 board. The random start put 256 words on each of 16 patterns. This table puts 16 words in each of 256 cells, all distinct.

How it works

Prime address (Definition). Token \(v\) with vocabulary id \(\mathrm{id}(v)\in\{0,\dots,V-1\}\) gets the prime \(p_{\mathrm{id}(v)+1}\). The vocabulary maps one-to-one onto the first \(V\) primes, and \(p_{4096}=38873\).

Zeta phases (Definition). Take the first 512 imaginary parts \(\gamma_k\) of the zeta zeros from a pinned table of published values. The phase and phasor of channel \(k\) are \[\theta_k(p)=\gamma_k\ln p \pmod{2\pi},\qquad z_k(p)=\cos\theta_k+i\sin\theta_k .\] Using a finite table of these constants does not require solving the Riemann hypothesis.

Quantize and place (Definition). Four consecutive channels per 8-dimensional block form a vector in \(\mathbb{C}^4\). It is split into two \(\mathbb{C}^2\to\mathbb{R}^4\) spinor pairs and stored as integers (PhaseQ29, UnitS3Q30). The pairs are embedded in the four orthogonal 2D root planes of a 16-root orbit of the E8 lattice. Each block takes the orbit root with the largest exact integer inner product.

Cells (Definition). A token's writer cell is the pair (root of block 0, root of the last block). That makes a \(16\times16=256\) cell grid. Two passes then run:

1. A quota pass puts exactly \(V/256=16\) tokens in each cell.
2. A uniqueness pass gives interior blocks distinct roots, so all 4,096 full vectors differ.

Where floating point lives. The logarithm, sine and cosine are confined to this one-time host step, under the October 14 zeta-zero exception. The output is an integer table loaded as the model's starting table (pinned_table_v1). The served model sees only integers.

Two matched controls share the same pipeline. TangentNull shifts every \(\gamma_k\) by 1.0. NormalNull permutes the primes and moves the phases off the critical line.

An honest caveat (proof, by reading the code). The quota and uniqueness passes also run on both controls. So the zero collisions come from those passes, not from prime phases. The seed does not change the PrimeZeta table: seeds 0, 1 and 2 give identical tables.

Rule check. No softmax or squashing (D23). No matrix multiplication; each token is scored by a few 8-element integer inner products, once, on the host. This is data preparation: no model quantity is computed there (D24, D30). The compiled integer module contains 0 floating-point instructions (D11, D32). Float is allowed here only by the October 14 exception.

What has been tried

Almost all of the evidence concerns construction and admission. No row measures language quality. "Admitted" means a target word sits in one of the few cells the reader opens (admission).

Reading these honestly. The last row closes the configuration "spread words evenly at K=8". The record calls it an instrument-reachability problem, not a failure of prime-zeta geometry. The older retrieval results ran on a previous store, and one of them was a banded-storage artifact. None tests zeta phases inside a token codebook on the current stack, and the #958 and #973 results never isolated the zeta term. D22 applies: these close configurations, not the mechanism.

What has never been tested

• Trained attribution. PrimeZeta against TangentNull, NormalNull and a quota-only injective control, at matched budget, with at least 2 seeds or 200 fresh rows.
• Meaning in the phases. Primes are assigned by token id, which is arbitrary, so the phases encode identity and not meaning. No test checks whether phase-near words behave alike (hypothesis).
• Any language effect. Every result is construction, census or zero-update admission.
• Seed variance. The table is a function of token id alone. Seed diversity needs a declared extra axis, such as a channel offset or batch order.
• Special tokens (start, end, pad) with reserved small primes or fixed points.
• Zeta phases as a position encoding on the discrete stack.

What comes next

The mechanism is ACTIVE, so this is a plan, not a reopening. A trained-in comparison needs its own pre-registered sheet that passes TEST FITNESS: FIT, plus the owner's training release. The sheet should report admission, top-1 and top-8, separated hinge losses and fresh transfer. Since the address-structured table now places words by their predecessors, a second question is whether this table still earns its place as the fallback, or whether a random injective table would do the same job.

Also known as

Prime-rank indexing plus zeta-phase routing; prime-zeta complex routing; CodebookMode::PrimeZeta; the "P8" baseline arm of the 19 October pre-flights; pinned_table_v1 (the loader that carries it); the complex-plane zeta-zero exception (October 14); ancestors: the prime router, prime-route attention, the 16-window zeta projection and the phase-clock design.

Code

• crates/uor-r4-discrete/src/prime_zeta.rs: the constructor, the quota and uniqueness passes, both controls and the zero-float PTX check.
• prime-zeta-qualify.rs and prime-zeta-codebook.rs: qualification and table export.
• training.rs: the pinned_table_v1 loader and the checkpoint-0 check.
• coverage_census.rs: distinct vectors, alias groups and tie mass.
• crates/uor-r4-core/src/zeta_zeros.rs: the 512 pinned zero ordinates.
• Pre-registration: m1-prime-zeta-complex-routing-2026-10-14.md.

Related mechanisms

address-cells: builds on this table and uses it as the fallback for words with no placed predecessor. discrete-learning: loads this table as its starting codebook. admission: its gates exist because spreading over 256 cells starves the reader. spiralcore-fbs: supplies the E8 orbit roots. route-read, flock-read and relation-read: the reads that consume these addresses. exact-memory: also uses primes, as exact keys rather than phase sources. hopf-observation: shares the unit-quaternion helpers. tokenizer: fixes the vocabulary size \(V\).

Address-structured cells

Status: ACTIVE. This is the starting table of the live attention line. At zero training it lifted the number of next-word targets the reader can reach from 127 to 1,351 of 3,847. Training then eroded that gain, and the first learning run stopped at its first checkpoint. No paired verdict exists, and the admission-preserving controller built to fix the erosion has not yet run on a GPU (A8 dose, pre-flight).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

Picture a 16 by 16 board of 256 cells. Each of the 4,096 words gets a home cell, and every cell holds 16 words. The trick is where words go. A word is placed next to the cells of the words that usually come just before it in the training text. Only about 1,350 words are placed this way; the other 2,749 of 4,096 have no placed predecessor and are placed by the prime-zeta fallback (rule 4 below). When the model has just read a word, the reader looks only at a few nearby cells. If likely next words live in those cells, the right answer is at least in view. This is a table made before training, and it changes nothing about how the reader works. It only decides what the reader can see.

What it replaces in a transformer

The token embedding table, in the part of its job that decides which tokens the next-word step can consider. A transformer's output step scores every word in the vocabulary. This model scores only the words in the cells it opens (admission), so where each word lives limits what can be chosen.

The same board with three placements. With the address-structured table the likely next words sit near the last word's cell, so more of them fall inside the eight opened cells.

How it works

Cells. A word's writer cell is the pair (root of block 0, root of the last block) on a 16-root E8 orbit, the same \(16\times16=256\) grid as the prime-zeta codebook. All 4,096 full vectors stay distinct.

What the reader can see (Definition). The reader admits the \(K=8\) occupied cells nearest its output \(q\), by L1 distance on those two root blocks, and can rank only the words inside them. Placement therefore decides visibility.

Building the table (Definition). This is host data preparation from the training split only.

1. Count integer bigrams \(s\to t\) at the positions where the model must answer, with \(s\) the last context word.
2. Take words by falling frequency (ties to the lower id).
3. Put each word in the cell \(c\) that minimises \[\sum_{s\ \text{placed}} \mathrm{count}(s\to t)\; L_1\big(\mathrm{cell}(s),\,c\big)\] subject to a quota of 16 words per cell.
4. A word with no placed predecessor goes to its prime-zeta cell if free, else the nearest cell with room. Inner blocks get distinct root pairs by rank in the cell.
5. A recount requires 4,096 distinct vectors with every cell at quota.

The control. The shuffled table (S8) runs the same greedy search with predecessor identities relabelled by a seeded permutation. It keeps frequency, quota and total mass but destroys the relation, so it separates "words placed near their predecessors" from "words packed neatly".

A stated gap (proof, by reading the construction). The reader's real centre is the last word plus the consensus of the context read, not the last word's cell alone. Placement only partly predicts admission for that reason. The gap was reported, not tuned away.

Rule check. The construction is integer counting and integer L1 sums, with no floating point, so there is no export gap. No softmax, no squashing, no matrix multiplication (D23, D30). Host work is data preparation only; no model quantity is computed there (D24).

What has been tried

Every number in the last four rows is a count of reachable target words on the development panel. None is an accuracy, loss or reply quality.

Reading these honestly. Placement works at zero training: it moved reachability ten-fold at the same \(K\) and the same board, and the shuffled control shows the predecessor relation, not neat packing, explains most of it. That is evidence the reader can now see its targets, not that it can learn to pick them. The dose then lost reachability in both arms (control down 37%, relation down 59%), consistent with accepted learning moves carrying words out of their placed cells. That is co-occurrence, not attribution. The earlier failures all ran on a start with 16 distinct vectors, so they close that start, not attention. The record's own risk section predicted the erosion and called it a diagnostic stop.

What has never been tested

• Whether the reader can learn on a well-placed table at all. No run has produced a paired development verdict.
• Any accuracy, ranking, bits-per-byte or reply quality for this table.
• Placement that also uses successor edges. Version 1 lets only already-placed predecessors pull a word.
• Placement keyed on the real read centre instead of the last word's cell.
• The compact 32-cell form, \(K\approx34\) or more, and partly injective tables.
• More than one shuffle seed, and training from the K=16 bracket arms.
• The admission-preserving rule in a real GPU run, and a finer, cell-level census of which moves eject which words.
• Other shapes, such as 16,384 words on 512 cells (planned after the dose).

What comes next

The mechanism is ACTIVE, so this is a plan, not a reopening. First comes the GPU qualification of the merged controller, then the admission-preserving rerun of the learned dose. Two risks are on the record. The rule could turn into a no-op if it rejects more than half the intervals, or three full intervals in a row. And \(K=8\) may be too small as occupancy grows. A relation arm must also beat the successor-table comparator (top-1 on 6,300 of 14,287 development rows) to count as learning.

Also known as

A8 (address_structured_v1); S8 (the shuffled control); P8, P16 and A16 (uniform and K=16 bracket arms); injective codebook initialisation; 256 by 16 cells; predecessor-structured placement. Not to be confused with the October 4 "observable geometric observation cells", which are a different, older mechanism that shares the word "cells".

Code

• address_cells.rs: bigram counts, the greedy build with quota and recount, the shuffled control.
• address-cells-codebook.rs: the exporter. It reads the training split only and never the development panel.
• attention_preflight.rs: the zero-update battery.
• attention_learning.rs: the relation-versus-frozen-zero dose with its first-checkpoint stop rule.
• attention_anchor.rs and attention_audited.rs: the admission-preserving controller.
• coverage_census.rs: alias ceiling, tie mass and crowding.
• Pre-registered sheets: pre-flight and training dose.

Related mechanisms

prime-zeta-codebook: parent and baseline; its cell is the fallback. admission: defines the gates that decide whether this table is any use. relation-read: the arm the dose was meant to test. flock-read: its consensus shifts the read centre away from the last word's cell. route-read: the read used in the two-objective redirect. rank-margin: the occupied-cell hinge that collapsed occupancy, the failure this table avoids by fixing the table instead of the objective. discrete-learning: the shared writer whose accepted moves erode the placement. spiralcore-fbs: source of the E8 orbit roots.

Vector-symbolic binding (hypervector codes)

Status: PARKED. Trained into the older prose learner, the idea lowered held-out bits per byte by 0.014 to 0.023 on 2 seeds and 2 slices. But that run used a CPU learner (the record says it belonged on the laptop; since 12 October the owner rule D24 bars CPU model compute), and the variants that tried to add geometry failed. The idea is not on the current discrete path. It stays open: what would reopen it is listed below (native test).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

Give every word a long string of 4,096 bits. To glue two things together, such as a role and a word, flip the bits of one wherever the other has a one (XOR). Applying the same glue again undoes it. To merge many strings into one summary, take a majority vote at each position. To tell whether two strings are alike, count how many positions differ. In the older prose model this gave the next-word score a cheap cue: "was this word recently in the context?" It is a lossy sketch. Exact copies still need an exact lookup.

What it replaces in a transformer

Part of the key-value memory: the cue that says whether something stored earlier matches the current query. A transformer compares a query against every stored key with dot products. A hypervector sketch compares bit strings by counting differences, using only XOR and bit counts.

Bind, bundle and probe on bit strips, and three ways to choose each word's code. Only the random-hash codes helped.

How it works

A hypervector has \(D=4096\) bits.

• Bind (Definition). Bitwise XOR. It is its own inverse: \((A\oplus B)\oplus B=A\). That follows from the definition of XOR (proof).
• Order (Definition). A cyclic bit rotation marks position.
• Bundle (Definition). A bitwise majority vote over a context window of up to 64 terms, with a fixed tie-breaker.
• Similarity (Definition). Hamming distance \(d_H\) from a bit count, turned into a bipolar correlation \(1-2d_H/D\) in Q1.15 fixed point.

Cross-talk (standard estimate, proof for random codes). Unbinding a bundle of \(k\) random bipolar terms returns the stored value plus noise with standard deviation about \(\sqrt{(k-1)/D}\). So 64 terms in 4,096 bits leave a signal-to-noise ratio near \(\sqrt{4096/63}\approx 8\). This is the textbook figure for random codes, not a measurement on this model.

How the older prose scorer used it. One additive feature per candidate word: \[\text{score}\mathrel{+}=\big(\text{vsa\_scale\_q15}\cdot \mathrm{corr}(\text{context vector},\ \mathrm{code}(\text{candidate}))\big)\gg 16 .\] The context vector bundles an associative transition context and up to four "orthogonal VSA attention" heads. The scale is trained. The codes are not.

Three ways to choose a word's code.

Rule check. The bit operations contain no softmax and no matrix multiplication. The Q15 scale multiply is a runtime product that has not been shown to be table-only, so it is not audited against the zero-multiplier serving rule (D11). The host learner that trained the scale was not audited against D23 here. The 9 October run used a CPU learner (the record says it was meant to run on the laptop, owner rule #2095). D24, dated 12 October, now bars CPU model compute. Binary 4,096-bit codes are not part of the current discrete path (D32). D32 welcomes XOR and Hamming comparison on ternary and E8 labels as one component of a model, not as a Hamming-only model.

What has been tried

Reading these honestly. The one clear gain is real but narrow. The two seeds differ by about 0.015 bits per byte, the same size as the effect, and the cross-arm comparison is a point estimate because the logs did not keep per-position losses. The same model's exact-memory table (the engram) is worth about 0.19 to 0.20 bits per byte, over ten times what VSA adds, so VSA may be duplicating evidence the copy and route heads already supply. The failures close configurations: a wiring and scoring fault, a frozen-artifact swap, codes with only 120 values, and a codebook rebuilt while the heads trained. D22 applies: these close configurations, not the mechanism.

What has never been tested

• Mode 2 with its codebook frozen after a warm-up. This is the one follow-up the 9 October result justifies.
• A scale sweep on a frozen artifact, and VSA with the exact copy head switched off.
• Role-times-filler binding for relation reads on held-out phrasing, against an equal-bit ordinary codebook.
• Octonion-signed binding against plain XOR at equal cost, using the canonical Fano table.
• Any hypervector binding on the discrete path (GPU, integer writer, ternary or E8 Hamming comparison).
• More than two seeds, more than 6.8 million training tokens, or chat data in place of TinyStories.
• Spectral against VSA retrieval after the dimension and hash-placeholder faults are fixed.
• Whether a 64-term bundle in 4,096 bits carries order and bindings or only membership (hypothesis).

What would reopen it

1. A lawful retraining of the fixed-code term, either as an offline float learner under D37 with a fresh TEST FITNESS: FIT review and a D11 integer export gap, or as a Hamming binding on the discrete writer, with owner release where a hold applies.
2. The freeze-after-warm-up test for mode 2, to settle the moving-codes hypothesis.
3. A redundancy test with the exact copy head switched off, plus a scale sweep (0, 250, 500, 1000, 2000, 4000), so a null cannot be blamed on a tiny scale or on duplicated evidence.
4. A role-times-filler test on held-out phrasing against an equal-bit ordinary codebook, reporting the share of decisions that flip, with exact word and occurrence identity kept apart from the sketch.
5. An equal-cost test of octonion-signed against plain XOR on order-sensitive relations, using the canonical Fano table and not the rejected draft.

Also known as

VSA; hyperdimensional computing (HDC); binary spatter code; Hypervector4096; HRR-style associative transition context; the vsa_scale_q15 term and set-vsa-code-mode; octonion-signed binding (a design only).

Code

• native_geometric/vsa/hypervector.rs: XOR bind, rotation, majority bundle, bit-count Hamming, Q1.15 score. Siblings: codebook.rs, context_engine.rs, attention.rs, hierarchical.rs.
• learner/vsa_codes.rs: the three code modes. jepa_trainer.rs holds the trained scale.
• bin/ablate-prose.rs: the held-out scorer with VSA ablations. set-vsa-code-mode.rs: the load-time code swap.
• semantic/vsa.rs: the router geometry and facet stores.
• tests/vsa_conformance.rs: algebra conformance tests.
• spiralcore_operator.rs: the canonical Fano table, the control for any octonion-signed binding.

Related mechanisms

ternary-xor: the same XOR and Hamming arithmetic; a discrete VSA would live there. exact-memory: the intended partner, where sketches propose and exact references decide. spin-weights: mode 1 took codes from icosian roots. read-binding: another route to a read that binds the right value. flock-read: its Hamming distance on coordinates is the discrete cousin. hopf-observation: another lossy summary kept beside exact identity. spiralcore-fbs: supplies the Fano table.

Hopf observation with a kept fibre

Status: PARKED. The map and the kept-fibre bookkeeping are built and unit-tested, but they run only as telemetry in the integer runtime, and the test that matters for language (does keeping the lost angle help?) has never been run. The forms that were tried for prediction failed or used banned parts: sector routing, softmax attention, and a curved-space read that came out neutral (mechanism census).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

A rotation state in this model is a point on a four-dimensional sphere. The Hopf map looks at that point through a three-dimensional shadow. The shadow forgets one angle, so many different states cast the same shadow. This mechanism keeps the forgotten angle in a separate slot, so nothing is lost, and uses it to track drifting phase and to sort states into routing bins. A related idea, the Lorentz read, scores a match by distance in a curved, tree-friendly space instead of by a dot product. Neither has been shown to help a language model.

What it replaces in a transformer

Attention scoring: the rule that decides how well a query matches a stored key. A transformer uses a dot product. The Lorentz read replaces it with a curved-space distance, and the Hopf bins were meant to route a query to a small group of keys before scoring.

What the shadow forgets, and what the old routing did with it. Moving the point around the fibre changes nothing in the shadow; the kept phase records it.

How it works

The map (Definition). Write a unit quaternion as \(q=(a,b,c,d)\) with \(z_1=a+ib\) and \(z_2=c+id\). The Hopf map to the 2-sphere is \[h(q)=\big(2(ac+bd),\ 2(bc-ad),\ a^2+b^2-c^2-d^2\big)=\big(2\,\mathrm{Re}(z_1\bar z_2),\ 2\,\mathrm{Im}(z_1\bar z_2),\ |z_1|^2-|z_2|^2\big).\]

Two facts (proof, by expanding the squares). First, \(|h(q)|^2=(a^2+b^2+c^2+d^2)^2=1\), so \(h\) lands on the unit sphere. Second, multiplying both \(z_1\) and \(z_2\) by the same phase \(e^{i\varphi}\) leaves \(z_1\bar z_2\) and both moduli unchanged. That phase moves \(q\) around a circle (the fibre) while \(h(q)\) stays put. So the shadow alone cannot be inverted. Rebuilding \(q\) needs the base point, the fibre phase and a chart convention, because there is no global identification \(S^3=S^2\times S^1\).

Kept fibre (Definition). Holonomy tracking accumulates the wrapped change in fibre phase, plus the Fubini-Study distance, along a trajectory of states. In the integer runtime these are recorded per session and are marked telemetry only: they do not change any output.

Sector routing (Definition). Three Hopf coordinates are binned \(8\times8\times8=512\) ways. When the inputs are non-negative at most 64 sectors are reachable, a fact of the binning (proof).

Lorentz read (Definition). Lift query \(q\) and key \(k\) to the hyperboloid, \(q_0=\sqrt{1+|q|^2}\) and \(k_0=\sqrt{1+|k|^2}\), and set \(z=q_0k_0-q\cdot k\). The score is \(\beta\,(\delta-\operatorname{arccosh} z)\), with a learned radius \(\delta\) and scale \(\beta\).

Icosian shadows (from enumeration). The 120 icosians map onto 30 points of the 2-sphere, every fibre of size 4 (checked by finite enumeration in the geometry chapter).

Rule check.

• D11: not yet. The integer helpers use multiplication and division, the core helpers decode to f64, and the integer runtime refuses Lorentz models until an integer arccosh table exists.
• D23: the map has no softmax. Every Lorentz read and attention that was actually run normalised scores with softmax, which is excluded.
• D30: the map is a few products, not a matrix multiplication. The float Lorentz stacks used dense query and key projections, which are barred.
• D32/D37: the float Hopf helpers (sine, cosine, square root) fall outside the zeta-zero exception. Under D37 a float version could be re-registered with a fresh review. The current discrete Route, Flock and Relation reads use no Hopf quantity (the geometry chapter).

What has been tried

Reading these honestly. Only the occupancy rows test the Hopf map itself, and they tested one projection of one state. The attention failures were an additive summary, a heatmap readout, and softmax constructions; their records say Hopf and H4 are not refuted. The Lorentz read was neutral at best, and it was never run without softmax and dense projections. The strong hyperbolic result (77.5% against 0.4%) was about keys that index a hierarchy, not about scoring a read. The audit suggests splitting this page in two: the kept-fibre map is nearer READY than PARKED, while sector routing and the Lorentz read are the parked forms. The status is left unchanged here. D22 applies: these close configurations, not the mechanism.

What has never been tested

• Kept fibre for language: never tested in a language model (the one kept-fibre datum is the small selector comparison above). Base only against base plus fibre against explicit bank tags, at equal bytes.
• Any Hopf quantity inside the discrete reads (Route, Flock, Relation).
• The S7 quaternionic Hopf relation state. No implementation exists.
• A pairwise factorial separating the Hopf shadow channel from the predictor weights it interacts with (JEPA).
• A third paired seed for Lorentz against dot, and a Lorentz-scored pointer.
• A Lorentz read without softmax or dense matrices. Every executed form used both.
• Hopf holonomy as a dialogue-state feature that changes output. The integer tests assert nonzero winding, not usefulness.

What would reopen it

1. A retained-fibre test: base only against base plus fibre against explicit bank tags, at equal retained bytes, with fibre removal or permutation, a common action, one endpoint changed against both, and exact occurrence identity kept outside the lossy summary.
2. An integer, multiplier-free Hopf map wired into a consumer on the discrete path.
3. A Lorentz read re-registered as an offline D37 float sheet with a fresh review, a read that avoids softmax and dense matrices, a third paired seed and a D11 export gap (an integer arccosh table does not exist yet).
4. The reduced finite S7 construction, only after a witnessed information or cost need.
5. Hierarchy-heavy tasks where hyperbolic keys already showed a large gap, put on an equal-capacity, softmax-free harness.

Also known as

Hopf map \(S^3\to S^2\); retained fibre; holonomy tracking; UnitS3Q30::hopf and hopf_fiber_project; Fubini-Study trajectory; Hopf sector routing (512 sectors); Lorentz or hyperbolic read; LorentzAffine; HELM-D R4 Lorentz attention; S7 quaternionic Hopf relation state (conditional, never built).

Code

• native_geometric/hopf_metric.rs: the map, fibre point, Q30 versions and holonomy tracking.
• prime_route_attention.rs: UnitS3Q30::hopf, rotate_common_fiber, SpinTorsionState.
• uor-r4-integer/src/math.rs and model.rs: integer helpers, and the telemetry-only per-session state.
• uor-r4-router/tests/hopf_sector_occupancy.rs: the occupancy measurement.
• uor-r4-training/src/joint_model.rs: the Lorentz read score in the float stacks.
• helm_d_r4_attention.rs: the HELM-D constructions (softmax, now excluded).
• Existing static art: docs/figures/geometry/hopf-fibration.svg.

Related mechanisms

prime-zeta-codebook: shares the unit-quaternion helpers; the table uses points on the 3-sphere but not the Hopf map. spin-weights: acts with the same quaternions and icosian roots. spiralcore-fbs: both treat E8 and H4. vsa: another lossy sketch kept beside exact identity. route-read: hyperbolic keys were pitched as an address geometry. flock-read: ranks by frame proximity, a discrete cousin of a neighbourhood score. read-binding: phase binding and the Lorentz-against-L2 read both sat on it. exact-memory: exact occurrence identity must stay outside any Hopf summary.

Tokenizer

Status: ACTIVE. Every current corpus, driver, test panel and trained artifact is bound to one pinned tokenizer with 4,096 pieces (identity d36d3e87). A Rust trainer for a 16,384-piece tokenizer landed on 19 October as tooling only. No model has been trained or scored on any other tokenizer (trainer record, donor-corpus sheet).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea (see the charter, section 4.6). Unfamiliar project terms (K16, A8, admission, NOT_RUN) are in the glossary.

In plain words

The model never sees letters. It sees numbered pieces of text, and this component cuts text into those pieces and turns pieces back into text. It starts from raw bytes, so any text can be encoded. Then it learns which neighbouring pairs of pieces occur most often and glues them into bigger pieces, so common words become one piece and rare words stay in several. The project's pinned tokenizer has 4,096 pieces. This is a standard technique, not a novel one. What is distinctive here is that the tokenizer's fingerprint is recorded in every file that depends on it.

What it replaces in a transformer

It fills the same slot as a transformer's tokenizer; it replaces no transformer part with a different mechanism. A transformer has a tokenizer too, usually byte-level BPE. This page is on the board because the tokenizer fixes the vocabulary size and id space that the prime-zeta codebook and the address-structured cells are sized by. It also pins the identity that makes results comparable.

Bytes become pieces by repeated merging, and the fingerprint of the merge table travels with every prepared file. A two-digit number is still two pieces.

How it works

Vocabulary layout (Definition). Ids 0, 1 and 2 are start, end and unknown. Ids 3 to 258 are the 256 single bytes. The rest are learned merges. For the pinned tokenizer that is \(3+256+3837=4096\).

Training (Definition). Count adjacent pairs over the unique pieces of text in the corpus (pre-tokens), each weighted by how often it occurs. Then repeat: merge the pair with the highest weighted count into a new piece, and recount only the words that contain it. Ties go to the pair with the smaller left, then right, token string, so the result is deterministic. Special tokens are atomic. No merge crosses a special token, a pre-token boundary or an input file.

Encoding (Definition). Apply the merges to a text's bytes in rank order. This is a table lookup with no learned arithmetic.

Identity (Definition). The tokenizer is stored as a tokenizer.json. Its raw-byte blake3 hash is the tokenizer's identity, and that hash is bound into every prepared corpus and artifact. A different tokenizer is therefore a different corpus.

Prepared corpora. The UORT v1 format is a 64-byte header followed by 16-bit token ids, with start markers and an optional binary response mask. Before reading a target, the discrete driver verifies the file hash, the token count and the tokenizer identity.

One dialogue encoding. A DialogueProtocol object fixes how roles and turns are written out, so training, test panels and chat use identical token segments. The need is real. Two branches once used incompatible serialisations, and even identical visible text can encode differently, because the merge rules may join a marker's trailing space to the first content token.

Numbers. In the pinned vocabulary no piece made only of digits has more than one digit: it has 10 pure single-digit pieces and 0 pure multi-digit pieces (measurement, below). Mixed pieces, such as a space plus a digit, were not ruled out. A separate numeral codec reads consecutive digit pieces left to right into one ordered value, so pieces 8, 4 give 84 and pieces 4, 8 give 48.

Rule check. Everything here is integer bookkeeping on the host and is not model compute. It involves no softmax or squashing (D23), no matrix multiplication (D30) and no float. The encode path was not itself put through the D11 instruction audit. It sits outside the served numerical kernels, and the integer runtime takes the tokenizer as an optional dependency for text sessions.

What has been tried

No experiment has varied the tokenizer. Every row below is side evidence about data preparation, indexing or diagnosis. The 16,384-piece row is tooling validation, not a model result.

Reading these honestly. The numeric misses were measured on a pointer-copy float stack with no memory operator, so they speak about that learned read and the 4,096 vocabulary, not about byte-level BPE as a mechanism. The dialogue clash was a coordination defect, fixed by a shared protocol, not a tokenizer failure. The data-versus-size row is one seed and says little about vocabulary size.

What has never been tested

• Whether 16,384 pieces help or hurt the discrete model. No model has used any tokenizer other than the pinned one.
• A number-aware tokenizer (multi-digit pieces or a numeric slot), planned in the numeric-addressability plan but never built.
• Whether the tokenizer interacts with prime-zeta placement or cell coverage. The prime-zeta qualification used \(V=4096\) only.
• Fairness across scripts and languages. The training corpora are English chat and code.
• Reclaiming the three superscript-digit slots (idle vocabulary) for multi-digit pieces.

What comes next

The mechanism is ACTIVE, so this is a plan, not a reopening. The next step is a matched 4,096-against-16,384 comparison sheet. Open questions it should answer: does 16,384 improve the prime-zeta and address-cell numbers or just spread cells thinner (the planned shape uses 512 cells instead of 256), do digit-split numerals stay a barrier once the discrete read can address an exact value, and would training the tokenizer on the donor corpus make it a different corpus identity.

Also known as

BPE; byte-pair encoding; uor-r4-tokenizer; hf_bpe (its old name inside the core crate); the pinned tokenizer d36d3e87; train-bpe; the UORT prepared-corpus format; DialogueProtocol; data preparation.

Code

• uor-r4-tokenizer/src/lib.rs: runtime byte-level BPE, tokenizer.json parser and the raw-byte identity.
• training.rs: the deterministic merge trainer (weighted pair counts, pair-to-word index, lazy heap). bin/train-bpe.rs: the host-only command, for vocabularies from 259 to 65,536.
• dialogue.rs: the shared dialogue encoding. tests/training.rs: checks against an independent recount.
• uor-r4-discrete/src/corpus.rs: the prepared-corpus loader that verifies hash, count and identity.
• native_geometric/numeral.rs: the numeral codec (older engine, outside the selected build).
• Corpus preparation: prepare-knowledge-corpus, prepare-chat-parquet and mix-chat-corpus in crates/uor-r4-training/src/bin/.

Related mechanisms

prime-zeta-codebook: maps each id to a prime and phase position; the tokenizer fixes \(V\). address-cells: the cell placement is sized by the vocabulary. discrete-learning: the driver verifies tokenizer identity on every corpus. native-geometric: the numeral codec and an older lexical codec sit on token ids. lut-serving: the served engine carries the tokenizer for text sessions.

Discrete geometric learning (exact-move counterfactual training)

Status: ACTIVE. It is the learning rule of the only live model path, crates/uor-r4-discrete. It has trained a short pilot, a full K=8 dose, the four K16 runs (runs with a shortlist of K=16 cells; see the glossary) and the Relation runs that stopped at the first checkpoint. None has shown a language gain or beaten its frozen control, and training stays held until the owner releases each run (K16 outcome).

Labels used below: proof means derived from definitions or code, measurement means a recorded run, hypothesis means an untested idea. See docs/formal_vocabulary.md.

In plain words

The model is a big table of small whole-number vectors, one per word, plus a few routing choices. To teach it, the machine picks one table entry and tries every allowed rotation of it, 16 options counting "leave it alone". For each option it replays a batch of training examples and counts the mistakes with whole-number arithmetic. It keeps the best option only if that is strictly better than leaving the entry alone. There are no gradients, no decimals and no matrix multiplication. Every step stays inside the values the finished model can hold. So far the method has moved some counts but has not produced better language.

What it replaces in a transformer

The optimiser. A transformer is trained by backpropagation: it computes a smooth slope for every weight and nudges all of them a little. Here nothing is smooth. Learning is a search over a short list of legal moves for one coordinate at a time, scored by a replay of real examples.

One learning step on one table entry: try all 16 legal states, pick the cheapest, commit only on strict improvement, then check the stored result.

How it works

State (definition). A shared integer codebook maps each of the \(V=4096\) tokens to \(B=4\) blocks of 8 integers. Each block is one of 16 roots of a single orbit of the E8 lattice (a fixed set of 16 integer vectors; not the full set of 240). The model also holds, for each routing stage, one of 64 signed-axis rotations of 8-dimensional space (the SpiralCore group), and optional gates that take the values \(-1\), \(0\) or \(+1\). Each of these is a coordinate: a vector block, a route frame or a gate.

Read and write (definition). A read turns the token window into an integer vector \(q\). A shared writer gives each token a cell from the root numbers of its first and last block (\(16\times16=256\) cells), keeps the \(K\) nearest occupied cells to \(q\) by L1 distance (admission), and picks the nearest token inside them. The same table encodes input, carries memory and ranks output.

Loss (definition). The loss is the integer rank-margin hinge. Per row, with \(T\) the token hinge and \(A\) the address hinge:

\[\ell = \frac{8\,T + w\,A}{8w},\qquad w = 8B = 32 \text{ in the lineage of record.}\]

Learning step (definition). For one coordinate \(\theta\) and a batch of rows \(\mathcal R\) whose eligibility is fixed by the baseline:

\[L(m)=\sum_{x\in\mathcal R}\ell\big(x;\ \theta\leftarrow m\big),\qquad m\in\{\mathrm{id},m_1,\dots,m_{15}\}.\]

The 15 non-identity moves are bivector rotations. The step picks \(m^*=\arg\min_m L(m)\). Ties go to the identity, then to the lowest resulting port number, then to the lowest enumeration index. It applies \(m^*\) only if \(L(m^*)<L(\mathrm{id})\), then re-validates the stored table on the GPU. Nothing is sampled, and no floating-point number appears anywhere in the step.

Consequence (proof, from the definition). Every committed move strictly lowers the loss on its own batch, and the new state is always a legal state. The pilot's receipt audit confirmed this on every accepted move (measurement, pilot record). The step says nothing about rows outside the batch. A move that helps its batch could push other targets out of the shortlist; that is a hypothesis consistent with the Q1 stops below, and causal attribution was not made.

Speed-ups. The row-parallel kernel (rows_v1) computes the baseline once per row and each candidate once per row and lane, instead of replaying every row serially per candidate. It reproduces the serial losses on every checked case (measurement: Route read 3.843 s to 0.0691 s per proposal, 55.6 times faster, 64 rows; Route-mode index coverage was widened after review). BVG-K (batched verified coordinates) scores up to 64 coordinates per launch and commits a block only if its joint loss beats the best single move.

Rule check. No softmax, exp, softplus, sigmoid or tanh (D23), and no matrix multiplication (D30): the choice is an integer minimum, distances are integer L1 and Hamming, and moves are table lookups. The snapshot is integer, but it has not been exported or audited against the D11 serving form, no serving engine for it exists and no export gap or tokens per second has been measured. D37 allows offline float training; that would need a separate scanned module and a reported export gap.

What has been tried

\(P_{succ}\) is the 3,847-row copy-successor sub-panel (see relation-read). "Q1" is the checkpoint at 4,096 batches. "Admitted" counts rows whose target cell is in the shortlist. A "construction control" tests that code does what it says; it is not a learning result.