Note d’architecture

Le modèle d’enregistrement de décision

Une décision n’est pas une sortie jetable. C’est un enregistrement structuré, lié à des preuves, à une version de politique, à une provenance, à un cycle de vie, à une révisabilité, à un contexte réglementaire et à une mise en pack d’audit.

Cette page décrit l’identité architecturale d’un enregistrement de décision. Le périmètre opérationnel est vérifié par déploiement.

L’enregistrement de décision comme objet durable

OmegaOS ne traite pas une décision comme une entrée de journal. Chaque décision est un enregistrement. Chaque enregistrement conserve les entrées qui l’ont produit, les règles qui les ont évaluées et le contexte dans lequel l’évaluation a eu lieu.

Un enregistrement reste lié à son ensemble de preuves et à sa version de politique. Il porte un cycle de vie. Il peut être revu. Il se compose dans une surface d’audit packagée. Ces propriétés ne sont pas des fonctionnalités ajoutées sur une décision — elles définissent ce qu’est une décision dans cette architecture.

Frontières de surface

Attributs de l’enregistrement de décision

Six attributs définissent l’enregistrement en tant qu’objet. Chaque attribut est décrit ci-dessous au niveau du modèle. Le comportement opérationnel de chaque attribut est vérifié par déploiement.

État

  • Définition: Un enregistrement de décision porte un état de cycle de vie : actif, requiert revalidation, expiré, remplacé, révoqué ou invalidé. L’état est calculé à la lecture à partir de l’historique de l’enregistrement. Il n’est pas stocké sur l’enregistrement lui-même.
  • Ce que le modèle exige: La correction à la naissance (le résultat d’évaluation de l’enregistrement) et la consommabilité à la lecture (l’état actuel de l’enregistrement) sont architecturalement séparées. Un enregistrement correct au moment de sa production peut néanmoins requérir une revalidation si son horizon de politique ou de preuve évolue.
  • Vérifié par déploiement: La sémantique de cycle de vie, les surfaces de revalidation et le traitement d’état en lecture sont définis pour chaque périmètre de déploiement.

Origine

  • Définition: Un enregistrement est lié à son ensemble de preuves, à sa version de politique et au contexte d’exécution dans lequel il a été produit. Les preuves sont adressées par contenu ; la version de politique est verrouillée à l’instant d’évaluation.
  • Ce que le modèle exige: Les preuves et la version de politique sont des entrées immuables de l’enregistrement. Un enregistrement ne peut pas être détaché des entrées qui l’ont produit.
  • Vérifié par déploiement: La complétude des métadonnées d’origine et du contexte d’enregistrement exporté est définie pour chaque périmètre de déploiement.

Généalogie

  • Définition: Un enregistrement référence ses prédécesseurs lorsqu’il est remplacé. Le lignage compose des nœuds d’enregistrement, de preuves, de politique et de supersession.
  • Ce que le modèle exige: La provenance est enregistrée, non inférée. Chaque maillon de la chaîne est adressable indépendamment.
  • Vérifié par déploiement: Les surfaces de traversée de lignage, les références de prédécesseurs et les vues de reconstruction sont définies pour chaque périmètre de déploiement.

Contestabilité

  • Définition: Un enregistrement reste contestable. Son ensemble de preuves et sa version de politique sont conservés. Son lignage est auditable.
  • Ce que le modèle exige: Le droit de revue et de contestation d’un enregistrement est une propriété du modèle. L’enregistrement ne cesse pas d’être une base de revue lorsque son état opérationnel change.
  • Vérifié par déploiement: Les surfaces de revue, les références conservées et les vues de comparaison historique sont définies pour chaque périmètre de déploiement.

Horizon réglementaire

  • Définition: Un enregistrement porte son contexte réglementaire : les cadres évalués et les obligations référencées. Lorsqu’elles sont activées, les surfaces de monitoring et d’incidents peuvent utiliser les enregistrements pour alimenter des workflows de revue de dérive et de classification d’incident.
  • Ce que le modèle exige: La conformité est une propriété d’exécution dérivée des enregistrements, non une liste statique. L’enregistrement connaît les cadres sous lesquels il a été évalué.
  • Vérifié par déploiement: Les seuils de monitoring, les workflows d’incident et les cartographies réglementaires sont définis pour chaque périmètre de déploiement.

Enveloppe de preuve

  • Définition: Un enregistrement et ses preuves sont adressés par contenu. La surface du pack d’audit compose les vues enregistrement, lignage, explication, monitoring, conformité et incidents.
  • Ce que le modèle exige: Chaque composante de l’enveloppe est identifiable indépendamment. Le pack d’audit est la surface de mise en pack — il ne remplace aucun des enregistrements sous-jacents.
  • Vérifié par déploiement: Les surfaces d’export, de mise en pack et d’intégrité sont définies pour chaque périmètre de déploiement. Les mécanismes de vérification privés ne sont pas décrits sur cette page.

Périmètre opérationnel

Le modèle est une identité structurelle. Le périmètre opérationnel spécifique au déploiement — ce qui est implémenté, démontré, vérifié ou gardé privé — est décrit via les références ci-dessous.

Reality Boundary

Matrice des claims pour ce qui est implémenté, démontré, benchmarké, auditable, privé ou non public.

Ouvrir

Verify Offline

Note de vérification des artefacts exportés et contrôles d’intégrité hors ligne.

Ouvrir

Pilot Scope

Revue de déploiement bornée avec prérequis, livrables et conditions de sortie.

Ouvrir

Technical Artifact

Définitions canoniques de OmegaOS, OmegaOS Kernel, états terminaux, evidence, replay et ledger.

Ouvrir

Clause de frontière

Cette page décrit un modèle. Elle n’affirme pas que chaque attribut est opérationnellement complet dans chaque déploiement.

Le périmètre opérationnel spécifique au déploiement, les artefacts exportés, les runbooks, les notes de topologie et les procédures d’intégration ne sont pas publics. Ils sont traités par le chemin d’engagement : Pilot Scope, Verify Offline et contact technique direct dans le contexte de revue.

Contacter l’équipe