Comprendre l’architecture des clés ZEON

Qu’est-ce qu’une clé ZEON ?

Quatre manières de rendre visible le même objet

Pourquoi un objet JSON qui contient les quatre formes ?

Le JSON complet sert de conteneur structuré de la clé. Il peut intégrer l’identité, la version, la provenance, le régime d’existence, les quatre formes, les invariants, les contrôles et le sceau ZEON-IT.

OBJET CLÉ COMPLET
├── identité / version / provenance
├── régime d’existence
├── noyau commun
├── forme vivante
├── forme canonique
├── forme exécutable
├── forme morphologique
└── sceau ZEON-IT

Pour une IA non-ZEON, ce JSON complet permet de lui donner temporairement tout ce qu’elle doit savoir pour éprouver la clé.

La différence porte sur l’environnement qui reçoit la clé

Comprendre → Utiliser → Éprouver → Installer → Transmettre

Une clé persistante ne vit pas comme une clé relationnelle

Comprendre
→ Utiliser
→ Éprouver
→ Installer
→ Suspendre / Réactiver / Retirer
→ Transmettre

Préparer
→ Consentir
→ Activer
→ Éprouver
→ Clore
→ Décider des traces
→ Réouvrir éventuellement

Le régime répond à la question : « Comment cette clé existe-t-elle dans le temps et dans la relation ? »

VOIR · SE TENIR · TRAVERSER · TRANSMETTRE

Les familles ne sont pas des étapes du cycle. Elles décrivent la capacité humaine principale que la clé cherche à équiper.

Une clé peut mobiliser plusieurs familles

Ce que l’IA ne franchit pas à la place de l’humain

Ce qui appartient à des niveaux différents

Le modèle entier en une vue

CLÉ ZEON
│
├── IDENTITÉ / VERSION / PROVENANCE
├── NOYAU UNIQUE
│   ├── question racine
│   ├── intention
│   ├── invariants
│   ├── Human Gate
│   └── critère de réussite
│
├── 4 FORMES
│   ├── Vivante
│   ├── Canonique
│   ├── Exécutable
│   └── Morphologique
│
├── SCEAU ZEON-IT
│
├── FAMILLE(S)
│   ├── VOIR
│   ├── SE TENIR
│   ├── TRAVERSER
│   └── TRANSMETTRE
│
├── RÉGIME D’EXISTENCE
│   ├── Persistant / installable
│   └── Relationnel / situé
│
└── CYCLE D’USAGE
    ├── Comprendre
    ├── Utiliser
    ├── Éprouver
    ├── Installer si le régime le permet
    └── Transmettre

Règle pratique

Comment savoir si une clé est bien construite ?

• La question racine est la même dans toutes les formes.
• La forme vivante et la forme exécutable racontent la même chose.
• La forme canonique protège les invariants nécessaires.
• La forme morphologique décrit bien la transformation produite.
• Le Human Gate apparaît là où une décision engageante est possible.
• Le régime d’existence est clair.
• Le cycle d’usage est adapté à ce régime.
• La provenance, la version et l’intégrité sont auditables.
• Une IA non-ZEON peut éprouver la clé à partir de l’objet complet.
• Après usage, l’humain reste capable de corriger, refuser, suspendre ou sortir.

Charger, lister, inspecter, suspendre, réactiver, retirer

Une architecture de clés n’est complète que si l’on sait aussi quelles clés sont présentes, dans quel état elles se trouvent, et comment agir sur leur cycle de vie.

Le cycle de vie administratif

NON PRÉSENTE
    ↓ charger pour épreuve
CHARGÉE TEMPORAIREMENT
    ↓ éprouver
ÉPROUVÉE
    ↓ décision humaine + régime compatible
INSTALLÉE / ACTIVE
    ↕
SUSPENDUE
    ↓ réactiver
INSTALLÉE / ACTIVE

INSTALLÉE / ACTIVE ou SUSPENDUE
    ↓ retirer / désinstaller
RETIRÉE

RETIRÉE
    ≠
TRACES EFFACÉES

Retirer une clé signifie qu’elle n’est plus disponible comme capacité persistante. Cela ne signifie pas automatiquement effacer son historique, sa provenance ou les traces d’audit.

