Marco runs a four-person localization desk inside a mid-size language-service provider, and on a Tuesday morning he is doing the math that keeps him up at night. His Italian and Spanish post-editors clear roughly forty files a week between them, every file an LLM, a large language model and general text-prediction system, has already pre-translated before anyone opens it. The output is fast. The output is also, file by file, subtly inconsistent: one linguist's chat session knows to keep the client's approved term, the next session has forgotten it; one prompt told the model to flag uncertainty, the next prompt did not; one session converted dates to the target market, the next carried them through raw. Every linguist on his team has, in their own browser tab, a slightly different idea of what to tell the model, retyped from scratch on every job, half-remembered, never identical twice. The previous lesson taught Marco's people the four levers that turn a generic chatbot into a disciplined translation assistant: context, glossary, locale, and stay-faithful-plus-flag-uncertainty. Those levers worked. The problem is that they worked only as well as whoever happened to type them that morning, and a discipline that depends on a tired post-editor remembering to retype five paragraphs of instructions at 4 p.m. on a Friday is not a discipline. It is a hope. This lesson is about turning that hope into a fixture. It is about taking the four levers and welding them into a single reusable instruction the model obeys on every segment, every file, every session, without anyone having to remember: the localization system prompt.

What a System Prompt Actually Is, and Why It Is Different

Start with the definition, because the whole lesson turns on it. A system prompt is a standing instruction set given to the model that frames every subsequent message in a conversation, separate from and prior to the individual task you type. Where the prompt you type in the chat box is the request for this one segment ("translate the following"), the system prompt is the job description that governs all requests: who the model is, what rules it obeys, what it must never do, and how it must format what it returns. The chat message is "do this thing now." The system prompt is "here is how you do everything I will ever ask you in this role." The model reads the system prompt first, treats it as higher-priority standing context, and applies it to every per-task message that follows until the conversation ends or the system prompt is replaced.

The distinction is not academic, and it is worth making concrete with the way the tools actually expose it. In a chat application's "custom instructions" or "project instructions" field, in an API call's dedicated system role, in a CAT-tool, the computer-assisted-translation environment where a linguist edits target text segment by segment, plugin's configuration panel, you are writing once into a slot that persists. Everything you would otherwise retype on every single message now lives in that slot and applies automatically. The per-task prompt shrinks to the only thing that genuinely changes between segments: the source text itself. The standing rules, source-fidelity, the approved terminology, the locale conventions, the demand to flag uncertainty, stop being something a human has to remember and become a property of the conversation.

A per-task prompt asks the model to do one thing. A system prompt tells the model who it is and what rules govern every thing it does. One is the request; the other is the contract.

The Retyping Tax, and Why It Is Not Just Annoying

Consider what Marco's team pays without a system prompt, and notice that the cost is not mainly the typing. The cost is the variance. When the four levers live in a person's memory and get retyped per job, three failure modes show up with grim reliability. First, omission: the linguist forgets a lever, usually the one that matters most on the file in front of them, because tired people drop the abstract instruction ("flag uncertainty") long before they drop the concrete one ("translate this"). Second, drift: each retyping is a little different, so the same client's content gets translated under five subtly different rule sets across five linguists and five days, and the terminology, register, and locale handling wobble accordingly. Third, the silent gap: a new team member, or the same person on a new project, simply does not know what the standing rules are supposed to be, because the rules were never written down anywhere durable. They were folklore, passed mouth to mouth, decaying with every retelling.

A system prompt converts folklore into infrastructure. The rules become an artifact: written once, reviewed once, version-controlled, attached to a client or a content type, and applied identically whether the linguist clearing the file is the senior reviser or the freelancer onboarded last week. This is the same move the whole program makes everywhere else, turning "trust me, it looks fine" into a defensible, repeatable control. The system prompt is that move applied to the instructions themselves. It does for prompting what a termbase does for terminology and what an MQM (Multidimensional Quality Metrics) error typology does for evaluation: it takes a piece of professional judgment that was living unreliably in someone's head and pins it to a surface where it can be inspected, corrected, and trusted to be the same tomorrow.

System Prompt Versus Per-Task Prompt: Dividing the Labor

