OmegaOS™ Kernel
Noyau de décision déterministe et auditable.
Produit Vrai / Faux / Indéterminé — où l’Indéterminé (I) est l’état natif tant que les preuves et la gouvernance ne permettent pas de conclure.
Une nouvelle catégorie
Nous ne vendons pas un « outil » de plus. Nous avons créé une catégorie : une infrastructure de décision gouvernable, où l’incertitude est traitée comme un résultat correct, pas comme un défaut.
Le problème
Dans les systèmes critiques, le binaire forcé (oui / non) produit des erreurs, des risques légaux et des audits fragiles. Les scores IA opaques et les modèles boîte noire aggravent le problème — les décisions deviennent difficiles à justifier, rejouer ou contester.
Le changement
L’Indéterminé (I) est la base. Vrai et Faux ne peuvent pas être créés arbitrairement — ils ne sont extraits que lorsque des seuils de preuve et des règles de gouvernance sont atteints.
Le résultat
Chaque décision est gouvernable : qui décide, quand, selon quelles preuves. Chaque raisonnement est rejouable. L’incertitude apparaît comme un état stable et auditable — pas un échec silencieux.
Trois états
Les systèmes binaires forcent chaque décision en autoriser ou refuser. Lorsque les preuves sont contradictoires ou absentes, ils devinent. OmegaOS™ Kernel ne devine pas.
Autoriser
Preuves favorables évaluées. Conditions de la politique remplies. La décision, la chaîne de preuves et la version de la politique sont enregistrées dans le registre en ajout seul.
Indéterminé
Preuves contradictoires ou insuffisantes. Le moteur suspend son jugement. Pas de verdict prématuré. Le conflit est exposé pour examen humain avec les deux chaînes de preuve.
Refuser
Preuves défavorables évaluées. Conditions de la politique non remplies. Le refus porte la même profondeur de preuve qu'une autorisation — chaque rejet est également traçable.
| Preuves actives | Résolution | Conflit | HTTP |
|---|---|---|---|
| Favorables uniquement (V) | Autoriser | Non | 200 |
| Défavorables uniquement (F) | Refuser | Non | 200 |
| V + F simultanées | Indéterminé | Oui | 409 |
| Aucune | Indéterminé | Non | 200 |
409 Conflict. Lorsqu'un moteur anti-fraude dit bloquer et qu'un contrôle KYC dit autoriser, les systèmes binaires choisissent silencieusement un gagnant. OmegaOS™ Kernel retourne 409 avec les deux chaînes de preuve — la contradiction est visible, traçable, auditable.
Architecture des Preuves
- Scénarios de résolution immuables avec preuves cryptographiques.
- Résultats déterministes V/F/I liés à des versions spécifiques de politiques.
- Vérification hors ligne via des extraits JSONL vérifiables.
Déterministe à grande échelle
En un clignement d’œil, OmegaOS résout 882 000 décisions avec des chaînes de preuves complètes.
Architecture
Deux services Rust. Un registre Postgres. PDP amont optionnel.
Flux de preuves
Une requête entre dans le gateway. Le gateway collecte les preuves de votre PDP, les évalue par résolution à trois états et écrit la décision avec sa chaîne de preuve complète dans le registre. La réponse inclut la décision, les références de preuves et l'identifiant de l'entrée du registre.
Les services d'exécution opèrent avec des permissions INSERT uniquement. Pas de UPDATE. Pas de DELETE. La piste d'audit est structurellement immuable.
Paquet de preuves
L'artefact de conformité. Exportez-le, vérifiez-le hors ligne, présentez-le à n'importe quel auditeur.
Manifeste SHA-256
L'exporteur calcule SHA-256 à la volée pour chaque fichier JSONL. Le manifeste enregistre les hachages par fichier, le nombre de lignes, l'identifiant du locataire, la plage temporelle et l'empreinte de build. Toute altération invalide le hachage.
Attestation Ed25519
Lorsque des clés de signature sont fournies, les licences et attestations de build sont signées avec Ed25519. La clé publique est intégrée à la compilation. La vérification ne nécessite aucun réseau, aucun serveur de licence, aucun service externe.
Vérification hors ligne
Un auditeur peut vérifier l'intégrité d'un paquet de preuves sans accès au système de production. Le paquet est autonome : fichiers de données, hachages d'intégrité et signatures d'attestation.
Replay déterministe
Réexécutez toute décision historique et prouvez qu’elle est correcte.
Replay exact
Réexécutez toute décision passée depuis son dossier dans le registre avec l’évidence originale et le snapshot de politique. Le système retourne un flag match_original : Vrai confirme la cohérence déterministe. Faux révèle une anomalie de non-déterminisme — elle-même une constatation d’audit.
Contrefactuel
Répondez à « qu’aurait changé la politique B ? » sans toucher à l’historique. Le replay contrefactuel calcule le diff entre résultat original et alternatif, permettant l’analyse what-if pour l’évolution des politiques.
AuditPack
Le replay par lot génère un AuditPack avec hash SHA-256, exportable directement pour soumission réglementaire. Chaque affirmation dans le pack pointe vers une entrée du registre. Formats : JSON, Markdown.
Moteur d’explication multilingue
Chaque décision expliquée en FR/DE/IT/EN — aucun LLM, aucun texte généré.
Les explications déterministes tracent chaque critère d’une décision jusqu’au champ d’évidence exact qui l’a produit : source, valeur, seuil et horodatage. Chaque affirmation est un fait rendu par template — pas du texte généré. Aucun LLM. Les sorties sont reproductibles et auditables à la demande.
Les décisions Indéterminées renseignent automatiquement un champ action_required et un escalation_reason, routant le cas vers la révision humaine avec des instructions adaptées à la langue. Satisfait l’Art. 13 EU AI Act (transparence) et l’Art. 22 RGPD (droit à l’explication).
Chaîne de preuve Merkle
Registre infalsifiable avec horodatage admissible en justice.
Arbre de Merkle RFC 9162
Chaque décision est enchaînée dans un arbre de Merkle append-only où toute modification rétroactive casse le hash racine — rendant la manipulation immédiatement détectable par tout tiers.
Preuve d’inclusion
Générez une preuve d’inclusion pour toute décision historique : vérifiable en O(log n) opérations, sans révéler les autres décisions, sans faire confiance à l’infrastructure OmegaOS™.
Horodatage RFC 3161
Les racines Merkle sont périodiquement ancrées auprès d’une autorité de services de confiance qualifiée (RFC 3161, conforme à ZertES et eIDAS), fournissant une preuve juridiquement contraignante admissible devant les tribunaux suisses et européens.
Moteur multi-réglementation
Une décision. Huit cadres réglementaires. Une preuve de conformité individuelle par réglementation.
Surcouche réglementaire croisée
Chaque décision est évaluée contre toutes les réglementations applicables simultanément. 27 articles à travers 8 cadres : EU AI Act, LPD/nDSG, DORA, MiFID II, FINMA, RGPD, SOX, Basel III. Chaque réglementation produit sa propre chaîne de conformité.
Matrice de conformité
Matrice de conformité par locataire montrant le statut cadre-par-article d’un seul coup d’oeil. Presets pour profils courants : swiss_bank_complete (20 politiques), eu_fintech_complete (18 politiques). Analyse des écarts en temps réel.
Stress test réglementaire
Simulez les changements réglementaires à venir et mesurez l’impact sur les décisions existantes. Analyse what-if pour les dates d’entrée en vigueur. Quantifiez les écarts de conformité avant qu’ils ne deviennent des violations.
AI Bill of Materials
SPDX 3.0 AI Profile. Transparence complète sur chaque composant derrière chaque décision.
BOM par décision
Chaque décision est liée à sa chaîne complète de composants AI : modèles utilisés, sources d’évidence, versions de politique, vérification d’intégrité par hash. Exportable en SPDX 3.0 JSON-LD, JSON compact ou Markdown.
BOM au niveau système
Inventaire complet du système AI : tous les composants, relations, lignée de données et provenance d’entraînement. Satisfait les obligations de transparence de l’EU AI Act pour la documentation des modèles et la traçabilité des composants.
Vérification d’intégrité
Chaque BOM porte un hash d’intégrité cryptographique. Vérifiez qu’aucun composant n’a été modifié, ajouté ou supprimé depuis la génération du BOM. Infalsifiable par construction.
Signalement d’incidents Art. 73
Détection, classification et notification automatisées des incidents graves.
Classification par sévérité
Les incidents sont automatiquement classifiés par niveau de sévérité avec délais calculés : 2 jours (critique), 10 jours (élevé), 15 jours (standard). Suivi du compte à rebours avec alertes de dépassement pour ne manquer aucun délai.
Génération de rapports
Génération automatisée de rapports initiaux et complets selon les exigences de l’Art. 73. Liés aux décisions et alertes de dérive qui ont déclenché l’incident. Chaque rapport référence des entrées du registre.
Notification aux autorités
Pipeline de notification structuré vers les autorités nationales compétentes. Suivi de la chronologie de la détection au rapport initial au rapport complet. Piste d’audit complète de toutes les communications.
Portail de vérification publique
Vérification zero-knowledge des décisions pour auditeurs externes et régulateurs.
Les parties externes — régulateurs, auditeurs, contreparties — peuvent vérifier qu’une décision spécifique a été prise, quand elle a été prise, et qu’elle n’a pas été altérée. Ils n’ont pas besoin d’accéder à vos systèmes.
La vérification utilise des jetons uniques liés à des preuves d’inclusion Merkle. Le vérificateur confirme que la décision existe dans le registre append-only sans voir les autres décisions, les politiques internes ou les détails d’évidence. Preuve cryptographique, pas confiance.
Registre immuable
Chaque décision, preuve et révocation est enregistrée. Le registre ne fait que croître.
Ajout seul
Les rôles de base de données d'exécution disposent uniquement de la permission INSERT. Pas de UPDATE, pas de DELETE. La piste d'audit ne peut être altérée depuis l'intérieur de l'application.
Row-Level Security
Chaque locataire opère dans un périmètre RLS Postgres. Le locataire A ne peut ni lire, ni référencer, ni interroger les données du locataire B. L'isolation est appliquée au niveau de la base de données.
Lignée de preuve
Chaque décision référence les preuves exactes qui l'ont produite. Les preuves référencent leurs sources. La chaîne est reconstructible depuis n'importe quel point en remontant jusqu'à la preuve originale.
Souveraineté technique
Code Rust à sécurité mémoire prouvée. Builds reproductibles. Code open-core auditable.
Déploiement on-premise exclusif. Aucun SaaS. Aucune télémétrie. Aucun appel réseau sortant. Licence Ed25519 vérifiée hors ligne — aucun serveur de licence.
Pour les banques privées et les family offices, la souveraineté juridique n’est pas un argument commercial. C’est un prérequis réglementaire.
Applications
Secteurs où les décisions d'autorisation exigent des preuves, pas de la confiance.
Services financiers
Autorisation de transactions avec piste d’audit complète. Les signaux contradictoires entre détection de fraude et conformité sont exposés, pas supprimés. Le replay déterministe permet une réponse réglementaire immédiate — toute décision peut être réexécutée et vérifiée en secondes.
- Paquets de preuves qui appuient les processus d’audit SOC 2 / ISO 27001
- Chaînes de preuve transactionnelles avec preuves d’inclusion Merkle
- Détection de conflits AML/KYC
- Surveillance post-marché Art. 72 avec détection de dérive
- Replay déterministe pour les demandes réglementaires
Gouvernement et défense
Vérification d'habilitation où chaque décision d'accès doit être reconstructible. Le chemin de preuve complet de la requête au résultat est préservé.
- Contrôle d'accès par habilitation
- Enregistrements de décision prêts pour l'audit
- Évaluation de preuves multi-sources
Infrastructure critique
Accès aux technologies opérationnelles où une autorisation incorrecte a des conséquences physiques. L'état indéterminé empêche une action prématurée.
- Gouvernance d'accès SCADA / OT
- Pistes de preuves qui appuient les exigences d'audit DORA / NIS2
- Vérification des actions opérateur
Surface API
RESTful. JSON. Spécifié OpenAPI 3.1.
API principale :3100
| POST | /decisions/resolve | Créer une décision |
| POST | /decisions/re-resolve | Ajouter des preuves, réévaluer |
| GET | /decisions/{id}/why | Piste d'audit complète |
| GET | /decisions | Liste (paginée) |
| POST | /proofs/revoke | Révoquer des preuves |
| GET | /health | État du service |
Gateway :3200
| POST | /gateway/decision | Sujet/action/ressource |
| POST | /gateway/http-check | Méthode HTTP/chemin |
| GET | /gateway/health | Mode + licence |
| GET | /gateway/metrics | Prometheus |
Boîte à outils opérateur
Six outils CLI pour les opérations courantes. Gestion des locataires, rotation des clés, export d'audit, migrations de schéma, maintenance des partitions, vérification d'intégrité post-restauration.
Tous s'exécutent en tant que hovo_admin. Aucun n'est livré dans les images de conteneurs de production.
| Outil | Fonction |
|---|---|
| hovo-admin | CRUD locataires + rotation des clés |
| hovo-license | Génération, signature, vérification (hors ligne) |
| hovo-export | Export d'audit JSONL + SHA-256 |
| hovo-migrate | Migrations de schéma (idempotentes) |
| hovo-maint | Gestion partitions + rétention |
| hovo-verify | Vérification d'intégrité post-restauration |
Questions fréquentes
Pourquoi trois valeurs au lieu de deux ?
Les systèmes binaires doivent résoudre chaque ambiguïté en autoriser ou refuser. Quand les preuves sont contradictoires ou absentes, ils devinent silencieusement. La logique à trois états rend cette ambiguïté explicite et auditable — l’Indéterminé est un résultat correct et traçable.
Pourquoi l’Indéterminé est-il l’état natif ?
Parce que l’absence de preuve n’est pas une preuve d’autorisation. I est l’état par défaut jusqu’à ce que les preuves atteignent le seuil de gouvernance configuré. Cela évite les verdicts prématurés dans les contextes à enjeux élevés.
Peut-on forcer un résultat binaire ?
Oui. Les seuils de gouvernance peuvent être configurés pour router les résultats Indéterminés vers une politique par défaut (refus, escalade ou autorisation avec journalisation). Le choix est explicite et auditable — pas un défaut système silencieux.
Cela remplace-t-il notre PDP existant ?
Non. OmegaOS™ opère en surcouche. Votre PDP existant reste disponible comme source de signal et solution de repli. Vous pouvez observer, comparer et appliquer de manière incrémentale — avec retour arrière complet à chaque étape.
Déployer avec le pilote guidé
Observer, comparer, appliquer. Conçu pour un changement de mode sans temps d’arrêt. Retour arrière complet à chaque étape.