Référence des résultats et de l’exécution

Ce qu’une exécution envoie à un système HTTP et attend en retour, comment chaque cas entre dans le dénominateur d’une métrique, les états de décision et les codes de raison qui les expliquent, les codes de sortie, et quelles données restent en local ou partent vers un espace de travail hébergé. Pour les idées qui les sous-tendent, lisez les Concepts ; pour les champs de la politique, lisez la Référence de configuration.

Le contrat d’un système HTTP

Un système HTTP (system.http dans oloproof.yaml) est appelé une fois par cas, et une fois par réplique.

L’URL, la méthode, le chemin de sortie et la correspondance des artefacts entrent dans la version du système, mais pas ce que fait le serveur. Changez system.version chaque fois que le comportement du serveur change ; voyez la Référence de configuration pour comprendre pourquoi.

Trois vocabulaires différents

Un résultat a trois sortes d’état, et aucune ne remplace une autre.

Une exécution qui se termine normalement est DECIDED, ou DECIDED_EARLY quand l’arrêt anticipé l’a terminée. Une exécution interrompue par Ctrl-C ou par l’annulation de la tâche est CANCELLED ; celle dont le harnais a levé une exception est RUN_ERROR. L’un comme l’autre laisse l’exécution PARTIAL, conserve les cas terminés, et permet à l’exécution suivante de réutiliser leurs enregistrements en cache. Voyez Erreurs.

Pour un seuil minimum T et un intervalle [L, U], une règle est PASS quand L >= T, FAIL quand U < T, et INSUFFICIENT_EVIDENCE sinon. Un seuil maximum est symétrique. Avant de lire l’intervalle, une règle vérifie si elle doit décider tout court : d’abord les raisons de MANUAL_REVIEW, puis celles de INSUFFICIENT_EVIDENCE. Le premier niveau qui a une raison décide, et liste toutes les raisons qu’il a trouvées.

Codes de raison

Chaque décision porte un ou plusieurs codes de raison.

MANUAL_REVIEW

INSUFFICIENT_EVIDENCE

PASS et FAIL

Espace de travail hébergé uniquement

Un espace de travail qui décide lui-même d’une exécution poussée peut retenir une décision avec ppi_not_verified (il n’a pas vérifié l’intervalle sur lequel repose la décision), execution_not_verified (les sorties ne viennent pas d’un exécuteur enregistré) ou workspace_cannot_decide (il ne détient aucune copie de la politique, ou n’a pas pu lire les preuves). Voyez Porte de CI.

Comment chaque cas entre dans le dénominateur

Chaque métrique rapporte quatre effectifs : n_total (cas de la suite), n_eligible, n_observed et n_missing, avec n_eligible = n_observed + n_missing. Les cas hors de n_eligible sont listés sous exclusions avec une raison.

Un cas manquant est borné, pas écarté. Pour un taux de réussite, la borne inférieure de l’intervalle traite chaque cas manquant comme un échec et sa borne supérieure comme une réussite, si bien qu’une exécution avec beaucoup de cas manquants a un intervalle large qui ne peut pas satisfaire une règle exigeante ; une moyenne bornée substitue de la même façon les extrémités de sa plage déclarée. Une méthode qui ne peut pas borner les cas manquants (une statistique de classement, par exemple) les écarte et enregistre l’hypothèse, et une règle qui s’y appuie lit missingness_unbounded tant qu’elle ne déclare pas max_missing_fraction.

Une règle observed_count compte les échecs sur la suite exécutée et ne lit aucun intervalle. Elle ne passe que lorsque les échecs observés plus tous les cas manquants tiennent encore dans max_failures.

Métriques sans intervalle admis

Une règle ne décide que sur un intervalle dont la méthode a été admise par audit. Là où il n’en existe pas, la métrique est quand même calculée et affichée, et une règle qui s’y appuie n’emprunte pas une méthode non validée :

Codes de sortie

oloproof gate, oloproof run avec une politique, et les autres commandes qui décident utilisent tous les mêmes codes.

Quand plusieurs s’appliquent, le code rapporté est le premier de 1, 5, 4, 3. Un état absent de block_on ne peut pas changer le code de sortie : avec block_on: [FAIL] et warn_on: [INSUFFICIENT_EVIDENCE], une règle indécise avertit et la porte sort avec 0. Le code 0 signifie donc seulement que rien de ce sur quoi votre politique bloque ne s’est produit, et non que chaque règle a réussi. Voyez Porte de CI.

Où le travail s’exécute et où vont les données

En local, par défaut

oloproof run, oloproof gate et le SDK s’exécutent sur votre machine. Chaque enregistrement (cas, sorties, artefacts, jugements, métriques et décisions) est écrit dans .oloproof/store.sqlite à côté de oloproof.yaml, ou sous OLOPROOF_HOME s’il est défini. Rien n’est envoyé à Oloproof. Le seul trafic réseau est celui que provoque votre configuration : les appels à l’URL de votre système HTTP, et les appels qu’un juge modèle ou un classifieur modèle fait à son fournisseur, qui reçoit le contenu des cas qu’il juge et vous le facture.

Pousser vers un espace de travail hébergé

oloproof push envoie les preuves d’une exécution à l’espace de travail que vous avez connecté avec oloproof login. Par défaut, il envoie les métriques, les intervalles, les décisions et les segments agrégés, ainsi que l’identité, le statut, les durées et l’usage de chaque enregistrement, mais pas son contenu. Le contenu brut est expurgé champ par champ avant que quoi que ce soit ne quitte la machine, et un enregistrement expurgé indique quelles catégories ont été retenues. Une catégorie ne part que lorsque egress: dans oloproof.yaml la liste :

Les empreintes des enregistrements ne sont pas recalculées après l’expurgation, si bien qu’un enregistrement hébergé désigne toujours les preuves d’origine, qui restent sur votre machine. L’expurgation n’est pas un chiffrement, et une métrique sur un très petit segment peut encore identifier les cas qui la composent.

Quand des relecteurs étiquettent des cas dans la file de relecture hébergée, leur navigateur récupère le contenu des cas auprès de oloproof collect qui tourne de votre côté ; il ne passe pas par l’espace de travail. Les clés de fournisseur qu’utilise un espace de travail sont stockées avec oloproof credentials set, et oloproof credentials list affiche leurs noms, jamais leurs valeurs. Une tâche gérée s’exécute sur un worker qu’exploite Oloproof, qui n’exécute pas votre code Python ; oloproof job rapporte son résultat et sort selon sa porte.

Dans un espace de travail hébergé, le moteur ne réutilise jamais les exécutions, jugements ou analyses en cache, parce qu’un push peut écrire dans ces caches ; il les recalcule.