title: "How a Translation Is Produced",

summary:

"What happens between submitting an informal requirement and receiving a formal specification: the settings that shape it, which model runs it, and what gets saved.",

category: "core-translation-engine",

tags: [

"translation-pipeline",

"model-selection",

"bring-your-own-key",

"history",

],

lastReviewed: "2026-09-10",

};

How a Translation Is Produced

When you submit a requirement, DevSpeak turns it into a formal, audience-specific document. This page explains what happens in between — enough to predict the behavior and troubleshoot it, without needing to know how it is built.

What This Page Covers

  • Which of your settings change the result, and how.
  • Which model runs your translation, and how to control that choice.
  • What is saved afterward, and what that enables.
  • What Shapes the Result

    Five inputs determine the document you get back. Everything else is fixed.

    1. Your text — the informal requirement, note, or draft you submit.

    2. Output format — technical specification, Jira tickets, API design, RFC, data model, or prompt.

    3. Audience — junior developer, senior developer, tech lead, SRE, or data engineer. This is the setting that most changes the result: the same requirement written for an SRE leads with failure modes, and for a junior developer leads with sequenced steps.

    4. Technical context — backend, frontend, mobile, data/ML, or DevOps.

    5. Tone — a slider from concise to detailed. Below the midpoint you get a tightened rewrite; above it you get a full document with sections and headings. The change at the midpoint is deliberate and noticeable, so if the output length is not what you expected, check this first.

    On paid plans, custom instructions are appended as standing constraints — house terminology, formatting rules, or things to always include.

    Which Model Runs It

    By default, translations run on DevSpeak's own curated model selection. You do not need to configure anything, and DevSpeak handles availability on your behalf: if the model serving your request is unavailable, another one takes over rather than the request failing.

    You can override this in two ways:

  • Pick a model from the selector in the translation editor to use a specific one for the next generation. This is useful for reproducibility, and for comparing how two models handle the same requirement.
  • Connect your own provider key in Settings → Keys & Providers. Translations then run through your account with that provider.
  • When both apply, an explicit model choice wins. Selecting a model from the list always uses that model, even if you have a key connected — so when you want your own provider, select it explicitly from the same list.

    What Happens to Your Content

    Text translations are saved to your history with the input, the output, and the settings used, so you can reopen, export, or refine them later.

    Attachments are uploaded before the translation runs and stay linked to the record. When you reopen an old translation, its files are still reachable.

    Large documents are processed as a background job rather than a single request. You can leave the page and return: the job continues, and progress is reported while it runs.

    Related Pages

  • [The Default Translation Flow](/docs/module-3-core-translation-engine/chapter-1-architecture/2-default-translation-flow)
  • [Latency Expectations](/docs/module-3-core-translation-engine/chapter-1-architecture/4-latency-expectations)