The most useful mental model is a division of labor between two layers. The system prompt holds everything that is stable across the work; the per-task prompt holds only what changes. Getting this division right is the difference between a system prompt that helps and one that fights you, so it is worth working through carefully with examples.

What belongs in the system prompt is the standing context that does not change from one segment to the next within a defined scope. The role the model plays. The language pair and the locale. The rules of fidelity. The behavior on uncertainty. The output format. The do-not-add and do-not-omit constraints. The glossary, if it is small and stable enough to live inline. None of these change when you move from segment 14 to segment 15 of the same file, so none of them should be retyped per segment. They are properties of the job, and the system prompt is where the job is defined.

What belongs in the per-task prompt is the genuinely variable material: the source segment or batch you want translated right now, and any segment-specific note that the standing rules cannot anticipate. "Here is segment 15." "This sentence appears as a button label, so keep it under 20 characters." "This paragraph is a heading; preserve the title case convention." The per-task prompt is small precisely because the system prompt is carrying the weight. If you find yourself retyping the same instruction in every per-task prompt, that is the signal that the instruction belongs in the system prompt instead.

The Scope Question: One Client, One Content Type, One Locale

A system prompt is only reusable to the extent its rules are actually constant, which forces a design decision: what is the scope of one system prompt? The answer that works in practice is to scope a system prompt to a stable combination of client, content type, and locale, the unit across which the rules genuinely do not change. A system prompt for "Acme medical device labelling, de-DE into en-US" is coherent: the register, the terminology, the locale conventions, and the fidelity demands are constant across every file of that kind. A system prompt for "all translation, any client, any language" is incoherent, because the rules that make medical labelling safe are wrong for a marketing tagline, and the locale rules for en-US are wrong for en-GB.

This means you maintain a small library of system prompts, not one universal prompt. One per client-and-content-type-and-locale combination that recurs often enough to be worth the artifact. This sounds like more work than it is. The prompts share most of their structure, differing only in the glossary block, the locale block, and the register line, so building the second is mostly copying the first and changing three sections. The payoff is that each prompt is exactly right for its scope rather than vaguely right for everything, and vaguely right is the enemy in high-consequence content.

Scope a system prompt to the unit across which the rules are actually constant: a client, a content type, and a locale. One universal prompt is one prompt that is wrong for almost everything.

The Anatomy of a Strong Localization System Prompt

A strong localization system prompt is not a paragraph of good intentions. It is a structured document with named sections, each doing one job, ordered so the most important constraints are stated clearly and the model cannot miss them. There are seven load-bearing components, and the rest of this lesson builds each one, then assembles them into a single worked example you can adapt. Learn the anatomy first; the example will then read like a body you understand rather than a wall of text.

• Role. Who the model is. "You are a translation assistant for regulated medical device labelling, working de-DE into en-US." The role primes the model's whole posture: register, caution level, and the neighborhood of its training it draws from.
• Fidelity constraints. The rules of accuracy: translate exactly what is written, preserve every negation and number, do not improve, summarize, infer, or author. This is the spine, the instruction that fights the model's helpful-improver instinct.
• Glossary handling. How approved terms are treated: which mappings are mandatory, that synonyms are forbidden, and what to do when a source term is not in the glossary.
• Locale rules. The specific conventions of the target market: dates, numbers, units, currency, formality, spelling, and crucially which conversions to apply and which to leave alone.
• Uncertainty flagging. The behavior that turns the model from a confident liar into a useful assistant: when unsure, surface the doubt as a visible flag rather than burying it in fluent prose.
• Output format. The exact shape the model must return, so the result drops cleanly into the CAT tool or the TMS, the translation-management system, without manual reformatting.
• Do-not-add and do-not-omit. The explicit prohibition on inventing content the source does not contain and on dropping content the source does contain, the two halves of the most dangerous failure modes.

Notice that these map directly onto the four levers from the previous lesson, but harden them. Context becomes Role. Stay-faithful becomes Fidelity plus Do-not-add/omit. Glossary and Locale keep their names but become standing rules rather than per-job reminders. And uncertainty-flagging and output-format get promoted to first-class sections, because in a reusable artifact the behaviors that were nice-to-have in a one-off prompt become non-negotiable structure.