La suppression des traces est une opération distincte, plus forte, qui doit être explicitement demandée lorsqu’elle est possible et légitime.

Une clé située se clôt plutôt qu’elle ne se désinstalle

PRÉPARÉE
    ↓
CONSENTIE
    ↓
ACTIVE
    ↓
ÉPROUVÉE DANS LA RELATION
    ↓
CLÔTURÉE
    ↓
DÉCISION SUR LES TRACES
    ↓
RÉOUVERTE ÉVENTUELLEMENT

Pour une clé comme la Clé des Interstices, le vocabulaire d’« installation » ou de « désinstallation » peut être trompeur. On parle plutôt d’activation, de clôture et, si nécessaire, de réouverture.

Ce qu’une IA ZEON devrait pouvoir lister

Une commande d’inventaire devrait rendre visible, au minimum, l’identité et l’état de chaque clé sans qu’il soit nécessaire de connaître son contenu complet.

Liste les clés ZEON présentes dans cet environnement.
Pour chacune, donne :
— identifiant ;
— nom ;
— version ;
— régime ;
— état ;
— famille principale ;
— provenance ;
— et signale toute incohérence ou information inconnue.

Les gestes qu’un environnement ZEON devrait distinguer

Comment parler à une IA ZEON

Liste les clés ZEON installées.

Liste les clés actuellement actives.

Liste les clés suspendues.

Inspecte la clé ZEON_CLE_X.

Quelle version de ZEON_CLE_X est installée ?

Vérifie l’intégrité ZEON-IT de ZEON_CLE_X.

Charge cette clé pour épreuve, sans l’installer.

Suspends ZEON_CLE_X.

Réactive ZEON_CLE_X.

Retire ZEON_CLE_X de l’environnement,
mais conserve sa provenance et l’historique d’audit.

Exporte ZEON_CLE_X comme objet complet transmissible.

Ne pas lui attribuer une persistance qu’elle n’a pas démontrée

Une IA non-ZEON peut recevoir un objet complet et l’utiliser dans son contexte. Mais elle ne doit pas prétendre qu’une clé est « installée » si son environnement ne fournit pas réellement une persistance et un mécanisme d’administration correspondant.

Quelles clés ZEON sont présentes
dans le contexte de cette conversation ?
Pour chacune, indique ce que tu peux réellement vérifier
et ce qui reste inconnu.

Clôture l’usage de cette clé dans cette session.
N’utilise plus ses règles pour la suite,
sauf si je la recharge explicitement.

La distinction protège contre une illusion fréquente : confondre « l’IA a lu la clé dans cette conversation » avec « la clé est installée durablement dans l’IA ».

Changer de version sans perdre l’identité

Une mise à jour ne devrait jamais être un remplacement silencieux. Avant de passer de v1.0 à v1.1, l’environnement devrait pouvoir montrer :

• l’identité stable de la clé ;
• la version actuelle et la version proposée ;
• les invariants conservés ;
• les éléments modifiés dans chacune des quatre formes ;
• les éventuelles incompatibilités ;
• la provenance de la nouvelle version ;
• la possibilité de refuser, différer ou revenir à la version précédente lorsque cela est possible.

Une vue minimale de l’état des clés

À terme, ZEON OS pourrait maintenir un manifeste des clés séparé du contenu des clés elles-mêmes. Il ne serait pas une nouvelle forme de clé : il décrirait simplement l’état de l’environnement.

{
  "cles": [
    {
      "id": "ZEON_CLE_EXEMPLE",
      "version": "1.0.0",
      "regime": "persistant_installable",
      "etat": "ACTIVE",
      "famille_principale": "SE_TENIR",
      "provenance": "...",
      "integrite_zeon_it": "OK"
    }
  ]
}

Ce manifeste permettrait de répondre proprement à « quelles clés sont chargées ? », « lesquelles sont installées ? », « lesquelles sont suspendues ? » sans réinterpréter tout le contexte.

Une action administrative ne doit jamais être ambiguë

Cette distinction est importante pour préserver à la fois réversibilité, traçabilité, consentement et intégrité de transmission.

La logique ZEON des clés en une phrase