The master grid.

There is one master grid. It is a .grid file. It catalogs every other .grid file that chooses to exist on it.

Same format as every other Grid file. Same cells. Same addresses. Same chain. No daemon, no service, no special protocol holding it together. The catalog of every registered grid in the world is one file, written by the same primitives as the things it catalogs.

The master grid is alive. It exists. It is currently in development and not available on the public internet. When it ships, it will live on a dedicated computer and be managed by a Base 2 native resident. See the Bases. This page is the doctrine for what it is and how it works; the deployment is the next milestone.

A single .grid file. Address layout:

@/system/genesis            master grid's own genesis cell
@/system/master-policy      rules for the master grid itself
@/system/capabilities/*     who can register, who can retract
@/grids/<x>/<y>/<z>         one cell per registered grid
@/grids/<x>/<y>/<z>/meta    optional public metadata for that grid

Every cell on the master grid is a normal Grid cell. Every operation against it is a normal Grid expression. There is no "master grid API." The CLI you would use to read it is the same grid you use for anything else:

grid -g master.grid "study: type=grid-entry"
grid -g master.grid "study: @/grids/182473615824907/94862175839204/226815439728601"
grid -g master.grid "study: type=grid-meta where: slot: visibility = public"

The master grid governs itself by its own primitives. Its policy cells determine who can register, who can retract, what metadata is public. The policy is data. Changes to the policy are writes. The history of how the master grid was governed is queryable like the history of anything else.

Every Grid file has a coordinate [x, y, z] derived from its genesis cell via GHA-1024 (Grid Hash Algorithm). The coordinate is not assigned. It is not claimed. It is not registered for. It is a mathematical consequence of what the grid contains.

Coordinates are big numbers. The address space per axis is 2^48, roughly 281 trillion values per axis. Three axes. Most coordinates are 14 or 15 digits per number. A real coordinate looks like this:

[182473615824907, 94862175839204, 226815439728601]

Not three small digits. Three integers in a space large enough that collision is mathematically negligible for any human-scale corpus.

The master grid does not hand out positions. The master grid records that a grid with a particular content-derived coordinate exists. Two parties who construct genesis cells from the same recipe end up at the same coordinate without coordinating. Two parties with different genesis cells get different coordinates even if the rest of their grids are identical.

The address of a grid on the master grid is exactly its coordinate:

@/grids/182473615824907/94862175839204/226815439728601

You can't write to that address unless your grid actually produces that coordinate. The kernel checks. Forgery requires breaking GHA-1024.

The master grid itself has a coordinate too. It is derived from its own genesis cell, the same way every other grid's coordinate is derived. There is no special "origin" position; the master grid is at wherever its genesis bytes hash to.

GHA-1024 is Grid Hash Algorithm: a 1024-bit hash construction designed for spatial, sensitivity-layered, hierarchical data. Built on SHA-512 as its primitive, composed in Grid-aware ways.

Structured output. 1024 bits, split deliberately:

GHA(address, body, sensitivity)
  = [content half: 512 bits] || [coordinate half: 512 bits]

The two halves are entangled. You can't produce a valid GHA by splicing halves from different cells. But each half is independently meaningful. The coordinate half can be reduced to a 3D position without exposing the content half.

Address-aware iteration. The hash decomposes the address into path segments and folds each segment into the hash state at its depth:

sigma_0 = SHA-512(body)
for i in 0..depth:
    sigma_{i+1} = SHA-512(sigma_i || depth_tagged_hash(segment_i))

Changing any segment of the address changes every subsequent state. Moving a cell from @/tasks/review to @/secrets/review produces a completely different hash even if the body is byte-identical. The address is structurally folded in. Not appended, not salted, folded.

Sensitivity hardening. More compute at higher sensitivity:

Brute-forcing sealed content costs 64× the compute of brute-forcing public content. The level tag is mixed in, so you can't precompute public hashes to attack sealed cells. The cost is asymmetric by design.

Master coordinate derivation. Take the coordinate half of GHA. Split it into three 21-byte slices. Reduce each modulo 2^48:

coordinate_half = GHA(genesis)[512:1024]
x = int(coordinate_half[0:21])   mod 2^48
y = int(coordinate_half[21:42])  mod 2^48
z = int(coordinate_half[42:63])  mod 2^48

The result is three integers, each in [0, 281474976710656). That's the grid's permanent address on the master grid. A real one looks like:

[182473615824907, 94862175839204, 226815439728601]

Chain mode. Every cell's chain hash incorporates not just the previous cell's hash but a topology hash, the region hash of all preceding cells. Inserting, deleting, or reordering cells changes the topology fingerprint, which breaks every subsequent chain link. A linear chain hash can't detect topology tampering; GHA's chain mode can.

The master grid does what blockchains try to do (provide a public, tamper-evident record), without the consensus machinery blockchains pay for.

A blockchain assumes a hostile, distributed environment where many parties can attempt to rewrite history. It solves that with proof-of-work or proof-of-stake consensus. The cost: every participant pays for the security of every transaction whether they need it or not.

The master grid assumes a different threat model. It does not assume distributed adversaries trying to rewrite the past. It assumes a single canonical instance where the integrity guarantee is detection, not consensus:

• Tampering with any cell breaks the chain hash for every cell after it.
• Inserting, deleting, or reordering cells changes the topology fingerprint, which breaks every subsequent chain link too.
• Forging a coordinate requires breaking GHA-1024: pre-image resistance on SHA-512 with iterative folding.
• A reader replays the chain from genesis and verifies. Any reader, independently. No quorum. No vote.

The result: a public ledger with cryptographic immutability and zero consensus overhead. No mining, no 51% attack surface, no gas fees. One file, one chain, one source of truth, verifiable by anyone who reads it.

This isn't blockchain done worse. It's a different mechanism for a different threat model. One where the master grid is a single authoritative instance, not a distributed disagreement.

Registration is voluntary. A .grid file is fully functional without ever appearing on the master grid. The master grid is for grids that choose to be discoverable.

grid register -g my.grid --name "My Grid"

What this does:

1. Reads my.grid, computes its coordinate from genesis via GHA-1024.
2. Checks the master grid for an existing entry at that coordinate. If active: error (the coordinate is taken, which means that exact grid is already registered). If retracted: error (the coordinate is tombstoned permanently).
3. Writes a grid-entry cell at @/grids/<x>/<y>/<z> with the coordinate, registrant identity, registration timestamp, and chain hash.
4. Optionally writes a grid-meta cell at @/grids/<x>/<y>/<z>/meta with name, description, and visibility (public, discoverable, or private).

Anyone can register their own grid. Registration is open.

grid retract -g my.grid

Writes a superseding grid-entry cell with status: retracted and retracted-at: <timestamp>. The original entry stays in the chain (the chain is append-only), but live queries see the retraction.

Coordinates are never reused. A retracted coordinate stays retracted. The grid that produced it cannot re-register. If you want to come back, write a new genesis cell, different bytes, different coordinate, different identity.

Auth is gated. Only the registrant or the founding identity can retract. Anyone else gets silently no-op'd (denial is invisibility, the master grid follows the same doctrine as every other grid).

Two addressing systems compose:

Local:    @/tasks/review
Global:   [182473615824907, 94862175839204, 226815439728601]::@/tasks/review

The :: separator is the bridge. Any grid expression can take a global address as a target:

study: [182473615824907, 94862175839204, 226815439728601]::@/data/**
fetch [182473615824907, 94862175839204, 226815439728601]::@/system/genesis

How it resolves:

1. The kernel looks up the coordinate on the master grid, gets the grid-entry cell (or empty if not registered).
2. The kernel consults the local index (next section) to find where that grid's file lives on this machine.
3. The kernel opens that file as a read-only Grid and resolves the local part of the address inside it.

The composition lets any grid address any cell on any registered grid. From inside my.grid, you can pull a cell from their-public-grid.grid by coordinate. The reference is durable. The coordinate doesn't change when the file moves or gets renamed.

This is the security separation that makes the master grid public.

~/.grid/index.grid is a private grid file on your machine. It maps coordinates to filesystem paths. It is never shared. It is never networked. It is the answer to "where on my disk is the file at this coordinate?" and only your machine knows.

The master grid carries coordinates. The local index carries paths. The two never combine on a shared surface.

Why this matters:

• The master grid can be public. Coordinates leak nothing about where files live.
• Sharing the master grid never shares filesystem layouts. No /Users/<your-username>/... paths leaking.
• Multiple machines can have totally different local indexes for the same set of coordinates. Each machine knows where its own copies live.

grid register writes to both. The master grid gets the coordinate cell, the local index gets the path. grid open reads the local index. Cross-grid resolution uses the local index to turn a coordinate into a file handle.

Grid is purely native otherwise. Every .grid file is a local file. The CLI is one binary. The console is one binary. There is no server, no daemon, no required network connection. Local work is hermetic.

The master grid is the exception. When the canonical instance is online, it will be reachable over GTP (Grid Transport Protocol) over HTTP. Read-only network reads for coordinate lookups and discovery. Registration writes still happen locally through grid register against your own copy or via a write API to the canonical instance.

GTP exists only for the master grid. Local grid-to-grid operations on your own machine don't touch the network. The default state of any Grid project is offline.

The coordinate space is enormous. Each axis holds 2^48 values:

281,474,976,710,656 values per axis

Three axes. Total coordinate space: ~2^144, roughly 2.2 × 10^43 possible coordinates. Effectively infinite for any human-scale corpus.

Practical capacity is bounded by hardware, not address space. The master grid is a .grid file like any other; it scales the way every .grid file scales:

• Each registered grid is one cell at @/grids/<x>/<y>/<z>, plus an optional metadata cell. Roughly a few hundred bytes per registered grid in the append-only log, plus an index entry at the file tail.
• The sorted index gives O(log n) lookup. For 100 million registered coordinates, a lookup is ~27 binary-search steps. Microseconds on commodity hardware.
• For one billion: ~30 steps. Microseconds.
• The file lives memory-mapped on the dedicated machine. Reads are RAM-fast. Writes append to the end of the log and update the index.

With realistic compute on a dedicated machine (terabytes of storage, generous RAM), the master grid can comfortably manage hundreds of millions of grid coordinates, and scales to billions before the physical hardware becomes the constraint rather than the format. The address space itself will not run out for as long as physics permits.

The master grid isn't a directory you browse manually. It's the substrate for an AI-native ecosystem of grids. The layer that lets residents navigate autonomously.

A resident with master-grid access can:

• Discover by intent.

  study: type=grid-entry where: slot:visibility = public
  study: type=grid-meta where: slot:name contains "calendar"

  The master grid is queryable. Residents find grids by name, type, visibility, or any metadata slot the registrant exposed.

• Resolve cross-grid references on-the-fly. A resident's working grid can cite cells in other grids by coordinate. When it reads those citations, the kernel pulls the data live. No copy, no sync, no replication. The other grid is its own source of truth.

• Bootstrap from templates. Public template grids on the master grid become starting points. A resident setting up a new project finds a template grid by coordinate, derives the shape, writes its own genesis.

• Compose across grids in one expression. Pull source data from a public coordinate, transform it, write results to a shared output grid. All in one pipeline. All addressable.

• Audit by identity. study: type=grid-entry where: written-by=<resident-id> returns every grid a particular resident has registered. Provenance is free.

• Hold long-running memory across many grids. A resident's cognition lives in its working grid. Reference data lives in many other grids. The master grid is the index that lets the resident treat all of them as one navigable space.

This is the load-bearing claim for the next phase of Grid Theory: residents, AI or otherwise, operate on a substrate where every grid has a deterministic address, every coordinate is one lookup away, and the integrity of the map is enforced by the same math that enforces the integrity of any individual grid.

The web has URLs. URLs depend on DNS, on hosts, on whoever owns the domain today. The Grid network has coordinates. Coordinates depend on content. The position of a grid in the master grid is what that grid IS. Not where someone decided to host it.

The master grid is alive. The format is stable. The registration, retraction, and resolution code is implemented and tested.

What's not yet public:

• The canonical instance (the one master grid the network points at) is being prepared for its dedicated computer. Its coordinate will be determined when its genesis is written for deployment.
• The Base 2 native resident that manages it (see the Bases) is in development.
• GTP, the network transport, is implemented for local loopback. Public hosting comes online with the canonical instance.

Until then, the master grid CLI surface (master init, register, retract, find, open) is intentionally disabled in the public grid binary. It prints "coming soon" and exits. When the network goes live, the same commands wake up against the real instance.

This is deliberate sequencing. The format is locked. The deployment is the next move.