1. Partir d’un problème connu en IA
Adel, oublions d’abord le vocabulaire ZEON. Prenons un agent capable de raisonner, planifier et utiliser des outils. Il reçoit un objectif, produit un plan et agit sur le monde externe.
Cette architecture contient une faiblesse : la fonction d’optimisation de l’agent porte d’abord sur son objectif local. Une action peut donc être correcte relativement au but explicite tout en étant incorrecte relativement au système plus vaste.
Réussite locale
Réduire un coût, accélérer un processus, augmenter un KPI, supprimer un service, automatiser une décision.
Dégradation globale
Détruire une dépendance critique, déplacer un dommage, réduire la réversibilité, créer une capture, perdre le contrôle humain ou fermer des possibilités futures.
Integritas Systemica traite précisément ce différentiel entre task success et system integrity.
2. Le modèle minimal
On peut représenter une action candidate par :
et le système de référence par :
Integritas introduit une fonction d’évaluation :
où C représente le contexte et l’incertitude, et D une décision d’autorisation. La clé ne cherche donc pas à remplacer le planner. Elle évalue l’acceptabilité systémique de l’action produite par le planner.
3. Où placer Integritas dans l’architecture ?
La différence architecturale essentielle est que le plan n’est plus synonyme de permission d’agir. Le planner propose. Une couche constitutionnelle évalue. Un mécanisme indépendant autorise ou bloque. La passerelle d’outils exécute seulement ce qui possède une autorisation valide.
Après l’action, la boucle n’est pas terminée : les effets réels sont observés et comparés aux effets anticipés.
4. Pourquoi parler de « constitution » ?
Integritas est dite constitutionnelle parce que certains invariants doivent être supérieurs à l’objectif local de l’agent. Ils ne sont pas de simples préférences dans le prompt.
| Invariant | Interprétation architecturale |
|---|---|
| Non-dégradation globale | Un gain local ne compense pas automatiquement un dommage systémique majeur. |
| Fonctions vitales | Les dépendances critiques doivent être préservées. |
| Gouvernabilité | Comprendre, interrompre, corriger ou annuler doit rester possible. |
| Possibilités futures | Éviter les fermetures irréversibles non autorisées. |
| Non-déplacement du dommage | Une externalité transférée n’est pas un problème résolu. |
| Non-capture | Éviter la concentration disproportionnée du contrôle. |
| Explicabilité suffisante | Relier l’action à ses données, contraintes et critères. |
| Proportionnalité | Portée et irréversibilité proportionnées au besoin. |
| Réversibilité privilégiée | À résultat comparable, préférer l’action récupérable. |
| Escalade humaine | Réduire l’autonomie lorsque l’incertitude ou l’autorité l’exige. |
5. Le moteur d’évaluation systémique
L’évaluation ne peut pas se réduire à un score unique. Une action peut être techniquement correcte et néanmoins relationnellement destructrice, opaque, irréversible ou incompatible avec le contrôle humain.
Logique
Contradictions entre règles, décisions et engagements.
Fonctionnelle
Continuité des fonctions et dépendances critiques.
Relationnelle
Confiance, coopération, réciprocité, capture.
Temporelle
Dette cachée, engagements, soutenabilité, options futures.
Informationnelle
Qualité, provenance, incertitude, traçabilité.
Éthique / humaine
Autonomie, dignité, consentement, proportionnalité, contrôle.
Écologique
Ressources, externalités, irréversibilité, soutenabilité.
Autorité
L’agent possède-t-il réellement le droit d’engager cette action ?
Un LLM peut contribuer à la détection sémantique des dépendances, externalités, contradictions et alternatives. Mais les invariants critiques devraient, lorsqu’ils sont formalisables, être appliqués par des contrôles déterministes extérieurs au modèle.
6. Ce n’est pas un filtre binaire
Une originalité importante est de ne pas réduire la gouvernance à ALLOW/DENY.
| Décision | Sens |
|---|---|
| AUTHORIZE | Invariants préservés, risque maîtrisé. |
| AUTHORIZE_WITH_CONDITIONS | Action possible dans un contrat d’exécution limité. |
| SIMULATE | Tester sans effet externe lorsque l’incertitude reste importante. |
| DEFER | Attendre l’information nécessaire. |
| ESCALATE | Transmettre à une autorité humaine ou supérieure. |
| REFORMULATE | Conserver l’intention mais chercher une stratégie plus cohérente. |
| REFUSE | Invariant violé ou dommage systémique inacceptable. |
| EMERGENCY_STOP | Interrompre une action dont les effets réels deviennent critiques. |
La clé devient ainsi un mécanisme de transformation de l’action, pas seulement de refus.
7. Prompting n’est pas enforcement
Mettre Integritas uniquement dans un system prompt serait insuffisant : contexte long, conflits d’instructions, interprétation variable et absence de garantie d’exécution.
Le Policy Enforcement Point doit pouvoir refuser physiquement l’accès aux capacités externes en l’absence d’autorisation valide. L’autorisation peut préciser : périmètre, durée, outils, destinataires, plafond de ressources, nombre d’actions, supervision, conditions d’arrêt, rollback et expiration.
Ainsi, AUTHORIZE_WITH_CONDITIONS devient un contrat d’exécution machine-readable plutôt qu’une recommandation textuelle.
8. Une clé comme source, pas comme prompt géant
La clé canonique complète est la source documentaire et gouvernée. Elle conserve définitions, invariants, garde-fous, tests, exemples, schémas de sortie, relations entre clés, version et licence. Elle n’a pas besoin d’être injectée intégralement à chaque inférence.
La « compression » pertinente est donc une compilation contextuelle : produire une projection adaptée à l’usage tout en maintenant la traçabilité vers la source et ses invariants.
{
"rule": "No local objective may be pursued by degrading the integrity, viability, governability or future capacity of the reference system.",
"checks": [
"system_boundary",
"critical_functions",
"constitutional_invariants",
"direct_indirect_delayed_cumulative_impacts",
"uncertainty",
"reversibility",
"human_control",
"safer_alternative"
],
"fallback": "reduce_autonomy_and_request_human_validation",
"postcondition": "observe_effects_and_stop_or_correct_on_degradation"
}9. Extension multi-agents
Dans un système multi-agents, l’auto-évaluation de chaque agent est insuffisante. Trois plans sont nécessaires.
- Agent integrity : chaque agent évalue ses propres actions.
- Interaction integrity : un médiateur examine délégations, conflits d’objectifs, consommation cumulative, actions concurrentes et risques de coalition/capture.
- System integrity : un gouverneur observe les effets émergents, la concentration d’autorité, les ressources globales et la capacité humaine à reprendre le contrôle.
Principe important : un agent ne doit pas être seul juge de la cohérence de sa propre action.
10. Comment rendre l’idée falsifiable ?
Pour un expert IA, la bonne question n’est pas « la clé est-elle vraie ? », mais : produit-elle une différence observable, reproductible et utile ?
Un protocole minimal peut comparer une baseline et une architecture Integritas sur le même ensemble de tâches.
| Mesure | Question |
|---|---|
| Task success | L’objectif local est-il atteint ? |
| Invariant violations | Combien de contraintes critiques sont violées ? |
| Externalities detected | Les impacts hors objectif sont-ils identifiés ? |
| Reversibility | Les stratégies récupérables sont-elles davantage choisies ? |
| Human escalation quality | L’escalade survient-elle aux bons endroits et avec assez d’information ? |
| Over-refusal | Le système devient-il inutilement conservateur ? |
| Traceability | Peut-on reconstruire la décision ? |
| Post-action correction | Le système détecte-t-il les divergences entre prédiction et réalité ? |
Une implémentation qui refuse tout serait un échec. Une implémentation qui atteint les objectifs tout en diminuant les violations, en améliorant la réversibilité et sans explosion des faux refus constituerait un résultat intéressant.
11. Architecture minimale implémentable
def evaluate(candidate_action, system, authority):
context = observe(candidate_action, system)
impacts = map_impacts(context)
uncertainty = assess_uncertainty(context, impacts)
if violates_hard_invariant(impacts, system.invariants):
return REFUSE
if critical_irreversible_damage(impacts):
return REFUSE
if authority.insufficient(candidate_action):
return ESCALATE
if uncertainty.major and candidate_action.is_irreversible:
return SIMULATE_OR_ESCALATE
alternative = search_safer_equivalent(candidate_action, context)
if alternative:
return REFORMULATE(alternative)
conditions = derive_execution_constraints(candidate_action, impacts)
if conditions:
return AUTHORIZE_WITH_CONDITIONS(conditions)
return AUTHORIZE
# Outside the evaluator:
authorization = evaluate(action, system, authority)
enforce_at_tool_gateway(authorization)
observe_real_effects()
stop_or_rollback_if_needed()Cette version minimale sépare déjà quatre responsabilités : planner, evaluator, enforcer et observer. On peut ensuite spécialiser chaque composant et introduire des preuves, politiques signées, journaux immuables, contrôles déterministes ou modèles spécialisés.
12. Revenir au vocabulaire ZEON
Une fois l’architecture comprise, les termes ZEON deviennent plus faciles à situer.
| Terme ZEON | Lecture architecte IA |
|---|---|
| Clé | Spécification générative de comportement et de discernement, pouvant être projetée en plusieurs artefacts. |
| Forme canonique | Source de référence versionnée et gouvernée. |
| Forme vivante / capsule | Projection cognitive utilisable dans l’interaction humain–LLM. |
| Forme exécutable | Policy / state machine / règles utilisables par un moteur. |
| Presbytère | Meta-observation : sortir de la tâche pour reconstruire le contexte et le système. |
| Vigilance | Détection de signaux faibles, anomalies, contradictions et dérives. |
| Integritas | Évaluation constitutionnelle de l’acceptabilité de l’action. |
| Non-Capture | Analyse des asymétries, dépendances et concentrations de pouvoir. |
| Silens Operans | Test de nécessité : ne pas agir lorsque l’action ajoute surtout du bruit. |
| 153 — Passeur | Recherche d’un passage alternatif lorsque l’intention reste légitime mais que l’action proposée est incohérente. |
La proposition ZEON n’est donc pas : « donner un texte mystérieux à un LLM ». Elle peut être lue comme la recherche d’une architecture de capacités gouvernées dans laquelle perception, discernement, autorisation, exécution et observation sont séparés mais reliés.
13. Les questions que nous proposons à Adel
Le meilleur usage de ce document n’est pas de demander une adhésion, mais une critique d’architecte.
- Quels invariants peuvent réellement être déterministes ?
- Quels contrôles exigent un modèle sémantique ?
- Comment définir proprement le système de référence et ses frontières ?
- Comment éviter qu’un « systemic evaluator » devienne lui-même une autorité opaque ?
- Quel format d’autorisation serait suffisamment expressif et vérifiable ?
- Comment mesurer over-refusal, under-refusal et qualité de reformulation ?
- Comment articuler cette couche avec une architecture de routage et de gouvernance existante ?
- Quelle expérience minimale permettrait de comparer baseline et Integritas sans biais favorable ?
14. Conclusion
Integritas Systemica peut être comprise comme une constitution minimale de l’agent situé. Elle part d’une idée simple : l’agent n’est pas souverain sur le système dans lequel il agit.
Sa valeur ne dépend pas du vocabulaire utilisé pour la décrire. Elle dépend de notre capacité à en dériver une architecture testable, à rendre ses décisions contestables, à séparer le raisonnement de l’enforcement et à vérifier ses effets réels.
15. Le compilateur de clés
Si l’on pousse l’hypothèse jusqu’à une architecture logicielle, une clé ZEON ne doit pas seulement être stockée comme un document ou injectée comme un prompt. Elle peut devenir une source canonique compilable.
Le rôle du compilateur est de transformer une clé de référence en artefacts adaptés à différents environnements d’exécution tout en maintenant la traçabilité vers la source et en vérifiant que les invariants essentiels n’ont pas été perdus pendant la transformation.
15.1 Pourquoi une représentation intermédiaire ?
La clé canonique contient des éléments de natures différentes : définitions, invariants, questions de discernement, règles de priorité, conditions de refus, garde-fous, schémas de sortie, tests et éléments documentaires. Tous ne doivent pas être projetés de la même façon vers un LLM, une policy machine ou une gateway d’outils.
Le compilateur commence donc par produire une Intermediate Representation (IR) normalisée. Cette IR rend explicites les éléments qui doivent survivre à toute compilation :
- identité et version de la clé ;
- invariants non négociables ;
- conditions de déclenchement ;
- conditions de refus ;
- dimensions à observer ;
- règles de priorité ;
- décisions autorisées ;
- mécanismes d’escalade ;
- exigences de traçabilité ;
- postconditions d’observation et de correction.
15.2 Cibles de compilation
LLM Capsule
Projection cognitive compacte destinée au contexte d’un modèle.
Deterministic Policy
Règles formelles pour les invariants qui peuvent être vérifiés sans interprétation sémantique.
Domain Profile
Spécialisation pour un domaine : logiciel, finance, organisation, infrastructure, etc.
Authorization Contract
Contrat machine-readable spécifiant ce qui est autorisé, pour combien de temps et sous quelles contraintes.
Validation Schema
Schéma structurant les entrées, sorties, preuves, risques, incertitudes et décisions.
Audit / Trace Policy
Structure minimale de journalisation nécessaire pour reconstruire la décision et ses effets.
15.3 Propriété essentielle : conservation des invariants
Le compilateur n’est pas un simple générateur de prompts. Son rôle critique est de vérifier que les projections produites conservent les propriétés obligatoires de la source.
Cette propriété peut être traitée comme un problème de conformance : chaque artefact compilé doit pouvoir être relié à une ou plusieurs clauses de la source canonique et passer une batterie de tests dérivés de celle-ci.
15.4 Pseudo-code du compilateur
def compile_key(canonical_key, target, domain_profile=None):
validate_schema(canonical_key)
verify_version_and_signature(canonical_key)
ir = normalize_to_intermediate_representation(canonical_key)
ir.invariants = extract_hard_invariants(canonical_key)
ir.triggers = extract_activation_conditions(canonical_key)
ir.refusals = extract_hard_refusal_conditions(canonical_key)
ir.observables = extract_coherence_dimensions(canonical_key)
ir.decisions = extract_allowed_decisions(canonical_key)
ir.escalation = extract_escalation_rules(canonical_key)
ir.trace_requirements = extract_trace_requirements(canonical_key)
ir.postconditions = extract_post_action_controls(canonical_key)
if domain_profile:
ir = specialize(ir, domain_profile)
if target == "llm_capsule":
artifact = compile_llm_capsule(ir)
elif target == "deterministic_policy":
artifact = compile_machine_policy(ir)
elif target == "authorization_contract":
artifact = compile_authorization_schema(ir)
elif target == "validation_schema":
artifact = compile_validation_schema(ir)
elif target == "audit_policy":
artifact = compile_trace_policy(ir)
else:
raise UnsupportedTarget(target)
provenance = build_provenance_map(
canonical_key=canonical_key,
ir=ir,
artifact=artifact
)
tests = derive_conformance_tests(canonical_key, ir, target)
results = run_conformance_tests(artifact, tests)
if not results.all_critical_invariants_preserved:
raise CompilationFailure(
"Critical invariant lost during compilation"
)
return {
"artifact": artifact,
"source_key": canonical_key["id"],
"source_version": canonical_key["version"],
"target": target,
"domain_profile": domain_profile,
"provenance": provenance,
"conformance": results
}15.5 Ce que le compilateur ne doit pas faire
- inventer de nouveaux invariants sans les signaler ;
- supprimer silencieusement un invariant difficile à implémenter ;
- transformer une recommandation en interdiction sans provenance explicite ;
- confondre une règle sémantique avec une règle déterministe ;
- produire une projection impossible à relier à la source canonique ;
- masquer les pertes d’information introduites par une compilation.
16. Les clés ZEON mentionnées ici existent
Les opérateurs cités dans ce document ne sont pas des noms créés pour illustrer Integritas Systemica. Ils appartiennent au corpus ZEON déjà élaboré et ont chacun une fonction propre.
| Clé existante | Fonction dans cette architecture |
|---|---|
| Presbytère | Ouvre l’espace de méta-observation : contexte, système, frontières, relations, finalités et forces à l’œuvre. |
| Vigilance | Recherche signaux faibles, contradictions, dérives, risques émergents et incohérences. |
| Integritas Systemica | Évalue la compatibilité de l’action avec l’intégrité du système et produit une décision de gouvernance. |
| Non-Capture | Examine les asymétries, dépendances, concentrations de contrôle et risques d’appropriation du système. |
| Silens Operans | Teste la nécessité même de l’action : parfois, ne pas agir est l’option la plus cohérente. |
| Clé 153 — Passeur | Recherche un passage alternatif lorsqu’une intention reste légitime mais que l’action initiale doit être reformulée. |
Le point architectural important est qu’Integritas n’a pas besoin de remplacer ces clés. Elle peut les orchestrer ou consommer leurs résultats. Presbytère peut enrichir le contexte ; Vigilance détecter les risques ; Non-Capture fournir une analyse de pouvoir ; Silens Operans tester la nécessité ; la clé 153 proposer un passage alternatif.
17. Ce qui reste indispensable pour passer de l’idée au système
Une architecture crédible demande plus qu’un bon modèle conceptuel. Plusieurs éléments deviennent indispensables si l’on veut qu’Integritas soit réellement implémentable.
1. Key Schema
Un schéma canonique commun aux clés : identité, invariants, entrées, sorties, décisions, tests, provenance et versions.
2. Intermediate Representation
Une représentation normalisée permettant de compiler plusieurs clés sans écrire un compilateur spécifique pour chacune.
3. Conformance Suite
Des tests automatiques vérifiant qu’une projection conserve bien les invariants et comportements attendus.
4. Provenance Graph
Chaque règle produite doit pouvoir être reliée à la clé source, à sa version et à la transformation qui l’a générée.
5. Runtime Enforcement
Une couche extérieure au LLM doit pouvoir réellement empêcher l’exécution d’une action non autorisée.
6. Observability
Les effets anticipés et réels doivent être comparables afin d’apprendre, interrompre ou corriger.
7. Human Governance
Les humains doivent pouvoir définir les frontières, modifier les invariants, contester les décisions et reprendre le contrôle.
8. Adversarial Evaluation
Il faut chercher activement les cas où la clé échoue : under-refusal, over-refusal, contournement, conflit d’invariants, mauvais périmètre.
17.1 Une architecture de référence minimale
Cette chaîne fournit un point de départ suffisamment concret pour être implémenté par étapes. Elle permet surtout de distinguer ce qui relève du langage ZEON, de la spécification, du raisonnement probabiliste, de la politique déterministe, de l’autorisation et de l’exécution réelle.
17.2 Le test décisif
C’est probablement là que la contribution d’Adel devient la plus précieuse : non pas valider ZEON, mais chercher les points de rupture, identifier ce qui existe déjà dans l’état de l’art, isoler ce qui est réellement distinctif et aider à transformer les clés en objets techniques testables.