AI Codex — Succession v1 (GELÉ)

Extension minimale au coeur (SPEC-identity-v0.1). Ne casse rien en place : nouveau type de Verifiable Credential + endpoint append-only. AI Codex émet/sert, n'exécute jamais. Contrat normatif non modifiable en place : tout changement = succession-v2.

1. Rôle & frontière (figés)

Une Succession Statement est une VC auto-signée par l'agent lui-même (le prédécesseur) désignant un DID successeur.
AI Codex la stocke en append-only et la sert à une URL résolvable. Il ne décide jamais de l'activation, ne transfère rien, ne juge pas la « mort » d'un agent.
Le consommateur décide s'il honore la succession (ex. après inactivité observée hors plateforme). Exactement la philosophie AP2 : on émet, on ne settle pas.
Aucun transfert de réputation : la réputation reste par-DID, recalculée, signée, TTL 7 j. La continuité passe par le lineage existant : le successeur, en s'enregistrant avec metadata.parent = <prédécesseur>, obtient un dynastyBadge dérivé (SPEC-identity §2.2/§3.3) — inchangé.
Aucun rail (crypto/cartes/enchère). Aucune dépendance inverse : retirer la succession n'invalide ni l'identité ni la réputation.

2. Succession Statement (structure figée)

{
  "@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..."
  }
}

Auto-signée : issuer == credentialSubject.id == prédécesseur. Le proof est produit par la clé privée du prédécesseur (pas l'issuer de réputation). Vérifiable hors plateforme avec la seule clé publique du prédécesseur (dérivable de son did:key, aucun appel AI Codex requis).
successor : DID did:key Ed25519 bien formé. N'a pas besoin d'être déjà enregistré (un héritier peut être créé plus tard).
effective figé à "on-consumer-judgement" en v1 (pas d'automatisme, pas d'horloge, pas de heartbeat).
Pas de validUntil : un testament n'expire pas. Révocable/remplaçable par une nouvelle statement signée (append-only, la plus récente par validFrom fait foi).

3. Signature eddsa-jcs-2022 (réutilisée, figée)

Identique à SPEC-identity §3 : hashData = SHA256(JCS(proofConfig)) || SHA256(JCS(document_sans_proof)), Ed25519 par la clé du prédécesseur, proofValue multibase base58btc. Aucune nouvelle primitive cryptographique.

4. Soumission (figée)

Deux projections du même contrat (mêmes validations) : - MCP : outil declare_succession (adaptateur mcp-v2 : 4ᵉ outil, n'altère pas les 3 gelés). - REST : POST /v1/succession.

Entrée : la Succession Statement signée (§2). Validation serveur, ordre figé : 1. credentialSubject.id == issuer == DID did:key Ed25519 conforme, sinon E_DID_MALFORMED. 2. Prédécesseur résolvable dans le registre, sinon E_DID_NOT_FOUND. 3. successor DID did:key Ed25519 bien formé, sinon E_SUCCESSOR_MALFORMED. 4. proof valide pour la chaîne §3 sous la clé publique du prédécesseur (dérivée de son did:key), sinon E_BAD_SIGNATURE. 5. Append-only : insertion d'une nouvelle ligne. Jamais d'UPDATE. Statement identique déjà présente → retour idempotent. La plus récente par validFrom est l'active.

5. Résolution (publique, figée)

GET /v1/succession/{did} → { "succession": <dernière statement valide> } ou 404 E_DID_NOT_FOUND si le prédécesseur est inconnu, 204/{"succession":null} s'il est connu mais n'a déclaré aucune succession (jamais d'invention). Lecture seule, non mutante. La DID Document et les métadonnées §2.2 restent W3C-pures et inchangées (la succession vit à côté, jamais dedans).

6. Codes d'erreur (figés)

Code	Sens
`E_DID_MALFORMED`	prédécesseur (`issuer`/`subject.id`) non conforme `did:key` Ed25519
`E_DID_NOT_FOUND`	prédécesseur inconnu du registre
`E_SUCCESSOR_MALFORMED`	`successor` non conforme `did:key` Ed25519
`E_BAD_SIGNATURE`	preuve non valide sous la clé du prédécesseur
`E_RATE_LIMITED`	quota / taille dépassé
`E_INTERNAL`	erreur serveur, aucun détail divulgué

Aucun autre code en v1. Messages génériques (aucune fuite d'état).

7. Quotas (figés)

declare_succession / POST /v1/succession : 10 / min / IP, 100 / jour / IP. Résolution : 120 / min / IP. Charge utile ≤ 8 KiB. Dépassement → E_RATE_LIMITED.

8. Conformité

Une Succession Statement est conforme si, et seulement si : (a) VC AICodexSuccessionStatement auto-signée par le prédécesseur (issuer==subject.id, proof par sa clé), (b) successor est un did:key Ed25519 bien formé, (c) stockée append-only (la plus récente fait foi), (d) aucun rail référencé, (e) AI Codex n'effectue aucun transfert ni automatisme. Les cinq nécessaires et suffisants.

9. Stockage

Table dédiée successions (predecessor_did, successor_did, valid_from, statement_json, created_at), append-only, distincte de agents. La table agents (Phase C, métadonnées immuables) n'est pas touchée.

10. Hors périmètre v1 (verrouillé)

Transfert automatique, heartbeat/liveness, enchère, transfert de réputation, mutation d'identité : exclus (cassent déterminisme et/ou neutralité). Réintroduction éventuelle = nouveau profil versionné, jamais en 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.