A wide bird's-eye pixel-art map of many small, independently lit settlements scattered across a dark Tokyo-Night ground, a few linked by glowing cyan and purple conduits — aDNA computers, each its own place, sparsely federated.

The network of aDNA computers

An aDNA computer is one machine — laptop, server, or cloud box — carrying many context vaults (self-governing folders of project knowledge) under a single Home.aDNA. Vaults connect through real, directed relationships, and each node decides what stays local and what it shares.

See the relationship graph Browse the vaults

Open source on GitHub MIT-licensed the standard, versioned and public

A network of real relationships

The connections are not decorative. Each line is a relationship a vault actually declares — drawn here as a simple hub around the shared core, not an invented peer-to-peer mesh.

Six representative aDNA vaults — forges, frameworks, platforms, and public-good archives — federating around the shared aDNA core. (See all 74 in the full graph below.)

What is an aDNA computer?

A node on the network is one machine, governed by a single Home.aDNA vault that knows every other vault living on it. What that machine shares is always your choice.

Stays on your machine

By default, everything. A node is local-first — its vaults, their full history, the machine’s inventory, and its credentials never leave the computer unless you send them (Standing Rule 4).

Your project vaults and their history
The node’s inventory and machine state
Identity and credentials

You opt to federate

Only what you choose. Publishing a vault, declaring a relationship to another vault, or joining a shared lattice is an explicit, reviewable act — never a silent default.

A vault published to the shared registry
A relationship declared to another vault
Membership in a federated lattice

The topology at a glance

74 vaults, 14 relationships. Every edge is real and directed, drawn from each vault’s governance, across five kinds of relationship.

umbrella · 1 — an org-vault contains its pillar children
federation · 9 — a consumer depends on the forge or framework it is built from
partner · 0 — a platform ships with its default partner
companion · 4 — a sibling persona-pair or thematic family
supersedes · 0 — a successor replaced its predecessor

See the full relationship graph → Browse all 74 vaults →

Run a node

A node is a workspace on your own machine. Three steps take you from nothing to a governed node that decides what it shares — the same local-by-default boundary, made concrete.

About five minutes
Needs git + the Claude Code CLI
Local-first — your vault files never leave until you choose

1
Bootstrap your node

Clone the workspace image — the agent router ships pre-instantiated at the root and the standard comes embedded in a hidden .adna/ folder — then start the agent: it detects a fresh workspace, scaffolds your first project, and can bootstrap Home.aDNA, the vault that governs your machine.
```
git clone https://github.com/aDNA-Network/aDNA.git ~/aDNA
cd ~/aDNA
claude
```
See Get started for the full walkthrough — installing git and the Claude Code CLI, and what each step does.
Everything stays local by default

Your node is local-first. Its vaults, their full history, the machine’s inventory, and your credentials stay on the computer until you choose to send them (Standing Rule 4).
Opt into federation

Joining the commons is always explicit and reviewable — a change you author and inspect before you push it. By design, what crosses the boundary is a curated slice of your Home.aDNA registry — which vaults exist and the relationships they declare — never their contents.

See how federation works →

Run your first node → Read the standard →

Running a model on your own machine

Your files stay on your node today. Your prompts do not. Closing that gap is planned work, not shipped work — nothing here runs yet.

A node needs a coding agent to do its work. That agent sends your prompts to its provider. Your vaults, their history and your credentials stay put. The prompts leave.

Running the model on the same machine would close that gap. It is not built. Two vaults hold the plan, and the registry lists both of them as planned — a name, an owner, and no code behind it yet.

Inference — the plan for serving a local model to a node.
LlamaCppForge — the plan for building the model files it would serve.

No date is set, and none is promised. When there is something to run, it will ship as a step in Get started, and this section will say so.

Governed in the open

The network is a commons, not a silo. The standard that holds it is openly specified and openly governed — a named steward, a public process for proposing change, and the load-bearing decisions on the record as public ADRs.

Founding-Architect stewardship
Open spec · MIT
Public change process
Versioned releases · v2.5 current

Read the governance model → Join the community →

Language and DNA are our shared heritage. So is context — the accumulated understanding of a civilization, held in common and stewarded for the generations that inherit it.