Role: The Model's Standing Posture

The role line is the first thing the model reads and the frame everything else hangs on. A vague role ("you are a helpful translation assistant") gives the model permission to be helpful, which on high-consequence content is exactly the permission you do not want it to have, because helpful and faithful pull in opposite directions when a source is ambiguous. A precise role narrows the model's posture before it sees a single segment.

Write the role to carry the domain, the language pair, the content type, and the stakes. "You are a translation assistant for regulated pharmaceutical labelling, translating from German (de-DE) into US English (en-US). The content is patient-facing and safety-critical: a mistranslation can cause a dosing error or a regulatory failure. Your job is to convey the source exactly, not to improve it." That is four sentences, and every one of them shifts the model's behavior. "Regulated" and "safety-critical" raise its caution. "Patient-facing" sets the register. "Convey, not improve" pre-empts the helpful-improver instinct before any source text triggers it. The role is small and it is doing enormous work, because it conditions every probability the model computes for everything that follows.

Fidelity: The Spine That Fights Fluency

Fidelity is the section that most directly serves the program's deepest principle: fluent is not correct. An LLM produces output that is fluent first and accurate second, and a fluent error does not trip your eye, which is exactly why it is the dangerous one. The fidelity section is your standing instruction against that tendency, and it must be explicit, because the model's default, rewarded by its training, is to be a willing improver that smooths an ambiguous source into a confident, specific target asserting more than the source said.

State the fidelity rules as hard, enumerated constraints, not as a gentle preference. "Translate the source exactly as written. Preserve every negation; a dropped 'not' inverts meaning and is a Critical error. Preserve every number, unit, dose, date, and proper noun precisely as in the source unless a locale rule explicitly requires reformatting. Do not add information the source does not contain. Do not omit information the source does contain. Do not narrow an open statement to a specific one, or broaden a specific one. Do not summarize, paraphrase for brevity, or improve the writing." Each clause closes a specific, documented failure mode: dropped negations, invented or altered numbers, the narrowing of "can be adjusted" into "can be increased." You are not insulting the model by spelling these out. You are naming the exact escape routes its training would otherwise take, and a named prohibition is far more effective than a general plea for accuracy.

Fidelity is not a tone you set; it is a list of named prohibitions. Preserve every negation, every number, every dose. Do not narrow, broaden, summarize, or improve. The model's default is to help; your job is to forbid the helpful error.

Glossary, Locale, and Flagging as Standing Rules

Three of the seven components, glossary handling, locale rules, and uncertainty flagging, deserve their own treatment, because turning them from per-job reminders into standing rules changes how you write them. A one-off prompt can say "use these terms." A system prompt has to anticipate the cases the linguist will not be there to handle in the moment, because the whole point is that the prompt runs without supervision on every segment.

Glossary Handling: Mandatory, Forbidden, and the Unknown-Term Rule

A glossary, also called a termbase, is the database of approved source-to-target term pairs a client requires used exactly, never paraphrased into a synonym the model "prefers." In a system prompt the glossary block does three things a per-task glossary often skips. It states the mappings as mandatory and exact. It names the forbidden alternatives explicitly, because closing the specific escape routes works better than a positive instruction alone. And, uniquely to the standing-rule context, it specifies what to do when a source term is not in the glossary, because over a long file the model will constantly hit terms the glossary does not cover, and you need a rule for that case that runs without you.

The unknown-term rule is the part people forget, and it matters. Without it, the model treats the absence of a term from the glossary as permission to choose freely and fluently, which reopens term drift for everything not explicitly pinned. With it, you tell the model: "For any source term not in the glossary above, use the most standard, conventional target-language equivalent for this domain, and if a term is technical and you are not confident of the standard equivalent, flag it for human terminology review rather than guessing." That single instruction connects the glossary section to the flagging section and turns an open hole into a routed query. The glossary handles what it knows; the unknown-term rule handles what it does not, by surfacing it instead of papering over it.

Locale Rules as a Standing Specification

