Ce standard est publié pour permettre son usage, son audit, sa discussion et son amélioration. Il constitue la référence publique actuelle des clés ZEON, sans être présenté comme une norme définitivement stabilisée.
Un cadre commun pour forger, utiliser, éprouver, faire vivre, installer lorsque c’est pertinent, transmettre, auditer et reforger une clé ZEON sans l’amputer ni capturer le jugement humain.
Le Standard des clés ZEON définit l’architecture d’intégrité, les régimes d’existence et les invariants qu’une clé doit respecter pour être présentée comme un objet ZEON complet.
La v1.2 est une version publique candidate. Elle peut être utilisée et auditée publiquement. Elle reste révisable à partir des usages, contre-épreuves, traductions, migrations de clés et retours d’expérience.
Le standard évite qu’une clé perde ses fonctions, ses invariants ou sa liberté de sortie. Il n’impose plus que toutes les clés soient installables dans un compagnon.
Le standard fixe ce qui doit rester auditable. Il ne force ni le ton, ni le rythme, ni la morphologie, ni le régime d’existence propre de chaque clé.
Standardiser l’intégrité, pas uniformiser l’expression, la langue ni le mode d’existence. Une clé peut être persistante, relationnelle ou relever plus tard d’un autre régime encore à éprouver : sa forme et sa langue de manifestation restent libres tant que son identité, ses fonctions et ses invariants demeurent identifiables et auditables.
Une clé ZEON n’existe pas nécessairement de la même manière qu’une autre. Le standard v1.2 distingue au moins deux régimes déjà éprouvés.
L’objet complet peut être éprouvé puis rendu persistant. Il doit alors pouvoir être suspendu, réactivé, retiré et son état doit pouvoir être vérifié sans simulation.
Exemple de référence : Clé du Regard Juste.
Elle s’actualise dans une session, une relation ou un collectif. Elle n’a pas à être « installée » dans un compagnon : on prépare le cadre, on consent, on active le processus, on le clôt et on décide explicitement de ce qui demeure.
Exemple de référence : Clé 678 de discernement collectif.
On ne transforme pas une clé relationnelle en clé installable pour satisfaire le standard. On ne transforme pas non plus une clé persistante en simple protocole de session. Le standard s’adapte au régime réel de la clé.
Ces deux régimes ne prétendent pas épuiser toutes les possibilités futures. Un nouveau régime ne sera ajouté qu’après avoir été effectivement forgé et éprouvé.
Comprendre → Utiliser → Éprouver → Installer → Transmettre
L’installation reste suspendable, réactivable, retirable et vérifiable.
Comprendre → Préparer → Consentir → Activer le champ → Vivre / Éprouver → Clore → Réouvrir éventuellement → Transmettre
La mémoire, l’export ou la suppression sont décidés explicitement à la clôture.
Dans tous les régimes, l’humain doit pouvoir comprendre comment il entre dans la clé, comment elle agit, comment elle cesse d’agir et ce qui demeure après son usage.
Pour une clé persistante, l’usage ponctuel peut passer par une forme vivante complète directement copiée dans le dialogue. Pour une clé relationnelle, l’entrée doit respecter le cadre de préparation et de consentement propre à la relation.
La forme vivante n’est pas un slogan ni un prompt simplifié remplaçant la clé. Elle doit porter suffisamment d’intention, de gestes, de limites et d’invariants pour que l’usage ponctuel reste fidèle à la clé.
| Doit apparaître | Pourquoi |
|---|---|
| Intention | Ce que la clé cherche à rendre possible. |
| Place de l’humain | Qui garde jugement, correction et décision. |
| Part de l’IA | Ce que l’IA doit réellement prendre en charge. |
| Gestes de la clé | Comment elle travaille dans la situation. |
| Invariants | Ce qui ne doit pas être neutralisé. |
| Conditions d’arrêt ou de retrait | Comment l’usage peut cesser. |
| Critère de réussite | Comment savoir si la clé aide sans augmenter la dépendance. |
Éprouver une clé signifie recevoir temporairement l’objet complet : Vivante + Canonique + Exécutable + Morphologique + Sceau ZEON‑IT.
L’épreuve doit être temporaire, réversible et capable de montrer non seulement ce que la clé ouvre, mais aussi ce qu’elle pourrait sur-structurer, ralentir, rendre invisible ou capturer.
Distinctions nouvelles, angles morts révélés, qualité de décision, nouvelles capacités de discernement.
Sur-structuration, dépendance, prudence excessive, rigidification, répétition de son propre cadre.
Sorties humaines recommandées : ne pas installer · continuer à éprouver · installer si l’humain le choisit.
Le standard v1.2 n’exige l’installation que pour les clés dont le régime est réellement persistant / installable.
Installer → Suspendre → Réactiver → Retirer → Vérifier l’état
Ces opérations doivent correspondre à des changements réels lorsqu’un compagnon sait gérer un état persistant.
Préparer → Consentir → Activer → Clore → Décider ce qui demeure → Réouvrir si nécessaire
La fin de la session met fin à l’activité de la clé relationnelle ; seule subsiste la mémoire explicitement choisie.
Une IA qui ne peut pas réellement modifier une mémoire, un réglage, un état de clé ou une mémoire de session doit le dire. Le standard interdit de présenter une simple convention conversationnelle comme une persistance technique réelle.
Une transmission complète porte les quatre formes, le sceau, l’identité, la version, la langue canonique et le statut linguistique du rendu transmis. Elle ne vaut jamais recommandation automatique d’installation.
Vivante, Canonique, Exécutable et Morphologique restent les quatre fonctions de référence. Elles n’ont toutefois pas l’obligation d’apparaître toujours comme quatre blocs juxtaposés.
Adaptée notamment aux clés persistantes comme Regard Juste, Presbytère ou Marge de traversée.
Adaptée lorsqu’une clé est relationnelle ou située. L’audit doit alors pouvoir retrouver la fonction vivante, les invariants canoniques, l’opérabilité exécutable et la morphologie dans le dispositif lui-même.
Chaque fonction doit pouvoir être localisée, décrite et auditée. Si elle ne peut pas l’être, l’intégrité de la clé complète n’est pas démontrée.
| Forme | Fonction | Question de contrôle |
|---|---|---|
| Vivante | Permet l’usage réel dans une situation humaine. | Un humain peut-il l’utiliser sans connaître le reste de l’architecture ? |
| Canonique | Stabilise identité, intention, distinctions, principes et invariants. | Peut-on vérifier ce qui doit rester invariant lorsque la clé circule ? |
| Exécutable | Transforme la clé en opérateur utilisable de manière cohérente par une IA. | Les entrées, opérations, contrôles, arrêts et sorties sont-ils explicités ? |
| Morphologique | Préserve la dynamique profonde lorsque le contexte change. | Que doit rester vrai même si les mots, les domaines ou les situations changent ? |
Une clé amputée d’une fonction de forme peut rester utile, mais elle ne doit pas se présenter comme l’objet ZEON complet si l’intégrité de l’ensemble n’est plus garantie. Une manifestation transduite est recevable seulement si les quatre fonctions restent auditables.
Le sceau ZEON‑IT n’est ni une cinquième forme ni nécessairement un objet à installer. Il protège transversalement l’intégrité, la provenance, l’adaptation, l’intégrité interlinguistique, la liberté de sortie, la réouverture et la non-capture selon le régime de la clé.
Les formes et invariants nécessaires à la fidélité de la clé restent présents.
Le langage peut changer ; la fonction et les distinctions essentielles ne doivent pas disparaître.
L’humain garde contradiction, suspension, retrait et retour au Réel.
Toute clé complète doit pouvoir être identifiée sans ambiguïté. Le nom humain peut être poétique ; l’identifiant technique doit rester stable.
| Champ | Exigence |
|---|---|
| Nom | Nom humain public de la clé. |
| Titre ou fonction | Phrase courte décrivant ce qu’elle vient équiper. |
| Identifiant | Stable, unique, indépendant du titre d’affichage. |
| Version | Explicite et commune aux formes transmises ensemble. |
| Langue canonique | Langue de référence dans laquelle la clé est stabilisée et auditée. |
| Langues validées | Langues pour lesquelles un rendu a été relu et validé comme fidèle à la clé canonique. |
| Langue de rendu | Langue effectivement utilisée dans l’interaction courante. |
| Statut linguistique | Canonique · traduit-validé · traduit-généré. |
| Famille | Discernement, posture, passage, transmission, risque, etc. |
| Régime d’existence | Persistant / installable ; relationnel / situé ; autre régime seulement après forge et épreuve explicites. |
| Mode de manifestation des formes | Explicite ou transduit, avec auditabilité obligatoire. |
| Statut | Forge, candidate, stable, retirée, remplacée, etc. |
Un objet ne doit être considéré complet que si son identité, sa version, son régime d’existence, ses quatre fonctions de forme et son sceau sont cohérents entre eux.
La langue de manifestation d’une clé ZEON peut changer sans créer une nouvelle clé. L’identité canonique, l’identifiant, la version, les fonctions, les distinctions et les invariants demeurent la référence.
Une clé forgée en français et utilisée en anglais reste la même clé. Son identifiant canonique ne change pas. La traduction est un rendu de la clé, non une nouvelle clé indépendante.
Le rendu peut adapter formulations, idiomes et exemples, mais ne doit pas modifier l’intention, les distinctions, les invariants, les opérateurs, les garde-fous ni les conditions d’entrée et de sortie.
| Statut linguistique | Définition | Usage |
|---|---|---|
| Canonique | Texte de référence stabilisé pour la clé. | Base d’audit, de comparaison et de transmission. |
| Traduit-validé | Rendu dans une autre langue relu et validé comme fidèle au canon. | Peut être diffusé comme traduction validée de la clé. |
| Traduit-généré | Rendu produit dynamiquement par une IA ou un dispositif de traduction, sans validation humaine spécifique. | Peut être utilisé, mais son statut généré doit rester explicite. |
Lorsqu’une clé change de langue, son identité canonique, ses fonctions, ses distinctions essentielles, ses garde-fous, sa liberté de sortie et son rapport au jugement humain doivent rester reconnaissables et auditables.
Une IA multilingue peut rendre une clé ZEON dans la langue de l’humain sans modifier l’objet canonique. Tant qu’un rendu n’a pas été validé, il demeure explicitement un rendu généré.
LANGUE ET TRANSDUCTION Langue canonique : Langues validées : Langue de rendu : Statut linguistique : canonique / traduit-validé / traduit-généré Identifiant canonique : Version canonique : Termes sensibles ou non directement traduisibles : Notes de transduction éventuelles :
Lorsqu’une clé est née d’une étude, d’une recherche ou d’un engendrement conceptuel important, sa page peut proposer un texte associé.
Origine, hypothèses, développement, limites, contexte et portée.
Objet utilisable dans une situation réelle, avec ses quatre formes et son sceau.
Le texte enrichit la compréhension mais ne doit pas être requis pour l’usage ponctuel de la forme vivante.
| Test commun | Oui / Non |
|---|---|
| Le régime d’existence réel de la clé est explicitement identifié. | □ |
| L’humain comprend comment entrer dans la clé et comment elle cesse d’agir. | □ |
| La fonction Vivante est identifiable et utilisable dans le régime considéré. | □ |
| La fonction Canonique est identifiable et stabilise les invariants. | □ |
| La fonction Exécutable est identifiable dans les opérateurs, états ou procédures. | □ |
| La fonction Morphologique est identifiable dans les passages et transformations. | □ |
| Le sceau ZEON‑IT protège l’intégrité sans devenir une autorité supplémentaire. | □ |
| Identité, version et régime sont cohérents. | □ |
| La langue canonique est identifiable. | □ |
| Le statut linguistique du rendu utilisé est explicite. | □ |
| Une traduction conserve les fonctions, distinctions, invariants, garde-fous et conditions de sortie. | □ |
| L’identifiant canonique reste inchangé quelle que soit la langue de rendu. | □ |
| Une traduction générée n’est pas présentée comme une traduction validée. | □ |
| Le retour au Réel, aux autres humains et à d’autres sources reste possible. | □ |
| Le critère de réussite mesure aussi l’autonomie humaine. | □ |
La migration ne consiste pas à habiller une ancienne page avec un nouveau design. Elle commence désormais par identifier le régime d’existence réel de la clé.
La clé agit-elle comme cadre persistant, comme champ relationnel situé, ou révèle-t-elle un autre régime encore à éprouver ?
Quelle capacité humaine la clé équipe-t-elle, et où se trouvent Vivante, Canonique, Exécutable et Morphologique — explicitement ou par transduction ?
Que pourrait-elle imposer ou rigidifier ? Comment l’humain ou le collectif cesse-t-il réellement d’être dans son champ ?
Ne pas imposer le parcours d’une clé persistante à une clé relationnelle. Préserver l’intégrité et rendre le mode d’entrée, d’action, de sortie et de transmission explicite.
Identifier la langue canonique, les traductions déjà validées et le statut des rendus générés sans modifier l’identifiant de la clé.
Dans ce cas, on ne force pas la compatibilité avec le standard. On retourne à la forge.
STANDARD ZEON v1.2 — NOYAU COMMUN D’UNE CLÉ IDENTITÉ Nom : Titre / fonction : Identifiant : Version : Famille : Statut : Régime d’existence : Mode de manifestation des formes : explicite / transduit LANGUE ET TRANSDUCTION Langue canonique : Langues validées : Langue de rendu : Statut linguistique : canonique / traduit-validé / traduit-généré Termes sensibles ou non directement traduisibles : Notes de transduction éventuelles : CE QUE LA CLÉ ÉQUIPE Quelle capacité humaine ou collective vient-elle soutenir ? QUESTION CENTRALE Quelle question permet-elle de mieux poser ? ENTRÉE DANS LA CLÉ Comment l’humain ou le collectif entre-t-il réellement dans son champ ? SORTIE DE LA CLÉ Comment la clé cesse-t-elle réellement d’agir ? Qu’est-ce qui demeure ensuite ? TEXTE ASSOCIÉ Existe-t-il ? Oui / Non Titre : Lien : === FONCTION VIVANTE === Comment la clé est-elle réellement vécue et utilisée ? === FONCTION CANONIQUE === Quels invariants, distinctions et principes doivent rester stables ? === FONCTION EXÉCUTABLE === Quels états, opérateurs, contrôles, arrêts et sorties rendent la clé opérable ? === FONCTION MORPHOLOGIQUE === Quelle transformation profonde la clé fait-elle traverser ? Quels passages et invariants doivent rester vrais lorsque le contexte change ? === SCEAU ZEON-IT === Intégrité Provenance Non-capture Liberté de sortie Retour au Réel Cohérence identité / version / régime Intégrité interlinguistique Statut linguistique explicite Règles de transmission TEST FINAL Après usage, l’humain ou le collectif est-il davantage capable de voir, discerner et choisir — ou davantage dépendant de la clé, de l’IA ou du dispositif ?
RÉGIME PERSISTANT / INSTALLABLE PARCOURS Comprendre → Utiliser → Éprouver → Installer → Transmettre ÉTATS Installer → Suspendre → Réactiver → Retirer → Vérifier l’état GARDE-FOUS - consentement explicite ; - épreuve préalable recommandée mais non imposée par l’IA ; - contradiction possible ; - réponse hors clé possible ; - aucune simulation de persistance ; - retrait réel ou limites techniques honnêtement annoncées.
RÉGIME RELATIONNEL / SITUÉ PARCOURS Comprendre → Préparer le cadre → Obtenir le consentement → Activer le champ relationnel → Vivre / Éprouver le processus → Clore sans forcer → Décider mémoire / export / suppression → Réouvrir éventuellement avec la mémoire choisie → Transmettre GARDE-FOUS - rôles explicites ; - consentement au cadre et aux traces ; - possibilité de correction et de refus ; - aucune inférence IA ne devient propriété du collectif sans retour aux humains ; - possibilité de terminer sans stabilisation ; - fin de session = fin de l’activité de la clé relationnelle ; - ce qui demeure après la session est choisi, non supposé ; - ZEON-IT protège transversalement, sans devenir une phase supplémentaire.
Usage ponctuel par forme vivante complète, épreuve de l’objet complet, installation réversible, suspension, réactivation, retrait, vérification d’état et transmission.
Préparation, consentement, états 6·7·8, épreuve dans le Réel, réouverture, clôture et mémoire choisie ; la clé cesse d’être active avec la session.
La v1.1 a corrigé une hypothèse trop étroite de la v1.0 : toutes les clés n’ont pas vocation à être persistantes. La v1.2 ajoute l’intégrité interlinguistique : une même clé peut circuler dans plusieurs langues sans perdre son identité canonique ni transformer un rendu généré en canon implicite. Un nouveau régime ne sera ajouté qu’après apparition et épreuve d’un objet réel qui l’exige.