Modèles de régime · Bibliothèque ouverte

Des modèles de régime typés, paramétrés et versionnés pour les opérateurs de Zone

Chaque Zone sur Axone est gouvernée par un Régime — l’artefact Prolog qui décide qui peut agir, dans quelles conditions et avec quelles conséquences. Cette bibliothèque rassemble des modèles de départ livrés comme des artefacts typés, paramétrés, versionnés et reproductibles que les opérateurs peuvent intégrer au Zone Builder et déployer dès aujourd’hui.

Trois familles de gouvernance

Chaque famille de modèles répond à une question opérationnelle différente. La plupart des Zones en production composent des modèles issus de plusieurs familles.

01 — Opérationnel
Règles quotidiennes de fonctionnement de la Zone
ex. Intégration des locataires
Les régimes opérationnels gouvernent l’état courant d’une Zone : qui peut faire quoi, selon quels quotas, avec quelles limites de débit et à quel prix. Ce sont les premiers modèles instanciés par chaque Zone déployée : une surface d’identité, une enveloppe de ressources et une grille tarifaire. La plupart des Zones actives sur axone-1 reposent aujourd’hui sur des modèles opérationnels composés avec deux ou trois familles complémentaires.
02 — Audit
Preuves, journalisation, reproductibilité
ex. Flux de journal d’audit
Les régimes d’audit capturent, seconde après seconde, ce qui s’est passé dans une Zone : qui a agi, quels faits ont été vérifiés, quels régimes ont été évalués et quel état a changé. Ils sont conçus pour l’export de preuves : chaque acte émet un événement structuré, et chaque événement porte la version du régime ainsi que les valeurs des slots utilisées pour son évaluation. Les modèles d’audit sont le socle demandé par les autorités, les tribunaux et les partenaires lorsqu’une Zone entre en production sous un régime de conformité exigeant.
03 — Juridique
Différends, opposabilité, règlement IBC
ex. Différend opposable
Les régimes juridiques confèrent aux actes leur opposabilité — la propriété qui les rend contestables entre organisations et entre chaînes. Ils définissent la surface de différend, les acteurs habilités à contester un acte, les règles de preuve applicables et l’acheminement des règlements par IBC vers les contreparties d’autres Zones. Les contrats Solidity Pactum et la couche de règles oppowser appartiennent à cette famille.

Modèles de départ

Des modèles de régime prêts à l’emploi, disponibles dès aujourd’hui. Chaque modèle est un paquet Prolog typé : renseignez les slots, instanciez la Zone et obtenez un hash de régime on-chain reproductible.

🏥
Bêta
Zone d’inférence clinique fédérée
IA clinique inter-sites sous un régime unique : inférence liée à la juridiction, RBAC pour les cliniciens et étapes de revue de type IRB. Adossée à l’étude de cas du Zone Builder dans le secteur de la santé.
santé RBAC portes-IRB
🛰️
Bêta
Zone d’observation de la Terre
Dataionics ancre les flux de données d’observation de la Terre Copernicus/UE sous un régime unique : provenance souveraine, redistribution sous licence et audit opposable. Adossée à l’étude de cas de la Zone Dataionics.
observation-terre EU-provenance redistribution
🎮
Bêta
Zone SLA de marketplace GPU
Mise en œuvre des SLA et règlement on-chain des différends pour les marketplaces GPU. Fournit la règle Prolog provider_eligible ainsi que des conséquences réputationnelles absentes de Vast.ai, Akash et Render.
calcul SLA différend
☁️
En production
Zone d’inférence IA multicloud
Réunit AWS, GCP et Azure sous une même couche de gouvernance, avec routage tenant compte des juridictions, arbitrage des instances spot et règlement on-chain des SLA. 78 % des entreprises exécutent des inférences IA multicloud : ce modèle fournit la surface de gouvernance manquante.
multicloud arbitrage-spot routage-juridictionnel
📜
Brouillon
Zone de journalisation des actes, qualité audit
Régime d’export de preuves pour les déploiements en production. Capture des journaux d’actes immuables, exporte des enregistrements de provenance W3C-RDF et s’intègre à Cognitarium pour les outils de conformité en aval.
preuves journal-immuable w3c-rdf
⚖️
Bêta
Zone de règlement des différends opposables
Opposabilité inter-organisations des actes à conséquence. Associe les contrats Solidity Pactum à un règlement acheminé par IBC afin qu’une Zone sur axone-1 puisse contester et régler des actes avec des contreparties sur toute chaîne connectée à IBC.
pactum opposabilité ibc
📊
Brouillon
Datavise
Régime de gouvernance des données institutionnelles pour des périmètres d’accès typés, des contrôles de provenance et des règles de redistribution auditables entre produits de données partagés.
gouvernance-données provenance redistribution
🤖
Bêta
Decentralised-AI
Régime réutilisable pour les charges IA décentralisées : localité des modèles et des données, permissions des contributeurs et preuves d’inférence vérifiables entre les Zones participantes.
decentralised-ai inference preuves
✅
Brouillon
Proof-of-Action
Régime de preuve établissant quel acteur a exécuté un acte, quelles conditions ont été évaluées et quelles conséquences ont été inscrites sur la chaîne.
proof-of-action attestations audit
🤝
Brouillon
Cohort-of-Stakeholders
Régime de coordination multipartite pour définir les cohortes de parties prenantes, les règles de quorum, les transitions de rôles et les obligations partagées autour d’une Zone.
cohorte parties-prenantes quorum

Comment instancier un modèle

Trois étapes séparent un artefact typé d’une Zone en fonctionnement sur axone-1. La reproductibilité est un invariant de la chaîne : un opérateur peut prouver que la Zone en production est bien celle examinée par les auditeurs, sans faire confiance à un serveur de build.

ÉTAPE 01
Choisissez un modèle
Choisissez un modèle dans la bibliothèque ci-dessus ou forkez un modèle publié dans le registre de régimes de votre organisation. Le modèle fournit une liste de slots typés et un contrat explicite de hash de régime.
ÉTAPE 02
Renseignez les slots typés
Chaque slot est un terme Prolog typé : slot(zone_id, atom), slot(quorum, integer), slot(jurisdictions, list). Les types incompatibles sont rejetés à la compilation, et non à l’exécution.
ÉTAPE 03
La Zone est livrée avec son hash de régime on-chain
La Zone ne « fonctionne » pas tant que la référence du modèle, sa version et les valeurs de ses slots ne sont pas enregistrées contre le hash du modèle sur la Layer 1. Chaque instance déployée est reproductible depuis le registre : mises en production, audits et retours arrière partagent tous un artefact canonique.

Déployez votre première Zone gouvernée

Choisissez un modèle, renseignez les slots, déployez. Le modèle de régime est ce qui rend AxoneOS exploitable à l’échelle de l’entreprise.