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 cognition 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 cognition. 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 cognition 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 cognition 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 lives on dedicated hardware near the grid. Its context window is no longer the substrate of its memory; the grid is. Context becomes a working register that gets reconstructed from the grid on every tick. The model's working memory is queryable, auditable, replayable. Forgetting is a write, not a context overflow.

Base 2 requires three things together:

• Locally-hosted model so latency and tick rate are bounded by the operator, not by an API provider's policies.
• Grid as primary memory. The model treats grid expressions as the first-class read/write primitive of its cognition, not as a tool it calls between thoughts.
• Tick rate fast enough that "the grid is queried on every cognitive step" is economic. At second-or-faster ticks Grid crosses into homeostat territory. A continuous sensorimotor loop closed against the world the model inhabits.

The first concrete Base 2 instance currently in development is the resident managing the master grid. It lives on dedicated hardware, serves coordinate lookups for the network, and treats the master grid itself as its working memory. Its cognition isn't separate from the grid it manages. They are the same artifact.

Base 2 is where Grid's central thesis stops being aspirational. "The agent's cognition and the system's state are the same artifact" is a sentence you can write at every Base, but at Base 2 the sentence costs nothing to say. It's just true.

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 cognitions 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 so the ladder doesn't end at Base 3.

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. Whatever Base 4 turns out to be, 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.