Infrastructure existante
Systèmes d’identité, gateways, moteurs de politique et services applicatifs restent sous contrôle opérateur et restent en place.
Frontière de déploiement
Intégration
OmegaOS est la couche plateforme. OmegaOS Kernel est le runtime overlay. Le déploiement est conçu pour s’installer à côté de l’infrastructure d’autorisation existante, pas pour la remplacer.
Progression de mode, frontière de panne et responsabilité opérateur. La sémantique produit est définie dans Product et Artefact technique.
Modèle overlay
Le modèle de déploiement garde l’environnement existant visible. OmegaOS ajoute un runtime et une couche de gouvernance autour de lui.
OmegaOS Kernel
Runtime overlay qui évalue les preuves, retourne ALLOW / DENY / INDETERMINATE et enregistre le contexte de décision pour le replay.
OmegaOS
Couche plateforme pour le cadrage de déploiement, la supervision, la gestion des preuves exportées et les surfaces de revue opérationnelle.
Progression de mode
Le déploiement passe de l’observation à l’application sans redéfinir le système. La différence entre les modes est l’autorité opérationnelle, pas la sémantique.
| Mode | Autorité d’évaluation | Effet opérateur | But |
|---|---|---|---|
| Observe | Le runtime évalue et enregistre, mais la pile existante reste autoritative. | Aucun changement de comportement sur le chemin appelant. | Établir une ligne de base de visibilité et de qualité d’artefact. |
| Shadow | Le runtime évalue aux côtés du moteur actuel et la divergence reste mesurable. | Le chemin appelant suit toujours le système autoritatif existant. | Comparer les résultats avant tout transfert d’autorité. |
| Enforce | La sortie du runtime devient la surface de décision retournée pour le chemin configuré. | L’opérateur porte les règles de rollback, la politique de dépendance et le mode de panne. | Utiliser le runtime déterministe comme frontière décisionnelle active. |
Conditions de frontière
Résultat d’évaluation
INDETERMINATE est un résultat d’évaluation complet. Il signifie que les preuves ne justifiaient pas un résultat stable ALLOW ou DENY.
Panne opérationnelle
Le comportement fail-closed est une politique de déploiement opérateur pour les dépendances requises en mode enforce. Il est distinct de INDETERMINATE.
Exécution de l’action
OmegaOS retourne une surface de décision. Le système appelant reste responsable d’exécuter ou de refuser l’action aval.
Patterns d’intégration courants
Gateway overlay
Placer le runtime près du gateway ou de l’entrée décisionnelle afin que la capture de preuves et l’enregistrement restent proches du chemin requête.
Déploiement parallèle
Exécuter à côté de l’environnement actuel avec un routage sous contrôle opérateur afin que la revue puisse avoir lieu avant le transfert d’autorité.
Comparaison shadow
Envoyer les mêmes requêtes au moteur actuel et au runtime pour mesurer la divergence avant l’application.
Surface portée par l’opérateur
Le modèle de déploiement public est volontairement conservateur. L’opérateur porte l’hébergement, le routage, le contrôle d’accès et la gestion du changement.
Reste porté par l’opérateur
- Qualité d’acquisition des preuves et correction des systèmes amont.
- Politique réseau, gestion des secrets, contrôle d’accès et durcissement infrastructure.
- Politique de rétention, staffing d’escalade et workflow d’action après un état retourné.
- Interprétation juridique par cadre et design de contrôles spécifique au tenant.
Besoin de la frontière d’engagement exacte ? Utiliser Périmètre pilote pour le flux public de déploiement et Frontière de réalité pour le niveau de preuve attaché à chaque claim public.