Dokumentacja wyników i wykonania

Co przebieg wysyła do systemu HTTP i czego oczekuje w odpowiedzi, jak każdy przypadek trafia do mianownika metryki, stany decyzji i kody przyczyn, które je wyjaśniają, kody wyjścia oraz jakie dane pozostają lokalnie, a jakie trafiają do hostowanego obszaru roboczego. Idee stojące za nimi opisują Pojęcia; pola polityki opisuje Dokumentacja konfiguracji.

Kontrakt systemu HTTP

System HTTP (system.http w oloproof.yaml) jest wywoływany raz na przypadek i raz na replikację.

URL, metoda, ścieżka wyniku i odwzorowanie artefaktów wchodzą do wersji systemu, ale to, co robi serwer, już nie. Zmieniaj system.version za każdym razem, gdy zmienia się zachowanie serwera; dlaczego, wyjaśnia Dokumentacja konfiguracji.

Trzy różne słowniki

Wynik ma trzy rodzaje stanu i nigdy nie zastępują się nawzajem.

Przebieg, który kończy się normalnie, ma stan DECIDED albo DECIDED_EARLY, gdy zakończyło go wczesne zatrzymanie. Przebieg przerwany przez Ctrl-C lub anulowanie zadania ma stan CANCELLED; taki, w którym zgłosiła wyjątek infrastruktura, ma stan RUN_ERROR. Każdy z nich zostawia przebieg jako PARTIAL, zachowuje ukończone przypadki i pozwala następnemu przebiegowi ponownie użyć ich rekordów z cache. Zob. Błędy.

Dla progu minimalnego T i przedziału [L, U] reguła ma stan PASS, gdy L >= T, FAIL, gdy U < T, a w przeciwnym razie INSUFFICIENT_EVIDENCE. Próg maksymalny jest symetryczny. Zanim przeczyta przedział, reguła sprawdza, czy w ogóle powinna rozstrzygać: najpierw przyczyny dla MANUAL_REVIEW, potem te dla INSUFFICIENT_EVIDENCE. Rozstrzyga pierwszy poziom, który ma przyczynę, i wymienia każdą znalezioną przyczynę.

Kody przyczyn

Każda decyzja niesie jeden lub więcej kodów przyczyn.

MANUAL_REVIEW

INSUFFICIENT_EVIDENCE

PASS i FAIL

Tylko w hostowanym obszarze roboczym

Obszar roboczy, który sam rozstrzyga wypchnięty przebieg, może wstrzymać decyzję z ppi_not_verified (nie zweryfikował przedziału, na którym opiera się decyzja), execution_not_verified (wyniki nie pochodziły z zarejestrowanego runnera) lub workspace_cannot_decide (nie ma kopii polityki albo nie mógł odczytać dowodów). Zob. Bramkowanie.

Jak każdy przypadek trafia do mianownika

Każda metryka raportuje cztery liczności: n_total (przypadki w zestawie), n_eligible, n_observed i n_missing, przy czym n_eligible = n_observed + n_missing. Przypadki spoza n_eligible są wymienione pod exclusions z przyczyną.

Brakujący przypadek jest ograniczany, a nie pomijany. Dla odsetka zaliczeń dolna granica przedziału traktuje każdy brakujący przypadek jako niepowodzenie, a górna jako sukces, więc przebieg z wieloma brakującymi przypadkami ma szeroki przedział, który nie może przejść wymagającej reguły; ograniczona średnia podstawia w ten sam sposób krańce swojego zadeklarowanego zakresu. Metoda, która nie potrafi ograniczyć brakujących przypadków (na przykład statystyka rankingowa), pomija je i zapisuje to założenie, a reguła na niej pokazuje missingness_unbounded, dopóki nie zadeklaruje max_missing_fraction.

Reguła observed_count liczy niepowodzenia na wykonanym zestawie i nie czyta przedziału. Przechodzi tylko wtedy, gdy zaobserwowane niepowodzenia plus każdy brakujący przypadek nadal mieszczą się w max_failures.

Metryki bez przyjętego przedziału

Reguła rozstrzyga tylko na podstawie przedziału, którego metoda została przyjęta po audycie. Gdy takiego nie ma, metryka jest nadal liczona i pokazywana, a reguła na niej nie pożycza niezwalidowanej metody:

Kody wyjścia

oloproof gate, oloproof run z polityką i inne polecenia, które rozstrzygają, używają tych samych kodów.

Gdy pasuje kilka kodów, zgłaszany jest pierwszy z 1, 5, 4, 3. Stan pominięty w block_on nie może zmienić kodu wyjścia: przy block_on: [FAIL] i warn_on: [INSUFFICIENT_EVIDENCE] nierozstrzygnięta reguła ostrzega, a bramka kończy się kodem 0. Kod 0 oznacza więc tylko, że nie wystąpiło nic, na czym blokuje Twoja polityka, a nie że każda reguła przeszła. Zob. Bramkowanie.

Gdzie odbywa się praca i dokąd trafiają dane

Lokalnie, domyślnie

oloproof run, oloproof gate i SDK działają na Twojej maszynie. Każdy rekord (przypadki, wyniki, artefakty, oceny, metryki i decyzje) jest zapisywany w .oloproof/store.sqlite obok oloproof.yaml albo pod OLOPROOF_HOME, gdy jest ustawione. Nic nie jest wysyłane do Oloproof. Jedyny ruch sieciowy to ten, który powoduje Twoja konfiguracja: wywołania URL Twojego systemu HTTP oraz wywołania, które sędzia-model lub klasyfikator-model wykonuje do swojego dostawcy; ten otrzymuje treść przypadków, które ocenia, i obciąża Cię za to.

Wypychanie do hostowanego obszaru roboczego

oloproof push wysyła dowody przebiegu do obszaru roboczego, z którym połączyłeś się przez oloproof login. Domyślnie wysyła metryki, przedziały, decyzje i zagregowane wycinki oraz tożsamość, status, czasy i zużycie każdego rekordu, ale nie jego treść. Surowa treść jest redagowana pole po polu, zanim cokolwiek opuści maszynę, a zredagowany rekord mówi, które kategorie wstrzymano. Kategoria jest wysyłana tylko wtedy, gdy wymienia ją egress: w oloproof.yaml:

Skróty rekordów nie są przeliczane po redakcji, więc rekord w hostowanym obszarze nadal wskazuje oryginalne dowody, które pozostają na Twojej maszynie. Redakcja to nie szyfrowanie, a metryka na bardzo małym wycinku może nadal zidentyfikować stojące za nią przypadki.

Gdy recenzenci etykietują przypadki w hostowanej kolejce przeglądu, ich przeglądarka pobiera treść przypadków z oloproof collect działającego po Twojej stronie; nie przechodzi ona przez obszar roboczy. Klucze dostawców używane przez obszar roboczy są przechowywane przez oloproof credentials set, a oloproof credentials list pokazuje ich nazwy, nigdy wartości. Zadanie zarządzane działa na workerze obsługiwanym przez Oloproof, który nie uruchamia Twojego kodu w Pythonie; oloproof job raportuje jego wynik i kończy się zgodnie z jego bramką.

W hostowanym obszarze roboczym silnik nigdy nie używa ponownie wykonań, ocen ani analiz z cache, ponieważ push może zapisywać te cache; liczy je od nowa.