Riferimento dei risultati e dell'esecuzione

Che cosa un'esecuzione invia a un sistema HTTP e che cosa si aspetta in risposta, come ogni caso entra nel denominatore di una metrica, gli stati di decisione e i codici di motivo che li spiegano, i codici di uscita, e quali dati restano in locale o si spostano in uno spazio di lavoro ospitato. Per le idee alla base leggi Concetti; per i campi della policy leggi il Riferimento della configurazione.

Il contratto del sistema HTTP

Un sistema HTTP (system.http in oloproof.yaml) viene chiamato una volta per caso, e una volta per replica.

L'URL, il metodo, il percorso dell'output e la mappatura degli artefatti entrano nella versione del sistema, ma ciò che fa il server no. Cambia system.version ogni volta che cambia il comportamento del server; il Riferimento della configurazione spiega perché.

Tre vocabolari diversi

Un risultato ha tre tipi di stato, e nessuno sostituisce mai un altro.

Un'esecuzione che termina normalmente è DECIDED, oppure DECIDED_EARLY quando l'arresto anticipato l'ha conclusa. Un'esecuzione interrotta da Ctrl-C o dalla cancellazione del task è CANCELLED; una il cui harness ha sollevato un'eccezione è RUN_ERROR. In entrambi i casi l'esecuzione resta PARTIAL, conserva i casi terminati e permette all'esecuzione successiva di riutilizzarne i record in cache. Vedi Errori.

Per una soglia minima T e un intervallo [L, U], una regola è PASS quando L >= T, FAIL quando U < T, e INSUFFICIENT_EVIDENCE altrimenti. Una soglia massima è simmetrica. Prima di leggere l'intervallo, una regola verifica se debba decidere del tutto: prima i motivi per MANUAL_REVIEW, poi quelli per INSUFFICIENT_EVIDENCE. Decide il primo livello che ha un motivo, ed elenca ogni motivo trovato.

Codici di motivo

Ogni decisione porta uno o più codici di motivo.

MANUAL_REVIEW

INSUFFICIENT_EVIDENCE

PASS e FAIL

Solo spazio di lavoro ospitato

Uno spazio di lavoro che decide da sé un'esecuzione ricevuta via push può trattenere una decisione con ppi_not_verified (non ha verificato l'intervallo su cui la decisione si basa), execution_not_verified (gli output non provengono da un runner registrato) o workspace_cannot_decide (non ha una copia della policy, o non ha potuto leggere le evidenze). Vedi Gating.

Come ogni caso entra nel denominatore

Ogni metrica riporta quattro conteggi: n_total (casi nella suite), n_eligible, n_observed e n_missing, con n_eligible = n_observed + n_missing. I casi fuori da n_eligible sono elencati sotto exclusions con un motivo.

Un caso mancante viene delimitato, non scartato. Per un tasso di successo il limite inferiore dell'intervallo tratta ogni caso mancante come un fallimento e il limite superiore come un successo, quindi un'esecuzione con molti casi mancanti ha un intervallo ampio che non può superare una regola esigente; una media delimitata sostituisce allo stesso modo gli estremi del suo intervallo dichiarato. Un metodo che non può delimitare i casi mancanti (una statistica di ranking, per esempio) li scarta e registra l'assunzione, e una regola su di esso riporta missingness_unbounded finché non dichiara max_missing_fraction.

Una regola observed_count conta i fallimenti sulla suite eseguita e non legge alcun intervallo. Passa solo quando i fallimenti osservati più ogni caso mancante rientrano ancora in max_failures.

Metriche senza un intervallo ammesso

Una regola decide solo su un intervallo il cui metodo è stato ammesso tramite audit. Dove non ne esiste uno, la metrica viene comunque calcolata e mostrata, e una regola su di essa non prende in prestito un metodo non validato:

Codici di uscita

oloproof gate, oloproof run con una policy e gli altri comandi che decidono usano tutti gli stessi codici.

Quando ne valgono diversi, il codice riportato è il primo tra 1, 5, 4, 3. Uno stato lasciato fuori da block_on non può cambiare il codice di uscita: con block_on: [FAIL] e warn_on: [INSUFFICIENT_EVIDENCE], una regola indecisa avvisa e il gate esce con 0. L'uscita 0 significa quindi solo che non si è verificato nulla su cui la tua policy blocca, non che ogni regola è passata. Vedi Gating.

Dove gira il lavoro e dove vanno i dati

In locale, l'impostazione predefinita

oloproof run, oloproof gate e l'SDK girano sulla tua macchina. Ogni record (casi, output, artefatti, giudizi, metriche e decisioni) viene scritto in .oloproof/store.sqlite accanto a oloproof.yaml, o sotto OLOPROOF_HOME quando è impostata. Nulla viene inviato a Oloproof. L'unico traffico di rete è quello causato dalla tua configurazione: le chiamate all'URL del tuo sistema HTTP, e le chiamate che un giudice basato su modello o un classificatore basato su modello fa al proprio provider, che riceve il contenuto dei casi che giudica e te lo fattura.

Push in uno spazio di lavoro ospitato

oloproof push invia le evidenze di un'esecuzione allo spazio di lavoro che hai collegato con oloproof login. Per impostazione predefinita invia metriche, intervalli, decisioni e slice aggregate, e l'identità, lo stato, i tempi e l'utilizzo di ogni record, ma non il suo contenuto. Il contenuto grezzo viene oscurato campo per campo prima che qualsiasi cosa lasci la macchina, e un record oscurato dice quali categorie sono state trattenute. Una categoria viene inviata solo quando egress: in oloproof.yaml la elenca:

I digest dei record non vengono ricalcolati dopo l'oscuramento, quindi un record ospitato nomina ancora le evidenze originali, che restano sulla tua macchina. L'oscuramento non è cifratura, e una metrica su una slice molto piccola può ancora identificare i casi che vi stanno dietro.

Quando i revisori etichettano casi nella coda di revisione ospitata, il loro browser recupera il contenuto dei casi da oloproof collect in esecuzione dalla tua parte; non passa attraverso lo spazio di lavoro. Le chiavi dei provider che uno spazio di lavoro usa vengono memorizzate con oloproof credentials set, e oloproof credentials list ne mostra i nomi, mai i valori. Un job gestito gira su un worker gestito da Oloproof, che non esegue il tuo codice Python; oloproof job ne riporta il risultato ed esce sul suo gate.

In uno spazio di lavoro ospitato il motore non riutilizza mai esecuzioni, giudizi o analisi in cache, perché un push può scrivere quelle cache; li ricalcola.