Job Specs

Wie Everyn wiederverwendbare Arbeitsanweisungen, Model-Auswahl und Ausgabeverträge erfasst.

Ein Job Spec ist der dauerhafte Arbeitsvertrag für eine Klasse von Everyn-Arbeit. Er ist mehr als ein Prompt: Er enthält Ziel, Instructions, Output Mode, ausgewähltes Model, Output Schema und Review-Erwartungen, denen nachfolgende Runs folgen sollen.

Job Specs sind wiederverwendbar. Ein Run führt keine unversionierte Idee aus; er führt eine gepinnte Job Spec Version aus. Dadurch lassen sich Sample Results, Revisionen, Full Runs, Retries und Exports später leichter erklären.

Job-Spec-Vertrag

Job Spec versus Job Spec Version

Objekt	Bedeutung
Job Spec	Veränderliches Produktobjekt für eine wiederverwendbare Klasse von Arbeit.
Job Spec Version	Unveränderlicher Snapshot von Instructions, Model, Mode und Output Schema.
Run	Ausführungsdatensatz, der eine Job Spec Version pinnt.

Wenn ein Job Spec gepatcht wird, können nachfolgende Runs eine neue Version nutzen. Bestehende Runs behalten die Version, die sie gepinnt haben.

Output Modes

Mode	Wann nutzen
`add_columns`	Jede Source Row soll ein generiertes Objekt mit neuen Feldern erhalten. Lead Scoring, Classification, Enrichment und Sentiment Extraction starten meist hier.
`create_rows`	Jede Source Row kann null, eine oder viele Child Records erzeugen. Nutze das, wenn Output eine Liste von Findings, Contacts, References oder extrahierten Items ist.

Output-Schema-Regeln

Gute Output Schemas sind explizit genug für konsistente Validierung:

stabile Machine Field Names wie fit_score oder evidence_url nutzen
Descriptions einschließen, die erklären, wie das Feld erzeugt wird
enum nutzen, wenn akzeptierte Werte bekannt sind
numerische Grenzen für Scores oder Confidence Values nutzen
Unsicherheit mit Feldern wie confidence, needs_review oder einem nullable optional field darstellen
versteckte Geschäftsregeln vermeiden, die nicht im Job Spec codiert sind

Column Names sollten stabil bleiben, weil sie Output Keys und Export Columns werden. Wenn das Schema eine Breaking Change braucht, behandle die überarbeitete Job Spec Version als neuen Vertrag und führe einen weiteren Sample aus.

Drafting Workflow

Dataset Columns und repräsentative Rows prüfen.
Ziel in Produktbegriffen wiedergeben.
add_columns oder create_rows wählen.
Output Schema und Review-Kriterien entwerfen.
Runnable Model aus dem Model Catalog auswählen.
Begrenzten Sample Run ausführen.
Outputs und Failures prüfen.
Job Spec überarbeiten, wenn der Sample Mehrdeutigkeit zeigt.
Freigegebene Version für den Full Run nutzen.

Beispiel: Lead-/Account-Scoring

Ein Lead-Scoring-Job-Spec kann add_columns mit Feldern wie diesen nutzen:

Feld	Typ	Beschreibung
`fit_score`	integer	Score von 1 bis 5 für Fit gegen das Zielkundenprofil.
`fit_reason`	string	Knappes Reasoning für den Score mit Evidence aus Row oder Research.
`territory_signal`	enum	Ob der Account in einer Prioritätsregion erscheint.
`evidence_url`	string	Öffentliche Quelle, die den Score stützt, falls verfügbar.
`needs_review`	boolean	Ob die Row vor Nutzung geprüft werden sollte.

Häufige Fehler

Einen Prompt als gesamten Job Spec behandeln.
Output Fields mit instabilen Namen wie result1 erzeugen.
Nach privatem Geschäftskontext fragen, den spätere Runs nicht haben.
Review-Kriterien weglassen und dann subjektiven Output als final behandeln.
Schema nach einem Sample ändern, ohne einen weiteren Sample auszuführen.
Einen Run starten, bevor geprüft wurde, ob die Model ID unterstützt wird.