Konzepte | everyn

Everyn ist ein verwaltetes Run-System. Es verwandelt wiederholbare Eingabedaten und eine wiederverwendbare Arbeitsdefinition in dauerhafte Arbeit, die geprüft, wiederholt und nach der Model-Antwort erklärt werden kann.

Das Kernmodell ist bewusst kleiner als ein Workflow Builder. Ein Dataset liefert stabile Rows. Ein Job Spec definiert die Arbeit. Ein Run wendet eine gepinnte Job Spec Version auf einen ausgewählten Row Scope an. Outputs, Failures, Events und Exports machen die Arbeit prüfbar.

Objektmodell

Konzept	Stabile ID	Bedeutung
Dataset	`ds_...`	Eingabedaten, die bei Everyn aus einem CSV-basierten Dataset Upload registriert sind.
Dataset Row	`dsr_...`	Stabile Row-Identität in einem Dataset Snapshot.
Job Spec	`js_...`	Veränderlicher Pointer für eine wiederverwendbare Klasse von Arbeit.
Job Spec Version	`jsv_...`	Unveränderlicher Snapshot des Job-Vertrags, den ein Run pinnt.
Run	`run_...`	Konkrete Ausführung einer Job Spec Version gegen einen Row Scope.
Run Row	`rr_...`	Per-Run-Ausführungsdatensatz für eine ausgewählte Dataset Row.
Output	`out_...`	Schema-gültiger generierter Wert oder Child Record einer Run Row.
Failure	keine oder eingebettet	Strukturierter Non-Success Outcome, wenn gültiger Output nicht erzeugt werden kann.
Event	`evt_...`	Append-only operative Spur für Inspection, Alerts und Support.
Export	`exp_...`	Generiertes Artifact, etwa CSV mit Outputs oder Resolved-Lineage-Results.
Alert Rule	`alr_...`	Regel, die Run- oder Row-Events beobachtet.
Alert Delivery	`ald_...`	Delivery-Versuch, den eine Alert Rule erzeugt.
Error Code	String-Code	Stabiler öffentlicher Code mit Docs-URL und Recovery-Hinweisen.

Beziehungskarte

Dataset
  DatasetRow[]

JobSpec
  JobSpecVersion[]

Run
  pinnt eine JobSpecVersion
  waehlt DatasetRow[] aus einem Dataset
  erzeugt RunRow[]
  emittiert Output[], Failure[], Event[]
  kann Export[] erzeugen

Kerninvarianten

Source Snapshots sind nach Dataset-Registrierung unveränderlich.
Dataset Row IDs bleiben über Scopes, Retries, Outputs, Failures, Exports und Inspection hinweg stabil.
Job Specs sind veränderliche Pointer; Job Spec Versions sind unveränderliche Snapshots.
Ein Run pinnt die Job Spec Version, die er nutzt.
Terminale Run Rows werden nicht wieder geöffnet.
Retry, Repair und Failed-Row-Follow-up erzeugen einen neuen Run mit Lineage.
Events sind append-only.
Generierter Output muss das outputSchema des Job Specs erfüllen; sonst sollte die Row fehlschlagen statt Daten zu erfinden.
requestId und docsUrl sind Teil des Support- und Recovery-Pfads, keine Dekoration.

Häufige Verwechslungen

Wenn du sagen willst	Besser	Warum
Task	Run oder Job Spec	"Task" verbirgt, ob Definition oder Ausführung gemeint ist.
Prompt	Job-Spec-Prompt oder Instructions	Ein Job Spec enthält auch Schema, Mode, Model und Review-Erwartungen.
Result	Output, Failure oder Export	Ein Run kann mehrere prüfbare Ergebnisformen erzeugen.
Rerun	Retry Run oder Follow-up Run	Runs passieren einmal; neue Arbeit erzeugt einen neuen Run.
Row Result	Row Outcome	Eine Row kann erfolgreich sein, fehlschlagen, übersprungen werden oder Review brauchen.

Wohin als Nächstes

Datasets erklärt Input Snapshots und Row Identity.
Job Specs erklärt wiederverwendbare Arbeitsverträge.
Runs erklärt Lifecycle, Inspection und Retry-Lineage.
Fehler erklärt öffentliche Recovery Codes.