Workflows

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; a quality check or QE gate never re-scores it either. 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.

The workflow page is tabbed: Steps, System prompt, Add a step, and the prompt-authoring assistant, with the open tab kept in the address so a link lands on it. Step prompts, and the workflow's own system prompt text where the System prompt overrides feature is on, are read-only until you unlock that section. Apply saves and locks it again, Restore default prompt returns to the built-in text after asking, and an edit that was never applied is discarded after 30 minutes. Leaving the page with unapplied changes asks first. Step prompts can be changed by anyone who tunes workflows (admins, managers and linguists); a workflow's own system prompt text is for admins and managers. Every change is in the audit log.

Formality set on the customer, project or document reaches every translate step of a run, plain or workflow, segmented or full text, as one sentence in the style-guide block of the prompt. The register a run used, and where it came from, is recorded on the run.

A workflow that belongs to a different customer than the document is refused on every surface, before any run is created; only a global workflow or one of the document's own customer runs. Re-running a batch refuses an archived workflow or project, the same way a new run does.

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

The QE gate and auto-fix#

A Translate step can score its own output. Open the step, and under Options tick QE routing gate, set the QE threshold (0 to 100, default 70), and choose the QE judge engine. Left on its default, the step reuses its own engine as an LLM judge. Pick a quality judge instead, hosted Jev or a Jev-compatible server you run, and each segment is scored by that typed judge. A Translate step with its QE gate on is a gate-producing step, so it can carry a branch just like a Check step.

With a Jev judge, each segment gets one of four outcomes:

• Pass: the score is at or above the threshold and the judge was sure of every dimension. The segment carries on.
• Fail: the score is below the threshold. The segment goes to review, or first to auto-fix when the step has it on. When the judge was unsure about any dimension, auto-fix runs only if a dimension it was sure of has a major error; otherwise the segment goes to review without a rewrite.
• Undecided: the score is high enough, but the judge was unsure about at least one dimension. The segment is neither passed nor failed: it carries on unchanged as machine output, is counted as QE skipped, and shows a QE undecided badge in the editor, so reviewers can find it by that badge. It is not sent to review; add a Review step if these segments must be seen by a person.
• Not scored: the judge could not score it, for example because it was unreachable, the spend cap was reached, or it was unsure and found no error it was sure of (low confidence). The segment carries on without a score and the run counts it as QE skipped.

Auto-fix failures

On a Translate step whose QE judge is a Jev judge, an Auto-fix failures option appears under the judge picker. It is off until you tick it. When it is on, a segment that fails the gate is handed to an LLM post-editor, which sees the source, every version so far and each of the judge's scores, and writes a new version. The same judge re-scores it, and the loop repeats up to the round limit. The settings:

• Post-editor: the LLM that rewrites the segment. Same as this step uses the step's own engine. It must be an LLM: a machine-translation engine or a judge cannot post-edit and is refused, and a step whose own engine is machine translation must name an LLM post-editor before it can be saved. Auto-fix never switches engines on its own.
• Max rounds: whole numbers 1 to 5, default 3. Blank uses 3; anything else, including a number outside 1 to 5, is refused when you save, not clamped.
• Cross-check each version with the post-editor: optional. The post-editor also gives its own score for each version, shown to it as a second opinion.

What happens next:

• A rewrite that passes the gate replaces the text, and the segment passes.
• If no rewrite passes, the best rewrite the judge was sure of that scores strictly higher than the original replaces the text for the reviewer, and the segment still goes to review. Otherwise the original text stays and the segment goes to review.
• A failing segment with an unsure dimension goes to review as it is unless a dimension the judge was sure of has a major error. If one does, auto-fix still runs on those errors; the unsure dimensions are left unchanged and flagged for review, and a kept rewrite cannot pass while they stay unsure. A rewrite that comes back unsure also stops the loop, and the segment goes to review. The segment's auto-fix skipped badge opens to show the reason.
• Every rewrite must pass the same checks as normal output, such as refusals, inline tags, and glossary and do-not-translate terms, or it is rejected. A post-editor reply identical to the previous version ends the loop without another judge call.

The reviewer sees the history. In the editor, a segment auto-fix repaired carries an auto-fixed in N rounds badge, and one it could not repair carries auto-fix tried N rounds; either way every round's score and text can be opened from the badge. While the LLM Ledger is on, every post-editor and judge call lands in it with its round number, and its cost counts toward the step.

Cost follows the engines you choose. A loop that can cost money, because the judge is hosted Jev or the post-editor is a paid LLM, does not start once the monthly spend cap is reached and stops between rounds when it is reached. A fully local loop, a judge you run such as SemIf with a local LLM post-editor, costs nothing and keeps running.

workflow edit-step 12 3 --qe-gate --qe-provider engine:7 --qe-autofix \
  --qe-autofix-provider local --qe-autofix-max-rounds 3 --qe-autofix-cross-check

The same flags work on workflow add-step; on workflow edit-step, --no-qe-autofix turns auto-fix off again. Over the API and MCP they are the step's qe_autofix, qe_autofix_provider, qe_autofix_max_rounds and qe_autofix_cross_check fields.

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.
• Quality judges: a Translate step's QE gate can be scored by hosted Jev or a Jev-compatible server you run, which also unlocks auto-fix.
• 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#