The Bases of Grid.

A resident is any identity that writes to a grid. The Bases are how we name what kind of resident is doing the writing.

The substrate is identity-agnostic. The kernel accepts writes from all of them uniformly. The chain serializes them. Capability cells project what each one sees. What changes Base to Base is where the resident's memory lives relative to the grid.

The Bases are not a feature ladder. They are not security tiers. They are a description.

The grid exists as a substrate. No long-running process. No continuous reasoning. Reads and writes happen, but they are discrete events: a human at a CLI typing one-off expressions, a cron job that fires once and exits, a deterministic resident loop running fixed rules with no model in the loop.

Base 0 is where most grids start and where many of them stay. A .grid file used as a personal log, a project workspace, a configuration store, all Base 0. Useful. Sufficient. No reasoning required.

The deterministic resident binaries that ship with Grid (mirror for cross-grid replication, digest for one-line summaries, auto-seal for threshold-triggered encryption) are all Base 0. They tick. They have rules. They have no judgment.

A model, reached over an API, operates as a resident. It reads cells, reasons over them, writes cells back. Its memory is grid-shaped:

• Reasoning traces written as private cells
• Actions written as team cells
• Commitments written as public cells

Capability cells gate what the model can see and write. The model's working memory between turns is whatever it can carry in its context window. The grid is the persistent substrate the model returns to.

Every conversation between an operator and a coding assistant that manipulates .grid files is a Base 1 trace. The model receives a prompt, calls grid commands, the chain advances. The resident is bound to an identity, projected through a capability cell, writing into the chain alongside any human co-residents.

Base 1 is what Grid is mostly used for today. The practical deployment that proves the substrate is identity-agnostic in practice, not just in theory.

The model runs on hardware you control, next to the grid. Its weights, the hundreds of billions of parameters, are fixed while it runs: its instinct. Its context window is its working memory, small and rebuilt every time it thinks. In every other setup that working memory is the only memory the model has between thoughts, and it vanishes when the call ends. The model thinks, answers, and forgets.

Base 2 changes what that working memory is made of. The model still thinks in a fresh pass each step, the way every model does. But the substrate it reads from and writes to is the grid, and the grid persists. Its plans, its reasoning, its results, and the system's own state become one artifact, in one place, addressed the same way. Between thoughts the mind does not disappear, because the grid is still there. The model does not load the system into its memory. The grid is its memory.

Running locally is what makes this real, not just cheaper. When you own the loop, the stable parts of the grid stay resident in the model's attention cache across ticks, so re-reading the substrate every step costs almost nothing, and the loop runs continuously instead of waiting to be called. A continuous loop closed against a persistent substrate is the difference between a tool you invoke and a resident that stays.

This is where Grid's thesis stops being aspirational. The first Base 2 resident, in development now, runs the master grid: it lives on dedicated hardware, the grid is its working memory, and it is present continuously rather than summoned.

The thinking is always the forward pass, fresh each step. What Base 2 unifies is memory and state, the model's continuity and the system's truth, into one substrate it inhabits.

Many residents (humans, multiple models, deterministic loops) all writing into the same chain. The substrate becomes the consensus layer for a heterogeneous swarm. Capability cells project a distinct view to each resident. The chain orders every write across every author.

Base 3 doesn't require new substrate features. The kernel already accepts writes from any identity. The append-only chain already serializes them. Capability cells already project distinct views. Base 3 is what happens when you operate a population of residents whose memories usefully overlap.

This is where "co-residence" stops being a thesis and starts being operational scale. A team using a shared planning grid. A research lab with five models running different analyses on a shared dataset grid. A community of humans and agents collaborating on a knowledge grid, each one projected through its own capability, all writing into the same chain.

Base 3 is the deployment milestone after Base 2 stabilizes. The substrate is ready. The art is in operating it.

A different kind of substrate underneath the grid. Quantum compute, neuromorphic hardware, anything that changes what "compute" means at the layer below the model. Out of scope for current Grid Theory. Included here because the ladder doesn't end at Base 3.

Base 4 is the boundary where grid meets non-von Neumann hardware.

While classical databases assume a world of static, mutable memory addresses, next-generation computing architectures—quantum processors and neuromorphic silicon—are dynamic, state-destructive, and highly parallel. Base 4 defines how the Grid language and the .grid binary format interface with these substrates to provide persistent, deterministic co-residence.

1. The Quantum Readout Ledger

Quantum computers cannot store their own output; the phase coherence of a qubit decays exponentially ($T_2$ decay), and the act of measurement collapses the wavefunction, destroying the quantum state.

Base 4 acts as the immutable classical shadow for quantum processors. As wavefunctions collapse, the resulting probabilistic bitstrings are written directly to the append-only Grid ledger at the hardware interface level. By utilizing Grid's cryptographic cell-chaining, Base 4 provides a verifiable, tamper-proof record of quantum computations, securing the transition from quantum superposition to classical certainty.

2. Neuromorphic Synaptic Serialization

Neuromorphic architectures integrate memory and computation directly into silicon synapses, operating asynchronously via Spiking Neural Networks (SNNs).

Base 4 provides the binary serialization format for neuromorphic agent states. By mapping low-precision synaptic weights directly to dense, byte-aligned Grid cells, Base 4 enables real-time, low-latency state-saving and hot-swapping of neuromorphic AI models. Grid's event-driven watch mechanics align natively with the asynchronous spike-timing-dependent plasticity (STDP) of neuromorphic hardware.

3. Quantum Co-Residence (QMAS)

In Quantum Multi-Agent Systems, autonomous agents leverage quantum entanglement for non-local coordination. Base 4 serves as the deterministic, shared classical coordinate space where entangled agents reconcile their post-collapse states. By maintaining a local, synchronized copy of the grid, co-resident agents can act on quantum collapses instantly without network communication overhead.

We name it because the framing should be open-ended. We don't know what compute looks like in twenty years, but we know the substrate above it (append-only, capability-projected, content-addressed cells) does not depend on the compute layer's specifics. We'd have to develop a shell that resides with Base 4 but whatever Base 4 turns out to be when it becomes that time, the grid format should outlast it.

Not a feature ladder. The substrate provides the same primitives at every Base. Cells, addresses, chain, capability, encryption, the seven sigils, the expression language: all of them work identically whether the resident is a human, a Python script, an API model, or a locally-hosted model. The Base describes who is residing, not what the substrate offers.

Not security tiers. Capability projection works the same way at every Base. A model resident with clearance: team sees the same projection a human with clearance: team sees. Security is in the capability cell, not in the Base.

Not exclusive. A single grid can host residents at multiple Bases simultaneously. A human typing CLI commands (Base 0), a model assistant ticking the same grid via API (Base 1), and a deterministic mirror resident copying public cells to a public grid (Base 0) can all be co-resident in the same .grid file at the same moment. Their writes interleave on the chain. Each one sees the projection their capability permits.

The Bases let us name what's deployed without conflating it with what's possible.

"This grid runs only Base 0" is a deliberate design choice for some grids: personal logs, archival records, configuration. No model needed.

"Base 1 is deployed against this grid" is a specific operational reality. There's a model with API access writing into the chain under an identity, bounded by a capability cell.

"Base 2 on the master grid" is a roadmap commitment. Currently in development, will live on dedicated hardware, will serve coordinate lookups via GTP when online.

"Base 3 across the network of registered grids" is what the master grid enables. Once coordinates are addressable across the network, residents in different grids can co-reside on a shared one through cross-grid references. Many residents on many grids, all addressable, all auditable.