Create Job
Jobs
Create Job
Create a new batch or training job
POST
Create Job
Overview
This endpoint creates a new job with the specified pipeline configuration and optional input files. The job is placed into the queue and will be processed when resources are available. Inputs are organized by port name. The available ports depend on the pipeline — call Get Pipeline Schema first if you don’t know them. The two batch pipelines deployed on the platform today are:machine-state-classification— time-series sensor classification via an Omega encoder + KNN. Input ports:worker.inference(CSV files to classify),worker.n_shots(labeled CSV example files withmetadata.class). Output port:worker.results.activity-detection— Newton C language model over a JSONL prompt file. Input port:worker.data(one JSONL file, each line anInferenceRecord). Output port:worker.result.
Request
A human-readable name for the job
The type of pipeline to run. One of:
batch, trainingThe key identifying the pipeline to use from the registry (e.g.
machine-state-classification, activity-detection)Specific pipeline version to use. If omitted, the latest published version is used.
Input files organized by port name. Each key is a port name (see the pipeline schema) and the value is an array of input file objects:
file_id(string, required) — The file ID returned from the Files APImetadata(object) — Optional per-input metadata. For n-shot ports this carries the class label ({"class": "..."}).
Pipeline parameters organized by component name (e.g.
worker). Each value is an object with:parallelism(integer) — Number of parallel workers for this componentconfig(object) — Free-form configuration passed to the container. The accepted shape is defined by the pipeline’suser_config_schema— fetch it via Get Pipeline Schema.
Response
Unique job identifier (TypeID,
job_ prefix)Organization identifier
Job name
Pipeline type (
batch or training)Pipeline key
Pipeline version used
Initial job status (typically
PENDING)Resolved job parameters (user-supplied values merged onto the pipeline’s
default_config)Number of times the job has been retried (always
0 on create)Number of times the job has been preempted (always
0 on create)Position in the queue at admission time. Omitted from the response when not queued (e.g. terminal-state jobs).
Total queue depth at admission time. Omitted from the response when not queued.
Per-status counts of tracked inputs (
pending, processing, completed, failed). Omitted from this response — populated only on read paths like GET /batch/jobs and GET /batch/jobs/{id}.Creation timestamp in RFC 3339 format
Last update timestamp
Start timestamp, or
null if not yet startedCompletion timestamp, or
nullFailure timestamp, or
nullCancellation timestamp, or
nullError details, or
nullExamples
The two batch pipelines deployed on the platform take very different request bodies. Switch tabs to compare.- machine-state-classification
- activity-detection
Classify time-series sensor data using n-shot example files. Inputs split across two ports — Response — See the
worker.inference for the CSVs to classify and worker.n_shots for the labeled example files (class declared via metadata.class).201 Creatednewton-machine-state-batch skill for model selection (omega_1_4_base vs the legacy 1.3 variants), window_size / step_size guidance at high sample rates, and the within-distribution vs cross-condition accuracy pitfall.Error responses
400 - Invalid Request
401 - Unauthorized