A locale is a language paired with a region and its conventions, written as a code like de-DE, en-US, pt-BR, or fr-CA, and it governs dates, numbers, units, currency, formality, and spelling. In a system prompt the locale block becomes a standing specification: the exact conventions for the target market, stated once, applied to every segment. The discipline here is the same one the previous lesson established, locale conversion is a set of specific rules, not a vibe, and the consequences run in both directions. Failing to convert a date is an error; over-converting a clinical unit is a worse one.

So the standing locale block enumerates both the conversions to apply and the conversions to suppress. "Target locale en-US. Convert dates from source day-month-year to US month/day/year and write the month name in full to remove ambiguity. Use a period as the decimal separator and a comma as the thousands separator. Keep all clinical and dosing units in metric exactly as in the source; do not convert mg, mL, or kg to imperial units. Use US spelling. Use a formal, directive register appropriate for patient-facing regulated content; avoid contractions." The instruction to keep clinical units in metric is not optional politeness; it is the guardrail against the catastrophic, unrequested transformation of a dose. The standing locale block is where you encode, once, every locale decision you would otherwise have to remember on every file, including the decisions about restraint.

Uncertainty Flagging as Default Behavior

Uncertainty flagging is the behavior that most repays being made standing rather than occasional, because it is the single most valuable thing the model can do for a post-editor and the easiest thing to forget to ask for. The instruction tells the model that when it is uncertain, when a source is ambiguous, when a term could reasonably translate more than one way and the choice affects meaning, when it cannot confirm a number or a reference, it must not silently pick one option and render it in confident prose. It must translate as faithfully as it can and attach a visible, structured flag that names the ambiguity and its reasoning, so a human reviewer can resolve it in seconds.

