Referentie voor resultaten en uitvoering

Wat een run naar een HTTP-systeem stuurt en terugverwacht, hoe elke case in de noemer van een metriek terechtkomt, de beslissingstoestanden en de redencodes die ze verklaren, de exitcodes, en welke gegevens lokaal blijven of naar een gehoste workspace gaan. Voor de ideeën erachter lees je Kernbegrippen; voor de beleidsvelden lees je de Configuratiereferentie.

Het contract van een HTTP-systeem

Een HTTP-systeem (system.http in oloproof.yaml) wordt één keer per case aangeroepen, en één keer per replicaat.

De URL, methode, het outputpad en de artefacttoewijzing gaan mee in de versie van het systeem, maar wat de server doet niet. Wijzig system.version telkens als het gedrag van de server verandert; zie de Configuratiereferentie voor de reden.

Drie verschillende woordenschatten

Een resultaat kent drie soorten toestand, en ze vervangen elkaar nooit.

Een run die normaal eindigt is DECIDED, of DECIDED_EARLY als vroeg stoppen hem beëindigde. Een run die door Ctrl-C of het annuleren van een taak wordt onderbroken is CANCELLED; een run waarvan het harnas een fout opwierp is RUN_ERROR. Beide laten de run PARTIAL, bewaren de cases die klaar waren, en laten de volgende run hun gecachete records hergebruiken. Zie Fouten.

Voor een minimumdrempel T en een interval [L, U] is een regel PASS als L >= T, FAIL als U < T, en anders INSUFFICIENT_EVIDENCE. Een maximumdrempel is symmetrisch. Voordat een regel het interval leest, controleert hij of hij überhaupt moet beslissen: eerst de redenen voor MANUAL_REVIEW, dan die voor INSUFFICIENT_EVIDENCE. Het eerste niveau met een reden beslist, en noemt elke reden die het vond.

Redencodes

Elke beslissing draagt een of meer redencodes.

MANUAL_REVIEW

INSUFFICIENT_EVIDENCE

PASS en FAIL

Alleen in een gehoste workspace

Een workspace die zelf over een gepushte run beslist, kan een beslissing achterhouden met ppi_not_verified (hij heeft het interval waarop de beslissing rust niet geverifieerd), execution_not_verified (de outputs kwamen niet van een geregistreerde runner) of workspace_cannot_decide (hij heeft geen kopie van het beleid, of kon het bewijs niet lezen). Zie Gating.

Hoe elke case in de noemer komt

Elke metriek rapporteert vier aantallen: n_total (cases in de suite), n_eligible, n_observed en n_missing, met n_eligible = n_observed + n_missing. Cases buiten n_eligible staan onder exclusions, met een reden.

Een ontbrekende case wordt begrensd, niet weggelaten. Voor een slagingspercentage behandelt de ondergrens van het interval elke ontbrekende case als mislukking en de bovengrens als succes, dus een run met veel ontbrekende cases heeft een breed interval dat geen veeleisende regel kan halen; een begrensd gemiddelde vult op dezelfde manier de uiteinden van zijn gedeclareerde bereik in. Een methode die ontbrekende cases niet kan begrenzen (een rangschikkingsstatistiek, bijvoorbeeld) laat ze vallen en legt die aanname vast, en een regel erover leest missingness_unbounded totdat hij max_missing_fraction declareert.

Een observed_count-regel telt mislukkingen over de uitgevoerde suite en leest geen interval. Hij slaagt alleen als de waargenomen mislukkingen plus elke ontbrekende case nog binnen max_failures passen.

Metrieken zonder toegelaten interval

Een regel beslist alleen op een interval waarvan de methode door een audit is toegelaten. Waar er geen bestaat, wordt de metriek nog steeds berekend en getoond, en een regel erover leent geen ongevalideerde methode:

Exitcodes

oloproof gate, oloproof run met een beleid, en de andere commando's die beslissen gebruiken allemaal dezelfde codes.

Als er meerdere van toepassing zijn, is de gerapporteerde code de eerste van 1, 5, 4, 3. Een toestand die buiten block_on blijft kan de exitcode niet veranderen: met block_on: [FAIL] en warn_on: [INSUFFICIENT_EVIDENCE] waarschuwt een onbesliste regel en eindigt de gate met 0. Exit 0 betekent dus alleen dat er niets gebeurde waarop je beleid blokkeert, niet dat elke regel slaagde. Zie Gating.

Waar het werk draait en waar de gegevens heen gaan

Lokaal, de standaard

oloproof run, oloproof gate en de SDK draaien op je eigen machine. Elk record (cases, outputs, artefacten, oordelen, metrieken en beslissingen) wordt geschreven naar .oloproof/store.sqlite naast oloproof.yaml, of onder OLOPROOF_HOME als die is gezet. Er wordt niets naar Oloproof gestuurd. Het enige netwerkverkeer is wat je configuratie veroorzaakt: aanroepen naar de URL van je HTTP-systeem, en aanroepen die een modeljudge of modelclassifier naar zijn provider doet, die de beoordeelde caseinhoud ontvangt en je ervoor factureert.

Pushen naar een gehoste workspace

oloproof push stuurt het bewijs van een run naar de workspace die je met oloproof login hebt verbonden. Standaard stuurt het metrieken, intervallen, beslissingen en geaggregeerde slices, en van elk record de identiteit, status, tijden en verbruik, maar niet de inhoud. Ruwe inhoud wordt veld voor veld geredigeerd voordat er iets de machine verlaat, en een geredigeerd record zegt welke categorieën zijn achtergehouden. Een categorie gaat alleen mee als egress: in oloproof.yaml hem noemt:

Recorddigests worden na redactie niet opnieuw berekend, dus een gehost record noemt nog steeds het oorspronkelijke bewijs, dat op je machine blijft. Redactie is geen versleuteling, en een metriek over een heel kleine slice kan de cases erachter nog steeds herkenbaar maken.

Als reviewers cases labelen in de gehoste reviewwachtrij, haalt hun browser de caseinhoud op bij oloproof collect dat aan jouw kant draait; die gaat niet door de workspace. Providersleutels die een workspace gebruikt worden opgeslagen met oloproof credentials set, en oloproof credentials list toont hun namen, nooit hun waarden. Een beheerde job draait op een worker die Oloproof beheert en die je Python-code niet uitvoert; oloproof job rapporteert het resultaat en eindigt op de gate ervan.

In een gehoste workspace hergebruikt de engine nooit gecachete uitvoeringen, oordelen of analyses, omdat een push die caches kan beschrijven; hij berekent ze opnieuw.