Configure the pipeline

Set which pipeline stages run, in two layers: a default on the engine, and an optional override on a single request.

You have decided which stages you want around the core translate step. Now there are two questions: where does that decision live, and what do you do when one job needs something different from the rest? The answer is two layers. The engine carries the default that every async job inherits. A pipelineConfig object on a single submission overrides that default for that submission only. Stages you leave out of the override inherit from the engine, so a request states only what differs.

New to the pipeline? Start with the Pipeline overview for what each stage does. This page is about turning them on and overriding them – not what they do once enabled.

Engine-level defaults#

Open the engine's Pipeline tab in the dashboard and toggle each stage independently. That configuration is the default for the engine: every async job routed to it runs with these stages unless a request overrides them. Set it once, and you do not restate the pipeline on every call.

Each stage is its own switch. You enable any combination – none of them, all of them, or anything between:

• Pre-localization AI edit – clean the source before translation.
• Post-localization human review – route to Internal or External review. You pick the mode, tier, and timeout in the same panel.
• Post-localization AI review – stays disabled until human review is enabled; it reconciles the human edit with your engine rules.
• Rephrase for natural copy – rewrite to read native. Independent of the other stages.
• Back-translation check – verify meaning survived the round trip. Independent of the other stages.

Core localization is not a switch – it always runs. The stages wrap around it.

The default is what every job inherits, so the engine config is the shape a pipelineConfig override is merged into. Each stage is one key:

{
  "preEdit": { "enabled": true },
  "humanEdit": {
    "enabled": true,
    "provider": "internal",
    "tier": "standard",
    "timeoutHours": 48
  },
  "postEdit": { "enabled": false },
  "rephrase": { "enabled": false },
  "backTranslation": { "enabled": true }
}

What each field controls – which review provider, which tier, how long the wait – is documented on the stage's own page. This page is about where the config lives and how the two layers combine.

Per-request override#

Most jobs should run the engine default. The exception is a single submission that needs a different pipeline – a one-off batch of marketing copy that wants the rephrase stage your engine normally leaves off, or a legal payload that should skip it. Editing the engine to handle one batch would change every other job too.

So you pass the difference on the request instead. Add a pipelineConfig object to the POST /jobs/localization body, and it overrides the engine default for that submission alone. Nothing on the engine changes; the next job without an override is back on the default.

{
  "sourceLocale": "en",
  "targetLocales": ["de", "fr"],
  "data": { "headline": "Ship in every language." },
  "pipelineConfig": {
    "rephrase": { "enabled": true },
    "backTranslation": { "enabled": false }
  }
}

This is the inheritance rule, and it is what keeps the override small: a stage you name is overridden; a stage you omit inherits the engine default. The request above turns rephrase on and backTranslation off for this one job. preEdit, humanEdit, and postEdit are not named, so they run exactly as the engine has them configured. You state only what differs.

Two more things the override does not do, stated plainly because this is the part that looks like it can do anything:

• It changes that submission only. It does not write back to the engine, so it is not how you make a lasting configuration change – that is the Pipeline tab. Use the override for the one-off; use the tab for the new normal.
• It does not relax a stage's own runtime rules. Post-localization AI review only runs when human review produced output, so enabling postEdit does nothing on a job that has no human stage to reconcile – whichever layer you enabled it on.

Confirm what ran#

Configuration sets which stages should run; the job's own record tells you which ones did. The job carries a steps[] array, and that array is how you confirm a per-request override actually took effect – not just that you sent it.

Reading those records – the stepId for each stage, what a skipped step means, where non-critical failures surface – is its own page.

Next steps#

You can set the default on the engine and override it on a request. From here, submit a job that carries an override, or read back the steps to confirm which stages ran.