Skip to content
Euler Docs

Pipeline settings

Pipeline settings is where a team decides what a run produces and what it costs. Every annotation layer has a mode, optional per-layer configuration, and a model where the layer resolves through a selectable registry surface. A preset sets every mode at once, and the panel shows the cost of the current selection before you spend anything.

A project that never opens this screen behaves exactly as it did before the screen existed. Defaults are computed, not blank.

Layer modes

Each layer is in one of three modes.

ModeWhat it means
in_runThe layer executes inside the pipeline run. Its output is there when the run finishes, and its cost is part of the run’s cost.
on_demandThe layer does not run automatically. It stays reachable afterwards through its annotation job or its per-episode endpoint.
offThe layer never spends. Enqueuing it returns 409 with a message naming the setting to change.

Applicability gates on top of the mode and always wins. A layer whose data kind cannot carry it is reported as inapplicable whatever mode is stored, and it never spends.

Two guards protect stored settings from going stale:

How a mode is resolved

The effective mode for a layer is resolved on every read, in this order, most specific first:

project settings  >  workspace settings  >  computed use-case default

The computed default is not a constant. It is derived from the workspace’s use case and the project’s target profile so that it reproduces the platform’s behaviour before per-layer settings existed:

A layer that is catalogued but not servable yet is pinned to off whatever is stored, so a stale setting can never queue work the platform cannot do. The 3D representation layer is in that state today; see the layer catalog.

Read the resolved state, including what is stored at each level:

curl -fsS -H "Authorization: Bearer $EULER_TOKEN" \
  "$EULER_BASE_URL/v1/projects/$PROJECT/annotation/settings"

The response carries the full catalog resolved for the project: effective mode per layer, the model options with their adoption evidence, per-kind applicability with the reason when a layer does not apply, the preset list, and the cost preview. workspace_modes and project_modes show what is actually stored at each level; empty means inherit.

Setting modes

Write project-level overrides with PUT. Every part of the body is optional: omitting a field leaves it untouched, and an empty object clears it back to inherit.

curl -fsS -X PUT -H "Authorization: Bearer $EULER_TOKEN" \
  -H "Content-Type: application/json" \
  "$EULER_BASE_URL/v1/projects/$PROJECT/annotation/settings" \
  -d '{
        "modes": {
          "depth": "on_demand",
          "optical_flow": "off",
          "hand_pose": "in_run"
        }
      }'

Workspace defaults, which every project without its own override inherits, are written separately:

curl -fsS -X PUT -H "Authorization: Bearer $EULER_TOKEN" \
  -H "Content-Type: application/json" \
  "$EULER_BASE_URL/v1/workspaces/$WORKSPACE/annotation/settings" \
  -d '{"modes": {"captions": "in_run", "metadata": "in_run"}}'

Both writes need the engineer role and are audited as a policy change.

Presets

A preset is a one-click bundle of per-layer modes for a use-case shape. Apply one by id; layers the preset does not name fall back to their catalog default. Explicit modes in the same request win on top of the preset.

PresetWhat it turns onWritten for
readiness-onlyMeasure and certify. No annotation spend beyond captions.Any workspace
manipulation-qcCaptions, objects, segments and metadata in-run; the heavy lanes on demand.Manipulation, humanoid and mobile work on teleoperated data
egocentric-fullThe full first-person stack: hands, dense text, captions, objects, segments and metadata in-run; body pose, tracks, segmentation, depth and flow on demand.Egocentric annotation on first-person capture
drive-log-liteDetection first: objects, captions and metadata in-run; tracks, segmentation, depth and flow on demand.Driving perception on drive logs
world-modelGeometry first: depth, flow and segmentation in-run, with captions and metadata for search and 3D on demand.Spatial, aerial, manipulation and humanoid work
everythingEvery applicable layer in the run. The full demonstration of what Euler produces.Any workspace

Presets are scoped to the work you are doing. The panel only offers the presets written for your workspace’s use case, because a drive-log bundle on a teleoperation project reads as a product that does not know what you ingested. A preset whose in-run layers cannot apply to anything this project ingested is shown disabled, with the reason the layer does not apply.

The scope shapes the picker, not the API: applying any preset by id over HTTP still works, so an integration is never blocked by a scoping decision made for a screen.

curl -fsS -X PUT -H "Authorization: Bearer $EULER_TOKEN" \
  -H "Content-Type: application/json" \
  "$EULER_BASE_URL/v1/projects/$PROJECT/annotation/settings" \
  -d '{"preset": "manipulation-qc"}'

Per-layer configuration

Beyond the mode, each layer exposes typed knobs. Send them under config, keyed by layer id:

curl -fsS -X PUT -H "Authorization: Bearer $EULER_TOKEN" \
  -H "Content-Type: application/json" \
  "$EULER_BASE_URL/v1/projects/$PROJECT/annotation/settings" \
  -d '{
        "config": {
          "object_labels": {
            "ontology_source": "manual",
            "classes": ["gripper", "cable", "connector"],
            "confidence_floor": 0.45,
            "masks": true
          },
          "dense_text": {"style": "chronological", "target_words": 180}
        }
      }'

Configuration resolves the same way modes do: catalog defaults, then workspace config, then project config. Submitted values are coerced against the layer’s schema rather than rejected: unknown keys are dropped, numbers are clamped to their range, and integer-stepped fields stay integral. A stale setting from an older catalog version can never break a run or lock a team out of the screen.

The full field list per layer, with types, ranges and plain-language help, is in the settings response and on the annotation layers page. Fields marked as cost-affecting in the response are the ones that move the estimate.

Choosing a model

Layers that resolve through a selectable registry surface accept a model choice:

curl -fsS -X PUT -H "Authorization: Bearer $EULER_TOKEN" \
  -H "Content-Type: application/json" \
  "$EULER_BASE_URL/v1/projects/$PROJECT/annotation/settings" \
  -d '{"models": {"detection": "google/owlv2-base-patch16-ensemble"}}'

Only vetted options are accepted. A surface that is not user-selectable, or a model outside that surface’s option list, returns 422. The option list and the benchmark evidence behind the active choice come from GET /v1/models.

Cost preview

The settings response carries a cost preview built from the layers currently set to in_run, their per-episode estimates, and the project’s episode count. It gives you the per-episode figure and the projected total for the current dataset before a run starts.

The same estimate is the pre-flight budget guard: enqueuing work whose estimate would breach the tenant’s weekly cap returns 402 rather than starting and failing partway. What is metered afterwards is the measured cost, not the estimate.

Read the tenant’s cap and rolling spend with GET /v1/budget and GET /v1/costs.

What actually ran

Settings describe intent. To see what landed, use the status view:

curl -fsS -H "Authorization: Bearer $EULER_TOKEN" \
  "$EULER_BASE_URL/v1/projects/$PROJECT/annotation/status"

Every layer reports one honest state: ran, partial, on_demand, off, inapplicable (with the reason) or planned, along with covered and applicable episode counts and whether it ran in the last run. For per-layer quality rather than presence, use GET /v1/projects/{id}/annotation/coverage.

Next