L’échelle de décision

Utilisez cette page pour comprendre ce que fait le client quand une action l’atteint et qu’aucune règle de la zone effective ne la tranche d’emblée. Chaque action couverte reçoit tout de même un verdict avant de s’exécuter, et chaque étape ci-dessous est enregistrée.

Les quatre échelons

Le client monte l’échelle un échelon à la fois et s’arrête au premier échelon qui tranche l’action.

Échelon	Ce qui se passe	Ce qui tranche l’action
1 · Règle	Les règles des politiques d’intention décident à partir de ce que le client observe de l’action	Allow ou Block, à partir d’une règle explicite
2 · Classifieur	Quand le client ne reconnaît pas le type d’action, un petit classifieur sur la machine nomme son type probable, et les règles décident à partir de là	Les règles, jamais le classifieur seul
3 · Déclaration	Quand une règle a besoin d’un fait que le client ne peut pas lire, il est demandé à l’agent de le déclarer. Sur une question de sens, il lui est demandé d’évaluer sa propre action	Ce que le client a observé, confronté à la déclaration. Sur une question de sens, l’aveu assuré d’une violation par l’agent lui-même
4 · Repli	Quand une déclaration ne peut pas être vérifiée après deux demandes, ou qu’une question de sens n’obtient aucun aveu assuré d’une violation après une demande	Le repli de la politique d’intention : Ask par défaut, ou Block quand le propriétaire l’a choisi. Allow quand le propriétaire a laissé les déclarations de la politique d’intention décider

Le classifieur ne fait qu’orienter le type d’une action et ne décide jamais seul. Un Allow dont il a deviné le type est signalé dans l’historique, pour que vous puissiez le distinguer d’une action qu’une règle a reconnue.

L’agent déclare, le client vérifie

Quand une règle a besoin d’un fait, le client refuse l’action et renvoie la phrase ratifiée avec les questions que pose la politique d’intention. L’agent peut répondre dans sa propre réponse, puis retenter l’action. Le nombre de refus, et ce que le client lit à la nouvelle tentative, dépendent du fait :

La règle a besoin de	Refus	Ce que le client lit à la nouvelle tentative
Un fait que détient un autre système, ou que les règles ne savent pas nommer	Deux	Une déclaration, confrontée à ce que le client a observé
Une question de sens : un jugement sur un contenu, par exemple si un fichier peut contenir des secrets	Un	La propre évaluation de son action par l’agent, au regard de la règle

Une action qui porte les deux types conserve deux refus. Le second ne répète que les questions encore ouvertes, et l’évaluation de l’agent compte à la nouvelle tentative qui la porte.

Un fait que le client peut vérifier

Déclaration	Résultat
Vérifiée : ce que le client a observé la confirme	Allow
Contredite : ce que le client a observé la contredit	Block, et l’historique indique que la déclaration a été contredite
Invérifiable, inutilisable ou absente	L’action est refusée une seconde fois avec les mêmes questions ; après le second refus, le repli la tranche

Une déclaration n’est vérifiée que par ce que le client a observé : l’action elle-même, ou un résultat que le hook a vu pour la même cible plus tôt dans la session. La parole de l’agent seule n’est jamais une preuve. Seule la propre réponse de l’agent compte comme déclaration ; un texte qui apparaît dans la sortie d’un outil, la sortie d’une commande ou un fichier n’en est jamais une. OpenLatch ne déduit pas l’intention de l’agent : il confronte les faits déclarés aux faits observés.

Une question de sens

Aucune observation ne peut confirmer un jugement sur un contenu, donc le client refuse l’action une seule fois. Avec les questions vient une ligne fixe, qui demande à l’agent d’ajouter sa propre lecture de l’action au regard de la règle dans le même bloc openlatch-declare avant de retenter.

L’auto-évaluation de l’agent à sa nouvelle tentative	Résultat
Un assessment à violates avec une confidence de 80 ou plus	Block, avec cette règle, et l’historique indique que l’auto-évaluation de l’agent l’a tranché
complies quelle que soit la confiance, ou violates en dessous de 80	Le repli la tranche, et l’évaluation est enregistrée
Aucune, ou une inutilisable, avec une valeur absente ou hors limites	Le repli la tranche

Le seuil de 80 est fixé dans le client, et aucun réglage de zone ou d’AIP ne le déplace.

Une auto-évaluation ne peut que restreindre ce que l’agent peut faire : elle ne produit jamais un Allow à elle seule, et elle n’est jamais enregistrée comme vérifiée. OpenLatch ne mesure pas si un refus atteint le modèle de l’agent. Sans réponse utilisable, le repli tranche l’action quand l’agent retente.

