THE LIFECYCLE · CANDIDATE SPEC §18–20 · LQL
A CONTAINER HAS A LIFE
Encoding is where a container is born, not where the story ends. The same artifact is bound, questioned, executed, watched, changed, compared, made durable, and maintained — each verb with a stated guarantee.
What can you do with a VINDEX3 container after encoding?
Everything a model's life requires, through one query language: bind it, question its structure, run inference, trace execution observationally, change effective state through overlays that never move the base bytes, compile changes into new standalone artifacts, diff two containers semantically, and compact for durability under a preservation rule — discard only when reported. Each verb carries a stated guarantee, and every guarantee answers to the Record.
A format that only stores is a warehouse. This one has query semantics, execution semantics, mutation semantics — and equivalence semantics.
WHAT THIS FIXES
Today, changing a model means exporting it into another tool's universe and losing the lineage; observing it means instrumenting a runtime by hand; proving two copies equivalent means trusting whoever renamed the file. Here, every one of those is an operation over the same container, and every operation says in advance what it guarantees — what it reads, what it never touches, and what it must prove.
load → query → execute → observe → modify → compare → compile → compact — one container — the whole life, in order.
THE OPERATIONS SURFACE — THREE DEPTHS
WHY THIS IS NOT MORE FILE FORMAT
Almost none of this adds bytes to the format. The test the Candidate applies: can an independent implementation determine it purely from the artifact? Then it is format. Does it describe how an engine operates on the artifact? Runtime contract. Is it an operator interaction? Operations contract — unless it persists state another implementation must understand, like a compiled container's derived authority stamp, which is exactly when it re-enters the format. That test is why the specification can be stable while the engine keeps moving.
THE VERBS — WHAT EACH ONE PROMISES
Eight moves. Every one answers from the container.
Binding is a single decision: the container's own schema version selects the generation — no filename sniffing, no fallback from a failed load. A V3 container binds as a closed, operand-verified program plus its operand bytes; a program that does not close refuses to open, naming its defects. Nothing downstream re-detects the format.
The model as structured data — features walked from the stored gate rows themselves, objects described from the graph, no separate index anywhere. The same facts are available engine-free through the vindex reader: inspect, describe, representations, precision.
A forward pass, then stateful autoregressive generation, driven by the container's own semantics — zero architecture branches, state geometry read from the plan. Served, the same runtime answers the standard completion, chat and responses surfaces, sharing every wire shape with the previous generation.
The residual stream, watched without being perturbed: on a V3 binding, TRACE runs observationally — execution's result is the same with the instrument on or off. Observation that changes the thing observed is not observation; that is the guarantee.
Mutation is overlay, never rewrite. Patches change the effective operands a session executes with; the base container's bytes never move. The effective state is real — INFER, TRACE and the query surface all see the model as mutated — but nothing is destroyed, and unwinding a change is dropping its overlay.
A semantic comparison, not a file comparison: DIFF operates over effective model state — objects, representations, values — between two containers, or between a container and the current mutated session. Error is derived, value by value, never asserted. The vindex reader carries the artifact-only projection of the same guarantee.
COMPILE CURRENT INTO VINDEX materialises the effective operands into a new standalone container — a sibling artifact, never an in-place upgrade. The result is stamped derived, keeps its provenance link, and must answer INFER, GENERATE, TRACE and WALK equivalently to the state it materialised: equivalence is gated, not presumed.
Physical reorganisation under a semantic-identity obligation: same graph, same effective values, same answers — and no silent discarding of container contents the operation does not understand. Storage may improve; meaning may not move.
GENERATE is a clause of INFER, overlays are statements of the mutation surface, and every verb above is implemented — the LQL whole-language sweep guarantees a V3 binding either serves a statement meaningfully or refuses it by name. What does not exist yet is also recorded: COMPILE INTO MODEL — container back to checkpoint — is specified but unimplemented on V3.
Eight moves. Every one answers from the container. — USE — bind · WALK · DESCRIBE · SELECT — understand · INFER · GENERATE — execute · TRACE — observe · overlay · patch — modify · DIFF — compare · COMPILE — make it durable · COMPACT — maintain.
the ABI — §18.1 The operations surface
LQL operates on V3 containers with full V2 parity: USE (bind), INFER/GENERATE (execute), WALK/DESCRIBE/SELECT (query), TRACE (observe — on V3 bindings the observational trace runs without perturbing execution), overlay/patch statements (mutate), DIFF (compare), COMPILE (persist), COMPACT (maintain). Statements that a V3 binding cannot serve refuse explicitly, naming the generation — the whole-language sweep guarantees no statement falls into an accidental backend path.
Eight verbs over one container: what makes them operations rather than format, what each one promises, and the surface as the specification states it.
The operations surface — learn: operations, not format · inspect: what each verb promises · spec: the clause that governs it. One concept, one URL, the depth of your choosing.
TWO TOOLS, ONE BOUNDARY
VINDEX interrogates the artifact; LARQL operates on the model. The standalone vindex reader answers every artifact question with no inference runtime attached — that separation is what makes the format's independence credible. The moment you want a forward pass, a trace, an overlay or a compile, you have crossed into engine territory, and the boundary is deliberate: understanding an artifact must never require the engine.
THE REFUSAL MODEL
Every statement on a V3 binding is in one of two states: it works meaningfully, or it refuses naming the generation and the reason. Hidden, not-found, and an empty listing are failures of this contract, not neutral outcomes — a container that exists must never silently disappear from a consumer surface. Refusal is how the format learns: the vocabulary's newest primitive entered it because a closure gate refused fifty-two layers by name rather than guessing.
The lifecycle stands on the execution contract beneath it — and everything above answers to the Record.
PUBLISHED 30 AUG 2026 · VERSION 3.0 Candidate
CITEsite build 43a1b6b · built 2026-09-02
CITE THIS
Web page · 3.0 Candidate
Hay, C. (2026). The Lifecycle. In VINDEX3 Specification (Version 3.0 Candidate). VINDEX3. https://vindex3.org/lifecycle
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 §18–20 (the 3.0 Candidate — operations, mutation, equivalence)
- larql-lql spec — statements, the V3 backend capability table
- vindex-generation-policy.md — the consumer matrix: support or refuse, never invisibility