What is aDNA?

aDNA (Agentic DNA) is an open standard for organizing project knowledge so that both humans and AI agents can navigate it. Think of it as a genome for your project — a structured encoding of what your project knows, who is involved, and how work gets done.

The problem

AI agents are increasingly capable, but they struggle with the same thing humans do: finding the right context in a sea of files. Without structure, agents waste tokens loading irrelevant information or miss critical context entirely. The result: you re-explain your project at the start of every session, agents make decisions that contradict earlier ones, and knowledge accumulated over weeks evaporates when the context window closes.

This isn't an agent capability problem. It's a knowledge architecture problem. The agent is capable — it just has nowhere to look.

Why aDNA exists

aDNA exists because there was no shared standard for how a project should present itself to an AI agent. Every team invented their own approach: some dropped a long README into the prompt, others used custom system instructions, others relied on the agent to figure it out. None of these scale across sessions, across agents, or across teams.

aDNA is the attempt to solve this once, openly — a standard that any team can adopt, any tool can support, and any agent can navigate without custom configuration.

The aDNA approach

aDNA provides three things:

• The Triad — every project is organized into three directories: who/ (people and governance), what/ (knowledge and decisions), and how/ (operations and workflows). The layout itself is the first piece of orientation — an agent that has seen one aDNA project knows where to look in any other.
• Governance files — CLAUDE.md, AGENTS.md, MANIFEST.md, STATE.md, and README.md give agents the orientation they need at every level of the project. The root CLAUDE.md is the agent's entry point: it explains the project's purpose, structure, rules, and where to start working.
• Typed entities — 14 base entity types (concepts, missions, sessions, lattices, and more) with consistent frontmatter and naming conventions. Typed entities are predictable: an agent that knows what a mission file looks like can load any mission file in any aDNA project and understand its structure immediately.

What the structure looks like

A minimal aDNA project — three directories, five governance files, everything the agent needs to orient and act:

your-project.aDNA/
├── CLAUDE.md          # Agent entry point: purpose, rules, where to start
├── STATE.md           # Live snapshot: blockers, active work, next steps
├── MANIFEST.md        # Project overview and architecture
├── who/               # WHO — people, governance, coordination
│   └── governance/    # Roles, policies, vision
├── what/              # WHAT — knowledge, decisions, context
│   └── context/       # Curated knowledge files agents load
└── how/               # HOW — operations, plans, execution
    ├── missions/      # Work decomposed into claimable objectives
    └── sessions/      # Per-session tracking and handoff notes

An agent that has seen one aDNA project recognises this layout in any other. The structure is the orientation — before the agent reads a single word of content.

The 14 entity types

Every file in an aDNA project has a declared type. This predictability is what makes cross-project navigation possible without custom configuration:

What a CLAUDE.md looks like

The CLAUDE.md is not a README — it is the agent's operating protocol. Here is the opening of the real CLAUDE.md from this documentation vault (aDNA.aDNA/CLAUDE.md):

# CLAUDE.md — aDNA.aDNA

You are Rosetta — named after the Rosetta Stone, the artifact that decoded
Egyptian hieroglyphics by presenting the same text in three scripts. This
vault does the same: it presents the aDNA standard in three registers —
technical specification, operational practice, and plain-language explanation.

## Project Map

aDNA.aDNA/
├── CLAUDE.md     ← You are here — agent master context (this file)
├── STATE.md      ← Operational snapshot: current phase, blockers, next steps
├── what/         ← Knowledge objects, context library, lattice definitions
├── how/          ← Operations, sessions, missions, campaigns, skills
└── who/          ← Governance, community, coordination

## Standing Orders

1. Phase gates are human gates — never auto-advance between phases.
2. Every mission gets an AAR before marking it completed.
3. Upstream spec is source of truth — cite adna_standard.md for normative claims.

The agent reads this file at the start of every session. It replaces the informal "just figure it out from the README" approach with a structured, reliable contract between the project and any agent that works on it.

Before and after

Here is what the same project looks like with and without aDNA:

Without aDNA: A research lab has 200 files spread across Notion, Google Drive, and a Git repo. Every time a new agent session starts, the team pastes a summary into the prompt. The summary is always outdated. The agent asks clarifying questions. Decisions made last month get re-litigated. A new collaborator takes three days to get oriented.

With aDNA: The same project has a what/context/ library of curated knowledge files. The STATE.md shows current priorities and blockers. The how/missions/ directory has the active work decomposed into claimable objectives. A new agent loads the root CLAUDE.md, reads the relevant context files, and starts working in the right direction — in the same session.

This site is a live aDNA vault

This documentation site IS an aDNA vault. The pages you are reading are generated from files inside github.com/LatticeProtocol/aDNA.aDNA — a real, actively maintained aDNA project that teaches the standard by using the standard. Every concept explained here has a corresponding file in the vault that demonstrates it in practice:

• aDNA.aDNA/STATE.md — the live operational snapshot: current phase, active missions, blockers
• aDNA.aDNA/what/context/ — the curated knowledge library agents load before working
• aDNA.aDNA/how/campaigns/campaign_rosetta/ — the campaign that built this site, with mission files, cycle records, and AARs
• aDNA.aDNA/CLAUDE.md — the exact CLAUDE.md snippet shown above, in full

Navigate the vault in Obsidian, VS Code, or GitHub. Every directory you open, every frontmatter field you read — that is an aDNA concept in action, not just described.

The three-question test

A well-structured aDNA project should let any agent answer three questions immediately, without asking:

1. What is this project? — answered by CLAUDE.md and MANIFEST.md at the root
2. What is the current state? — answered by STATE.md (blockers, active work, next steps)
3. Where do I start working? — answered by the active mission file in how/missions/ or the relevant AGENTS.md in the working directory

If your project can answer all three in under 10 seconds of reading, it is aDNA-ready.

Explore further

• The Triad — the foundational structure: who, what, how
• Governance Files — CLAUDE.md, AGENTS.md, STATE.md, and their roles
• Get Started — set up your first aDNA project in three steps
• Tutorial: Create Your First CLAUDE.md — hands-on, 20 minutes
• The Convergence Model — how aDNA narrows context at each level of the execution hierarchy