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.