Überblick | everyn

Everyn macht aus zeilenförmigen Daten und einem Ziel dauerhafte, prüfbare KI-Arbeit. Statt eine KI-Anfrage als einmaligen Prompt zu behandeln, hält Everyn Eingabe-Dataset, wiederverwendbare Job-Definition, Run Scope, Row Outcomes, generierte Outputs, Failures, Events, Usage und Exports fest.

Der Kernablauf ist: Daten einbringen, Arbeit definieren, einen kleinen Sample Run ausführen, Ergebnisse prüfen, bei Bedarf überarbeiten und erst dann den größeren Run oder Export freigeben. Die Dokumentation außerhalb des API-Bereichs erklärt dieses Produktmodell. Der API-Bereich erklärt, wie Software es aufruft.

Wie Everyn funktioniert

Erster Workflow

Dataset hochladen oder auswählen.
Gewünschtes zeilenbezogenes Ergebnis definieren.
Job Spec mit klarem Output Schema entwerfen oder auswählen.
Begrenzten Sample Run ausführen, bevor Geld für das volle Dataset ausgegeben wird.
Rows, Outputs, Failures, Events und Usage prüfen.
Job Spec überarbeiten, wenn der Sample Mehrdeutigkeit oder fehlende Output-Felder zeigt.
Full Run erst freigeben, wenn der Sample verständlich ist.
Results nach Review exportieren.

Was dauerhaft ist

Everyn persistiert die Teile, die KI-Arbeit auditierbar machen:

Dauerhaftes Objekt	Warum es wichtig ist
Dataset	Der unveränderliche Source Snapshot und stabile Row-Identitäten.
Job Spec	Das wiederverwendbare Ziel, die Anweisungen, Model-Auswahl und Output Schema.
Job Spec Version	Der unveränderliche Job-Vertrag, den ein Run pinnt.
Run	Der Ausführungsdatensatz für einen Scope von Rows.
Row Outcome	Der Erfolg, Failure-, Skip- oder Review-Status pro Row.
Event	Die append-only Spur für Inspection, Alerts und Support.
Export	Das Artifact, das Results für andere Nutzung paketiert.

Review und Freigabe

Vor dem Wechsel von einem Sample zu einem Full Run sollten Ziel, Output-Form, Row Scope, Spend-Toleranz, Qualitätsgrenze und Export-Entscheidung geprüft sein. Mehrdeutigkeit, fehlgeschlagene Rows und Retry-Pfade bleiben sichtbar, damit ein späterer Run oder Export aus den gespeicherten Records erklärbar ist.

Wohin als Nächstes

Lies Konzepte für Vokabular und Objektbeziehungen.
Lies Datasets, bevor du Eingabedaten hochlädst oder validierst.
Lies Job Specs, bevor du wiederverwendbare Arbeit entwirfst.
Lies Runs, bevor du Arbeit startest, prüfst, wiederholst oder exportierst.
Lies API, wenn du HTTP-Authentifizierung, Idempotency, Pagination, generierte Referenz oder Endpoint-Details brauchst.
Lies Fehler, wenn eine Antwort einen Error-code oder eine docsUrl enthält.

API versus Produktdokumentation

Nutze Top-Level-Produktdokumentation, um zu verstehen, was ein Objekt bedeutet und welche Entscheidungen zählen. Nutze API-Dokumentation, um gültige HTTP-Aufrufe zu machen. Zum Beispiel erklärt Runs Sample Runs, Retry-Lineage und Inspection; die Runs API listet Request- und Response-Details auf Endpoint-Ebene.