Runs

Ein Run ist Everyns dauerhafter Datensatz für Arbeit. Er hält fest, welche Job Spec Version genutzt wurde, welche Dataset Rows ausgewählt waren, was mit jeder Row passiert ist, welche Outputs oder Failures entstanden sind, welche Events emittiert wurden und welche Artifacts exportiert werden können.

Runs machen KI-Arbeit prüfbar. Es geht nicht nur darum, generierte Werte zurückzubekommen; es geht darum zu wissen, was versucht wurde, was erfolgreich war, was fehlgeschlagen ist, was es gekostet hat und was als Nächstes sicher passieren kann.

Lifecycle und Inspection

Lifecycle

Phase	Bedeutung	Nächste Handlung
Draft	Der Run-Datensatz existiert, aber Ausführung hat nicht begonnen.	Scope, Job Spec Version und Approval bestätigen.
Queued oder running	Everyn verarbeitet ausgewählte Rows.	Progress, Events und frühe Failures beobachten.
Succeeded	Die Ausführung hat einen erfolgreichen terminalen Zustand erreicht.	Outputs, Usage und Export Readiness prüfen.
Failed	Der Run hat einen terminalen Failure-Zustand erreicht.	Failures prüfen und entscheiden, ob Retry passend ist.
Canceled	Arbeit wurde vor normalem Abschluss gestoppt.	Teilzustand prüfen, bevor neue Arbeit erzeugt wird.

Terminale Runs und terminale Rows werden nicht wieder geöffnet. Neue Arbeit erzeugt einen neuen Run.

Sample Runs und Full Runs

Ein Sample Run ist ein begrenzter Run, meist über einen kleinen Row Scope. Er sollte beweisen, dass Job Spec, Output Schema, ausgewähltes Model und Qualitätsgrenze sinnvoll sind, bevor größerer Spend freigegeben wird.

Ein Full Run wendet die freigegebene Job Spec Version auf den größeren beabsichtigten Scope an. Full-Run-Approval sollte Sample Evidence, erwartete Output-Felder, bekannte Caveats und Usage- oder Kostenschätzung referenzieren, sofern vorhanden.

Inspection-Checkliste

Nachdem ein Run startet, prüfe mehr als den Top-Level-State:

Run Summary und ausgewählter Row Scope
Row States und Row Counts
generierte Outputs
strukturierte Failures
Events
Usage- und Cost-Summaries
Exports und Download Readiness
Retry- oder Follow-up-Lineage

Retry und Lineage

Retry-Arbeit erzeugt einen neuen Run. Sie mutiert keine terminalen Rows im Source Run. Der Retry Run sollte Lineage zum ursprünglichen Run bewahren und auf geeignete failed, flagged oder retryable skipped Rows begrenzt sein.

Nutze Retry, wenn dieselbe gepinnte Job Spec Version die ungelösten Rows sinnvoll lösen kann. Nutze einen überarbeiteten Job Spec und einen neuen Run, wenn Instructions, Schema, Model oder Qualitätsgrenze geändert werden müssen.

Häufige Fehler

Fehler	Besseres Verhalten
Doppelte Arbeit starten, weil ein Create Request timeoutet.	Idempotency nutzen und bestehenden Run prüfen.
Einen Sample als Approval für den Full Run behandeln.	Separates Approval für breiteren Scope oder Spend einholen.
Failed Rows verstecken, weil der Run größtenteils erfolgreich war.	Failures mit Codes, Row-Kontext und Recovery-Hinweisen zeigen.
Retry als Rerun bezeichnen.	Retry Run sagen und Lineage zur ursprünglichen `runId` bewahren.
Vor Review exportieren.	Bestätigen, dass Outputs nutzbar sind.