Made standing, this behavior converts the model's most dangerous tendency into its most useful one. The unprompted model hides uncertainty inside fluency, producing the silent critical error: a confident, grammatical sentence that is wrong in a way that reads perfectly and that a tired eye skims past. The flagging model surfaces that same uncertainty as a query. It has not become more accurate at translation; it has become honest about the limits of what it can determine, which is exactly the behavior a junior translator should have and exactly the routing that makes an AI-assisted workflow both fast and safe. In a system prompt you specify the flag's format, too, so the flags are machine-findable: "Mark any uncertainty with a bracketed note in the form [FLAG: reason], placed immediately after the affected text." Now the post-editor can scan a whole file for [FLAG: and find every segment the model itself doubted, which is the highest-signal triage list in the workflow.

Made a standing rule, uncertainty flagging turns the model's worst habit, hiding doubt inside fluent prose, into its best one: a scannable list of exactly the segments a human must adjudicate.

Output Format and the Do-Not Rules

The last two components, output format and the do-not-add/do-not-omit prohibitions, are the ones a beginner is most tempted to skip and a professional never does, because they are what make the prompt's output usable and safe at scale.

Output Format So It Drops Into the Tool

Output format matters because the translation does not live in the chat window; it has to go back into a CAT tool or a TMS, segment-aligned, tags intact, flags separated from translated text. If the model returns a chatty paragraph with the translation embedded in commentary, a human has to clean it up, and that cleanup erases part of the speed the engine was supposed to buy. The output-format section tells the model exactly how to shape its return so it drops in without handwork.

What "exact shape" means depends on the workflow, and a later lesson in this chapter goes deep on structured output for CAT and TMS. For the system prompt, the principle is to specify the structure unambiguously and demand nothing else: "Return only the translated text and any flags. Do not include explanations, preambles, or commentary outside the specified format. If you are given numbered segments, return the same numbers with the translation for each. Preserve all placeholder tokens and markup tags exactly as they appear in the source, in the same positions; never translate, reorder, or delete a placeholder or tag." That last clause is doing critical engineering work, because an LLM left alone will cheerfully translate the inside of a code placeholder or drop a formatting tag, breaking the string when it hits the build. The output-format section is where you make the model's return both human-clean and machine-safe.

Do-Not-Add and Do-Not-Omit: The Two Halves of the Worst Errors

The do-not-add and do-not-omit rules overlap with fidelity but deserve their own named section because they target the two specific failure modes that cause the most catastrophic shipped errors, and naming them separately makes the prohibition impossible to miss. Do-not-add forbids hallucination: the model inventing a clause, a number, a warning, or a qualification the source never contained, because its training found that addition statistically probable. On a drug label, an invented contraindication or an added dosing instruction is a fabrication that can harm a patient and that no amount of fluency excuses. Do-not-omit forbids the quieter, equally dangerous failure: the model dropping a clause, a condition, a negation, or a number the source did contain, because in a long or complex segment the model's compression instinct quietly discards material it judges redundant.

State them as flat prohibitions with the consequence attached, so the model weights them heavily. "Do not add any information, qualification, clause, or instruction that is not explicitly present in the source. Do not omit any information, condition, negation, number, or clause that is present in the source. The output must contain exactly what the source contains, no more and no less. If faithfully translating the source produces output that seems incomplete or odd, do not fix it; translate it faithfully and flag it." That final clause is the keystone: it forecloses the model's last escape route, the one where it notices an apparent problem in the source and helpfully repairs it, which is precisely how an unrequested change enters a regulated document. The model's job is to convey, not to author, and the do-not rules are where you say so in the bluntest possible terms.

The Fully Worked System Prompt, Annotated

Now assemble the seven components into one artifact. Below is a complete localization system prompt for Marco's recurring scenario, Acme insulin-pump labelling, de-DE into en-US, followed by an annotation of why each block is written the way it is. Read the prompt first as a whole, then read the annotations to see the anatomy you just learned doing its job. This is the kind of artifact you write once, review with your terminologist and your quality lead, version, and attach to the client-and-content-type-and-locale scope it serves.

The System Prompt

ROLE. You are a translation assistant for regulated medical device labelling, translating from German (de-DE) into US English (en-US). The content is patient-facing labelling and instructions for an insulin infusion pump. It is safety-critical: a mistranslation can cause a dosing error, a device misuse, or a regulatory failure. Your task is to convey the source exactly, never to improve, simplify, or expand it.

FIDELITY. Translate the source exactly as written. Preserve every negation precisely; a dropped or added negation inverts meaning and is a Critical error. Preserve every number, dose, unit, date, frequency, and proper noun exactly, except where a LOCALE rule below requires reformatting. Do not narrow an open statement to a specific one or broaden a specific one to a general one. Do not summarize, paraphrase for brevity, or improve the wording. Convey the source; do not author.

TERMINOLOGY (mandatory, exact, no synonyms). Use these approved equivalents every time the source term appears: 'Infusionsset' = 'infusion set' (never line, kit, tube, or device); 'Verstopfung' = 'occlusion' (never blockage or clog); 'Basalrate' = 'basal rate' (never base rate). For any source term not listed here, use the most standard conventional equivalent for medical-device labelling; if a technical term has no obvious standard equivalent, do not guess, flag it for terminology review.

LOCALE (en-US). Convert dates from source day-month-year to US month/day/year and spell the month name in full to remove ambiguity (03.06.2026 becomes June 3, 2026). Use a period as the decimal separator and a comma as the thousands separator. Keep all clinical and dosing units in metric exactly as in the source; never convert mg, mL, IU, or kg to imperial units. Use US spelling. Use a formal, directive, clinical register; avoid contractions.

UNCERTAINTY FLAGGING. When the source is ambiguous, when a term could reasonably translate more than one way and the choice affects meaning, or when you cannot confirm a number or reference, do not silently choose. Translate as faithfully as you can and add a flag in the form [FLAG: reason] immediately after the affected text, briefly stating the ambiguity and your reasoning so a human reviewer can resolve it.

OUTPUT FORMAT. Return only the translated text and any [FLAG: ...] notes. No preamble, no commentary, no explanation outside the flags. If segments are numbered, return the same numbers with each translation. Preserve every placeholder token and markup tag exactly as it appears in the source, in the same position; never translate, reorder, or delete a placeholder or a tag.

DO NOT ADD / DO NOT OMIT. Do not add any information, qualification, clause, warning, or instruction not explicitly present in the source. Do not omit any information, condition, negation, number, or clause present in the source. The output must contain exactly what the source contains, no more and no less. If a faithful translation seems incomplete or odd, do not fix it; translate it faithfully and flag it.

The Annotations: Why Each Block Reads That Way

On the role block. Every word is load-bearing. "Regulated" and "safety-critical" raise the model's caution before it sees a segment. "Patient-facing" fixes the register. "Convey the source, never to improve, simplify, or expand" pre-empts the helpful-improver instinct at the top, so it colors everything below. The role is deliberately narrow to one client's content type and one direction, because a narrow role is a precise posture and a broad role is a vague one.

On the fidelity block. Notice that negations and numbers get named specifically, not folded into a general "be accurate." That is because the documented failure modes, the dropped "nicht," the flipped dosage, the altered date, are specific, so the prohibitions are specific. "Convey; do not author" restates the role's posture as a fidelity rule, repetition that is deliberate, because the single most important instruction is worth stating more than once where the model will weight it.

On the terminology block. The forbidden alternatives are named ("never line, kit, tube, or device") because closing the escape routes beats a positive instruction alone. And the unknown-term rule is present, the clause most people omit, turning every out-of-glossary term from a free-choice hole into either a conventional rendering or a routed flag. Without that clause the glossary controls only the handful of terms it lists and leaves everything else to drift.

On the locale block. The date example is given inline so the model has a concrete pattern, not just an abstract rule. The "never convert to imperial" clause is the restraint guardrail: it prevents the catastrophic helpful conversion of a clinical unit. The block specifies both what to change and what to leave alone, because locale correctness runs in both directions.

On the flagging block. The flag's format is specified, [FLAG: reason], so flags are machine-scannable. A post-editor can search the whole file for "[FLAG:" and pull every segment the model itself doubted, the highest-signal triage list in the workflow. The block ties directly back to the terminology block's unknown-term rule and the fidelity block's ambiguity cases, so the three reinforce one another.

On the output-format block. "Return only the translated text and any flags" kills the chatty preamble that would otherwise require manual cleanup. The placeholder-and-tag clause is pure localization engineering: it stops the model from translating the inside of a code placeholder or dropping a markup tag, the failure that breaks a string at build time. Format is not cosmetic; it is what lets the output drop into the TMS without handwork.

On the do-not-add/do-not-omit block. It overlaps fidelity on purpose, because the two worst failure modes deserve a section the model cannot miss. The keystone is the last sentence: "if a faithful translation seems incomplete or odd, do not fix it, translate it faithfully and flag it." That closes the final escape route, the one where the model notices an apparent source problem and silently repairs it, which is exactly how an unrequested change enters a regulated document.

Operating the System Prompt in Real Work

An artifact this careful is only worth building if it is operated correctly, and there are four disciplines that separate a system prompt that holds from one that quietly fails.

The system prompt is not the quality gate. This is the line that separates a professional from someone who has learned a trick, and it carries straight over from the previous lesson. A strong system prompt makes good output dramatically more probable; it does not make it certain. The model remains a probability machine, not a rule engine, and "more probable" is not "guaranteed." It can still, despite a perfect standing prompt, drop a negation, drift a term, carry a wrong number, or ignore a flag instruction on a particular segment. The system prompt raises the floor across every file at once, which is exactly its value, but the post-editor still reads the output against the source segment, still checks the negation, the number, the date, and the term, and still owns the delivery. "The system prompt told it to" is no more an answer than "the engine wrote it" when a Critical error ships. Accountability stays human, always, with the person whose name is on the file.

Version it and review it like code. A system prompt is a controlled document. When the client updates an approved term, the glossary block changes, and that change should be made once, in the versioned prompt, and propagate to everyone, rather than being remembered ad hoc by whoever happens to know. Date the versions, note what changed, and have the terminologist and quality lead review changes to the terminology and fidelity sections, because a sloppy edit to a standing prompt is an error multiplied across every file it touches. The reusability that makes a system prompt powerful is the same property that makes a bad edit dangerous: it scales.

Test it before you trust it. Before a system prompt goes into production on a client's files, run it against a small set of segments with known-hard cases: a sentence with a negation, one with an ambiguous term, one with a date to convert, one with a clinical unit that must not convert, one with a placeholder, one out-of-glossary term. Confirm the prompt produces the right behavior on each, including the flags it should raise and the conversions it should and should not make. A system prompt that has not been tested against its own hard cases is an assumption, not a control.

Keep the per-task prompt thin. With the system prompt carrying the standing rules, resist the urge to restate them in the per-task message. The per-task prompt should be the source segment and nothing more, unless a segment genuinely needs a one-off note the standing rules cannot anticipate ("this string is a 20-character button label"). Restating the system prompt's rules per task reintroduces exactly the retyping, drift, and omission the system prompt was built to eliminate. The discipline is to trust the standing layer to do its job and let the per-task layer shrink to the one thing that actually changes.

A system prompt is infrastructure: version it, review it, test it against its own hard cases, and keep the per-task prompt thin. It raises the floor on every file at once, but it never moves the accountability off the human who signs the delivery.

What Marco Gains, Concretely

Return to Marco's desk and the variance that kept him up. With a small library of reviewed, versioned system prompts, one per recurring client-and-content-type-and-locale scope, his senior reviser and his week-old freelancer now clear files under identical standing rules. The approved term holds whether it is Tuesday or Friday, 9 a.m. or 4 p.m. The locale conversions happen the same way every time, including the clinical units that must not convert. Every file comes back with a scannable list of the model's own flags, so triage starts from a high-signal list instead of a cold read. The terminology lives in one place, so when the client changes a term, Marco changes it once. And none of this depends on a tired person remembering five paragraphs, because the five paragraphs are no longer in anyone's memory. They are in the artifact. The four levers stopped being folklore and became a fixture, which is the whole point: a discipline you can actually run a team on, file after file, is a discipline that has been written down where it cannot be forgotten.

Key Takeaways

• A system prompt is a standing instruction set that frames every message in a conversation, separate from and prior to the per-task prompt; the per-task prompt is the request for one segment ("translate this"), while the system prompt is the contract that governs every request (who the model is, what rules it obeys, how it formats output). Write the standing rules once into the system slot so they apply automatically and the per-task prompt shrinks to just the source text.
• Without a system prompt, the four levers live in human memory and get retyped per job, producing three failure modes: omission (the tired linguist drops the abstract instruction), drift (each retyping differs slightly), and the silent gap (a new person never learns the standing rules). A system prompt converts that folklore into versioned, reviewable infrastructure applied identically by everyone.
• Divide the labor: the system prompt holds everything stable across the work (role, fidelity, glossary, locale, flagging, output format, do-not rules); the per-task prompt holds only what changes (the source segment, and rare one-off notes). If you keep retyping an instruction per task, it belongs in the system prompt.
• Scope a system prompt to the unit across which the rules are genuinely constant: a client, a content type, and a locale. Maintain a small library of scoped prompts rather than one universal prompt, because the rules that make medical labelling safe are wrong for a marketing tagline, and en-US rules are wrong for en-GB.
• The seven load-bearing components are role, fidelity constraints, glossary handling, locale rules, uncertainty flagging, output format, and do-not-add/do-not-omit. They harden the four levers from the previous lesson into standing structure, with flagging and output format promoted to first-class sections.
• Standing-rule context changes how you write each block: the glossary needs an unknown-term rule (use the conventional equivalent or flag it) so out-of-glossary terms do not drift; the locale block must specify both conversions to apply and conversions to suppress (convert the date, never convert the clinical unit); and flagging must specify a machine-scannable format like [FLAG: reason] so a post-editor can pull every doubted segment at once.
• Output format makes the result usable (return only translation and flags, no preamble) and machine-safe (preserve every placeholder and tag exactly, in place); the do-not-add/do-not-omit block targets the two worst failure modes, hallucinated additions and silent omissions, with the keystone clause that even an odd-looking faithful translation must be flagged, not fixed.
• Operate it as infrastructure: the system prompt raises the floor on every file at once but is never the quality gate; version and review it like code; test it against its own hard cases (negation, ambiguity, date conversion, unit-that-must-not-convert, placeholder, out-of-glossary term) before trusting it; keep the per-task prompt thin; and remember that accountability for the shipped string stays with the human who signs the delivery, never with the prompt.