Overview
Understand Everyn's managed run model and public API resources.
Everyn turns row-shaped data and a goal into durable, inspectable AI work. Instead of treating an AI request as a one-off prompt, Everyn records the input dataset, reusable job definition, run scope, row outcomes, generated outputs, failures, events, usage, and exports.
The core workflow is: bring data, define the work, run a small sample, inspect what happened, revise if needed, then approve the larger run or export. The docs outside the API section explain that product model. The API section explains how software calls it.
How Everyn works
First workflow
- Upload or select a dataset.
- Define the desired row-level outcome.
- Draft or choose a job spec with a clear output schema.
- Run a limited sample before spending on the full dataset.
- Inspect rows, outputs, failures, events, and usage.
- Revise the job spec when the sample shows ambiguity or missing output fields.
- Approve a full run only after the sample is understandable.
- Export results after review.
What is durable
Everyn persists the parts that make AI work auditable:
| Durable object | Why it matters |
|---|---|
| Dataset | The immutable source snapshot and stable row identities. |
| Job spec | The reusable goal, instructions, model choice, and output schema. |
| Job spec version | The immutable job contract pinned by a run. |
| Run | The execution record for a scope of rows. |
| Row outcome | The per-row success, failure, skipped, or review state. |
| Event | The append-only trace used for inspection, alerts, and support. |
| Export | The artifact that packages results for use elsewhere. |
Review and approval
Before expanding from a sample to a full run, verify the goal, output shape, row scope, spend tolerance, quality bar, and export decision. Keep ambiguity, failed rows, and retry paths visible so a later run or export can be explained from the stored records.
Where to go next
- Read Concepts for vocabulary and object relationships.
- Read Datasets before uploading or validating input data.
- Read Job specs before drafting reusable work.
- Read Runs before starting, inspecting, retrying, or exporting work.
- Read API when you need HTTP authentication, idempotency, pagination, generated reference, or endpoint details.
- Read Errors when a response includes an error
codeordocsUrl.
API versus product docs
Use top-level product docs to understand what an object means and which decisions matter. Use API docs to make valid HTTP calls. For example, Runs explains sample runs, retry lineage, and inspection; Runs API lists endpoint-level request and response details.