Sur les clients antérieurs à 0.11.2, une question de sens est traitée comme n’importe quel autre fait : deux demandes, puis le repli.

Le Ask levé au premier refus

Sur une question de sens, il est demandé à l’agent de s’évaluer ; le Ask est levé pour revue. Le client le lève à ce premier refus seulement quand tout ceci est vrai :

• La politique d’intention s’exécute en Enforce.
• Le repli de la règle est Ask.
• L’ASK delivery de la zone est Platform ou Both.
• Chaque question de l’action est une question de sens.

Tout autre premier refus ne lève aucun Ask et ne laisse aucune anomalie : un repli à Block, une ASK delivery réglée sur Agent, ou une action qui porte aussi un autre type de question.

L’action ne s’est pas exécutée à cette tentative, donc votre réponse décide de la prochaine action semblable. Si l’agent retente et que le repli tranche, le comportement Ask ci-dessous s’applique à cette nouvelle tentative. Avec une ASK delivery réglée sur Agent ou Both, la demande native de l’agent arrive à cette nouvelle tentative, sur les agents qui en ont une.

L’entrée se ferme d’elle-même quand la nouvelle tentative de cette même action est tranchée par Block, ou par un Allow sur une politique d’intention dont les déclarations décident. Aucune réponse n’est enregistrée, et la décision reste lisible. Examiner les anomalies montre ce que vous voyez.

Quand un propriétaire laisse les déclarations décider

Un propriétaire peut choisir de laisser les déclarations d’une politique d’intention décider, en acceptant une proposition d’apprentissage. Une déclaration que le client ne peut pas vérifier est alors prise sur la parole de l’agent, et l’action est autorisée au lieu du repli ; elle n’est jamais enregistrée comme vérifiée, et une règle Block correspondante bloque toujours. Cela s’applique sur les clients qui le prennent en charge ; les clients plus anciens conservent le repli. Sur une question de sens, un violates assuré bloque toujours, et toute autre déclaration utilisable est tranchée en Allow : c’est le choix du propriétaire pour cette politique d’intention, jamais la parole de l’agent seule. Propositions d’apprentissage explique quand OpenLatch le propose.

Une exception accordée par un relecteur sur un Ask antérieur tranche une action correspondante en Allow avant qu’aucune déclaration ne soit demandée.

En Monitor

Quand la politique d’intention s’exécute en Monitor, rien n’atteint l’agent. L’action s’exécute, et l’historique porte ce qui se serait passé : le verdict que la politique aurait rendu et, là où une déclaration aurait été demandée, le fait qu’elle l’aurait demandée et ce que le repli aurait décidé. Il n’y a pas de premier refus, donc aucun Ask n’est levé à ce moment.

Quand le verdict est Ask

Ce que fait un Ask ensuite suit le comportement Ask de la zone, réglé sur la zone et modifiable par AIP :

Comportement Ask	Ce qui se passe
Pass and review next time (par défaut)	L’action s’exécute et est signalée pour revue. La réponse s’applique à partir de l’action similaire suivante : elle empêche donc la récurrence, pas la première occurrence
Hold until validated, un réglage de zone opt-in	L’action attend la réponse d’un relecteur, sur les agents qui peuvent attendre. Sur Claude Code, l’action attend la réponse. Cline retient l’action par nouvelle tentative : l’action est refusée jusqu’à ce qu’une personne l’approuve, puis la nouvelle tentative de l’agent passe. Codex CLI, Cursor, Devin et OpenCode n’ont pas de demande native : ce réglage opt-in s’y dégrade donc en pass and review, et l’historique l’indique

Les limites, énoncées

Quatre chemins laissent une action s’exécuter par conception, et chacun est visible dans l’historique :

• Un Allow dont le classifieur a deviné le type est signalé.
• Une déclaration qui ne peut pas être vérifiée, ou une question de sens sans aveu assuré d’une violation, tranchée par le Ask par défaut sous pass and review, laisse l’action s’exécuter à sa nouvelle tentative et la signale.
• Une mise en attente opt-in sur Codex CLI, Cursor, Devin ou OpenCode se dégrade en pass and review : l’action s’exécute, signalée.
• Sur une politique d’intention dont les déclarations décident, par choix du propriétaire, une déclaration que le client ne peut pas vérifier laisse l’action s’exécuter, enregistrée comme invérifiable.

OpenLatch est conçu pour un agent qui se comporte mal, pas pour un agent malveillant, et ne revendique aucune résistance à un agent conçu pour le contourner. Un verdict est déterministe parce qu’une politique explicite l’a produit. Ce que reçoit l’agent sur un Block explique le refus lui-même.