Concepts | everyn

Everyn is a managed run system. It turns repeatable input data and a reusable work definition into durable work that can be inspected, retried, and explained after the model response is gone.

The core model is intentionally smaller than a workflow builder. A dataset supplies stable rows. A job spec defines the work. A run applies a pinned job spec version to a selected row scope. Outputs, failures, events, and exports make the work reviewable.

Object model

Concept	Stable ID	Meaning
Dataset	`ds_...`	Input data registered with Everyn from a CSV-backed dataset upload.
Dataset row	`dsr_...`	Stable row identity inside a dataset snapshot.
Job spec	`js_...`	Mutable pointer for a reusable class of work.
Job spec version	`jsv_...`	Immutable snapshot of the job contract pinned by a run.
Run	`run_...`	Concrete execution of a job spec version against a row scope.
Run row	`rr_...`	Per-run row execution record for a selected dataset row.
Output	`out_...`	Schema-valid generated value or child record produced by a run row.
Failure	none or embedded ID	Structured non-success outcome when valid output cannot be produced.
Event	`evt_...`	Append-only operational trace for inspection, alerts, and support.
Export	`exp_...`	Generated artifact such as a CSV of outputs or resolved lineage results.
Alert rule	`alr_...`	Rule that watches run or row events.
Alert delivery	`ald_...`	Delivery attempt produced by an alert rule.
Error code	string code	Stable public code with a docs URL and recovery guidance.

Relationship map

Dataset
  DatasetRow[]

JobSpec
  JobSpecVersion[]

Run
  pins one JobSpecVersion
  selects DatasetRow[] from one Dataset
  creates RunRow[]
  emits Output[], Failure[], Event[]
  can produce Export[]

Core invariants

Source snapshots are immutable once a dataset is registered.
Dataset row IDs stay stable across scopes, retries, outputs, failures, exports, and inspection.
Job specs are mutable pointers; job spec versions are immutable snapshots.
A run pins the job spec version it uses.
Terminal run rows are not reopened.
Retry, repair, and failed-row follow-up create a new run with lineage.
Events are append-only.
Generated output must satisfy the job spec's outputSchema; otherwise the row should fail instead of fabricating data.
requestId and docsUrl values are part of the support and recovery path, not decoration.

Common confusions

If you are tempted to say	Prefer	Why
Task	Run or job spec	"Task" hides whether you mean definition or execution.
Prompt	Job spec prompt or instructions	A job spec also includes schema, mode, model, and review expectations.
Result	Output, failure, or export	A run can produce several inspectable result forms.
Rerun	Retry run or follow-up run	Runs happen once; new work creates a new run.
Row result	Row outcome	A row can succeed, fail, be skipped, or need review.

Where to read next

Datasets explains input snapshots and row identity.
Job specs explains reusable work contracts.
Runs explains lifecycle, inspection, and retry lineage.
Errors explains public recovery codes.