The System Graph

Chris Hay

THE SYSTEM GRAPH · LIVING SPEC §5–6 · GRAPH_SCHEMA 6

COMPONENTS, OBJECTS, EDGES

Everything VINDEX3 knows about a model, it knows as a graph — judged once when the container is built, stored verbatim inside it, and read by everything downstream.

What is the VINDEX3 system graph?

The container's understanding of the model, judged once from evidence at compile time and stored verbatim: which components exist, what logical objects they own, how hidden states flow between them, and — per layer — which operator runs and what it requires. From then on the graph is the only semantic authority; execution, verification and the query surface read it, never the checkpoint, and ambiguity is refused rather than guessed.

model.layers.3.self_attn.q_proj.weight is a name, not a meaning.

TWO TENSORS, ONE NAME — Kimi-Linear-48B, recorded

…self_attn.q_proj.weight

Two tensors in one container, indistinguishable by name. A reader that decides what a tensor is by matching strings has already finished — and is already wrong, with every shape still lining up plausibly.

WHAT THIS FIXES

Every runtime that infers meaning from tensor names carries the guess forever — one more family branch for every family, growing until nobody can delete anything. And names lie quietly: a zero that means no rotation will one day be read as rotation by zero, which is not nothing — it is nonsense wearing a number. The graph exists so that meaning is judged once, from evidence, at compile time. Every guess dies there, where it can still be argued with.

THE SYSTEM GRAPH — THREE DEPTHS

The system graph is the container's understanding of the model: which sub-systems exist, what logical things they own, and how hidden states flow between them. It is built once, from source evidence, when the container is made. It is stored inside the container, verbatim. And from then on it is the only semantic authority — execution, verification, and the query surface all read the graph, never the checkpoint.

the ABI — §5.3 The graph shape — canonical

Written by every mainline producer: larql vindex3 encode, larql extract --generation v3, LQL EXTRACT … FORMAT VINDEX3, the factory pin — all one shared pipeline (encode_checkpoint).

<container>/
├── index.json            envelope (§5.2); system_graph set, moe_manifest null
├── system_graph.json     the SystemGraph, verbatim
├── segments/
│   ├── target.decoder_stack.bin      one logical object → one canonical
│   ├── target.embedding.bin          representation → one or more plain
│   ├── target.output_head.bin        contiguous tensor-table segments
│   └── …                             (perception/drafter objects likewise)
├── tokenizer.json                    capability snapshot: tokenizer_config,
└── …                                 special_tokens_map, generation_config,
                                      chat_template — what keeps the
                                      container servable, not executable

Within a segment, tensors are addressed by a per-representation tensor table (name relative to the binding prefix, dtype, shape, offset, length), payloads concatenated in table order. Every canonical representation records a source payload hash and the segment records its own hash — the verification inputs (§20). Segment framing: [u64 LE header length][header JSON][payload bytes].

the whole document →

One structure, three ways in: what it is, the graph itself to walk, and the canonical shape the specification requires.

The system graph — learn: what the graph is · inspect: walk a real graph · spec: the clause that governs it. One concept, one URL, the depth of your choosing.

SystemGraph — THREE ARRAYS

Components own objects. Edges connect components.

components: [Component]WHAT SUB-SYSTEMS EXIST

One entry per sub-system of the release — the text model, a vision tower, a speculative drafter. Roles are evidence-derived, never declared: an artifact declaring target_layer_ids is a drafter; a nested *_config component is perception; otherwise primary_text. Ids are conceptual — target, vision, draft — and never directory names.

idconceptual name: target, vision, draft

roleprimary_text · perception · drafter — derived from evidence

source_artifactwhich source artifact this component came from

num_layers · hidden_sizethe component's own geometry

attentionper-layer AttentionLayerPolicy — position, span, and gating judged per layer

objects: [LogicalObject]WHAT THINGS THEY OWN

The logical things a component owns, named in an architectural vocabulary, not a familial one. Identity is the pair {component}.{kind} — target.decoder_stack. Physical tensor names may bind an object, but they never define it. A representation's id is {object_id}@{encoding}.

id{component}.{kind} — e.g. target.decoder_stack

kindembedding · decoder_stack · final_norm · output_head · perception_tower · perception_adapter · feature_projector · expert_bank

source_bindings[{ artifact, tensor_prefix, tensors, bytes }] — the physical trace back to the source

