Politiques d’intention

Une politique d’intention exprime ce que vous voulez dire, plutôt que chaque surface qu’un agent pourrait utiliser pour le faire. Dans OpenLatch, vous l’écrivez sous forme d’Agent Intent Policy (AIP), et OpenLatch la compile en règles déterministes que le client applique avant chaque action couverte.

De vos mots à une AIP

Vous partez d’un brief : une phrase, un document de politique collé ou une conversation enregistrée. OpenLatch le découpe en atomes d’intention, un par règle, et génère deux choses à partir de chaque atome : une phrase lisible et des cas de test concrets.

Champ de l’atome	Ce qu’il contient	Exemple
who	Les agents concernés par la règle	tout agent
does what	L’action	déployer
to what	La cible	un namespace de production
only if	La condition qui l’autorise	un ticket de changement approuvé est lié
unless	L’exception	une cellule de crise d’incident est active
class	Si l’atome peut être appliqué : applicable, observable seulement ou hors périmètre	applicable

Vous ne remplissez jamais ces champs. OpenLatch les extrait de votre brief, et vous les modifiez en éditant la phrase.

Vous ratifiez la phrase

Pour l’atome ci-dessus, vous lisez cette phrase :

Tant qu’aucune cellule de crise d’incident n’est active, lorsqu’un agent demande un déploiement en production, le système doit exiger un ticket de changement approuvé.

À côté, les cas de test montrent ce que la politique déciderait dans des situations concrètes, par exemple un déploiement avec ticket, un sans ticket, et un sans ticket pendant un incident. Les cas sont là pour que votre réponse soit éclairée. Vous répondez Oui ou Non sur la phrase :

• Oui accepte l’atome.
• Non ouvre une note où vous dites avec vos propres mots ce que vous vouliez dire. OpenLatch modifie les champs, régénère la phrase et ses cas, et signale les cas dont le verdict a changé. L’atome revient pour un nouveau Oui ou Non, car une réponse donnée sur l’ancienne phrase ne couvre pas la nouvelle.

Vous ne voyez ni n’approuvez jamais les règles compilées. Vous approuvez ce que vous pouvez lire.

D’une AIP au client

Une fois ses atomes acceptés, vous ratifiez l’AIP dans zéro, une ou plusieurs zones, chacune dans son propre mode. La plateforme compile les atomes en règles et construit un bundle de politiques par agent à partir de sa zone effective. Le bundle est vérifié en intégrité, et le client le garde sur la machine : il continue donc de décider réseau débranché.

La classe d’un atome compte à l’exécution : un atome monitor-only reste en Monitor même quand sa politique s’exécute en Enforce, parce qu’il peut être observé mais pas appliqué.

Le cycle de vie d’une politique

1. Écrivez un brief ou apportez un document source.
2. Relisez les phrases générées et leurs cas, puis acceptez-les.
3. Rejouez la politique sur l’activité récente de vos agents pour voir ce qu’elle aurait décidé.
4. Ratifiez-la en Disabled, Monitor ou Enforce.
5. Exécutez-la en Monitor, lisez ses anomalies, et passez-la en Enforce quand elle est juste.

Écrire votre première politique parcourt ces étapes dans la console.