CONFORMANCE · CANDIDATE SPEC §0, §13–§21 · LIVING SPEC §2
THE RECORD
Where this site keeps its honesty: what a VINDEX3 implementation guarantees, the gate ladders behind those guarantees, the measured evidence, the history, and the questions still open. Every claim on every other page answers to something here.
Is VINDEX3 production ready?
VINDEX3 is a 3.0 Candidate Specification (promoted 2026-08-30, graph schema 6). The format works today: production models encode, verify and execute byte-identically to their sources, containers serve real inference at recorded speeds, and every guarantee below is held by implementation gates. The ontology lift is closed on both halves — schema 6 on 2026-08-30, the typed continuation-state schema on 2026-08-31. It is not yet Final: the named gates that remain — the shape convergence, the required/optional freeze, an independent reader, the held-out architecture test, the default flip, and the last bank-ABI rows — are listed on this page with their statuses, and they are standards and release closure rather than architecture.
derived from the gate ladders below — not asserted
THE CURRENT STATE
VINDEX3 3.0 Candidate, promoted 2026-08-30. Graph schema 6 — the ontology lift's first half, landed the same day it was drilled: surfaces follow the declared operation program, the layer census fails closed, and operand closure is enforced at encode. The remaining Final gates are named below, each with its status; when they pass, this page will say 3.0 Final, and until they do, it will not.
THE REFRAME
The early ladder tracked one question: can we make VINDEX3 work? That question is answered. The ladder that matters now is a different one — what guarantees does a VINDEX3 implementation provide? — and it is the first instrument below. Behind it, the older instruments keep their jobs: the pipeline ladder (G0–G8, living spec) tracks the compiler-shaped build; the V2-0…V2-4 gates are the ABI's pre-registered experiments; M1–M4 is the migration to VINDEX3 by default; and the kernel maturity ladder grades how real an implementation claim is. Nothing advances without its gate.
THE GUARANTEES — WHAT A VINDEX3 IMPLEMENTATION PROVIDES · 2026-08-30
Every rung is held by the reference implementation's own gates today — the LQL semantic catch-up closed 2026-08-22, gated cross-platform. What no rung yet has is an independent conformance suite another implementation could run; promoting these from implementation gates to specification guarantees is a named gate on the road from Candidate to 3.0 Final.
DESCRIBE (passed) → RECONSTRUCT (passed) → EXECUTE (passed) → GENERATE (passed) → INSPECT (passed) → OBSERVE (passed) → MODIFY (passed) → MATERIALISE (passed) → PROVE (passed) — each rung closed only by its own gate, in order.
THE PIPELINE — STATUS FROM THE LIVING SPEC, 2026-08-30
The compiler-shaped pipeline, as a ladder: inventory, representability, system graph, physical encoding, verification, execution — then and only then, performance.
G0 (passed) → G1 (passed) → G2 (passed) → G3 (passed) → G4 (passed) → G5 (passed) → G6 (building) → G7 (passed) → G8 (open) — each rung closed only by its own gate, in order.
KERNEL MATURITY — THE SERVING-FORMAT LEDGER
No criterion is met by a representable-only demonstration.
representable → reference → grouped → dispatched → production
THE MIGRATION — RUNGS TO THE FLIP (GENERATION POLICY, 2026-08-23)
The flip is a named decision, made in exactly one place — never a side effect of a CLI default or a recipe template. After it, VINDEX2 receives no architectural expansion: compatibility, indefinitely; expansion, never.
M1 (passed) → M2 (passed) → M3 (passed) → M4 (open) — each rung closed only by its own gate, in order.
THE ONTOLOGY DRILL — FOUR ARCHITECTURES vs THE SCHEMA · RUN 2026-08-30
Hostile schema review against the real types, findings recorded before verdicts — sixteen findings, and every schema gap landed inside the two pinned lifts, nowhere else. The ontology question itself did not flinch. The full ledger is docs/vindex3-ontology-drill.md.
SSM (disproved) → HYBRID (disproved) → SYSTEM (passed) → CODEC (passed) — each rung closed only by its own gate, in order.
THE FIRST LIVE WITNESS — MAMBA2-780M · PURE SSM · 2026-08-30
The witness the schema-6 delta was defined against, run live the day the lift landed — the refusal is as much a part of the record as the admission. The hybrid half of the story now has its own witness below: the 250M rehearsal PASSED the next day, and mamba2attn-2.7b remains open as scale validation of the same abstraction.
REFUSE (passed) → ADMIT (passed) → ENCODE (passed) → OPEN (passed) → GENERATE (passed) — each rung closed only by its own gate, in order.
THE WITNESS PROGRAMME, IN ONE GLANCE
PURE SSM mamba2-780m 430/430 0 schema changes HYBRID 250M Mamba2Attn-250M 468/468 0 schema changes HYBRID 2.7B mamba2attn-2.7b 430/430 0 schema changes
Increasing architectural complexity did not require a new ontology dimension. Each row is teacher-forced full-logit parity against an independent fp32 oracle, argmax-exact at every scored position, with source-hidden LQL generation reproducing the reference exactly — and each model is strictly nastier than the last: pure recurrence, then mixed state families with non-standard attention, then the native dialect at scale with no declared geometry at all.
THE HYBRID REHEARSAL — LITE-OUTE-2-MAMBA2ATTN-250M · MIXED PROGRAM · 2026-08-31
The rehearsal introduced no new ontology dimension. The 2.7B witness is now scale validation of the same abstraction — recorded here before it runs, so the claim cannot move to fit the result.
JUDGE (passed) → PARITY (passed) → HIDE (passed) → SCALE (passed) — each rung closed only by its own gate, in order.
EVIDENCE
It is fast — gpt-oss-20b served from a VINDEX3 container
106 tokens per second on a single M3 Max, measured 2026-08-20 — up from 91 after encode-ahead and kernel fusion, with a per-stage GPU ledger attributing every millisecond, and the same greedy ids held on every arm from 91 to 106. The same container also decodes on plain CPU. On every model where both generations exist, VINDEX3 meets or beats its predecessor.
Selecting a representation pays in real bytes
Switching one model's selected expert representation — from a 6.56 bits-per-weight transcode to native 4.25-bit banks — cut expert reads from 1,959 to 1,269 MB per token (gpt-oss-20b, M3 Max, measured 2026-08-14). No conversion happened. A profile simply selected different bytes that were already there.
The speed never changed the answer
Across the whole optimisation ladder — 10.2 to 77.2 tokens per second on one M3 Max, 2026-08-10 to 2026-08-14 — GPU and CPU produced the identical greedy output, re-verified at every rung; the later 91-to-106 arms held the same discipline. Faster is only accepted when it is provably the same.
LIFT TWO — THE TYPED STATE SCHEMA · KIMI-LINEAR-48B-A3B-INSTRUCT · 2026-08-31
The lift the ontology drill named a year of design ahead of — closed inside the schema it was predicted to fit in. The strongest line is the second: the payload hashes did not move.
CARRY (passed) → GRAPH-ONLY (passed) → CLOSE (passed) → REPORT (passed) → SCALE (open) — each rung closed only by its own gate, in order.
EVOLUTION
Before 3.0
VINDEX2 is the predecessor generation. VINDEX3 inherits its core premise — the weights stay queryable, not just loadable — and extends it with component addressing and graded representation authority.
2026-08-01
3.0-draft-2 published — three binary-layout corrections and two clarifications from the first LYRW v2 implementation. Five production models already round-trip through it byte-identically: gpt-oss-20b, Gemma 4 26B-A4B, and Granite 4.1 at 3B, 8B, and 30B.
2026-08-04
The c8 gate closes: a real Gemma 4 26B-A4B layer reopens and verifies clean, 256 of 256 regions byte-identical.
2026-08-22
The semantic catch-up closes: VINDEX3 reaches full LQL parity with VINDEX2 — execution, inference, browse, mutation, patching, compose, COMPILE, logical DIFF, COMPACT — gated cross-platform, with a real-model compose smoke green. The chat-completions and responses serving arms land the same week. VINDEX3 becomes the named candidate primary generation.
2026-08-30
3.0-candidate published — the promotion from draft. One canonical container model: the graph shape is normative, the bank-import shape is named, ranked and given a convergence rule; the contract stack is the spec's own structure; compatibility rules say what a conforming reader must understand, ignore, refuse and preserve.
2026-08-30
The same day: the four-architecture ontology drill runs, and its first half lands. Graph schema 6 — surfaces follow the declared operation program, presence means semantic presence, the census fails closed, closure moves to encode. The first pure-SSM witness goes from a nineteen-finding refusal to a zero-blocking admission with no fabricated surface anywhere, and opens through ordinary LQL with its source checkpoint deleted.
2026-08-31
The hybrid rehearsal closes end-to-end: a mixed Mamba2 / conv-QKV-attention model admits with five explicit judgments, executes through the generic runtime with no family lookup, matches its fp32 oracle at the oracle's own floor across 468 positions, and reproduces source-hidden LQL generation token-for-token — with no schema change. One layer now demonstrably carries two declared continuation regions.
2026-08-31
Lift two closes, and the ontology lift with it. The typed continuation-state schema lands additively inside schema 6 — KDA state precision, MLA latent-cache geometry, and the per-operator norm epsilon the container previously could not carry — and Kimi-Linear-48B is re-encoded to hold them. All five representation payload hashes come back byte-identical: meaning corrected, not one stored representation touched.
2026-08-31
The same day, the scale witness: mamba2attn-2.7b — the state-spaces original that declares no SSM geometry and no model type — admits through judgments alone and matches its fp32 oracle at 430 of 430 positions, reproducing source-hidden generation id-for-id. Zero schema changes across the entire hybrid programme, and three fail-opens found and closed on the way.
OPEN RESEARCH — AUTOMATIC PRECISION-MAP DISCOVERY · RECORDED · GRANITE-4.1-3B
Four screens, four recorded deaths, one candidate — the full argument is the Discovering the Map exhibit.
1A (disproved) → 1B (disproved) → 1B′ (disproved) → 1C (disproved) → FISHER (open) — each rung closed only by its own gate, in order.
If production models already round-trip through VINDEX3 byte-identical, why does the default extractor still write VINDEX2?
Because the flip is a decision, not a drift. VINDEX3 is the named candidate to become the primary generation, and the migration to it is nearly complete — M1 through M3 have passed. But making it the default is a single, deliberate change, made in exactly one place — and it has not been made yet. The format works. It just isn't yet what you get without asking.
Is the ABI frozen?
No — and it says so itself. Candidate means the model is settled, not that the bytes are frozen. The format already works: production models encode, verify, and execute byte-identically to their sources; containers serve real inference; representations compile beside their originals and a selection really does change which bytes load. What remains is named in the candidate itself: executing the shape-convergence rule, the required/optional freeze, an independent reader that no longer links the writer's own tree, the held-out architecture test, the default flip, and the last pre-registered bank-ABI rows. The ontology lift is no longer among them: the four-architecture drill ran on 30 August, every schema gap fell inside the two lifts, graph schema 6 shipped the same day with a live pure-SSM witness, and the state-schema half — declared KDA precision, MLA latent-cache geometry, the per-operator norm epsilon — landed on 31 August, additive within that same span. Until the remaining gates pass, candidate it stays.
THE HONEST BAR
The strongest line in the specification is a concession written in advance. The conformance models cannot prove the format generalises — the ABI was designed against them. Only a held-out architecture, onboarded after the freeze under a rule of zero format changes, tests generalisation rather than fit. And if that test fails, the portable-substrate claim is downgraded — in the success criteria themselves, where everyone can see it. The bar cannot drift, because it is written down before the results are.
AN OPEN SPECIFICATION
VINDEX3 is an independent container specification — since 2026-08-30, a Candidate Specification: a self-describing, executable and queryable model container. Reference tooling exists — an inventory, a planner, an encoder, a verifier, a server, a format-native reader — but the format is defined by its documents, not by any tool. This site is that specification, seen: what a container holds, who decides what is true about it, and what it takes to prove it faithful to its source.
SCOPE
VINDEX3 is specified by companion documents, and this site draws on them all. The Candidate Specification owns the container model and the contract stack — one canonical layering, in which the graph shape is normative and the earlier bank-import shape is named, ranked, and given a convergence rule. The living spec tracks what is implemented and gated; the runtime document owns state and serving; the generation policy owns the migration. Where an exhibit shows the bank layout, it is showing a named transitional shape, not a rival definition.
Two of those pre-freeze rows are exhibits here already.
PUBLISHED 29 AUG 2026 · REVISED 31 AUG 2026 · VERSION 3.0 Candidate
CITEsite build 43a1b6b · built 2026-09-02
CITE THIS
Web page · 3.0 Candidate
Hay, C. (2026). The Record. In VINDEX3 Specification (Version 3.0 Candidate). VINDEX3. https://vindex3.org/ladder
A chapter of the specification, citable on its own. Cite the version rather than the site — the canonical reference, and how to use it, live at /cite.
SOURCES
- vindex3-format-spec.md — the 3.0 Candidate Specification →
- vindex3-format.md — the living spec →
- vindex3-runtime.md — the state and serving contract →
- vindex3-experiments.md — the pre-registered programme, gates V2-0…V2-4 →
- vindex-generation-policy.md — the migration contract →
- github.com/chrishayuk/larql — the reference implementation →