agents.language-copy-check·version 1.0.0·draft1 to verify
Check customer-facing copy in the target language
The changed copy has passed the language gate — mechanical, terminology and meaning checks — and every blocking finding is decided before publication.
When to use
Customer-facing copy in the target language has changed and must be checked before it is seen. Not for writing the copy in the first place — that belongs to growth.launch-website or growth.newsletter. Not for a contract or NDA translated for signature — that is documents.translate-contract, where the standard is legal equivalence, not marketing style. Not for a customer review or support reply already sent — that is growth.customer-reviews or support.answer-ticket.
Before you start
- The source of truth is known — the file or record a future build reads. Checking a screenshot is not a check.
- The glossary exists (even five lines). Without it, S3 has nothing to check against.
- The target language is named. This playbook ships with the LV ruleset; each added language brings its own ruleset and terminology source.
What a run requires1
- Approval · S6 · ownerthe run stops until a named person records the decision
Any step can wait until a date and reopens by itself; every closed step leaves evidence (a note, a link, a number).
The trail8 steps
Scope the runagent
List the changed texts, their sources, the target language and where each will appear.
Done when the run lists every text with its source location and publication channel.
Mechanical passagent
Run the language gate: diacritics present and correct, encoding clean (UTF-8), quotes and dashes as the brand uses them, spacing, obvious spelling.
Done when a mechanical findings list exists, each with an exact location (file + line or CMS field).
Terminology passagent
Check domain terms against the company glossary; for terms the glossary does not cover, check the official terminology source. Flag any term that also appears in a signed contract or invoice template.
Done when every flagged term has a verdict: matches glossary · proposed new term · conflict with contract wording.
Grammar and style passagent
Apply the target-language ruleset: agreement, case government, punctuation, register appropriate to the channel. Classify every finding: mechanical · terminological · style · blocking.
Done when no finding is unclassified and blocking findings state why they block.
Back-check meaningagent
Compare the target text against the source text paragraph by paragraph: does it say the same thing — numbers, names, promises, conditions?
Done when each paragraph carries a same / changed verdict, and every "changed" is explained.
⛔ A "correction" that changes a number, a promise or a condition is never mechanical — it goes to S6.
Rule on blocking and disputed findingsownerneeds approval · owner
Approval · S6 · owner — the run stops until a named person records the decision
Present blocking findings and any agent correction the owner may disagree with, each with the agent's reasoning.
Done when every blocking finding has a decision: fix · accept as written.
⛔ "Accept as written" for a factual or contractual mismatch is not available to anyone — those are fixed.
Apply fixes in the sourceagent
Correct the source of truth, not the rendered page. Re-run the gate on the corrected source.
Done when the re-run returns zero mechanical findings and the source contains the accepted wording.
Record and hand backagent
Attach the findings report to the run; add newly approved terms to the glossary; send the owner a summary: texts checked, findings fixed, findings accepted, anything still open.
Done when the report is linked, the glossary is updated, and the summary is sent.
Checks — how we know it worked
- Re-run of the gate on the source returns zero mechanical findings (a clean run on the rendered page is not evidence).
- Diacritics and quotes render correctly in the browser or the actual channel, not only in the editor.
- Every term flagged in S3 matches the glossary or carries the owner's approval from S6.
- The S5 back-check has a verdict for every paragraph, including "same".
If it goes wrong
| Symptom | Response |
|---|---|
| Diacritics mangled (ā → aÌ„ etc.) | Encoding round-trip; restore from the source, re-export as UTF-8, re-run S2. Never hand-repair rendered text. |
| Owner rejects an agent correction | Record the owner's form in the glossary as the approved term so the gate stops flagging it; do not re-litigate per run. |
| Copy already published before the gate | Run the gate retroactively; if a blocking finding appears, open a fix task and correct the live copy the same day. |
| The gate is unavailable | Do the pass manually against the same ruleset, mark the run "manual" in the evidence, and note which checks a machine did not repeat. |
| Terminology conflicts with a signed contract | Do not change the contract wording in marketing copy silently; flag it and route to ops.contract-renewal-watch or the contract owner. |
What each step leaves behind
- S1the run lists every text with its source location and publication channel.
- S2a mechanical findings list exists, each with an exact location (file + line or CMS field).
- S3every flagged term has a verdict: matches glossary · proposed new term · conflict with contract wording.
- S4no finding is unclassified and blocking findings state why they block.
- S5each paragraph carries a same / changed verdict, and every "changed" is explained.
- S6every blocking finding has a decision: fix · accept as written.
- S7the re-run returns zero mechanical findings and the source contains the accepted wording.
- S8the report is linked, the glossary is updated, and the summary is sent.
Evidence to keep
The run id · the source text version checked · the findings report with verdicts · the S6 decisions (who, when) · the gate re-run output · the glossary diff.
How this playbook improves
After every 10 runs ask: how many findings were false positives the owner had to overturn — which rule produced them, and should it be relaxed? Did any finding reappear in a later run (a fix that never reached the source)? Did any blocking issue reach the public after publication? A new version changes the rule or the step that caused the false positive or the leak, and says so in its change note.
Obligātās sīkdatnes tur sarunu kopā. Analītika ir izslēgta, līdz tu atļauj — tā neliek nevienu sīkdatni un neglabā ierīces identifikatoru.Necessary storage keeps your conversation together. Analytics is off until you allow it — it sets no cookie and stores no device identifier. Ko mēs glabājamWhat we store