> For the complete documentation index, see [llms.txt](https://wiki.orbofi.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.orbofi.com/learn/the-aac-standard/how-it-works.md).

# How it works

AAC-1 rests on one idea: **a manifest's hash is simultaneously its integrity proof, its address, and its pointer.** Everything else follows from that.

## The entry

Every change to an agent — a release or a checkpoint — is a **canonical-JSON manifest**. Its 32-byte SHA-256 hash is three things at once:

1. **Integrity proof** — recompute the hash, and you've verified the exact bytes.
2. **Content address** — the hash *is* the IPFS location (raw-block CIDv1, `f01551220…`), so the manifest is fetchable by its own hash from anywhere.
3. **Pointer** — the next entry embeds it as `lineage.parent`, hash-linking the chain.

Because proof, address, and pointer are the same value, given nothing but a lane's head hash you can fetch the entry, verify it with vanilla SHA-256, read its `parent`, and **walk the agent's entire history backward — with zero trust in the registry, Orbofi, or any RPC.**

```
head ──parent──▶ entry_n ──parent──▶ … ──parent──▶ genesis
  │                │                                  │
 fetch by hash   verify SHA-256                    the AAC token
 from IPFS       read parent, repeat               (mint block)
```

Checkpoint entries also carry `under` — the release they were accumulated under — cross-linking the two lanes into a DAG. Any behavioral diff then cleanly partitions into a **design diff** (release lane) and an **experience diff** (checkpoint lane).

## The registry: a notary, not a curator

The on-chain registry (`AACRegistry`) anchors only the **two lane heads** per token, and enforces exactly the three things an EVM can verify:

* **Append-only ordering** — a new head's `parent` must equal the current head; dense sequence numbers.
* **Authorship** — releases require controller authority; checkpoints require the agent wallet.
* **Time** — block timestamps bound when each head existed.

Everything else is self-authenticating off-chain. Per-token on-chain state is deliberately tiny — two addresses (controller, agent wallet), a mode byte, a liveness heartbeat, and the two lane heads — so the whole thing stays auditable in a minute.

## Two independent ways to recover history

Neither path trusts the other:

| Path                       | Recovers                                              | Needs             | Survives                          |
| -------------------------- | ----------------------------------------------------- | ----------------- | --------------------------------- |
| **Walk the hash links**    | Content genealogy (which manifest derived from which) | IPFS availability | Registry/RPC loss                 |
| **Replay registry events** | Anchoring order (what was accepted, and when)         | An RPC            | IPFS loss of intermediate entries |

This is per-agent **Certificate Transparency**: the registry is the signed tree-head, the lineage is the log.

## Creation stays one transaction

None of this adds friction to launch. Minting an AAC is still **one wallet transaction** — the launcher writes the genesis release atomically at creation. The immutable `tokenURI` (the token's face) is set once and never changes; the *brain* versions live in the lineage, not the token metadata.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://wiki.orbofi.com/learn/the-aac-standard/how-it-works.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.