Docs · Features

Workflows

A workflow is a recipe: an ordered list of steps a document runs through, from translation to automated quality checks to human review, in the same order every time.

What it does#

A workflow belongs to one source language and one target language; a multilingual family is the same recipe copied per target, resolved automatically at run time so one workflow can cover every language you ship. It is built from five kinds of step: Translate, where a model writes the translation; Check, where a model judge scores it against a pass threshold you set; Review, where a person approves it; TM match, which pre-fills and locks qualifying translation-memory hits before any model runs; and External, which dispatches the packaged text to a linked vendor and pauses the run until it returns.

The smallest useful workflow is one Translate step. A common, more complete shape is: translate, check the result, fix anything flagged only if the check failed, and check again, branching back to the fix step on failure and forward to the end on success. That shape is deliberate: the fix step runs only when the first check failed, so a translation that was already fine is never rewritten, and a bounded number of visits keeps the loop from running forever.

Two kinds of content are protected from every machine step in a run, regardless of how the workflow is built. A segment a person has approved or edited is authoritative: no translate, fix, or re-run step will touch its text or reset its status, and it is excluded from every model call up front, not just refused afterward. An edit you make during a paused human-review step becomes protected the same way from the next run onward. And a segment a TM match step hard-locks, meaning a perfect memory match was applied under the stricter locking policy, is excluded from every translate step and refused at the point translated text is written back, so it stays exactly as it is.

Getting started#

If you are not sure what steps you need, describe what you want in plain language and review the drafted workflow before confirming it; nothing is created until you press confirm, and the same validation the manual builder uses runs on your draft. Otherwise, build one by hand:

  1. Create a workflow for a source and target language pair.
  2. Add steps in order: at minimum a Translate step with a prompt that references the source text.
  3. Run it over a document, and open the run view to see each step's score, gate, and cost.
workflow create --name "Help articles" --scope global
workflow add-step 1 --type llm_agent --prompt "Translate: {text}"
workflow run 42 1 de-DE
workflow show-run 108 --findings

Works with#

  • Memories: active memories for a run's customer are injected into Translate steps' prompts automatically, with no wiring required.
  • Glossary: a Translate step can pin one approved glossary for its language pair, and its terms are enforced after translation.
  • TM: a Translate step can show the model similar past translations, and a TM match step pre-fills and locks perfect matches before translation runs.
  • Vendors: an External step dispatches packaged text to a linked vendor and pauses the run until a signed return arrives.
  • Engines: every Translate and Check step resolves an engine, its own or the run's default, and a step pointed at a dead or unconfigured engine is refused rather than silently faked.
  • Documents: a workflow always runs over a document and one of its target languages, and the run's output lands on that document's segments.

Current limits#

Current limits

A branch can only target a step that appears earlier in the list; there are no forward jumps. To build a loop, place the check after the step you want to re-run and point its failure branch back at it.

A drafted workflow that would need a branch to a later step drops that branch at draft time and shows a warning, rather than silently accepting something that could not run. Editing a step re-validates the whole workflow, so a change that looks fine in isolation can still be refused because of what it would do to a later branch; the refusal names the step and the reason.

When two Check steps run in parallel, only one of them may carry the branch. The other lane's score is still recorded and can still be used in a condition.

Loops are bounded: a step has a maximum number of visits, and a run has an absolute total-step cap, so hitting either ceiling ends the loop gracefully rather than running indefinitely.

A long run started from the CLI executes synchronously inside that request; the web path enqueues it as a background job instead.