representations[{ encoding, fidelity: canonical | approximate }] — encodings observed from shard headers, never invented

edges: [HiddenStateEdge]HOW STATE FLOWS

The logical flow of residual states across a component boundary — a drafter tapping the target's layers, a projector consuming a perception tower's output. The edge's producer must be exactly one other component deep enough to own every declared tap. Zero candidates, or two: the interface is unresolved, and blocks. Never guessed.

producer_component · producer_layerswho produces the states, and which layers are tapped

consumer_component · consumer_objectwho consumes them, through which object

block_sizeoptional — the capture granularity, when the consumer needs one

Graph schema 6 — since 2026-08-30, presence means semantic presence: the execution surface's attention and FFN groups exist iff the component's declared program runs those operations, and the per-layer operator is explicit. The graph is stored verbatim in the container — inspect prints it back from the bytes alone, with the source deleted.

Components own objects. Edges connect components. — components: [Component] · objects: [LogicalObject] · edges: [HiddenStateEdge].

RESOLVED

exactly one component owns every declared tap — the edge exists.

The edge is not the tensor.

A projector that implements an edge's consumer side is a separate object, referenced by id. The flow of states and the weights that transform them are distinct facts, never merged. The graph runs on six such distinctions, each load-bearing. An artifact is not a component. A tensor name is not a logical object. An interface is not its implementing tensor. NoPE is not rope with theta zero. A logical object is not its physical representation. And representable means judged — not merely parsed.

G3 — HOW THE GRAPH BECOMES A CONTAINER

<container>/
├── index.json            sole root authority
├── system_graph.json     the SystemGraph, verbatim
└── segments/
    ├── target.decoder_stack.bin
    ├── target.embedding.bin
    ├── target.output_head.bin
    └── …                 one segment per logical object

segment framing:  [u64 LE header length][header JSON][payload bytes]

SegmentHeader {
  schema, representation,
  tensors: [ { name, dtype, shape, offset, len } ]
}

Offsets are relative to the payload. The table's order is the payload's order — deterministic, sorted by name. Names are object-relative (3.self_attn.q_proj.weight), never artifact-global. Two hashes are computed in one writing pass: the payload, and the whole file. And the write order is deliberate — segments first, index.json last — so a crash midway leaves a directory that never claimed to be a container, rather than one that claims to be and is missing its banks.

This layout — graph, objects, representations, segments — is the canonical shape of a VINDEX3 container: it is what every mainline producer writes. The bank layout on the Bytes page is a named transitional shape: the LYRW v2 import layout for routed expert banks, carrying a programme manifest instead of a graph. Same root rule, same authorities — and since the 3.0 Candidate, a stated hierarchy rather than two rival definitions: the graph is the format; a bank layout is an encoding a representation may use. Unifying the two writers is a named gate for 3.0 Final.

THE G3 GATE

Materialisation is proven, not assumed: after encode, inspect must reconstruct the entire system — components, objects, edges, policies — solely from the container. If a fact survives only in the source checkpoint, the encoding failed, whatever the bytes say.

TWO GRAPHS, ONE VOCABULARY

This page describes the container's SystemGraph — what one particular model is, persisted inside its artifact. The site also keeps a second, deliberately separate graph: the VINDEX knowledge graph, which holds what the format's concepts mean — definitions, claims, evidence, gate statuses — and is what Ask resolves against. The two never merge; they join through stable semantic identities, so a container can say FfnGate and the knowledge graph can say what a gate is. One vocabulary, linked authorities.

A graph says what the system is. What the generic operations need to run it is the execution surface.

FOLLOW THIS IDEA — FROM DESCRIPTION TO COMPUTATION →FOLLOW THIS IDEA — ONE DIRECTORY, ONE ROOT →FOLLOW THIS IDEA — ASK — THE KNOWLEDGE GRAPH, QUERIED →

PUBLISHED 29 AUG 2026 · REVISED 30 AUG 2026 · VERSION 3.0 Candidate

CITE

site build 43a1b6b · built 2026-09-02

CITE THIS

Web page · 3.0 Candidate

Hay, C. (2026). The System Graph. In VINDEX3 Specification (Version 3.0 Candidate). VINDEX3. https://vindex3.org/graph

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.md §5–6 (the living spec)
reference implementation — graph/component.rs · graph/object.rs · encode/segment.rs