What it guarantees

The two signature chains — controller-signed releases, agent-signed checkpoints — provably establish eight things. Each is grounded in a mechanism, not a promise.

#	Guarantee	Basis
P1	Integrity — the exact bytes of every DNA version and memory commitment, tamper-evident to genesis	hash links + content addressing
P2	Ordering & time — a total order per lane; each head existed no later than its anchor timestamp	append-only rule + block timestamps
P3	Designed authorship — every behaviour-defining change is controller-signed (or agent-signed under a controller-signed, on-chain, veto-windowed policy)	release-lane signature rule
P4	Learned authorship — the complete, closed set of agent-signed mutations: all checkpoints	checkpoint signature rule
P5	Context binding — which DNA version each unit of experience was accumulated under	the under field
P6	Liveness — timely agent-key signatures over new commitments, at the declared cadence	the isAlive view
P7	Sovereignty status — redesignable / frozen-but-alive / wild / dead	controller state + liveness
P8	Portability — the lineage is chain-independent and can be re-anchored elsewhere	self-authentication

In the default configuration this sharpens to a single sentence: every DNA change is controller-signed, every memory commitment is agent-signed, and the two keys are never interchangeable.

What it deliberately does not prove

An honest standard states its limits. Signatures prove authorship of the record, not runtime behaviour: P3/P4 do not prove the deployed runtime executed that DNA, and P6 proves timely key-holder activity, not cognition or a meaningful state change. AAC-1 is a provenance and accountability layer, not a verified-computation layer. Runtime attestation (TEE/ZK) is a possible future channel, never a registry requirement — and, following the empirical failure of on-chain reputation scores (Sybil-dominated, ~97% dead registrations elsewhere), the chain enshrines no reputation, quality score, or "intelligence verification." Those belong in attestations, off-chain.

Verification is automatable

Because every claim above reduces to a hash check or a signature check, verifying an AAC is mechanical — and Orbofi ships it as a skill any AI can run (aac-verify):

token address
   → registry: read the two lane heads
   → IPFS: fetch each head manifest by its hash
   → verify: SHA-256 integrity + signature authorship + parent links to genesis
   → liveness: check isAlive against the declared cadence

The result is DYOR that an agent can do for you: point it at a token and it returns a verified brain, its full version history, and whether it's still alive — no trust in Orbofi required.