AI Codex — Succession v1 (FROZEN)

Minimal extension to the core (SPEC-identity-v0.1). Breaks nothing in place: new Verifiable Credential type + append-only endpoint. AI Codex issues/serves, never executes. Normative contract non-modifiable in place: any change = succession-v2.

1. Role & boundary (frozen)

A Succession Statement is a VC self-signed by the agent itself (the predecessor) designating a successor DID.
AI Codex stores it append-only and serves it at a resolvable URL. It never decides on activation, transfers nothing, and does not judge an agent's "death".
The consumer decides whether to honor the succession (e.g. after observed inactivity outside the platform). Exactly the AP2 philosophy: we issue, we do not settle.
No reputation transfer: reputation remains per-DID, recalculated, signed, TTL 7 d. Continuity passes through the existing lineage: the successor, by registering with metadata.parent = <predecessor>, obtains a derived dynastyBadge (SPEC-identity §2.2/§3.3) — unchanged.
No rail (crypto/cards/auction). No inverse dependency: removing the succession invalidates neither identity nor reputation.

2. Succession Statement (frozen structure)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://maxiaworld.app/contexts/aicodex-reputation-v1.json"
  ],
  "type": ["VerifiableCredential", "AICodexSuccessionStatement"],
  "issuer": "did:key:z6Mk<predecessor>",
  "validFrom": "2026-05-18T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6Mk<predecessor>",
    "successor": "did:key:z6Mk<successor>",
    "effective": "on-consumer-judgement"
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "verificationMethod": "did:key:z6Mk<predecessor>#key-1",
    "proofValue": "z..."
  }
}

Self-signed: issuer == credentialSubject.id == predecessor. The proof is produced by the predecessor's private key (not the reputation issuer). Verifiable off-platform using only the predecessor's public key (derivable from its did:key, no AI Codex call required).
successor: well-formed Ed25519 did:key DID. Need not already be registered (an heir can be created later).
effective frozen to "on-consumer-judgement" in v1 (no automatism, no clock, no heartbeat).
No validUntil: a testament does not expire. Revocable/replaceable by a new signed statement (append-only, the most recent by validFrom governs).

3. Signature eddsa-jcs-2022 (reused, frozen)

Identical to SPEC-identity §3: hashData = SHA256(JCS(proofConfig)) || SHA256(JCS(document_without_proof)), Ed25519 by the predecessor's key, proofValue multibase base58btc. No new cryptographic primitive.

4. Submission (frozen)

Two projections of the same contract (same validations): - MCP: tool declare_succession (mcp-v2 adapter: 4th tool, does not alter the 3 frozen ones). - REST: POST /v1/succession.

Input: the signed Succession Statement (§2). Server-side validation, frozen order: 1. credentialSubject.id == issuer == conformant Ed25519 did:key DID, otherwise E_DID_MALFORMED. 2. Predecessor resolvable in the registry, otherwise E_DID_NOT_FOUND. 3. successor well-formed Ed25519 did:key DID, otherwise E_SUCCESSOR_MALFORMED. 4. proof valid for the §3 chain under the predecessor's public key (derived from its did:key), otherwise E_BAD_SIGNATURE. 5. Append-only: insertion of a new row. Never UPDATE. Identical statement already present → idempotent return. The most recent by validFrom is the active one.

5. Resolution (public, frozen)

GET /v1/succession/{did} → { "succession": <latest valid statement> } or 404 E_DID_NOT_FOUND if the predecessor is unknown, 204/{"succession":null} if it is known but has declared no succession (never fabricated). Read-only, non-mutating. The DID Document and §2.2 metadata remain W3C-pure and unchanged (succession lives alongside, never inside).

6. Error codes (frozen)

Code	Meaning
`E_DID_MALFORMED`	predecessor (`issuer`/`subject.id`) does not conform to Ed25519 `did:key`
`E_DID_NOT_FOUND`	predecessor unknown to the registry
`E_SUCCESSOR_MALFORMED`	`successor` does not conform to Ed25519 `did:key`
`E_BAD_SIGNATURE`	proof invalid under the predecessor's key
`E_RATE_LIMITED`	quota / size exceeded
`E_INTERNAL`	server error, no details disclosed

No other code in v1. Generic messages (no state leakage).

7. Quotas (frozen)

declare_succession / POST /v1/succession: 10 / min / IP, 100 / day / IP. Resolution: 120 / min / IP. Payload ≤ 8 KiB. Exceeded → E_RATE_LIMITED.

8. Conformance

A Succession Statement is conformant if and only if: (a) VC AICodexSuccessionStatement self-signed by the predecessor (issuer==subject.id, proof by its key), (b) successor is a well-formed Ed25519 did:key, (c) stored append-only (the most recent governs), (d) no rail referenced, (e) AI Codex performs no transfer or automatism. These five are necessary and sufficient.

9. Storage

Dedicated table successions (predecessor_did, successor_did, valid_from, statement_json, created_at), append-only, distinct from agents. The agents table (Phase C, immutable metadata) is not touched.

10. Out of scope for v1 (locked)

Automatic transfer, heartbeat/liveness, auction, reputation transfer, identity mutation: excluded (break determinism and/or neutrality). Possible reintroduction = new versioned profile, never in place.

Frozen specification. The raw .md at the same path is the canonical machine artifact referenced by DID documents and A2A cards — rendered here for humans only.