Master Art of Translation | The Retry and Idempotency Fidelity System — How Retry, Repeat, Resume, Replay and Deduplicate Preserve One Intended Action

How do you translate retry, repeat, resume, restart, replay, reprocess and deduplicate without causing a second payment, second submission or duplicated message? This guide explains retry translation, idempotency in localization, error-message wording and how to translate instructions after an interrupted operation. A fluent synonym is not enough: the target language must preserve whether the user wants the same intended action to finish or a new action to occur.

The hidden problem is an uncertain outcome. A screen can report a timeout even though the remote system accepted the first request. A translator who turns “try again” into “do it again” may change the reader’s assumption about what already happened. “Resume” may be safer than “restart”; “resend” may create another communication while “redeliver” may describe an existing message arriving again. The correct words depend on identity, state, effect and the evidence actually available.

For accurate software translation, multilingual user interfaces, API documentation, transactional workflows and technical manuals, use a repeatable method: identify the original operation; decide whether its outcome is known, unknown or partly known; distinguish a retry of one logical request from a deliberate new request; preserve limits, intervals, duplicate controls and verification; then test the target wording against a realistic failure. This chapter gives a practical translation-quality framework, original worked cases, diagnostic exercises and source-backed terminology rather than a one-word dictionary.

Quick answer: Retry means attempting the same intended operation again after difficulty, subject to its safety rules. Repeat can mean intentionally doing an action another time. Resume continues work from an interruption point where that capability exists. Restart begins a process again, and may or may not preserve existing work. Replay reintroduces a recorded input or event. Reprocess runs processing on designated material. Deduplicate detects or handles items considered the same under defined criteria. Idempotent describes a property of an operation: its intended effect after repeated identical requests equals the intended effect of one such request; it does not mean every request is safe to repeat.

This is the EDKSG-TRANS-MASTER-WORLD-1850 chapter. Its learning job is deliberately narrower than Change-Operation Fidelity: that earlier article distinguishes which update an instruction performs; this chapter asks what remains true when a request is attempted again, partially completed, acknowledged late or discovered to be a duplicate. Return to Master Art of Translation | The Complete System for Moving Meaning Between Languages for the full route.

The problem before the dictionary: a result can be unknown even when a message is clear

Imagine pressing a button labelled “Send payment.” The interface waits, loses contact with the server, and displays “Connection lost.” This message describes communication, not financial truth. The payment may never have reached the server. It may have succeeded while the confirmation was lost. It may be waiting for a downstream processor. A sentence that declares it failed would overstate what is known; a sentence that declares it succeeded would make the opposite mistake. The translator must preserve the uncertainty, not resolve it by style.

Human readers often treat error text as permission to act. An ordinary “Please try again” is harmless for searching a catalogue but potentially costly when attached to a one-time transaction. A system may have a duplicate-prevention token; a workflow may require confirmation before another request; or the correct instruction may be to wait for verification. Localization is therefore a matter of operational truth and reader expectation. Language can become a control surface even when it is not executable code.

A second confusion is about where an event lives. A message can be sent once and delivered twice. A form can be submitted twice yet produce one accepted record. A job can start twice while its effect happens once. Conversely, the interface can display only one confirmation while the actual work occurred twice. One-to-one assumptions about clicks, requests, attempts, processing, commits, receipts and effects are unsafe. The chapter repeatedly separates those layers rather than treating their ordinary names as interchangeable.

Seven distinctions that every translation must keep intact

• The attempt and the operation. An attempt is a particular effort or transmission; the operation is the logical action the user intends. Several attempts may belong to one operation. A new operation can look textually identical to an earlier one. Translate messages so they preserve this difference.
• The original request and a fresh request. An original request may have a client-provided identifier. A later request with the same identifier may be interpreted as the same intended operation; a fresh identifier can indicate a new operation. This depends on the documented service contract.
• Communication success and business success. A successful network response does not always mean the requested real-world result is final. Likewise, a network timeout is not proof of business failure. Translate the stage named by the source, not an imagined finality.
• Delivery and processing. A delivered message may remain unprocessed. A re-delivered message may already have had its effect during the first attempt. The target must distinguish arrival, acknowledgment, application and downstream completion.
• Resume and restart. Resume depends on saved progress or a checkpoint. Restart may require starting from the first step; it might preserve a draft or erase volatile state. Neither word authorizes guessing the product’s actual behavior.
• Retry policy and retry permission. A technical platform may back off, limit attempts, reject retries or demand verification. Translate qualifiers such as ‘up to’, ‘only’, ‘after’, ‘if’, ‘when safe’, and ‘manually’. Removing them can alter the operational promise.
• Duplicate equality and semantic identity. Two requests with identical visible fields need not be the same intended purchase or task. Conversely, differently formatted events can represent the same logical action. Deduplication therefore needs an identity criterion, not visual similarity.

The technical idea behind idempotency, without the jargon barrier

The HTTP standard defines idempotency in terms of the intended effect of repeated identical requests. In HTTP, the standard names PUT, DELETE and safe methods as idempotent by their defined semantics. It does not say that every application side effect, log entry, billing event or API built on top of those methods is magically harmless. The practical translator should ask what exactly is promised by the specific operation and service. A button bearing the same label tells you nothing conclusive about this property.

A different technique uses a caller-provided request identifier: the client sends a unique identifier for one intended action and reuses it when safely retrying that action. The service can recognise a duplicate request even when the first response went missing. AWS documents why identical parameters alone can be insufficient for deciding whether a new request is a duplicate: a caller may genuinely want two otherwise identical resources. This is the reason terms such as ‘same request ID’, ‘new attempt’ and ‘new order’ matter in translation.

Message delivery adds another layer. Google Cloud’s Pub/Sub documentation describes scoped exactly-once delivery behavior for supported pull subscriptions, including acknowledgment requirements and limits. That is not a universal promise of exactly-once business effects: duplicate publishing, redelivery and downstream consumers still demand careful design. For translators the lesson is modest but important: never promote a narrow documented guarantee into a universal statement merely because the shorter wording sounds confident.

An operational meaning map for the translator

Source expression	Meaning that must survive	Dangerous paraphrase	Diagnostic
retry	Attempt the same logical operation again after an error, timeout, or other permitted condition.	Treating an identical-looking second attempt as a fresh business transaction.	Are we preserving the same request identity, and is another attempt authorized?
repeat	Perform an action another time; may create another legitimate instance.	Silently importing idempotency or failure recovery into a deliberate second action.	Is a new effect intended, or is this only another attempt to finish the first?
resume	Continue from an interruption point or saved checkpoint.	Promising preserved progress when the system starts over.	Which work is already saved and which step will run next?
restart	Start the process again from a defined beginning.	Telling the reader that an existing result will be preserved or erased without evidence.	Does the system reuse, reset, or discard earlier state?
replay	Feed a previously captured input, message, recording, or event through a process.	Implying that every replay reproduces actual external consequences, or that no consequences exist.	Does replay affect a simulation, log, queue, or live environment?
reprocess	Apply a process again to selected data or work items.	Suggesting new source data or entire-batch reruns when only failed entries are selected.	Which exact items are in scope?
resubmit	Send an application, form, command, or submission again.	Equating submission with acceptance or recording it twice without a warning.	Does the platform recognise the earlier submission?
redeliver	Deliver the same message or event again to a consumer or recipient.	Calling a redelivery a fresh publication or completed action.	Which identifier stays stable, and does the receiver know it was seen before?
deduplicate	Identify and handle equivalent items under an explicit comparison rule.	Claiming every repeated-looking item should be deleted.	What is the identity key, and what remains after duplicates are handled?
acknowledge	Record or signal that a delivery, message, or stage was received or accepted under a protocol.	Treating receipt as proof of business completion.	What exactly does this acknowledgment confirm?
reconcile	Compare uncertain or inconsistent views to establish the actual state.	Replacing an audit with another attempt to do the action.	Which system of record can resolve the uncertainty?
back off	Wait according to a retry delay policy before further attempts.	Presenting the wait as an indefinite stop or guaranteed completion time.	What are the delay, maximum attempts, and possible escalation?
continue	Proceed with remaining work; depending on context, may skip completed items.	Turning continuation into restarting all items.	Which stage and items are already complete?
abort	Stop a pending operation or attempt according to the system’s actual capability.	Implying that past committed effects are undone.	Does the stop affect only future work or also committed results?
recover	Restore useful functioning or state after a failure; the mechanism varies.	Replacing the specific promise with an unsupported assertion of full rollback.	Is restoration, reconstruction or continuation actually available?
ignore duplicate	Recognise a repeat as representing an already-handled logical request, then avoid another protected effect.	Dropping any superficially similar new request.	Which evidence establishes that the request is genuinely the same?

The thirty-pass translation and review method

1. Establish the genre. Decide whether the source is a user-facing button, customer notice, operator runbook, protocol specification, API reference, error log or training example. A short button label has a different evidence burden from a legal or financial instruction.
2. Locate the actor. Identify who acts: user, client library, server, queue, worker, editor, operator, or automated scheduler. The passive voice can conceal the actor; the target should not assign responsibility to an unmentioned party.
3. Locate the object. Name the form, transaction, message, order, record, job, or file that the operation concerns. A word such as ‘again’ is uninterpretable without an object.
4. Recover the initial intention. Ask what the first request was supposed to accomplish. Two identical payloads may mean one interrupted action or two distinct desired outcomes.
5. Separate request from attempt. Note whether the documentation describes a new send attempt of a stable request or the creation of another request. Identity boundaries determine the safe wording.
6. Identify evidence of earlier execution. Determine whether the source says the operation definitely failed, definitely succeeded, or has an unknown outcome. Do not translate silence as a negative result.
7. Record the idempotency contract. Look for a documented guarantee concerning duplicate calls. Do not infer it from an HTTP verb, a visual spinner, or a familiar product term without checking context.
8. Preserve the identity token. If the source mentions a request ID, transaction ID, event ID or client token, keep it unchanged where it is machine-readable and explain its role in natural language.
9. Preserve scope. Determine whether the command applies to one item, failed items, an entire batch, a whole process, or a historical event. A missing scope restriction is often the most damaging error.
10. Preserve sequence. Translate ordering requirements explicitly. An acknowledgment before processing may have a different meaning from acknowledgment after durable processing.
11. Preserve time. Keep wait intervals, deadlines, expiration times, time zones and timeouts distinct. ‘After five seconds’ is not ‘within five seconds’.
12. Preserve count. Check ‘once’, ‘at most once’, ‘at least once’, ‘up to three attempts’ and ‘three additional attempts’. These are not equivalent quantitative claims.
13. Preserve conditionality. Keep ‘if the result is unknown’, ‘only when safe’, ‘unless already completed’ and ‘until confirmed’ attached to the correct action.
14. Track prior side effects. Ask whether a payment, notification, deletion, reservation or external API call may have committed already. A retry message should not promise to reverse an action.
15. Disambiguate resume versus restart. Search for a checkpoint or saved draft, then decide whether the target wording should promise continuation, a fresh start or an uncertain state.
16. Disambiguate replay versus execution. Distinguish audit replay, media playback, simulation, event re-ingestion and live operation. Translate an event-log action without promising a real-world re-enactment.
17. Check duplicate equivalence. Identify whether duplicates are determined by an ID, content hash, time window, business key or application-specific rule. Do not replace the criterion with ‘same-looking data’.
18. Preserve acknowledgment stages. Separate received, accepted, queued, processed, committed, settled and reconciled. Each stage changes what the reader may reasonably believe.
19. Respect no-retry warnings. Retain explicit prohibitions. When the source says the operation is not safe to retry, softening that into ‘retry carefully’ changes the rule.
20. Respect retry ceilings. Retain maximum attempts and backoff behavior, and do not invent a fixed schedule when the source says exponential or variable delay.
21. Protect nontranslatable tokens. Preserve identifiers, placeholders, API endpoints, codes and structured keys. Localize explanatory text without changing executable data.
22. Check tense and aspect. A completed verb, ongoing progressive, conditional future or modal possibility can alter the known state. Compare whether ‘has been sent’ differs from ‘is being sent’.
23. Check agency and responsibility. Some notices command the reader; others describe automatic system behavior. Changing ‘The system retries’ into ‘Try again’ shifts an operational duty.
24. Check negative polarity. Make sure ‘do not retry’, ‘not yet processed’, ‘no duplicate charge’ and ‘duplicate prevention not available’ retain their exact negative scope.
25. Check interface fit. Test the translation where it will appear. If a label must be short, shorten the explanation elsewhere, not the safety condition that determines what users do.
26. Test a known-failure case. Simulate an attempt that definitely never reached the server. Does the target correctly describe an authorized attempt to recover?
27. Test an uncertain-commit case. Simulate a successful server action with a lost response. Would a reasonable reader interpret the translation as permission to duplicate an effect?
28. Test a legitimate second action. Simulate a user who actually wants a second identical purchase or task. Does the target mistakenly block it as a duplicate?
29. Test partial completion. Simulate a batch with some succeeded items. Does the translated wording preserve which items can resume, retry, skip or be audited?
30. Verify independent evidence. Review UI behavior, system specifications and examples with a domain reviewer. If the design does not reveal the effect, record uncertainty and escalate rather than invent.

From the principle to practice: a diagnostic atlas of retry language

The following environments are teaching cases, not claims about a named service’s live implementation. Every case distinguishes a source phrase, a likely mistranslation, a precise correction and a test of the target reader’s understanding. The point is to learn the decision, not memorize a single English word as a universal equivalent. Where actual software behavior is unspecified, the safest translation preserves that limitation and requests confirmation.

Worked domain 1: Card checkout — preserving the intended effect

In card checkout, the buyer intends one intended charge. The operative object is payment request, connected with purchase authorization. This is not merely a vocabulary exercise: authorization may exist even when the page lacks a receipt. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is two charges for one purchase. The available check is payment provider status and merchant ledger, while the relevant identity signal is merchant reference and payment attempt identifier.

The important counterexample is a buyer intentionally ordering an additional identical item. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to show an order-status check before enabling another charge. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

1.1 Retry the original request

Suppose the buyer reports a missing confirmation after initiating purchase authorization. A later screen has no reliable final status.

Source wording: “Retry the original request after the connection error.” Unsafe paraphrase: “Perform a second new action.” What must survive: another attempt to complete the same logical request, not authorization to create an additional independent result. In this workflow the protected outcome is one intended charge, and the error to prevent is two charges for one purchase. The decisive evidence is whether the earlier request’s result is unknown or confirmed, and whether stable request identity is supported, interpreted alongside merchant reference and payment attempt identifier.

Translation decision: Treat the source as an instruction about payment request, not as a general invitation to create purchase authorization. Same-operation identity must be retained when the contract supports it. Show an order-status check before enabling another charge. Reader diagnostic: If the first attempt had already committed, would a second attempt be recognized as the same intention? For this case the reviewer should consult payment provider status and merchant ledger and compare it with the plausible independent second action: a buyer intentionally ordering an additional identical item.

1.4 Restart the process

Suppose one part of the workflow is complete while another stage is delayed. Authorization may exist even when the page lacks a receipt.

Source wording: “Restart the process from the beginning.” Unsafe paraphrase: “Continue where you left off.” What must survive: begin anew under the specified process rules, with state retention or reset described separately. In this workflow the protected outcome is one intended charge, and the error to prevent is two charges for one purchase. The decisive evidence is whether earlier records or effects remain after the restart, interpreted alongside merchant reference and payment attempt identifier.

Translation decision: Treat the source as an instruction about payment request, not as a general invitation to create purchase authorization. Do not imply that restarting automatically undoes committed real-world effects. Show an order-status check before enabling another charge. Reader diagnostic: Does the translation make clear what a new beginning means for existing work? For this case the reviewer should consult payment provider status and merchant ledger and compare it with the plausible independent second action: a buyer intentionally ordering an additional identical item.

1.7 Resubmit after verification

Suppose the buyer intentionally asks for another instance after the first purchase authorization was completed. This is a new decision, not necessarily a recovery.

Source wording: “Verify submission status before resubmitting.” Unsafe paraphrase: “Submit again immediately.” What must survive: a status check is a prerequisite, not an optional background suggestion. In this workflow the protected outcome is one intended charge, and the error to prevent is two charges for one purchase. The decisive evidence is the possibility that acceptance occurred even though the original response was lost, interpreted alongside merchant reference and payment attempt identifier.

Translation decision: Treat the source as an instruction about payment request, not as a general invitation to create purchase authorization. Verify against a trustworthy record before issuing a new submission. Show an order-status check before enabling another charge. Reader diagnostic: Can the reader tell that no second submission is permitted before the check? For this case the reviewer should consult payment provider status and merchant ledger and compare it with the plausible independent second action: a buyer intentionally ordering an additional identical item.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. Preserve the difference between being notified and having a verified result. An email, toast, push alert or status badge can arrive later than the underlying event. Localize the prose, not the opaque identifiers or protocol keys that the service uses to recognise an existing action.

1.10 Reconcile the uncertain result

Suppose an earlier payment request was accepted but its confirmation failed to reach the buyer. The first result might already exist.

Source wording: “Reconcile the operation status before attempting recovery.” Unsafe paraphrase: “Repeat the operation to check whether it works.” What must survive: compare authoritative evidence to establish what actually happened before choosing another action. In this workflow the protected outcome is one intended charge, and the error to prevent is two charges for one purchase. The decisive evidence is trustworthy records, timestamps and the known limits of their information, interpreted alongside merchant reference and payment attempt identifier.

Translation decision: Treat the source as an instruction about payment request, not as a general invitation to create purchase authorization. Reconciliation is an evidence-gathering step, not an invitation to trigger a second effect. Show an order-status check before enabling another charge. Reader diagnostic: Is the first action’s actual state checked before a new effect can occur? For this case the reviewer should consult payment provider status and merchant ledger and compare it with the plausible independent second action: a buyer intentionally ordering an additional identical item.

1.13 Continue the unfinished batch

Suppose the buyer reports a missing confirmation after initiating purchase authorization. A later screen has no reliable final status.

Source wording: “Continue with remaining work without rerunning completed entries.” Unsafe paraphrase: “Restart the entire operation.” What must survive: continue remaining items while preserving earlier successful results. In this workflow the protected outcome is one intended charge, and the error to prevent is two charges for one purchase. The decisive evidence is item-level progress, not a single misleading all-or-nothing batch label, interpreted alongside merchant reference and payment attempt identifier.

Translation decision: Treat the source as an instruction about payment request, not as a general invitation to create purchase authorization. Preserve the negative instruction against replaying completed entries. Show an order-status check before enabling another charge. Reader diagnostic: Could the reader name what stays completed and what still needs processing? For this case the reviewer should consult payment provider status and merchant ledger and compare it with the plausible independent second action: a buyer intentionally ordering an additional identical item.

Domain synthesis: The card checkout problem is solved only when the target distinguishes one intended charge from two charges for one purchase and can establish the correct result using payment provider status and merchant ledger. A deliberately new action, such as a buyer intentionally ordering an additional identical item, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 2: Travel reservation — preserving the intended effect

In travel reservation, the traveller intends a single reserved itinerary. The operative object is booking request, connected with seat reservation. This is not merely a vocabulary exercise: seat hold may succeed before ticket issuance. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is two chargeable bookings. The available check is ticketing system and confirmed itinerary record, while the relevant identity signal is booking reference and reservation identity.

The important counterexample is a traveller buying another seat for a companion. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to check reservation and issuance status separately. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

2.2 Repeat the action

Suppose the traveller intentionally asks for another instance after the first seat reservation was completed. This is a new decision, not necessarily a recovery.

Source wording: “Repeat the action to create another result.” Unsafe paraphrase: “Try to finish the first failed request.” What must survive: a new instance may be intentionally wanted even when its fields match those of a previous instance. In this workflow the protected outcome is a single reserved itinerary, and the error to prevent is two chargeable bookings. The decisive evidence is an explicit fresh user intention rather than the visual similarity of the source fields, interpreted alongside booking reference and reservation identity.

Translation decision: Treat the source as an instruction about booking request, not as a general invitation to create seat reservation. Do not silently merge two legitimately separate intentions. Check reservation and issuance status separately. Reader diagnostic: Could the reader deliberately request another identical outcome without the system mistaking it for a retry? For this case the reviewer should consult ticketing system and confirmed itinerary record and compare it with the plausible independent second action: a traveller buying another seat for a companion.

2.5 Replay the event

Suppose an earlier booking request was accepted but its confirmation failed to reach the traveller. The first result might already exist.

Source wording: “Replay the recorded event in the test environment.” Unsafe paraphrase: “Repeat the real-world operation.” What must survive: reintroduce a recorded event to a defined processing context; replay is not by itself a command to reproduce external consequences. In this workflow the protected outcome is a single reserved itinerary, and the error to prevent is two chargeable bookings. The decisive evidence is the distinction between replay input and the receiving environment’s behavior, interpreted alongside booking reference and reservation identity.

Translation decision: Treat the source as an instruction about booking request, not as a general invitation to create seat reservation. Preserve test-versus-live boundaries and guard against external side effects. Check reservation and issuance status separately. Reader diagnostic: Would the target reader know whether replay changes a log, simulation, or live system? For this case the reviewer should consult ticketing system and confirmed itinerary record and compare it with the plausible independent second action: a traveller buying another seat for a companion.

2.8 Redeliver the message

Suppose the traveller reports a missing confirmation after initiating seat reservation. A later screen has no reliable final status.

Source wording: “The message may be redelivered if acknowledgment is not received.” Unsafe paraphrase: “A new message will be generated.” What must survive: the same published message may reach a consumer again, without implying a new publication or a new business event. In this workflow the protected outcome is a single reserved itinerary, and the error to prevent is two chargeable bookings. The decisive evidence is delivery identity and acknowledgment status, interpreted alongside booking reference and reservation identity.

Translation decision: Treat the source as an instruction about booking request, not as a general invitation to create seat reservation. The receiver must not infer that a redelivered message has never been processed. Check reservation and issuance status separately. Reader diagnostic: Does the translation distinguish receiving twice from performing the underlying action twice? For this case the reviewer should consult ticketing system and confirmed itinerary record and compare it with the plausible independent second action: a traveller buying another seat for a companion.

2.11 Retry with backoff

Suppose one part of the workflow is complete while another stage is delayed. Seat hold may succeed before ticket issuance.

Source wording: “Retry with increasing delay, up to the stated attempt limit.” Unsafe paraphrase: “Keep trying continuously until it works.” What must survive: repeat attempts are subject to waiting, a ceiling and eventual failure handling. In this workflow the protected outcome is a single reserved itinerary, and the error to prevent is two chargeable bookings. The decisive evidence is the specified retry policy and how the operation behaves under overload, interpreted alongside booking reference and reservation identity.

Translation decision: Treat the source as an instruction about booking request, not as a general invitation to create seat reservation. Retain both the interval rule and the maximum count, including whether the original attempt is counted. Check reservation and issuance status separately. Reader diagnostic: Would an operator know when to stop and what the delay requirement means? For this case the reviewer should consult ticketing system and confirmed itinerary record and compare it with the plausible independent second action: a traveller buying another seat for a companion.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. An acceptable target expression must preserve a decision boundary. A natural-sounding command is not accurate when it silently grants permission absent from the source. Review the translation with an actual failure trace; a dictionary example alone will not expose this operational ambiguity.

2.14 Stop further attempts

Suppose the traveller intentionally asks for another instance after the first seat reservation was completed. This is a new decision, not necessarily a recovery.

Source wording: “Stop further retries after the limit is reached; do not reverse completed work.” Unsafe paraphrase: “Cancel and undo the whole transaction.” What must survive: future retry attempts cease while already committed effects retain their documented state. In this workflow the protected outcome is a single reserved itinerary, and the error to prevent is two chargeable bookings. The decisive evidence is the difference between stopping an automated attempt loop and compensating for a past action, interpreted alongside booking reference and reservation identity.

Translation decision: Treat the source as an instruction about booking request, not as a general invitation to create seat reservation. Never claim an undo operation where none is specified. Check reservation and issuance status separately. Reader diagnostic: Does the target correctly distinguish stopping new attempts from reversing old results? For this case the reviewer should consult ticketing system and confirmed itinerary record and compare it with the plausible independent second action: a traveller buying another seat for a companion.

Domain synthesis: The travel reservation problem is solved only when the target distinguishes a single reserved itinerary from two chargeable bookings and can establish the correct result using ticketing system and confirmed itinerary record. A deliberately new action, such as a traveller buying another seat for a companion, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 3: Online examination — preserving the intended effect

In online examination, the candidate intends one assessed submission. The operative object is assessment response, connected with answer submission. This is not merely a vocabulary exercise: the uploaded file may be stored before assessment status changes. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is an unwanted second attempt or lost answer version. The available check is submission timestamp and assessment receipt, while the relevant identity signal is attempt number and submission receipt ID.

The important counterexample is a permitted resit counted as a new attempt. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to verify saved answers and allowed attempt rules. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

3.3 Resume from the checkpoint

Suppose the candidate reports a missing confirmation after initiating answer submission. A later screen has no reliable final status.

Source wording: “Resume the interrupted operation from the last saved checkpoint.” Unsafe paraphrase: “Start all steps again.” What must survive: continue from trustworthy persisted progress, rather than repeating already completed work. In this workflow the protected outcome is one assessed submission, and the error to prevent is an unwanted second attempt or lost answer version. The decisive evidence is a verified checkpoint and the subset of remaining steps, interpreted alongside attempt number and submission receipt ID.

Translation decision: Treat the source as an instruction about assessment response, not as a general invitation to create answer submission. Never claim that unsaved work was retained. Verify saved answers and allowed attempt rules. Reader diagnostic: Can the reader identify the completed portion and the exact point of continuation? For this case the reviewer should consult submission timestamp and assessment receipt and compare it with the plausible independent second action: a permitted resit counted as a new attempt.

3.6 Reprocess failed items only

Suppose one part of the workflow is complete while another stage is delayed. The uploaded file may be stored before assessment status changes.

Source wording: “Reprocess only the items marked failed; do not include completed items.” Unsafe paraphrase: “Run the full batch again.” What must survive: a deliberately limited processing set restricted to diagnosed failures. In this workflow the protected outcome is one assessed submission, and the error to prevent is an unwanted second attempt or lost answer version. The decisive evidence is per-item status and durable evidence of earlier completion, interpreted alongside attempt number and submission receipt ID.

Translation decision: Treat the source as an instruction about assessment response, not as a general invitation to create answer submission. The exception for completed items must remain attached to the scope. Verify saved answers and allowed attempt rules. Reader diagnostic: If half the items succeeded, would the translation keep the successful half out of the rerun? For this case the reviewer should consult submission timestamp and assessment receipt and compare it with the plausible independent second action: a permitted resit counted as a new attempt.

3.9 Deduplicate matching records

Suppose the candidate intentionally asks for another instance after the first answer submission was completed. This is a new decision, not necessarily a recovery.

Source wording: “Deduplicate records using the defined business key.” Unsafe paraphrase: “Delete all records that look similar.” What must survive: equivalence is judged by the domain’s declared identity rule rather than superficial resemblance. In this workflow the protected outcome is one assessed submission, and the error to prevent is an unwanted second attempt or lost answer version. The decisive evidence is the business key, review policy and rules for which record survives, interpreted alongside attempt number and submission receipt ID.

Translation decision: Treat the source as an instruction about assessment response, not as a general invitation to create answer submission. Legitimate separate records must not be collapsed. Verify saved answers and allowed attempt rules. Reader diagnostic: Would two independent but visually identical actions remain distinguishable? For this case the reviewer should consult submission timestamp and assessment receipt and compare it with the plausible independent second action: a permitted resit counted as a new attempt.

3.12 Acknowledge successful delivery

Suppose an earlier assessment response was accepted but its confirmation failed to reach the candidate. The first result might already exist.

Source wording: “Acknowledge the message only after the required processing step succeeds.” Unsafe paraphrase: “Acknowledge immediately upon receipt.” What must survive: a protocol signal must follow a defined stage rather than merely arrival. In this workflow the protected outcome is one assessed submission, and the error to prevent is an unwanted second attempt or lost answer version. The decisive evidence is whether work is durable and which stage the protocol requires, interpreted alongside attempt number and submission receipt ID.

Translation decision: Treat the source as an instruction about assessment response, not as a general invitation to create answer submission. Do not convert receipt into evidence of downstream business completion. Verify saved answers and allowed attempt rules. Reader diagnostic: Would the translation lead to acknowledgment before work is safely recorded? For this case the reviewer should consult submission timestamp and assessment receipt and compare it with the plausible independent second action: a permitted resit counted as a new attempt.

Domain synthesis: The online examination problem is solved only when the target distinguishes one assessed submission from an unwanted second attempt or lost answer version and can establish the correct result using submission timestamp and assessment receipt. A deliberately new action, such as a permitted resit counted as a new attempt, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 4: Research survey — preserving the intended effect

In research survey, the participant intends one legitimate response in the study dataset. The operative object is questionnaire response, connected with survey entry. This is not merely a vocabulary exercise: the final page may fail after answers are saved. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is duplicate observations that bias analysis. The available check is data-collection log and anonymized response status, while the relevant identity signal is consented response identifier.

The important counterexample is a study design that legitimately permits repeated daily measures. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to avoid disclosing personal identity while checking saved status. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

4.1 Retry the original request

Suppose one part of the workflow is complete while another stage is delayed. The final page may fail after answers are saved.

Source wording: “Retry the original request after the connection error.” Unsafe paraphrase: “Perform a second new action.” What must survive: another attempt to complete the same logical request, not authorization to create an additional independent result. In this workflow the protected outcome is one legitimate response in the study dataset, and the error to prevent is duplicate observations that bias analysis. The decisive evidence is whether the earlier request’s result is unknown or confirmed, and whether stable request identity is supported, interpreted alongside consented response identifier.

Translation decision: Treat the source as an instruction about questionnaire response, not as a general invitation to create survey entry. Same-operation identity must be retained when the contract supports it. Avoid disclosing personal identity while checking saved status. Reader diagnostic: If the first attempt had already committed, would a second attempt be recognized as the same intention? For this case the reviewer should consult data-collection log and anonymized response status and compare it with the plausible independent second action: a study design that legitimately permits repeated daily measures.

4.4 Restart the process

Suppose the participant intentionally asks for another instance after the first survey entry was completed. This is a new decision, not necessarily a recovery.

Source wording: “Restart the process from the beginning.” Unsafe paraphrase: “Continue where you left off.” What must survive: begin anew under the specified process rules, with state retention or reset described separately. In this workflow the protected outcome is one legitimate response in the study dataset, and the error to prevent is duplicate observations that bias analysis. The decisive evidence is whether earlier records or effects remain after the restart, interpreted alongside consented response identifier.

Translation decision: Treat the source as an instruction about questionnaire response, not as a general invitation to create survey entry. Do not imply that restarting automatically undoes committed real-world effects. Avoid disclosing personal identity while checking saved status. Reader diagnostic: Does the translation make clear what a new beginning means for existing work? For this case the reviewer should consult data-collection log and anonymized response status and compare it with the plausible independent second action: a study design that legitimately permits repeated daily measures.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. The first task is to reconstruct the timeline: initial intent, attempted transmission, possible state change, and any receipt. Translate only after those events are placed in order. Keep the current stage visible to the reader. A receipt, queue position and final settlement are different pieces of evidence.

4.7 Resubmit after verification

Suppose an earlier questionnaire response was accepted but its confirmation failed to reach the participant. The first result might already exist.

Source wording: “Verify submission status before resubmitting.” Unsafe paraphrase: “Submit again immediately.” What must survive: a status check is a prerequisite, not an optional background suggestion. In this workflow the protected outcome is one legitimate response in the study dataset, and the error to prevent is duplicate observations that bias analysis. The decisive evidence is the possibility that acceptance occurred even though the original response was lost, interpreted alongside consented response identifier.

Translation decision: Treat the source as an instruction about questionnaire response, not as a general invitation to create survey entry. Verify against a trustworthy record before issuing a new submission. Avoid disclosing personal identity while checking saved status. Reader diagnostic: Can the reader tell that no second submission is permitted before the check? For this case the reviewer should consult data-collection log and anonymized response status and compare it with the plausible independent second action: a study design that legitimately permits repeated daily measures.

4.10 Reconcile the uncertain result

Suppose the participant reports a missing confirmation after initiating survey entry. A later screen has no reliable final status.

Source wording: “Reconcile the operation status before attempting recovery.” Unsafe paraphrase: “Repeat the operation to check whether it works.” What must survive: compare authoritative evidence to establish what actually happened before choosing another action. In this workflow the protected outcome is one legitimate response in the study dataset, and the error to prevent is duplicate observations that bias analysis. The decisive evidence is trustworthy records, timestamps and the known limits of their information, interpreted alongside consented response identifier.

Translation decision: Treat the source as an instruction about questionnaire response, not as a general invitation to create survey entry. Reconciliation is an evidence-gathering step, not an invitation to trigger a second effect. Avoid disclosing personal identity while checking saved status. Reader diagnostic: Is the first action’s actual state checked before a new effect can occur? For this case the reviewer should consult data-collection log and anonymized response status and compare it with the plausible independent second action: a study design that legitimately permits repeated daily measures.

4.13 Continue the unfinished batch

Suppose one part of the workflow is complete while another stage is delayed. The final page may fail after answers are saved.

Source wording: “Continue with remaining work without rerunning completed entries.” Unsafe paraphrase: “Restart the entire operation.” What must survive: continue remaining items while preserving earlier successful results. In this workflow the protected outcome is one legitimate response in the study dataset, and the error to prevent is duplicate observations that bias analysis. The decisive evidence is item-level progress, not a single misleading all-or-nothing batch label, interpreted alongside consented response identifier.

Translation decision: Treat the source as an instruction about questionnaire response, not as a general invitation to create survey entry. Preserve the negative instruction against replaying completed entries. Avoid disclosing personal identity while checking saved status. Reader diagnostic: Could the reader name what stays completed and what still needs processing? For this case the reviewer should consult data-collection log and anonymized response status and compare it with the plausible independent second action: a study design that legitimately permits repeated daily measures.

Domain synthesis: The research survey problem is solved only when the target distinguishes one legitimate response in the study dataset from duplicate observations that bias analysis and can establish the correct result using data-collection log and anonymized response status. A deliberately new action, such as a study design that legitimately permits repeated daily measures, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 5: Clinical appointment — preserving the intended effect

In clinical appointment, the patient intends one scheduled consultation. The operative object is booking or reminder message, connected with appointment confirmation. This is not merely a vocabulary exercise: a reminder can arrive late after the booking is already confirmed. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is two appointments or extra reminder messages. The available check is appointment calendar and booking confirmation, while the relevant identity signal is visit identifier and confirmation token.

The important counterexample is a patient booking a separate follow-up appointment. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to verify appointment status before resending a booking request. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

5.2 Repeat the action

Suppose an earlier booking or reminder message was accepted but its confirmation failed to reach the patient. The first result might already exist.

Source wording: “Repeat the action to create another result.” Unsafe paraphrase: “Try to finish the first failed request.” What must survive: a new instance may be intentionally wanted even when its fields match those of a previous instance. In this workflow the protected outcome is one scheduled consultation, and the error to prevent is two appointments or extra reminder messages. The decisive evidence is an explicit fresh user intention rather than the visual similarity of the source fields, interpreted alongside visit identifier and confirmation token.

Translation decision: Treat the source as an instruction about booking or reminder message, not as a general invitation to create appointment confirmation. Do not silently merge two legitimately separate intentions. Verify appointment status before resending a booking request. Reader diagnostic: Could the reader deliberately request another identical outcome without the system mistaking it for a retry? For this case the reviewer should consult appointment calendar and booking confirmation and compare it with the plausible independent second action: a patient booking a separate follow-up appointment.

5.5 Replay the event

Suppose the patient reports a missing confirmation after initiating appointment confirmation. A later screen has no reliable final status.

Source wording: “Replay the recorded event in the test environment.” Unsafe paraphrase: “Repeat the real-world operation.” What must survive: reintroduce a recorded event to a defined processing context; replay is not by itself a command to reproduce external consequences. In this workflow the protected outcome is one scheduled consultation, and the error to prevent is two appointments or extra reminder messages. The decisive evidence is the distinction between replay input and the receiving environment’s behavior, interpreted alongside visit identifier and confirmation token.

Translation decision: Treat the source as an instruction about booking or reminder message, not as a general invitation to create appointment confirmation. Preserve test-versus-live boundaries and guard against external side effects. Verify appointment status before resending a booking request. Reader diagnostic: Would the target reader know whether replay changes a log, simulation, or live system? For this case the reviewer should consult appointment calendar and booking confirmation and compare it with the plausible independent second action: a patient booking a separate follow-up appointment.

5.8 Redeliver the message

Suppose one part of the workflow is complete while another stage is delayed. A reminder can arrive late after the booking is already confirmed.

Source wording: “The message may be redelivered if acknowledgment is not received.” Unsafe paraphrase: “A new message will be generated.” What must survive: the same published message may reach a consumer again, without implying a new publication or a new business event. In this workflow the protected outcome is one scheduled consultation, and the error to prevent is two appointments or extra reminder messages. The decisive evidence is delivery identity and acknowledgment status, interpreted alongside visit identifier and confirmation token.

Translation decision: Treat the source as an instruction about booking or reminder message, not as a general invitation to create appointment confirmation. The receiver must not infer that a redelivered message has never been processed. Verify appointment status before resending a booking request. Reader diagnostic: Does the translation distinguish receiving twice from performing the underlying action twice? For this case the reviewer should consult appointment calendar and booking confirmation and compare it with the plausible independent second action: a patient booking a separate follow-up appointment.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. A duplicate-prevention promise should be stated at the scope that the product actually guarantees. It may cover a request ID, a message subscription, or one stage only. Cross-check a second source, such as the authoritative ledger or a documented API response, before concluding that an operation should be repeated.

5.11 Retry with backoff

Suppose the patient intentionally asks for another instance after the first appointment confirmation was completed. This is a new decision, not necessarily a recovery.

Source wording: “Retry with increasing delay, up to the stated attempt limit.” Unsafe paraphrase: “Keep trying continuously until it works.” What must survive: repeat attempts are subject to waiting, a ceiling and eventual failure handling. In this workflow the protected outcome is one scheduled consultation, and the error to prevent is two appointments or extra reminder messages. The decisive evidence is the specified retry policy and how the operation behaves under overload, interpreted alongside visit identifier and confirmation token.

Translation decision: Treat the source as an instruction about booking or reminder message, not as a general invitation to create appointment confirmation. Retain both the interval rule and the maximum count, including whether the original attempt is counted. Verify appointment status before resending a booking request. Reader diagnostic: Would an operator know when to stop and what the delay requirement means? For this case the reviewer should consult appointment calendar and booking confirmation and compare it with the plausible independent second action: a patient booking a separate follow-up appointment.

5.14 Stop further attempts

Suppose an earlier booking or reminder message was accepted but its confirmation failed to reach the patient. The first result might already exist.

Source wording: “Stop further retries after the limit is reached; do not reverse completed work.” Unsafe paraphrase: “Cancel and undo the whole transaction.” What must survive: future retry attempts cease while already committed effects retain their documented state. In this workflow the protected outcome is one scheduled consultation, and the error to prevent is two appointments or extra reminder messages. The decisive evidence is the difference between stopping an automated attempt loop and compensating for a past action, interpreted alongside visit identifier and confirmation token.

Translation decision: Treat the source as an instruction about booking or reminder message, not as a general invitation to create appointment confirmation. Never claim an undo operation where none is specified. Verify appointment status before resending a booking request. Reader diagnostic: Does the target correctly distinguish stopping new attempts from reversing old results? For this case the reviewer should consult appointment calendar and booking confirmation and compare it with the plausible independent second action: a patient booking a separate follow-up appointment.

Domain synthesis: The clinical appointment problem is solved only when the target distinguishes one scheduled consultation from two appointments or extra reminder messages and can establish the correct result using appointment calendar and booking confirmation. A deliberately new action, such as a patient booking a separate follow-up appointment, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 6: Parcel dispatch — preserving the intended effect

In parcel dispatch, the dispatcher intends one intended physical parcel movement. The operative object is dispatch instruction, connected with shipment handoff. This is not merely a vocabulary exercise: a parcel may have been collected before the scanner reconnects. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is two pick-ups or two printed carrier labels. The available check is carrier scan history and warehouse dispatch ledger, while the relevant identity signal is consignment and label identifier.

The important counterexample is a customer intentionally sending a second matching parcel. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to check scan and manifest state before printing a replacement. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

6.3 Resume from the checkpoint

Suppose one part of the workflow is complete while another stage is delayed. A parcel may have been collected before the scanner reconnects.

Source wording: “Resume the interrupted operation from the last saved checkpoint.” Unsafe paraphrase: “Start all steps again.” What must survive: continue from trustworthy persisted progress, rather than repeating already completed work. In this workflow the protected outcome is one intended physical parcel movement, and the error to prevent is two pick-ups or two printed carrier labels. The decisive evidence is a verified checkpoint and the subset of remaining steps, interpreted alongside consignment and label identifier.

Translation decision: Treat the source as an instruction about dispatch instruction, not as a general invitation to create shipment handoff. Never claim that unsaved work was retained. Check scan and manifest state before printing a replacement. Reader diagnostic: Can the reader identify the completed portion and the exact point of continuation? For this case the reviewer should consult carrier scan history and warehouse dispatch ledger and compare it with the plausible independent second action: a customer intentionally sending a second matching parcel.

6.6 Reprocess failed items only

Suppose the dispatcher intentionally asks for another instance after the first shipment handoff was completed. This is a new decision, not necessarily a recovery.

Source wording: “Reprocess only the items marked failed; do not include completed items.” Unsafe paraphrase: “Run the full batch again.” What must survive: a deliberately limited processing set restricted to diagnosed failures. In this workflow the protected outcome is one intended physical parcel movement, and the error to prevent is two pick-ups or two printed carrier labels. The decisive evidence is per-item status and durable evidence of earlier completion, interpreted alongside consignment and label identifier.

Translation decision: Treat the source as an instruction about dispatch instruction, not as a general invitation to create shipment handoff. The exception for completed items must remain attached to the scope. Check scan and manifest state before printing a replacement. Reader diagnostic: If half the items succeeded, would the translation keep the successful half out of the rerun? For this case the reviewer should consult carrier scan history and warehouse dispatch ledger and compare it with the plausible independent second action: a customer intentionally sending a second matching parcel.

6.9 Deduplicate matching records

Suppose an earlier dispatch instruction was accepted but its confirmation failed to reach the dispatcher. The first result might already exist.

Source wording: “Deduplicate records using the defined business key.” Unsafe paraphrase: “Delete all records that look similar.” What must survive: equivalence is judged by the domain’s declared identity rule rather than superficial resemblance. In this workflow the protected outcome is one intended physical parcel movement, and the error to prevent is two pick-ups or two printed carrier labels. The decisive evidence is the business key, review policy and rules for which record survives, interpreted alongside consignment and label identifier.

Translation decision: Treat the source as an instruction about dispatch instruction, not as a general invitation to create shipment handoff. Legitimate separate records must not be collapsed. Check scan and manifest state before printing a replacement. Reader diagnostic: Would two independent but visually identical actions remain distinguishable? For this case the reviewer should consult carrier scan history and warehouse dispatch ledger and compare it with the plausible independent second action: a customer intentionally sending a second matching parcel.

6.12 Acknowledge successful delivery

Suppose the dispatcher reports a missing confirmation after initiating shipment handoff. A later screen has no reliable final status.

Source wording: “Acknowledge the message only after the required processing step succeeds.” Unsafe paraphrase: “Acknowledge immediately upon receipt.” What must survive: a protocol signal must follow a defined stage rather than merely arrival. In this workflow the protected outcome is one intended physical parcel movement, and the error to prevent is two pick-ups or two printed carrier labels. The decisive evidence is whether work is durable and which stage the protocol requires, interpreted alongside consignment and label identifier.

Translation decision: Treat the source as an instruction about dispatch instruction, not as a general invitation to create shipment handoff. Do not convert receipt into evidence of downstream business completion. Check scan and manifest state before printing a replacement. Reader diagnostic: Would the translation lead to acknowledgment before work is safely recorded? For this case the reviewer should consult carrier scan history and warehouse dispatch ledger and compare it with the plausible independent second action: a customer intentionally sending a second matching parcel.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. Be especially careful with the scope of ‘again’. It can modify a network attempt, an internal processing step, or an entire real-world operation, and those are different objects. A good diagnostic is a counterfactual: if the first request secretly succeeded, would the target still direct the reader safely?

Domain synthesis: The parcel dispatch problem is solved only when the target distinguishes one intended physical parcel movement from two pick-ups or two printed carrier labels and can establish the correct result using carrier scan history and warehouse dispatch ledger. A deliberately new action, such as a customer intentionally sending a second matching parcel, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 7: Refund processing — preserving the intended effect

In refund processing, the support agent intends a single authorized return of funds. The operative object is refund initiation request, connected with approved refund. This is not merely a vocabulary exercise: refund initiation may succeed before settlement appears. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is an accidental duplicate refund. The available check is payment processor refund state and finance ledger, while the relevant identity signal is original sale and refund transaction reference.

The important counterexample is two separately authorized partial refunds. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to match refund request to its original transaction and posted status. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

7.1 Retry the original request

Suppose the support agent intentionally asks for another instance after the first approved refund was completed. This is a new decision, not necessarily a recovery.

Source wording: “Retry the original request after the connection error.” Unsafe paraphrase: “Perform a second new action.” What must survive: another attempt to complete the same logical request, not authorization to create an additional independent result. In this workflow the protected outcome is a single authorized return of funds, and the error to prevent is an accidental duplicate refund. The decisive evidence is whether the earlier request’s result is unknown or confirmed, and whether stable request identity is supported, interpreted alongside original sale and refund transaction reference.

Translation decision: Treat the source as an instruction about refund initiation request, not as a general invitation to create approved refund. Same-operation identity must be retained when the contract supports it. Match refund request to its original transaction and posted status. Reader diagnostic: If the first attempt had already committed, would a second attempt be recognized as the same intention? For this case the reviewer should consult payment processor refund state and finance ledger and compare it with the plausible independent second action: two separately authorized partial refunds.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. Preserve the difference between being notified and having a verified result. An email, toast, push alert or status badge can arrive later than the underlying event. Do not promise complete recovery where only a limited retry facility exists. The boundaries are part of the meaning.

7.4 Restart the process

Suppose an earlier refund initiation request was accepted but its confirmation failed to reach the support agent. The first result might already exist.

Source wording: “Restart the process from the beginning.” Unsafe paraphrase: “Continue where you left off.” What must survive: begin anew under the specified process rules, with state retention or reset described separately. In this workflow the protected outcome is a single authorized return of funds, and the error to prevent is an accidental duplicate refund. The decisive evidence is whether earlier records or effects remain after the restart, interpreted alongside original sale and refund transaction reference.

Translation decision: Treat the source as an instruction about refund initiation request, not as a general invitation to create approved refund. Do not imply that restarting automatically undoes committed real-world effects. Match refund request to its original transaction and posted status. Reader diagnostic: Does the translation make clear what a new beginning means for existing work? For this case the reviewer should consult payment processor refund state and finance ledger and compare it with the plausible independent second action: two separately authorized partial refunds.

7.7 Resubmit after verification

Suppose the support agent reports a missing confirmation after initiating approved refund. A later screen has no reliable final status.

Source wording: “Verify submission status before resubmitting.” Unsafe paraphrase: “Submit again immediately.” What must survive: a status check is a prerequisite, not an optional background suggestion. In this workflow the protected outcome is a single authorized return of funds, and the error to prevent is an accidental duplicate refund. The decisive evidence is the possibility that acceptance occurred even though the original response was lost, interpreted alongside original sale and refund transaction reference.

Translation decision: Treat the source as an instruction about refund initiation request, not as a general invitation to create approved refund. Verify against a trustworthy record before issuing a new submission. Match refund request to its original transaction and posted status. Reader diagnostic: Can the reader tell that no second submission is permitted before the check? For this case the reviewer should consult payment processor refund state and finance ledger and compare it with the plausible independent second action: two separately authorized partial refunds.

7.10 Reconcile the uncertain result

Suppose one part of the workflow is complete while another stage is delayed. Refund initiation may succeed before settlement appears.

Source wording: “Reconcile the operation status before attempting recovery.” Unsafe paraphrase: “Repeat the operation to check whether it works.” What must survive: compare authoritative evidence to establish what actually happened before choosing another action. In this workflow the protected outcome is a single authorized return of funds, and the error to prevent is an accidental duplicate refund. The decisive evidence is trustworthy records, timestamps and the known limits of their information, interpreted alongside original sale and refund transaction reference.

Translation decision: Treat the source as an instruction about refund initiation request, not as a general invitation to create approved refund. Reconciliation is an evidence-gathering step, not an invitation to trigger a second effect. Match refund request to its original transaction and posted status. Reader diagnostic: Is the first action’s actual state checked before a new effect can occur? For this case the reviewer should consult payment processor refund state and finance ledger and compare it with the plausible independent second action: two separately authorized partial refunds.

7.13 Continue the unfinished batch

Suppose the support agent intentionally asks for another instance after the first approved refund was completed. This is a new decision, not necessarily a recovery.

Source wording: “Continue with remaining work without rerunning completed entries.” Unsafe paraphrase: “Restart the entire operation.” What must survive: continue remaining items while preserving earlier successful results. In this workflow the protected outcome is a single authorized return of funds, and the error to prevent is an accidental duplicate refund. The decisive evidence is item-level progress, not a single misleading all-or-nothing batch label, interpreted alongside original sale and refund transaction reference.

Translation decision: Treat the source as an instruction about refund initiation request, not as a general invitation to create approved refund. Preserve the negative instruction against replaying completed entries. Match refund request to its original transaction and posted status. Reader diagnostic: Could the reader name what stays completed and what still needs processing? For this case the reviewer should consult payment processor refund state and finance ledger and compare it with the plausible independent second action: two separately authorized partial refunds.

Domain synthesis: The refund processing problem is solved only when the target distinguishes a single authorized return of funds from an accidental duplicate refund and can establish the correct result using payment processor refund state and finance ledger. A deliberately new action, such as two separately authorized partial refunds, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 8: Subscription invitation — preserving the intended effect

In subscription invitation, the administrator intends one active invitation for the intended recipient. The operative object is invitation email request, connected with membership invitation. This is not merely a vocabulary exercise: invitation creation and email delivery may occur at different times. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is multiple active invitations with conflicting links. The available check is invitation registry and delivery history, while the relevant identity signal is invitation record and recipient identity.

The important counterexample is a deliberate fresh invitation after an earlier one has expired. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to check the current invitation before generating another token. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

8.2 Repeat the action

Suppose the administrator reports a missing confirmation after initiating membership invitation. A later screen has no reliable final status.

Source wording: “Repeat the action to create another result.” Unsafe paraphrase: “Try to finish the first failed request.” What must survive: a new instance may be intentionally wanted even when its fields match those of a previous instance. In this workflow the protected outcome is one active invitation for the intended recipient, and the error to prevent is multiple active invitations with conflicting links. The decisive evidence is an explicit fresh user intention rather than the visual similarity of the source fields, interpreted alongside invitation record and recipient identity.

Translation decision: Treat the source as an instruction about invitation email request, not as a general invitation to create membership invitation. Do not silently merge two legitimately separate intentions. Check the current invitation before generating another token. Reader diagnostic: Could the reader deliberately request another identical outcome without the system mistaking it for a retry? For this case the reviewer should consult invitation registry and delivery history and compare it with the plausible independent second action: a deliberate fresh invitation after an earlier one has expired.

8.5 Replay the event

Suppose one part of the workflow is complete while another stage is delayed. Invitation creation and email delivery may occur at different times.

Source wording: “Replay the recorded event in the test environment.” Unsafe paraphrase: “Repeat the real-world operation.” What must survive: reintroduce a recorded event to a defined processing context; replay is not by itself a command to reproduce external consequences. In this workflow the protected outcome is one active invitation for the intended recipient, and the error to prevent is multiple active invitations with conflicting links. The decisive evidence is the distinction between replay input and the receiving environment’s behavior, interpreted alongside invitation record and recipient identity.

Translation decision: Treat the source as an instruction about invitation email request, not as a general invitation to create membership invitation. Preserve test-versus-live boundaries and guard against external side effects. Check the current invitation before generating another token. Reader diagnostic: Would the target reader know whether replay changes a log, simulation, or live system? For this case the reviewer should consult invitation registry and delivery history and compare it with the plausible independent second action: a deliberate fresh invitation after an earlier one has expired.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. An acceptable target expression must preserve a decision boundary. A natural-sounding command is not accurate when it silently grants permission absent from the source. Preserve the relationship between the requested operation and its evidence; the target should never imply a new intention without authorization.

8.8 Redeliver the message

Suppose the administrator intentionally asks for another instance after the first membership invitation was completed. This is a new decision, not necessarily a recovery.

Source wording: “The message may be redelivered if acknowledgment is not received.” Unsafe paraphrase: “A new message will be generated.” What must survive: the same published message may reach a consumer again, without implying a new publication or a new business event. In this workflow the protected outcome is one active invitation for the intended recipient, and the error to prevent is multiple active invitations with conflicting links. The decisive evidence is delivery identity and acknowledgment status, interpreted alongside invitation record and recipient identity.

Translation decision: Treat the source as an instruction about invitation email request, not as a general invitation to create membership invitation. The receiver must not infer that a redelivered message has never been processed. Check the current invitation before generating another token. Reader diagnostic: Does the translation distinguish receiving twice from performing the underlying action twice? For this case the reviewer should consult invitation registry and delivery history and compare it with the plausible independent second action: a deliberate fresh invitation after an earlier one has expired.

8.11 Retry with backoff

Suppose an earlier invitation email request was accepted but its confirmation failed to reach the administrator. The first result might already exist.

Source wording: “Retry with increasing delay, up to the stated attempt limit.” Unsafe paraphrase: “Keep trying continuously until it works.” What must survive: repeat attempts are subject to waiting, a ceiling and eventual failure handling. In this workflow the protected outcome is one active invitation for the intended recipient, and the error to prevent is multiple active invitations with conflicting links. The decisive evidence is the specified retry policy and how the operation behaves under overload, interpreted alongside invitation record and recipient identity.

Translation decision: Treat the source as an instruction about invitation email request, not as a general invitation to create membership invitation. Retain both the interval rule and the maximum count, including whether the original attempt is counted. Check the current invitation before generating another token. Reader diagnostic: Would an operator know when to stop and what the delay requirement means? For this case the reviewer should consult invitation registry and delivery history and compare it with the plausible independent second action: a deliberate fresh invitation after an earlier one has expired.

8.14 Stop further attempts

Suppose the administrator reports a missing confirmation after initiating membership invitation. A later screen has no reliable final status.

Source wording: “Stop further retries after the limit is reached; do not reverse completed work.” Unsafe paraphrase: “Cancel and undo the whole transaction.” What must survive: future retry attempts cease while already committed effects retain their documented state. In this workflow the protected outcome is one active invitation for the intended recipient, and the error to prevent is multiple active invitations with conflicting links. The decisive evidence is the difference between stopping an automated attempt loop and compensating for a past action, interpreted alongside invitation record and recipient identity.

Translation decision: Treat the source as an instruction about invitation email request, not as a general invitation to create membership invitation. Never claim an undo operation where none is specified. Check the current invitation before generating another token. Reader diagnostic: Does the target correctly distinguish stopping new attempts from reversing old results? For this case the reviewer should consult invitation registry and delivery history and compare it with the plausible independent second action: a deliberate fresh invitation after an earlier one has expired.

Domain synthesis: The subscription invitation problem is solved only when the target distinguishes one active invitation for the intended recipient from multiple active invitations with conflicting links and can establish the correct result using invitation registry and delivery history. A deliberately new action, such as a deliberate fresh invitation after an earlier one has expired, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 9: Payroll processing — preserving the intended effect

In payroll processing, the payroll operator intends one authorized payment for a pay cycle. The operative object is payment batch item, connected with salary disbursement. This is not merely a vocabulary exercise: some employees may be paid while others remain pending. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is duplicate salary transfers. The available check is payroll ledger and bank settlement confirmation, while the relevant identity signal is employee, pay period and disbursement reference.

The important counterexample is an authorized corrective payment documented separately. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to separate failed line items from completed transfers. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

9.3 Resume from the checkpoint

Suppose the payroll operator intentionally asks for another instance after the first salary disbursement was completed. This is a new decision, not necessarily a recovery.

Source wording: “Resume the interrupted operation from the last saved checkpoint.” Unsafe paraphrase: “Start all steps again.” What must survive: continue from trustworthy persisted progress, rather than repeating already completed work. In this workflow the protected outcome is one authorized payment for a pay cycle, and the error to prevent is duplicate salary transfers. The decisive evidence is a verified checkpoint and the subset of remaining steps, interpreted alongside employee, pay period and disbursement reference.

Translation decision: Treat the source as an instruction about payment batch item, not as a general invitation to create salary disbursement. Never claim that unsaved work was retained. Separate failed line items from completed transfers. Reader diagnostic: Can the reader identify the completed portion and the exact point of continuation? For this case the reviewer should consult payroll ledger and bank settlement confirmation and compare it with the plausible independent second action: an authorized corrective payment documented separately.

9.6 Reprocess failed items only

Suppose an earlier payment batch item was accepted but its confirmation failed to reach the payroll operator. The first result might already exist.

Source wording: “Reprocess only the items marked failed; do not include completed items.” Unsafe paraphrase: “Run the full batch again.” What must survive: a deliberately limited processing set restricted to diagnosed failures. In this workflow the protected outcome is one authorized payment for a pay cycle, and the error to prevent is duplicate salary transfers. The decisive evidence is per-item status and durable evidence of earlier completion, interpreted alongside employee, pay period and disbursement reference.

Translation decision: Treat the source as an instruction about payment batch item, not as a general invitation to create salary disbursement. The exception for completed items must remain attached to the scope. Separate failed line items from completed transfers. Reader diagnostic: If half the items succeeded, would the translation keep the successful half out of the rerun? For this case the reviewer should consult payroll ledger and bank settlement confirmation and compare it with the plausible independent second action: an authorized corrective payment documented separately.

9.9 Deduplicate matching records

Suppose the payroll operator reports a missing confirmation after initiating salary disbursement. A later screen has no reliable final status.

Source wording: “Deduplicate records using the defined business key.” Unsafe paraphrase: “Delete all records that look similar.” What must survive: equivalence is judged by the domain’s declared identity rule rather than superficial resemblance. In this workflow the protected outcome is one authorized payment for a pay cycle, and the error to prevent is duplicate salary transfers. The decisive evidence is the business key, review policy and rules for which record survives, interpreted alongside employee, pay period and disbursement reference.

Translation decision: Treat the source as an instruction about payment batch item, not as a general invitation to create salary disbursement. Legitimate separate records must not be collapsed. Separate failed line items from completed transfers. Reader diagnostic: Would two independent but visually identical actions remain distinguishable? For this case the reviewer should consult payroll ledger and bank settlement confirmation and compare it with the plausible independent second action: an authorized corrective payment documented separately.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. The case is not solved by translating ‘idempotent’ into ‘safe’. Safety depends on what can change, which identifier is reused, and what external effects are possible. Mark the outcome as uncertain if the original does not prove it; that is more faithful than smoothing the message into a false yes-or-no.

9.12 Acknowledge successful delivery

Suppose one part of the workflow is complete while another stage is delayed. Some employees may be paid while others remain pending.

Source wording: “Acknowledge the message only after the required processing step succeeds.” Unsafe paraphrase: “Acknowledge immediately upon receipt.” What must survive: a protocol signal must follow a defined stage rather than merely arrival. In this workflow the protected outcome is one authorized payment for a pay cycle, and the error to prevent is duplicate salary transfers. The decisive evidence is whether work is durable and which stage the protocol requires, interpreted alongside employee, pay period and disbursement reference.

Translation decision: Treat the source as an instruction about payment batch item, not as a general invitation to create salary disbursement. Do not convert receipt into evidence of downstream business completion. Separate failed line items from completed transfers. Reader diagnostic: Would the translation lead to acknowledgment before work is safely recorded? For this case the reviewer should consult payroll ledger and bank settlement confirmation and compare it with the plausible independent second action: an authorized corrective payment documented separately.

Domain synthesis: The payroll processing problem is solved only when the target distinguishes one authorized payment for a pay cycle from duplicate salary transfers and can establish the correct result using payroll ledger and bank settlement confirmation. A deliberately new action, such as an authorized corrective payment documented separately, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 10: Laboratory assay — preserving the intended effect

In laboratory assay, the technician intends one traceable analytical result. The operative object is analysis job, connected with sample measurement. This is not merely a vocabulary exercise: instrument capture may finish before the report is committed. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is two results falsely treated as independent specimens. The available check is instrument run log and laboratory information record, while the relevant identity signal is sample ID and measurement run ID.

The important counterexample is an authorized replicate measurement for quality control. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to distinguish technical rerun from new biological sampling. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

10.1 Retry the original request

Suppose an earlier analysis job was accepted but its confirmation failed to reach the technician. The first result might already exist.

Source wording: “Retry the original request after the connection error.” Unsafe paraphrase: “Perform a second new action.” What must survive: another attempt to complete the same logical request, not authorization to create an additional independent result. In this workflow the protected outcome is one traceable analytical result, and the error to prevent is two results falsely treated as independent specimens. The decisive evidence is whether the earlier request’s result is unknown or confirmed, and whether stable request identity is supported, interpreted alongside sample ID and measurement run ID.

Translation decision: Treat the source as an instruction about analysis job, not as a general invitation to create sample measurement. Same-operation identity must be retained when the contract supports it. Distinguish technical rerun from new biological sampling. Reader diagnostic: If the first attempt had already committed, would a second attempt be recognized as the same intention? For this case the reviewer should consult instrument run log and laboratory information record and compare it with the plausible independent second action: an authorized replicate measurement for quality control.

10.4 Restart the process

Suppose the technician reports a missing confirmation after initiating sample measurement. A later screen has no reliable final status.

Source wording: “Restart the process from the beginning.” Unsafe paraphrase: “Continue where you left off.” What must survive: begin anew under the specified process rules, with state retention or reset described separately. In this workflow the protected outcome is one traceable analytical result, and the error to prevent is two results falsely treated as independent specimens. The decisive evidence is whether earlier records or effects remain after the restart, interpreted alongside sample ID and measurement run ID.

Translation decision: Treat the source as an instruction about analysis job, not as a general invitation to create sample measurement. Do not imply that restarting automatically undoes committed real-world effects. Distinguish technical rerun from new biological sampling. Reader diagnostic: Does the translation make clear what a new beginning means for existing work? For this case the reviewer should consult instrument run log and laboratory information record and compare it with the plausible independent second action: an authorized replicate measurement for quality control.

10.7 Resubmit after verification

Suppose one part of the workflow is complete while another stage is delayed. Instrument capture may finish before the report is committed.

Source wording: “Verify submission status before resubmitting.” Unsafe paraphrase: “Submit again immediately.” What must survive: a status check is a prerequisite, not an optional background suggestion. In this workflow the protected outcome is one traceable analytical result, and the error to prevent is two results falsely treated as independent specimens. The decisive evidence is the possibility that acceptance occurred even though the original response was lost, interpreted alongside sample ID and measurement run ID.

Translation decision: Treat the source as an instruction about analysis job, not as a general invitation to create sample measurement. Verify against a trustworthy record before issuing a new submission. Distinguish technical rerun from new biological sampling. Reader diagnostic: Can the reader tell that no second submission is permitted before the check? For this case the reviewer should consult instrument run log and laboratory information record and compare it with the plausible independent second action: an authorized replicate measurement for quality control.

10.10 Reconcile the uncertain result

Suppose the technician intentionally asks for another instance after the first sample measurement was completed. This is a new decision, not necessarily a recovery.

Source wording: “Reconcile the operation status before attempting recovery.” Unsafe paraphrase: “Repeat the operation to check whether it works.” What must survive: compare authoritative evidence to establish what actually happened before choosing another action. In this workflow the protected outcome is one traceable analytical result, and the error to prevent is two results falsely treated as independent specimens. The decisive evidence is trustworthy records, timestamps and the known limits of their information, interpreted alongside sample ID and measurement run ID.

Translation decision: Treat the source as an instruction about analysis job, not as a general invitation to create sample measurement. Reconciliation is an evidence-gathering step, not an invitation to trigger a second effect. Distinguish technical rerun from new biological sampling. Reader diagnostic: Is the first action’s actual state checked before a new effect can occur? For this case the reviewer should consult instrument run log and laboratory information record and compare it with the plausible independent second action: an authorized replicate measurement for quality control.

10.13 Continue the unfinished batch

Suppose an earlier analysis job was accepted but its confirmation failed to reach the technician. The first result might already exist.

Source wording: “Continue with remaining work without rerunning completed entries.” Unsafe paraphrase: “Restart the entire operation.” What must survive: continue remaining items while preserving earlier successful results. In this workflow the protected outcome is one traceable analytical result, and the error to prevent is two results falsely treated as independent specimens. The decisive evidence is item-level progress, not a single misleading all-or-nothing batch label, interpreted alongside sample ID and measurement run ID.

Translation decision: Treat the source as an instruction about analysis job, not as a general invitation to create sample measurement. Preserve the negative instruction against replaying completed entries. Distinguish technical rerun from new biological sampling. Reader diagnostic: Could the reader name what stays completed and what still needs processing? For this case the reviewer should consult instrument run log and laboratory information record and compare it with the plausible independent second action: an authorized replicate measurement for quality control.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. The source may include a reassuring interface word that conceals a technical precondition. The target should remain usable without deleting that safety condition. Keep the current stage visible to the reader. A receipt, queue position and final settlement are different pieces of evidence.

Domain synthesis: The laboratory assay problem is solved only when the target distinguishes one traceable analytical result from two results falsely treated as independent specimens and can establish the correct result using instrument run log and laboratory information record. A deliberately new action, such as an authorized replicate measurement for quality control, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 11: Document signing — preserving the intended effect

In document signing, the signatory intends one valid signature event for the intended document. The operative object is electronic signing request, connected with document signature. This is not merely a vocabulary exercise: signature application may succeed before email confirmation arrives. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is multiple signature requests for incompatible versions. The available check is signing audit trail and current envelope state, while the relevant identity signal is envelope ID and document version.

The important counterexample is a separate amendment that requires a new signature. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to verify document version, signed status and envelope identity. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

11.2 Repeat the action

Suppose one part of the workflow is complete while another stage is delayed. Signature application may succeed before email confirmation arrives.

Source wording: “Repeat the action to create another result.” Unsafe paraphrase: “Try to finish the first failed request.” What must survive: a new instance may be intentionally wanted even when its fields match those of a previous instance. In this workflow the protected outcome is one valid signature event for the intended document, and the error to prevent is multiple signature requests for incompatible versions. The decisive evidence is an explicit fresh user intention rather than the visual similarity of the source fields, interpreted alongside envelope ID and document version.

Translation decision: Treat the source as an instruction about electronic signing request, not as a general invitation to create document signature. Do not silently merge two legitimately separate intentions. Verify document version, signed status and envelope identity. Reader diagnostic: Could the reader deliberately request another identical outcome without the system mistaking it for a retry? For this case the reviewer should consult signing audit trail and current envelope state and compare it with the plausible independent second action: a separate amendment that requires a new signature.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. A duplicate-prevention promise should be stated at the scope that the product actually guarantees. It may cover a request ID, a message subscription, or one stage only. Localize the prose, not the opaque identifiers or protocol keys that the service uses to recognise an existing action.

11.5 Replay the event

Suppose the signatory intentionally asks for another instance after the first document signature was completed. This is a new decision, not necessarily a recovery.

Source wording: “Replay the recorded event in the test environment.” Unsafe paraphrase: “Repeat the real-world operation.” What must survive: reintroduce a recorded event to a defined processing context; replay is not by itself a command to reproduce external consequences. In this workflow the protected outcome is one valid signature event for the intended document, and the error to prevent is multiple signature requests for incompatible versions. The decisive evidence is the distinction between replay input and the receiving environment’s behavior, interpreted alongside envelope ID and document version.

Translation decision: Treat the source as an instruction about electronic signing request, not as a general invitation to create document signature. Preserve test-versus-live boundaries and guard against external side effects. Verify document version, signed status and envelope identity. Reader diagnostic: Would the target reader know whether replay changes a log, simulation, or live system? For this case the reviewer should consult signing audit trail and current envelope state and compare it with the plausible independent second action: a separate amendment that requires a new signature.

11.8 Redeliver the message

Suppose an earlier electronic signing request was accepted but its confirmation failed to reach the signatory. The first result might already exist.

Source wording: “The message may be redelivered if acknowledgment is not received.” Unsafe paraphrase: “A new message will be generated.” What must survive: the same published message may reach a consumer again, without implying a new publication or a new business event. In this workflow the protected outcome is one valid signature event for the intended document, and the error to prevent is multiple signature requests for incompatible versions. The decisive evidence is delivery identity and acknowledgment status, interpreted alongside envelope ID and document version.

Translation decision: Treat the source as an instruction about electronic signing request, not as a general invitation to create document signature. The receiver must not infer that a redelivered message has never been processed. Verify document version, signed status and envelope identity. Reader diagnostic: Does the translation distinguish receiving twice from performing the underlying action twice? For this case the reviewer should consult signing audit trail and current envelope state and compare it with the plausible independent second action: a separate amendment that requires a new signature.

11.11 Retry with backoff

Suppose the signatory reports a missing confirmation after initiating document signature. A later screen has no reliable final status.

Source wording: “Retry with increasing delay, up to the stated attempt limit.” Unsafe paraphrase: “Keep trying continuously until it works.” What must survive: repeat attempts are subject to waiting, a ceiling and eventual failure handling. In this workflow the protected outcome is one valid signature event for the intended document, and the error to prevent is multiple signature requests for incompatible versions. The decisive evidence is the specified retry policy and how the operation behaves under overload, interpreted alongside envelope ID and document version.

Translation decision: Treat the source as an instruction about electronic signing request, not as a general invitation to create document signature. Retain both the interval rule and the maximum count, including whether the original attempt is counted. Verify document version, signed status and envelope identity. Reader diagnostic: Would an operator know when to stop and what the delay requirement means? For this case the reviewer should consult signing audit trail and current envelope state and compare it with the plausible independent second action: a separate amendment that requires a new signature.

11.14 Stop further attempts

Suppose one part of the workflow is complete while another stage is delayed. Signature application may succeed before email confirmation arrives.

Source wording: “Stop further retries after the limit is reached; do not reverse completed work.” Unsafe paraphrase: “Cancel and undo the whole transaction.” What must survive: future retry attempts cease while already committed effects retain their documented state. In this workflow the protected outcome is one valid signature event for the intended document, and the error to prevent is multiple signature requests for incompatible versions. The decisive evidence is the difference between stopping an automated attempt loop and compensating for a past action, interpreted alongside envelope ID and document version.

Translation decision: Treat the source as an instruction about electronic signing request, not as a general invitation to create document signature. Never claim an undo operation where none is specified. Verify document version, signed status and envelope identity. Reader diagnostic: Does the target correctly distinguish stopping new attempts from reversing old results? For this case the reviewer should consult signing audit trail and current envelope state and compare it with the plausible independent second action: a separate amendment that requires a new signature.

Domain synthesis: The document signing problem is solved only when the target distinguishes one valid signature event for the intended document from multiple signature requests for incompatible versions and can establish the correct result using signing audit trail and current envelope state. A deliberately new action, such as a separate amendment that requires a new signature, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 12: Media upload — preserving the intended effect

In media upload, the creator intends one intended managed asset. The operative object is media ingest request, connected with image file upload. This is not merely a vocabulary exercise: bytes may finish transferring before indexing completes. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is multiple redundant assets consuming storage. The available check is media library item and upload completion state, while the relevant identity signal is asset ID, file hash and upload session.

The important counterexample is a deliberate second version with different rights or metadata. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to compare asset identity and processing status rather than filename alone. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

12.3 Resume from the checkpoint

Suppose an earlier media ingest request was accepted but its confirmation failed to reach the creator. The first result might already exist.

Source wording: “Resume the interrupted operation from the last saved checkpoint.” Unsafe paraphrase: “Start all steps again.” What must survive: continue from trustworthy persisted progress, rather than repeating already completed work. In this workflow the protected outcome is one intended managed asset, and the error to prevent is multiple redundant assets consuming storage. The decisive evidence is a verified checkpoint and the subset of remaining steps, interpreted alongside asset ID, file hash and upload session.

Translation decision: Treat the source as an instruction about media ingest request, not as a general invitation to create image file upload. Never claim that unsaved work was retained. Compare asset identity and processing status rather than filename alone. Reader diagnostic: Can the reader identify the completed portion and the exact point of continuation? For this case the reviewer should consult media library item and upload completion state and compare it with the plausible independent second action: a deliberate second version with different rights or metadata.

12.6 Reprocess failed items only

Suppose the creator reports a missing confirmation after initiating image file upload. A later screen has no reliable final status.

Source wording: “Reprocess only the items marked failed; do not include completed items.” Unsafe paraphrase: “Run the full batch again.” What must survive: a deliberately limited processing set restricted to diagnosed failures. In this workflow the protected outcome is one intended managed asset, and the error to prevent is multiple redundant assets consuming storage. The decisive evidence is per-item status and durable evidence of earlier completion, interpreted alongside asset ID, file hash and upload session.

Translation decision: Treat the source as an instruction about media ingest request, not as a general invitation to create image file upload. The exception for completed items must remain attached to the scope. Compare asset identity and processing status rather than filename alone. Reader diagnostic: If half the items succeeded, would the translation keep the successful half out of the rerun? For this case the reviewer should consult media library item and upload completion state and compare it with the plausible independent second action: a deliberate second version with different rights or metadata.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. Be especially careful with the scope of ‘again’. It can modify a network attempt, an internal processing step, or an entire real-world operation, and those are different objects. Review the translation with an actual failure trace; a dictionary example alone will not expose this operational ambiguity.

12.9 Deduplicate matching records

Suppose one part of the workflow is complete while another stage is delayed. Bytes may finish transferring before indexing completes.

Source wording: “Deduplicate records using the defined business key.” Unsafe paraphrase: “Delete all records that look similar.” What must survive: equivalence is judged by the domain’s declared identity rule rather than superficial resemblance. In this workflow the protected outcome is one intended managed asset, and the error to prevent is multiple redundant assets consuming storage. The decisive evidence is the business key, review policy and rules for which record survives, interpreted alongside asset ID, file hash and upload session.

Translation decision: Treat the source as an instruction about media ingest request, not as a general invitation to create image file upload. Legitimate separate records must not be collapsed. Compare asset identity and processing status rather than filename alone. Reader diagnostic: Would two independent but visually identical actions remain distinguishable? For this case the reviewer should consult media library item and upload completion state and compare it with the plausible independent second action: a deliberate second version with different rights or metadata.

12.12 Acknowledge successful delivery

Suppose the creator intentionally asks for another instance after the first image file upload was completed. This is a new decision, not necessarily a recovery.

Source wording: “Acknowledge the message only after the required processing step succeeds.” Unsafe paraphrase: “Acknowledge immediately upon receipt.” What must survive: a protocol signal must follow a defined stage rather than merely arrival. In this workflow the protected outcome is one intended managed asset, and the error to prevent is multiple redundant assets consuming storage. The decisive evidence is whether work is durable and which stage the protocol requires, interpreted alongside asset ID, file hash and upload session.

Translation decision: Treat the source as an instruction about media ingest request, not as a general invitation to create image file upload. Do not convert receipt into evidence of downstream business completion. Compare asset identity and processing status rather than filename alone. Reader diagnostic: Would the translation lead to acknowledgment before work is safely recorded? For this case the reviewer should consult media library item and upload completion state and compare it with the plausible independent second action: a deliberate second version with different rights or metadata.

Domain synthesis: The media upload problem is solved only when the target distinguishes one intended managed asset from multiple redundant assets consuming storage and can establish the correct result using media library item and upload completion state. A deliberately new action, such as a deliberate second version with different rights or metadata, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 13: Newsletter delivery — preserving the intended effect

In newsletter delivery, the publisher intends the intended campaign communication. The operative object is campaign send, connected with subscriber notification. This is not merely a vocabulary exercise: sending may finish for some recipients but not others. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is multiple unwanted emails to one reader. The available check is send log and per-recipient delivery record, while the relevant identity signal is campaign ID and delivery recipient key.

The important counterexample is a genuinely separate correction or follow-up campaign. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to never infer that every recipient missed a campaign from one dashboard timeout. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

13.1 Retry the original request

Suppose the publisher reports a missing confirmation after initiating subscriber notification. A later screen has no reliable final status.

Source wording: “Retry the original request after the connection error.” Unsafe paraphrase: “Perform a second new action.” What must survive: another attempt to complete the same logical request, not authorization to create an additional independent result. In this workflow the protected outcome is the intended campaign communication, and the error to prevent is multiple unwanted emails to one reader. The decisive evidence is whether the earlier request’s result is unknown or confirmed, and whether stable request identity is supported, interpreted alongside campaign ID and delivery recipient key.

Translation decision: Treat the source as an instruction about campaign send, not as a general invitation to create subscriber notification. Same-operation identity must be retained when the contract supports it. Never infer that every recipient missed a campaign from one dashboard timeout. Reader diagnostic: If the first attempt had already committed, would a second attempt be recognized as the same intention? For this case the reviewer should consult send log and per-recipient delivery record and compare it with the plausible independent second action: a genuinely separate correction or follow-up campaign.

13.4 Restart the process

Suppose one part of the workflow is complete while another stage is delayed. Sending may finish for some recipients but not others.

Source wording: “Restart the process from the beginning.” Unsafe paraphrase: “Continue where you left off.” What must survive: begin anew under the specified process rules, with state retention or reset described separately. In this workflow the protected outcome is the intended campaign communication, and the error to prevent is multiple unwanted emails to one reader. The decisive evidence is whether earlier records or effects remain after the restart, interpreted alongside campaign ID and delivery recipient key.

Translation decision: Treat the source as an instruction about campaign send, not as a general invitation to create subscriber notification. Do not imply that restarting automatically undoes committed real-world effects. Never infer that every recipient missed a campaign from one dashboard timeout. Reader diagnostic: Does the translation make clear what a new beginning means for existing work? For this case the reviewer should consult send log and per-recipient delivery record and compare it with the plausible independent second action: a genuinely separate correction or follow-up campaign.

13.7 Resubmit after verification

Suppose the publisher intentionally asks for another instance after the first subscriber notification was completed. This is a new decision, not necessarily a recovery.

Source wording: “Verify submission status before resubmitting.” Unsafe paraphrase: “Submit again immediately.” What must survive: a status check is a prerequisite, not an optional background suggestion. In this workflow the protected outcome is the intended campaign communication, and the error to prevent is multiple unwanted emails to one reader. The decisive evidence is the possibility that acceptance occurred even though the original response was lost, interpreted alongside campaign ID and delivery recipient key.

Translation decision: Treat the source as an instruction about campaign send, not as a general invitation to create subscriber notification. Verify against a trustworthy record before issuing a new submission. Never infer that every recipient missed a campaign from one dashboard timeout. Reader diagnostic: Can the reader tell that no second submission is permitted before the check? For this case the reviewer should consult send log and per-recipient delivery record and compare it with the plausible independent second action: a genuinely separate correction or follow-up campaign.

13.10 Reconcile the uncertain result

Suppose an earlier campaign send was accepted but its confirmation failed to reach the publisher. The first result might already exist.

Source wording: “Reconcile the operation status before attempting recovery.” Unsafe paraphrase: “Repeat the operation to check whether it works.” What must survive: compare authoritative evidence to establish what actually happened before choosing another action. In this workflow the protected outcome is the intended campaign communication, and the error to prevent is multiple unwanted emails to one reader. The decisive evidence is trustworthy records, timestamps and the known limits of their information, interpreted alongside campaign ID and delivery recipient key.

Translation decision: Treat the source as an instruction about campaign send, not as a general invitation to create subscriber notification. Reconciliation is an evidence-gathering step, not an invitation to trigger a second effect. Never infer that every recipient missed a campaign from one dashboard timeout. Reader diagnostic: Is the first action’s actual state checked before a new effect can occur? For this case the reviewer should consult send log and per-recipient delivery record and compare it with the plausible independent second action: a genuinely separate correction or follow-up campaign.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. Precision here is reader care. The target should tell people the right action after a lost response without misleading them into making the same commitment again. Do not promise complete recovery where only a limited retry facility exists. The boundaries are part of the meaning.

13.13 Continue the unfinished batch

Suppose the publisher reports a missing confirmation after initiating subscriber notification. A later screen has no reliable final status.

Source wording: “Continue with remaining work without rerunning completed entries.” Unsafe paraphrase: “Restart the entire operation.” What must survive: continue remaining items while preserving earlier successful results. In this workflow the protected outcome is the intended campaign communication, and the error to prevent is multiple unwanted emails to one reader. The decisive evidence is item-level progress, not a single misleading all-or-nothing batch label, interpreted alongside campaign ID and delivery recipient key.

Translation decision: Treat the source as an instruction about campaign send, not as a general invitation to create subscriber notification. Preserve the negative instruction against replaying completed entries. Never infer that every recipient missed a campaign from one dashboard timeout. Reader diagnostic: Could the reader name what stays completed and what still needs processing? For this case the reviewer should consult send log and per-recipient delivery record and compare it with the plausible independent second action: a genuinely separate correction or follow-up campaign.

Domain synthesis: The newsletter delivery problem is solved only when the target distinguishes the intended campaign communication from multiple unwanted emails to one reader and can establish the correct result using send log and per-recipient delivery record. A deliberately new action, such as a genuinely separate correction or follow-up campaign, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 14: Inventory allocation — preserving the intended effect

In inventory allocation, the stock planner intends the intended units held for one demand. The operative object is allocation command, connected with reserved inventory. This is not merely a vocabulary exercise: some order lines may reserve while another line fails. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is stock reserved twice against one order. The available check is inventory movement log and reservation table, while the relevant identity signal is order line and reservation reference.

The important counterexample is a separate order for the same product quantity. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to review the line-level allocation result before trying again. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

14.2 Repeat the action

Suppose the stock planner intentionally asks for another instance after the first reserved inventory was completed. This is a new decision, not necessarily a recovery.

Source wording: “Repeat the action to create another result.” Unsafe paraphrase: “Try to finish the first failed request.” What must survive: a new instance may be intentionally wanted even when its fields match those of a previous instance. In this workflow the protected outcome is the intended units held for one demand, and the error to prevent is stock reserved twice against one order. The decisive evidence is an explicit fresh user intention rather than the visual similarity of the source fields, interpreted alongside order line and reservation reference.

Translation decision: Treat the source as an instruction about allocation command, not as a general invitation to create reserved inventory. Do not silently merge two legitimately separate intentions. Review the line-level allocation result before trying again. Reader diagnostic: Could the reader deliberately request another identical outcome without the system mistaking it for a retry? For this case the reviewer should consult inventory movement log and reservation table and compare it with the plausible independent second action: a separate order for the same product quantity.

14.5 Replay the event

Suppose an earlier allocation command was accepted but its confirmation failed to reach the stock planner. The first result might already exist.

Source wording: “Replay the recorded event in the test environment.” Unsafe paraphrase: “Repeat the real-world operation.” What must survive: reintroduce a recorded event to a defined processing context; replay is not by itself a command to reproduce external consequences. In this workflow the protected outcome is the intended units held for one demand, and the error to prevent is stock reserved twice against one order. The decisive evidence is the distinction between replay input and the receiving environment’s behavior, interpreted alongside order line and reservation reference.

Translation decision: Treat the source as an instruction about allocation command, not as a general invitation to create reserved inventory. Preserve test-versus-live boundaries and guard against external side effects. Review the line-level allocation result before trying again. Reader diagnostic: Would the target reader know whether replay changes a log, simulation, or live system? For this case the reviewer should consult inventory movement log and reservation table and compare it with the plausible independent second action: a separate order for the same product quantity.

14.8 Redeliver the message

Suppose the stock planner reports a missing confirmation after initiating reserved inventory. A later screen has no reliable final status.

Source wording: “The message may be redelivered if acknowledgment is not received.” Unsafe paraphrase: “A new message will be generated.” What must survive: the same published message may reach a consumer again, without implying a new publication or a new business event. In this workflow the protected outcome is the intended units held for one demand, and the error to prevent is stock reserved twice against one order. The decisive evidence is delivery identity and acknowledgment status, interpreted alongside order line and reservation reference.

Translation decision: Treat the source as an instruction about allocation command, not as a general invitation to create reserved inventory. The receiver must not infer that a redelivered message has never been processed. Review the line-level allocation result before trying again. Reader diagnostic: Does the translation distinguish receiving twice from performing the underlying action twice? For this case the reviewer should consult inventory movement log and reservation table and compare it with the plausible independent second action: a separate order for the same product quantity.

14.11 Retry with backoff

Suppose one part of the workflow is complete while another stage is delayed. Some order lines may reserve while another line fails.

Source wording: “Retry with increasing delay, up to the stated attempt limit.” Unsafe paraphrase: “Keep trying continuously until it works.” What must survive: repeat attempts are subject to waiting, a ceiling and eventual failure handling. In this workflow the protected outcome is the intended units held for one demand, and the error to prevent is stock reserved twice against one order. The decisive evidence is the specified retry policy and how the operation behaves under overload, interpreted alongside order line and reservation reference.

Translation decision: Treat the source as an instruction about allocation command, not as a general invitation to create reserved inventory. Retain both the interval rule and the maximum count, including whether the original attempt is counted. Review the line-level allocation result before trying again. Reader diagnostic: Would an operator know when to stop and what the delay requirement means? For this case the reviewer should consult inventory movement log and reservation table and compare it with the plausible independent second action: a separate order for the same product quantity.

14.14 Stop further attempts

Suppose the stock planner intentionally asks for another instance after the first reserved inventory was completed. This is a new decision, not necessarily a recovery.

Source wording: “Stop further retries after the limit is reached; do not reverse completed work.” Unsafe paraphrase: “Cancel and undo the whole transaction.” What must survive: future retry attempts cease while already committed effects retain their documented state. In this workflow the protected outcome is the intended units held for one demand, and the error to prevent is stock reserved twice against one order. The decisive evidence is the difference between stopping an automated attempt loop and compensating for a past action, interpreted alongside order line and reservation reference.

Translation decision: Treat the source as an instruction about allocation command, not as a general invitation to create reserved inventory. Never claim an undo operation where none is specified. Review the line-level allocation result before trying again. Reader diagnostic: Does the target correctly distinguish stopping new attempts from reversing old results? For this case the reviewer should consult inventory movement log and reservation table and compare it with the plausible independent second action: a separate order for the same product quantity.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. A human translator cannot repair a missing product contract by choosing a bolder synonym. When documentation does not say whether repeated actions are safe, mark the gap. Preserve the relationship between the requested operation and its evidence; the target should never imply a new intention without authorization.

Domain synthesis: The inventory allocation problem is solved only when the target distinguishes the intended units held for one demand from stock reserved twice against one order and can establish the correct result using inventory movement log and reservation table. A deliberately new action, such as a separate order for the same product quantity, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 15: Public application — preserving the intended effect

In public application, the applicant intends one accepted filing. The operative object is submitted form, connected with application filing. This is not merely a vocabulary exercise: files can upload even when the final acceptance check fails. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is two separate filings or conflicting applications. The available check is official acknowledgement and status register, while the relevant identity signal is application number and revision identity.

The important counterexample is an explicitly permitted replacement or supplemental filing. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to verify whether the submission is recorded before making another. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

15.3 Resume from the checkpoint

Suppose the applicant reports a missing confirmation after initiating application filing. A later screen has no reliable final status.

Source wording: “Resume the interrupted operation from the last saved checkpoint.” Unsafe paraphrase: “Start all steps again.” What must survive: continue from trustworthy persisted progress, rather than repeating already completed work. In this workflow the protected outcome is one accepted filing, and the error to prevent is two separate filings or conflicting applications. The decisive evidence is a verified checkpoint and the subset of remaining steps, interpreted alongside application number and revision identity.

Translation decision: Treat the source as an instruction about submitted form, not as a general invitation to create application filing. Never claim that unsaved work was retained. Verify whether the submission is recorded before making another. Reader diagnostic: Can the reader identify the completed portion and the exact point of continuation? For this case the reviewer should consult official acknowledgement and status register and compare it with the plausible independent second action: an explicitly permitted replacement or supplemental filing.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. The case is not solved by translating ‘idempotent’ into ‘safe’. Safety depends on what can change, which identifier is reused, and what external effects are possible. Cross-check a second source, such as the authoritative ledger or a documented API response, before concluding that an operation should be repeated.

15.6 Reprocess failed items only

Suppose one part of the workflow is complete while another stage is delayed. Files can upload even when the final acceptance check fails.

Source wording: “Reprocess only the items marked failed; do not include completed items.” Unsafe paraphrase: “Run the full batch again.” What must survive: a deliberately limited processing set restricted to diagnosed failures. In this workflow the protected outcome is one accepted filing, and the error to prevent is two separate filings or conflicting applications. The decisive evidence is per-item status and durable evidence of earlier completion, interpreted alongside application number and revision identity.

Translation decision: Treat the source as an instruction about submitted form, not as a general invitation to create application filing. The exception for completed items must remain attached to the scope. Verify whether the submission is recorded before making another. Reader diagnostic: If half the items succeeded, would the translation keep the successful half out of the rerun? For this case the reviewer should consult official acknowledgement and status register and compare it with the plausible independent second action: an explicitly permitted replacement or supplemental filing.

15.9 Deduplicate matching records

Suppose the applicant intentionally asks for another instance after the first application filing was completed. This is a new decision, not necessarily a recovery.

Source wording: “Deduplicate records using the defined business key.” Unsafe paraphrase: “Delete all records that look similar.” What must survive: equivalence is judged by the domain’s declared identity rule rather than superficial resemblance. In this workflow the protected outcome is one accepted filing, and the error to prevent is two separate filings or conflicting applications. The decisive evidence is the business key, review policy and rules for which record survives, interpreted alongside application number and revision identity.

Translation decision: Treat the source as an instruction about submitted form, not as a general invitation to create application filing. Legitimate separate records must not be collapsed. Verify whether the submission is recorded before making another. Reader diagnostic: Would two independent but visually identical actions remain distinguishable? For this case the reviewer should consult official acknowledgement and status register and compare it with the plausible independent second action: an explicitly permitted replacement or supplemental filing.

15.12 Acknowledge successful delivery

Suppose an earlier submitted form was accepted but its confirmation failed to reach the applicant. The first result might already exist.

Source wording: “Acknowledge the message only after the required processing step succeeds.” Unsafe paraphrase: “Acknowledge immediately upon receipt.” What must survive: a protocol signal must follow a defined stage rather than merely arrival. In this workflow the protected outcome is one accepted filing, and the error to prevent is two separate filings or conflicting applications. The decisive evidence is whether work is durable and which stage the protocol requires, interpreted alongside application number and revision identity.

Translation decision: Treat the source as an instruction about submitted form, not as a general invitation to create application filing. Do not convert receipt into evidence of downstream business completion. Verify whether the submission is recorded before making another. Reader diagnostic: Would the translation lead to acknowledgment before work is safely recorded? For this case the reviewer should consult official acknowledgement and status register and compare it with the plausible independent second action: an explicitly permitted replacement or supplemental filing.

Domain synthesis: The public application problem is solved only when the target distinguishes one accepted filing from two separate filings or conflicting applications and can establish the correct result using official acknowledgement and status register. A deliberately new action, such as an explicitly permitted replacement or supplemental filing, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 16: Emergency alerting — preserving the intended effect

In emergency alerting, the incident coordinator intends one authoritative message with the correct current status. The operative object is alert publication, connected with public alert. This is not merely a vocabulary exercise: some channels may distribute the warning before others. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is multiple contradictory alerts or alert fatigue. The available check is alert distribution logs and current incident bulletin, while the relevant identity signal is alert identifier, version and audience group.

The important counterexample is a necessary updated alert with new information. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to retain urgency, cancellation scope and version information. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

16.1 Retry the original request

Suppose one part of the workflow is complete while another stage is delayed. Some channels may distribute the warning before others.

Source wording: “Retry the original request after the connection error.” Unsafe paraphrase: “Perform a second new action.” What must survive: another attempt to complete the same logical request, not authorization to create an additional independent result. In this workflow the protected outcome is one authoritative message with the correct current status, and the error to prevent is multiple contradictory alerts or alert fatigue. The decisive evidence is whether the earlier request’s result is unknown or confirmed, and whether stable request identity is supported, interpreted alongside alert identifier, version and audience group.

Translation decision: Treat the source as an instruction about alert publication, not as a general invitation to create public alert. Same-operation identity must be retained when the contract supports it. Retain urgency, cancellation scope and version information. Reader diagnostic: If the first attempt had already committed, would a second attempt be recognized as the same intention? For this case the reviewer should consult alert distribution logs and current incident bulletin and compare it with the plausible independent second action: a necessary updated alert with new information.

16.4 Restart the process

Suppose the incident coordinator intentionally asks for another instance after the first public alert was completed. This is a new decision, not necessarily a recovery.

Source wording: “Restart the process from the beginning.” Unsafe paraphrase: “Continue where you left off.” What must survive: begin anew under the specified process rules, with state retention or reset described separately. In this workflow the protected outcome is one authoritative message with the correct current status, and the error to prevent is multiple contradictory alerts or alert fatigue. The decisive evidence is whether earlier records or effects remain after the restart, interpreted alongside alert identifier, version and audience group.

Translation decision: Treat the source as an instruction about alert publication, not as a general invitation to create public alert. Do not imply that restarting automatically undoes committed real-world effects. Retain urgency, cancellation scope and version information. Reader diagnostic: Does the translation make clear what a new beginning means for existing work? For this case the reviewer should consult alert distribution logs and current incident bulletin and compare it with the plausible independent second action: a necessary updated alert with new information.

16.7 Resubmit after verification

Suppose an earlier alert publication was accepted but its confirmation failed to reach the incident coordinator. The first result might already exist.

Source wording: “Verify submission status before resubmitting.” Unsafe paraphrase: “Submit again immediately.” What must survive: a status check is a prerequisite, not an optional background suggestion. In this workflow the protected outcome is one authoritative message with the correct current status, and the error to prevent is multiple contradictory alerts or alert fatigue. The decisive evidence is the possibility that acceptance occurred even though the original response was lost, interpreted alongside alert identifier, version and audience group.

Translation decision: Treat the source as an instruction about alert publication, not as a general invitation to create public alert. Verify against a trustworthy record before issuing a new submission. Retain urgency, cancellation scope and version information. Reader diagnostic: Can the reader tell that no second submission is permitted before the check? For this case the reviewer should consult alert distribution logs and current incident bulletin and compare it with the plausible independent second action: a necessary updated alert with new information.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. The source may include a reassuring interface word that conceals a technical precondition. The target should remain usable without deleting that safety condition. A good diagnostic is a counterfactual: if the first request secretly succeeded, would the target still direct the reader safely?

16.10 Reconcile the uncertain result

Suppose the incident coordinator reports a missing confirmation after initiating public alert. A later screen has no reliable final status.

Source wording: “Reconcile the operation status before attempting recovery.” Unsafe paraphrase: “Repeat the operation to check whether it works.” What must survive: compare authoritative evidence to establish what actually happened before choosing another action. In this workflow the protected outcome is one authoritative message with the correct current status, and the error to prevent is multiple contradictory alerts or alert fatigue. The decisive evidence is trustworthy records, timestamps and the known limits of their information, interpreted alongside alert identifier, version and audience group.

Translation decision: Treat the source as an instruction about alert publication, not as a general invitation to create public alert. Reconciliation is an evidence-gathering step, not an invitation to trigger a second effect. Retain urgency, cancellation scope and version information. Reader diagnostic: Is the first action’s actual state checked before a new effect can occur? For this case the reviewer should consult alert distribution logs and current incident bulletin and compare it with the plausible independent second action: a necessary updated alert with new information.

16.13 Continue the unfinished batch

Suppose one part of the workflow is complete while another stage is delayed. Some channels may distribute the warning before others.

Source wording: “Continue with remaining work without rerunning completed entries.” Unsafe paraphrase: “Restart the entire operation.” What must survive: continue remaining items while preserving earlier successful results. In this workflow the protected outcome is one authoritative message with the correct current status, and the error to prevent is multiple contradictory alerts or alert fatigue. The decisive evidence is item-level progress, not a single misleading all-or-nothing batch label, interpreted alongside alert identifier, version and audience group.

Translation decision: Treat the source as an instruction about alert publication, not as a general invitation to create public alert. Preserve the negative instruction against replaying completed entries. Retain urgency, cancellation scope and version information. Reader diagnostic: Could the reader name what stays completed and what still needs processing? For this case the reviewer should consult alert distribution logs and current incident bulletin and compare it with the plausible independent second action: a necessary updated alert with new information.

Domain synthesis: The emergency alerting problem is solved only when the target distinguishes one authoritative message with the correct current status from multiple contradictory alerts or alert fatigue and can establish the correct result using alert distribution logs and current incident bulletin. A deliberately new action, such as a necessary updated alert with new information, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 17: Software deployment — preserving the intended effect

In software deployment, the release engineer intends the intended service version deployed to the defined environment. The operative object is deployment job, connected with release rollout. This is not merely a vocabulary exercise: some nodes may update while others remain old. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is parallel conflicting rollouts. The available check is release controller history and current runtime version, while the relevant identity signal is release build and deployment job ID.

The important counterexample is a distinct rollout to another authorized environment. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to check deployment checkpoints and target environment before restarting. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

17.2 Repeat the action

Suppose an earlier deployment job was accepted but its confirmation failed to reach the release engineer. The first result might already exist.

Source wording: “Repeat the action to create another result.” Unsafe paraphrase: “Try to finish the first failed request.” What must survive: a new instance may be intentionally wanted even when its fields match those of a previous instance. In this workflow the protected outcome is the intended service version deployed to the defined environment, and the error to prevent is parallel conflicting rollouts. The decisive evidence is an explicit fresh user intention rather than the visual similarity of the source fields, interpreted alongside release build and deployment job ID.

Translation decision: Treat the source as an instruction about deployment job, not as a general invitation to create release rollout. Do not silently merge two legitimately separate intentions. Check deployment checkpoints and target environment before restarting. Reader diagnostic: Could the reader deliberately request another identical outcome without the system mistaking it for a retry? For this case the reviewer should consult release controller history and current runtime version and compare it with the plausible independent second action: a distinct rollout to another authorized environment.

17.5 Replay the event

Suppose the release engineer reports a missing confirmation after initiating release rollout. A later screen has no reliable final status.

Source wording: “Replay the recorded event in the test environment.” Unsafe paraphrase: “Repeat the real-world operation.” What must survive: reintroduce a recorded event to a defined processing context; replay is not by itself a command to reproduce external consequences. In this workflow the protected outcome is the intended service version deployed to the defined environment, and the error to prevent is parallel conflicting rollouts. The decisive evidence is the distinction between replay input and the receiving environment’s behavior, interpreted alongside release build and deployment job ID.

Translation decision: Treat the source as an instruction about deployment job, not as a general invitation to create release rollout. Preserve test-versus-live boundaries and guard against external side effects. Check deployment checkpoints and target environment before restarting. Reader diagnostic: Would the target reader know whether replay changes a log, simulation, or live system? For this case the reviewer should consult release controller history and current runtime version and compare it with the plausible independent second action: a distinct rollout to another authorized environment.

17.8 Redeliver the message

Suppose one part of the workflow is complete while another stage is delayed. Some nodes may update while others remain old.

Source wording: “The message may be redelivered if acknowledgment is not received.” Unsafe paraphrase: “A new message will be generated.” What must survive: the same published message may reach a consumer again, without implying a new publication or a new business event. In this workflow the protected outcome is the intended service version deployed to the defined environment, and the error to prevent is parallel conflicting rollouts. The decisive evidence is delivery identity and acknowledgment status, interpreted alongside release build and deployment job ID.

Translation decision: Treat the source as an instruction about deployment job, not as a general invitation to create release rollout. The receiver must not infer that a redelivered message has never been processed. Check deployment checkpoints and target environment before restarting. Reader diagnostic: Does the translation distinguish receiving twice from performing the underlying action twice? For this case the reviewer should consult release controller history and current runtime version and compare it with the plausible independent second action: a distinct rollout to another authorized environment.

17.11 Retry with backoff

Suppose the release engineer intentionally asks for another instance after the first release rollout was completed. This is a new decision, not necessarily a recovery.

Source wording: “Retry with increasing delay, up to the stated attempt limit.” Unsafe paraphrase: “Keep trying continuously until it works.” What must survive: repeat attempts are subject to waiting, a ceiling and eventual failure handling. In this workflow the protected outcome is the intended service version deployed to the defined environment, and the error to prevent is parallel conflicting rollouts. The decisive evidence is the specified retry policy and how the operation behaves under overload, interpreted alongside release build and deployment job ID.

Translation decision: Treat the source as an instruction about deployment job, not as a general invitation to create release rollout. Retain both the interval rule and the maximum count, including whether the original attempt is counted. Check deployment checkpoints and target environment before restarting. Reader diagnostic: Would an operator know when to stop and what the delay requirement means? For this case the reviewer should consult release controller history and current runtime version and compare it with the plausible independent second action: a distinct rollout to another authorized environment.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. Think of the translation as a contract between observed evidence and permitted behavior. Inferences that exceed the evidence are mistranslations even when elegant. Localize the prose, not the opaque identifiers or protocol keys that the service uses to recognise an existing action.

17.14 Stop further attempts

Suppose an earlier deployment job was accepted but its confirmation failed to reach the release engineer. The first result might already exist.

Source wording: “Stop further retries after the limit is reached; do not reverse completed work.” Unsafe paraphrase: “Cancel and undo the whole transaction.” What must survive: future retry attempts cease while already committed effects retain their documented state. In this workflow the protected outcome is the intended service version deployed to the defined environment, and the error to prevent is parallel conflicting rollouts. The decisive evidence is the difference between stopping an automated attempt loop and compensating for a past action, interpreted alongside release build and deployment job ID.

Translation decision: Treat the source as an instruction about deployment job, not as a general invitation to create release rollout. Never claim an undo operation where none is specified. Check deployment checkpoints and target environment before restarting. Reader diagnostic: Does the target correctly distinguish stopping new attempts from reversing old results? For this case the reviewer should consult release controller history and current runtime version and compare it with the plausible independent second action: a distinct rollout to another authorized environment.

Domain synthesis: The software deployment problem is solved only when the target distinguishes the intended service version deployed to the defined environment from parallel conflicting rollouts and can establish the correct result using release controller history and current runtime version. A deliberately new action, such as a distinct rollout to another authorized environment, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 18: Data migration — preserving the intended effect

In data migration, the data steward intends one traceable target representation for each source record. The operative object is migration batch, connected with record migration. This is not merely a vocabulary exercise: some records may be copied while validation fails on others. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is duplicated customer records or relationships. The available check is migration ledger, match map and reconciliation totals, while the relevant identity signal is source record key and import job ID.

The important counterexample is a new migration of a genuinely new source snapshot. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to resume from validated checkpoints where supported. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

18.3 Resume from the checkpoint

Suppose one part of the workflow is complete while another stage is delayed. Some records may be copied while validation fails on others.

Source wording: “Resume the interrupted operation from the last saved checkpoint.” Unsafe paraphrase: “Start all steps again.” What must survive: continue from trustworthy persisted progress, rather than repeating already completed work. In this workflow the protected outcome is one traceable target representation for each source record, and the error to prevent is duplicated customer records or relationships. The decisive evidence is a verified checkpoint and the subset of remaining steps, interpreted alongside source record key and import job ID.

Translation decision: Treat the source as an instruction about migration batch, not as a general invitation to create record migration. Never claim that unsaved work was retained. Resume from validated checkpoints where supported. Reader diagnostic: Can the reader identify the completed portion and the exact point of continuation? For this case the reviewer should consult migration ledger, match map and reconciliation totals and compare it with the plausible independent second action: a new migration of a genuinely new source snapshot.

18.6 Reprocess failed items only

Suppose the data steward intentionally asks for another instance after the first record migration was completed. This is a new decision, not necessarily a recovery.

Source wording: “Reprocess only the items marked failed; do not include completed items.” Unsafe paraphrase: “Run the full batch again.” What must survive: a deliberately limited processing set restricted to diagnosed failures. In this workflow the protected outcome is one traceable target representation for each source record, and the error to prevent is duplicated customer records or relationships. The decisive evidence is per-item status and durable evidence of earlier completion, interpreted alongside source record key and import job ID.

Translation decision: Treat the source as an instruction about migration batch, not as a general invitation to create record migration. The exception for completed items must remain attached to the scope. Resume from validated checkpoints where supported. Reader diagnostic: If half the items succeeded, would the translation keep the successful half out of the rerun? For this case the reviewer should consult migration ledger, match map and reconciliation totals and compare it with the plausible independent second action: a new migration of a genuinely new source snapshot.

18.9 Deduplicate matching records

Suppose an earlier migration batch was accepted but its confirmation failed to reach the data steward. The first result might already exist.

Source wording: “Deduplicate records using the defined business key.” Unsafe paraphrase: “Delete all records that look similar.” What must survive: equivalence is judged by the domain’s declared identity rule rather than superficial resemblance. In this workflow the protected outcome is one traceable target representation for each source record, and the error to prevent is duplicated customer records or relationships. The decisive evidence is the business key, review policy and rules for which record survives, interpreted alongside source record key and import job ID.

Translation decision: Treat the source as an instruction about migration batch, not as a general invitation to create record migration. Legitimate separate records must not be collapsed. Resume from validated checkpoints where supported. Reader diagnostic: Would two independent but visually identical actions remain distinguishable? For this case the reviewer should consult migration ledger, match map and reconciliation totals and compare it with the plausible independent second action: a new migration of a genuinely new source snapshot.

18.12 Acknowledge successful delivery

Suppose the data steward reports a missing confirmation after initiating record migration. A later screen has no reliable final status.

Source wording: “Acknowledge the message only after the required processing step succeeds.” Unsafe paraphrase: “Acknowledge immediately upon receipt.” What must survive: a protocol signal must follow a defined stage rather than merely arrival. In this workflow the protected outcome is one traceable target representation for each source record, and the error to prevent is duplicated customer records or relationships. The decisive evidence is whether work is durable and which stage the protocol requires, interpreted alongside source record key and import job ID.

Translation decision: Treat the source as an instruction about migration batch, not as a general invitation to create record migration. Do not convert receipt into evidence of downstream business completion. Resume from validated checkpoints where supported. Reader diagnostic: Would the translation lead to acknowledgment before work is safely recorded? For this case the reviewer should consult migration ledger, match map and reconciliation totals and compare it with the plausible independent second action: a new migration of a genuinely new source snapshot.

Domain synthesis: The data migration problem is solved only when the target distinguishes one traceable target representation for each source record from duplicated customer records or relationships and can establish the correct result using migration ledger, match map and reconciliation totals. A deliberately new action, such as a new migration of a genuinely new source snapshot, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 19: Charity donation — preserving the intended effect

In charity donation, the donor intends one intended contribution. The operative object is giving request, connected with donation transfer. This is not merely a vocabulary exercise: payment acceptance may precede receipt generation. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is two unintended charitable charges. The available check is donation processor receipt and charity ledger, while the relevant identity signal is donation reference and payment token.

The important counterexample is a donor deliberately making a second equivalent gift. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to show donation status before another payment action. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

19.1 Retry the original request

Suppose the donor intentionally asks for another instance after the first donation transfer was completed. This is a new decision, not necessarily a recovery.

Source wording: “Retry the original request after the connection error.” Unsafe paraphrase: “Perform a second new action.” What must survive: another attempt to complete the same logical request, not authorization to create an additional independent result. In this workflow the protected outcome is one intended contribution, and the error to prevent is two unintended charitable charges. The decisive evidence is whether the earlier request’s result is unknown or confirmed, and whether stable request identity is supported, interpreted alongside donation reference and payment token.

Translation decision: Treat the source as an instruction about giving request, not as a general invitation to create donation transfer. Same-operation identity must be retained when the contract supports it. Show donation status before another payment action. Reader diagnostic: If the first attempt had already committed, would a second attempt be recognized as the same intention? For this case the reviewer should consult donation processor receipt and charity ledger and compare it with the plausible independent second action: a donor deliberately making a second equivalent gift.

19.4 Restart the process

Suppose an earlier giving request was accepted but its confirmation failed to reach the donor. The first result might already exist.

Source wording: “Restart the process from the beginning.” Unsafe paraphrase: “Continue where you left off.” What must survive: begin anew under the specified process rules, with state retention or reset described separately. In this workflow the protected outcome is one intended contribution, and the error to prevent is two unintended charitable charges. The decisive evidence is whether earlier records or effects remain after the restart, interpreted alongside donation reference and payment token.

Translation decision: Treat the source as an instruction about giving request, not as a general invitation to create donation transfer. Do not imply that restarting automatically undoes committed real-world effects. Show donation status before another payment action. Reader diagnostic: Does the translation make clear what a new beginning means for existing work? For this case the reviewer should consult donation processor receipt and charity ledger and compare it with the plausible independent second action: a donor deliberately making a second equivalent gift.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. Precision here is reader care. The target should tell people the right action after a lost response without misleading them into making the same commitment again. Mark the outcome as uncertain if the original does not prove it; that is more faithful than smoothing the message into a false yes-or-no.

19.7 Resubmit after verification

Suppose the donor reports a missing confirmation after initiating donation transfer. A later screen has no reliable final status.

Source wording: “Verify submission status before resubmitting.” Unsafe paraphrase: “Submit again immediately.” What must survive: a status check is a prerequisite, not an optional background suggestion. In this workflow the protected outcome is one intended contribution, and the error to prevent is two unintended charitable charges. The decisive evidence is the possibility that acceptance occurred even though the original response was lost, interpreted alongside donation reference and payment token.

Translation decision: Treat the source as an instruction about giving request, not as a general invitation to create donation transfer. Verify against a trustworthy record before issuing a new submission. Show donation status before another payment action. Reader diagnostic: Can the reader tell that no second submission is permitted before the check? For this case the reviewer should consult donation processor receipt and charity ledger and compare it with the plausible independent second action: a donor deliberately making a second equivalent gift.

19.10 Reconcile the uncertain result

Suppose one part of the workflow is complete while another stage is delayed. Payment acceptance may precede receipt generation.

Source wording: “Reconcile the operation status before attempting recovery.” Unsafe paraphrase: “Repeat the operation to check whether it works.” What must survive: compare authoritative evidence to establish what actually happened before choosing another action. In this workflow the protected outcome is one intended contribution, and the error to prevent is two unintended charitable charges. The decisive evidence is trustworthy records, timestamps and the known limits of their information, interpreted alongside donation reference and payment token.

Translation decision: Treat the source as an instruction about giving request, not as a general invitation to create donation transfer. Reconciliation is an evidence-gathering step, not an invitation to trigger a second effect. Show donation status before another payment action. Reader diagnostic: Is the first action’s actual state checked before a new effect can occur? For this case the reviewer should consult donation processor receipt and charity ledger and compare it with the plausible independent second action: a donor deliberately making a second equivalent gift.

19.13 Continue the unfinished batch

Suppose the donor intentionally asks for another instance after the first donation transfer was completed. This is a new decision, not necessarily a recovery.

Source wording: “Continue with remaining work without rerunning completed entries.” Unsafe paraphrase: “Restart the entire operation.” What must survive: continue remaining items while preserving earlier successful results. In this workflow the protected outcome is one intended contribution, and the error to prevent is two unintended charitable charges. The decisive evidence is item-level progress, not a single misleading all-or-nothing batch label, interpreted alongside donation reference and payment token.

Translation decision: Treat the source as an instruction about giving request, not as a general invitation to create donation transfer. Preserve the negative instruction against replaying completed entries. Show donation status before another payment action. Reader diagnostic: Could the reader name what stays completed and what still needs processing? For this case the reviewer should consult donation processor receipt and charity ledger and compare it with the plausible independent second action: a donor deliberately making a second equivalent gift.

Domain synthesis: The charity donation problem is solved only when the target distinguishes one intended contribution from two unintended charitable charges and can establish the correct result using donation processor receipt and charity ledger. A deliberately new action, such as a donor deliberately making a second equivalent gift, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Worked domain 20: Maintenance order — preserving the intended effect

In maintenance order, the field technician intends one recorded service action with evidence. The operative object is work order task, connected with maintenance intervention. This is not merely a vocabulary exercise: physical work may finish before electronic sign-off is synchronized. A localized notice that overlooks that intermediate state can suggest a second operation even though a first operation may already have taken effect. The practical duplicate risk is duplicate visits or repeated unsafe procedures. The available check is completed checklist and asset service history, while the relevant identity signal is asset ID and work order number.

The important counterexample is a scheduled second inspection with distinct authorization. Such a request can resemble a duplicate but be a legitimate new intention. Do not translate duplicate prevention as a blanket ban on everything similar. A safe working assumption is to verify real-world completion before issuing a new instruction. Once this distinction is understood, the same reader can recognise why ‘retry’ and ‘repeat’ may need different target expressions within one interface.

20.2 Repeat the action

Suppose the field technician reports a missing confirmation after initiating maintenance intervention. A later screen has no reliable final status.

Source wording: “Repeat the action to create another result.” Unsafe paraphrase: “Try to finish the first failed request.” What must survive: a new instance may be intentionally wanted even when its fields match those of a previous instance. In this workflow the protected outcome is one recorded service action with evidence, and the error to prevent is duplicate visits or repeated unsafe procedures. The decisive evidence is an explicit fresh user intention rather than the visual similarity of the source fields, interpreted alongside asset ID and work order number.

Translation decision: Treat the source as an instruction about work order task, not as a general invitation to create maintenance intervention. Do not silently merge two legitimately separate intentions. Verify real-world completion before issuing a new instruction. Reader diagnostic: Could the reader deliberately request another identical outcome without the system mistaking it for a retry? For this case the reviewer should consult completed checklist and asset service history and compare it with the plausible independent second action: a scheduled second inspection with distinct authorization.

20.5 Replay the event

Suppose one part of the workflow is complete while another stage is delayed. Physical work may finish before electronic sign-off is synchronized.

Source wording: “Replay the recorded event in the test environment.” Unsafe paraphrase: “Repeat the real-world operation.” What must survive: reintroduce a recorded event to a defined processing context; replay is not by itself a command to reproduce external consequences. In this workflow the protected outcome is one recorded service action with evidence, and the error to prevent is duplicate visits or repeated unsafe procedures. The decisive evidence is the distinction between replay input and the receiving environment’s behavior, interpreted alongside asset ID and work order number.

Translation decision: Treat the source as an instruction about work order task, not as a general invitation to create maintenance intervention. Preserve test-versus-live boundaries and guard against external side effects. Verify real-world completion before issuing a new instruction. Reader diagnostic: Would the target reader know whether replay changes a log, simulation, or live system? For this case the reviewer should consult completed checklist and asset service history and compare it with the plausible independent second action: a scheduled second inspection with distinct authorization.

20.8 Redeliver the message

Suppose the field technician intentionally asks for another instance after the first maintenance intervention was completed. This is a new decision, not necessarily a recovery.

Source wording: “The message may be redelivered if acknowledgment is not received.” Unsafe paraphrase: “A new message will be generated.” What must survive: the same published message may reach a consumer again, without implying a new publication or a new business event. In this workflow the protected outcome is one recorded service action with evidence, and the error to prevent is duplicate visits or repeated unsafe procedures. The decisive evidence is delivery identity and acknowledgment status, interpreted alongside asset ID and work order number.

Translation decision: Treat the source as an instruction about work order task, not as a general invitation to create maintenance intervention. The receiver must not infer that a redelivered message has never been processed. Verify real-world completion before issuing a new instruction. Reader diagnostic: Does the translation distinguish receiving twice from performing the underlying action twice? For this case the reviewer should consult completed checklist and asset service history and compare it with the plausible independent second action: a scheduled second inspection with distinct authorization.

Read it as an operator rule: The operator must preserve identity, authorization, scope and a recoverable evidence trail rather than rely on the apparent similarity of buttons. A human translator cannot repair a missing product contract by choosing a bolder synonym. When documentation does not say whether repeated actions are safe, mark the gap. Keep the current stage visible to the reader. A receipt, queue position and final settlement are different pieces of evidence.

20.11 Retry with backoff

Suppose an earlier work order task was accepted but its confirmation failed to reach the field technician. The first result might already exist.

Source wording: “Retry with increasing delay, up to the stated attempt limit.” Unsafe paraphrase: “Keep trying continuously until it works.” What must survive: repeat attempts are subject to waiting, a ceiling and eventual failure handling. In this workflow the protected outcome is one recorded service action with evidence, and the error to prevent is duplicate visits or repeated unsafe procedures. The decisive evidence is the specified retry policy and how the operation behaves under overload, interpreted alongside asset ID and work order number.

Translation decision: Treat the source as an instruction about work order task, not as a general invitation to create maintenance intervention. Retain both the interval rule and the maximum count, including whether the original attempt is counted. Verify real-world completion before issuing a new instruction. Reader diagnostic: Would an operator know when to stop and what the delay requirement means? For this case the reviewer should consult completed checklist and asset service history and compare it with the plausible independent second action: a scheduled second inspection with distinct authorization.

20.14 Stop further attempts

Suppose the field technician reports a missing confirmation after initiating maintenance intervention. A later screen has no reliable final status.

Source wording: “Stop further retries after the limit is reached; do not reverse completed work.” Unsafe paraphrase: “Cancel and undo the whole transaction.” What must survive: future retry attempts cease while already committed effects retain their documented state. In this workflow the protected outcome is one recorded service action with evidence, and the error to prevent is duplicate visits or repeated unsafe procedures. The decisive evidence is the difference between stopping an automated attempt loop and compensating for a past action, interpreted alongside asset ID and work order number.

Translation decision: Treat the source as an instruction about work order task, not as a general invitation to create maintenance intervention. Never claim an undo operation where none is specified. Verify real-world completion before issuing a new instruction. Reader diagnostic: Does the target correctly distinguish stopping new attempts from reversing old results? For this case the reviewer should consult completed checklist and asset service history and compare it with the plausible independent second action: a scheduled second inspection with distinct authorization.

Domain synthesis: The maintenance order problem is solved only when the target distinguishes one recorded service action with evidence from duplicate visits or repeated unsafe procedures and can establish the correct result using completed checklist and asset service history. A deliberately new action, such as a scheduled second inspection with distinct authorization, must remain possible under its actual authorization rules. That is the central meaning-preservation test for this environment.

Cross-domain failure modes and precise repair decisions

1. An error becomes proof of failure. A timeout reports communication trouble, not necessarily the outcome of the original work. Repair: Rewrite as ‘Status not confirmed’ when the source supports uncertainty; keep any verified result in a separate field.
2. A ‘retry’ becomes a new order. A second click is framed as buying or submitting another instance. Repair: Preserve request identity and describe the same logical operation as the retry target.
3. A ‘repeat’ becomes an idempotent retry. A legitimate second action is silently folded into the first. Repair: Identify explicit fresh user intention and distinguish it from a failed first attempt.
4. Saved state disappears from ‘resume’. The target says to begin again despite a checkpoint. Repair: Name the checkpoint and remaining work when known; do not invent restoration of unsaved stages.
5. Restart claims to undo. The translation suggests that starting over reverses committed effects. Repair: Separate beginning a process again from compensating for or reversing a prior result.
6. Replay means live execution. A test event re-ingestion is described as performing the real-world action again. Repair: Preserve test environment and event-input scope; document any true live side effects separately.
7. The whole batch replaces failed items. The word ‘only’ disappears from a failed-item retry instruction. Repair: Reattach the restriction to the item set and test with one success plus one failure.
8. A duplicate key is translated. An identifier used for matching is localized as if it were a sentence. Repair: Protect machine tokens and translate only the explanatory label.
9. Acknowledged becomes completed. Receipt or delivery is upgraded to final settlement. Repair: Specify the stage acknowledged and do not claim downstream completion.
10. No acknowledgment becomes no delivery. The target assumes that silence means nothing arrived. Repair: Preserve possibility of processed but unacknowledged work.
11. Up to three is rendered as at least three. A ceiling becomes a minimum. Repair: Keep upper-bound language, including whether the initial attempt counts.
12. Backoff becomes instant retry. A waiting policy disappears. Repair: Retain the timing rule and avoid inventing an exact interval.
13. Automatic becomes manual. The target tells the user to do what the system handles. Repair: Keep actor and voice: ‘system retries’ versus ‘you may retry’.
14. Manual becomes automatic. The target promises background action that does not exist. Repair: Use an explicit user-command phrase when the source demands user intervention.
15. Pending is translated as failed. An incomplete state is treated as a terminal negative result. Repair: Retain pending or unknown; offer an evidence check rather than a premature retry.
16. Failed is translated as pending. A terminal failure is softened into apparent progress. Repair: Preserve terminal state and approved next action; avoid misleading optimism.
17. Idempotent becomes risk-free. The translated statement promises no side effects of any kind. Repair: Describe the intended-effect property at the documented operation scope.
18. Exactly once is generalized. A scoped transport guarantee becomes a universal processing promise. Repair: State the relevant subscription, region, stage or application assumption when provided.
19. Duplicate records are deleted on appearance. Similarity is substituted for business identity. Repair: Preserve the matching key and conflict-resolution rule.
20. Real duplicates are kept as new. A stable request identity is ignored. Repair: Review the ID and resulting effect, not merely the display formatting.
21. Source ambiguity is hidden. The translator chooses a confident technical conclusion with no documentation. Repair: Mark the unresolved contract and ask the system owner for authoritative wording.
22. An imperative changes responsibility. Passive background behavior becomes a reader instruction. Repair: Preserve who has to act and when.
23. A prohibition is softened. ‘Do not retry’ becomes ‘retry carefully’. Repair: Restore the full prohibition and its governing conditions.
24. A condition attaches to the wrong clause. ‘After confirming’ modifies sending instead of checking. Repair: Diagram clause relations and retest with a lost-confirmation scenario.
25. A partial batch is described as complete. One aggregate status hides item-level failures. Repair: Retain item-level success/failure and explain the aggregation.
26. A response is mistaken for a receipt. A screen message is treated as a durable record. Repair: Specify whether there is a transaction receipt, log ID or only a transient notification.
27. A new version is called a duplicate. An intentional document revision is collapsed into an old version. Repair: Track version identity separately from repeated transmission.
28. A revision is called a new operation. A reattempt to upload one revision becomes a second distinct revision. Repair: Keep the same version ID while retrying transfer.
29. A stopped retry loop becomes cancellation. The translated text implies that already committed work is undone. Repair: Explain that further attempts stop and earlier effects require separate reconciliation.
30. A same-payload shortcut decides intent. An application equates identical fields with an identical user action. Repair: Use an explicit logical request identifier and retain the possibility of legitimate identical new actions.
31. Review tests only the happy path. A beautiful target string is approved without uncertain-commit testing. Repair: Test a response-loss case, a valid fresh action and a partially complete batch.
32. A non-translatable placeholder changes. Localized text accidentally alters a token referenced by code. Repair: Protect placeholder syntax and run a rendering test after translation.
33. A privacy-sensitive audit is exposed. The translated check tells readers to disclose secret IDs publicly. Repair: Specify a secure account-status route without publishing credentials or sensitive records.
34. An apology changes the legal promise. The translator adds a refund or completion guarantee not stated in the source. Repair: Keep empathy separate from verified operational commitments.
35. A completion count loses its denominator. ‘Five processed’ is presented as ‘all processed’. Repair: Preserve numerator, denominator and what ‘processed’ means.
36. The same verb is forced everywhere. A glossary dictates one equivalent across UI, programming and everyday use. Repair: Use a concept entry with meaning notes and contextual variants.
37. A fallback hides a retry ceiling. The system switches methods after failure, but the translation implies unbounded retries. Repair: Represent the conditional transition and the attempt limit independently.
38. An old status persists after reconciliation. Target text remains ‘pending’ even after the authoritative ledger confirms final state. Repair: Version the localized message with its data source and stage, not with guesswork.

A repeatable translator’s test bench

Build a four-column review sheet: source phrase, intended effect, uncertain-state counterexample and acceptable target-language effect. Do not score a translation only by whether a fluent reader likes it. Give it a failure scenario. If the first operation succeeded but the response disappeared, would a user following the translated text create a new effect? If the first operation truly failed, would the instruction allow a legitimate recovery? If the user now wants a second independent action, would the text incorrectly suppress that choice? Those three questions expose most false synonym choices.

Next, test a partial batch and a delayed acknowledgment. These are different failure patterns. A partially processed batch has successful and failed items; a delayed acknowledgment may conceal completed work with no visible confirmation. Your target wording should preserve the narrower truth in each case. It should also preserve the identity of the item or request, the limit on additional attempts, the reader’s available verification route and any escalation trigger.

During bilingual review, ask the second reviewer to explain the operational meaning back to you without seeing the English source. Their answer should cover who retries, what is retried, whether the same or new operation is meant, what is known about the previous result, and what must not happen twice. If they cannot answer those questions after reading a single button, the product needs accompanying context. That is a design finding, not proof that the translator lacks vocabulary.

A glossary of conditional phrases that should not be diluted

Source qualifier	What it contributes
if the first attempt did not complete	The retry is conditional on incomplete execution, not mere frustration.
if the result cannot be confirmed	Uncertainty is the trigger; a separate verification route may be needed.
only for transient errors	The retry class is restricted; permanent validation failures require another response.
using the same request identifier	Logical identity persists across attempts; do not generate a new one in translation.
once the previous attempt is verified	Evidence precedes action, not the other way around.
without repeating completed steps	A continuation excludes durable earlier progress.
up to three attempts	There is an upper bound, not a mandatory minimum.
after a delay	The next attempt must not be immediate.
with exponential backoff	Delays grow according to a specified policy, not necessarily a fixed number of seconds.
unless already processed	Earlier completion is an exception to further processing.
until acknowledged	A protocol signal determines cessation, not necessarily downstream finality.
only when authorized	Operational permission is a separate condition from technical possibility.
not safe to retry automatically	Automatic attempts are prohibited; manual handling may still require checks.
replay in a test environment	The location in the computing system, not a geographic location, limits the operation’s meaning.
ignore repeated delivery of the same event	The event identity determines suppression, not the arrival count.
show the original transaction status	The user needs evidence about the first action rather than another new action.
continue with outstanding items	Only remaining work is in scope.
the outcome is unknown	The statement explicitly avoids asserting success or failure.
do not resend a payment	A direct negative instruction is an important safety boundary.
a new request requires a new identifier	This is a new intended action, not a retry of the earlier one.

Twenty-five reader exercises with explanations

1. The screen timed out after a donation. Do not conclude the gift failed. Find the authoritative donation record; another charge is a separate step. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
2. A user presses ‘repeat purchase’ after success. This may be a legitimate new order. Preventing duplicate retries must not silently stop intentional purchases. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
3. A batch reports 83 of 100 entries complete. The remaining scope is seventeen entries, subject to item-level status; a full rerun could duplicate eighty-three effects. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
4. An app says ‘resuming from checkpoint 7’. The source promises a continuation only from a saved checkpoint. Do not claim restoration of unsaved edits. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
5. A test harness replays recorded events. Translate it as reintroducing test inputs. Do not imply that the original real-world event happens again. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
6. Two receipts share the same amount. Equal amounts are not enough to establish duplicate business intention. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
7. The same request ID appears in two logs. It may indicate separate attempts at one logical action, but verify the contract and result before assuming equivalence. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
8. A client receives HTTP 500 with unknown commit status. The status alone may not prove the work did not happen. Retry guidance must depend on documented operation semantics. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
9. A queue redelivers after an ack deadline. Delivery repeated; processing and external effect remain separate questions. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
10. An operator is told ‘retry up to four times’. Preserve the ceiling, and clarify whether that count includes the initial attempt when the source defines it. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
11. A restart button leaves a draft. The product behavior determines whether ‘restart’ can coexist with saved work; translate the source contract, not the word’s intuition. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
12. An alert is distributed to most channels. The progress metric cannot be translated as full audience delivery. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
13. A software job says ‘reprocess invalid rows’. Only the designated invalid rows should be in scope, not every record in the import. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
14. An API promises idempotent replacement. Preserve what operation has that intended-effect property; do not generalize to every endpoint. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
15. A client token is reused across retries. Keep the token opaque and unchanged; it may be the evidence linking attempts. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
16. A recipient gets the same email twice. Delivery duplication does not prove a campaign was newly published twice. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
17. A refund was initiated but not settled. Do not translate ‘initiated’ as ‘refunded in full’. These are distinct states. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
18. A form returns a receipt ID but no email. Email absence is not proof of submission absence. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
19. A laboratory repeats a measurement. A purposeful replicate is different from rerunning an uncertain job under the same run ID. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
20. An examiner permits a formal second attempt. An authorized resit should be described as a new attempt, not merely a retry after network failure. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
21. An import deduplicates by customer identifier. The key is the domain identity rule; two different customers with the same name need separate records. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
22. A user clicks ‘stop retries’. This limits future attempts. It should not be described as undoing an already committed request. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
23. The system ‘will retry automatically’. Do not turn automatic handling into an instruction requiring a user click. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
24. A notification says ‘operation completed’ before ledger confirmation. The translator must reflect whichever stage the source truly guarantees, and flag misleading product text. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.
25. Two matching parcels carry different consignment IDs. They may be two legitimate physical shipments. Do not deduplicate by description alone. Ask the reviewer to write a target-language sentence, identify one prohibited interpretation, and explain the evidence that would confirm the correct status.

How to learn the distinction across language pairs

This is a world-facing translation architecture, not an English-only glossary. Some target languages use one everyday word for two of these operations and distinguish them through objects, prepositions, aspect, adverbs, explicit conditions or a longer phrase. That does not mean accurate translation is impossible. It means the target-language construction must restore what the bare lexical item cannot carry. A translator may write a slightly longer button description or help message where the interface permits it, while retaining a short verified label.

Develop a concept-oriented glossary rather than a one-to-one word list. Each record should have the source concept, a concise definition, a positive example, a counterexample, relevant interface context, machine tokens to preserve and a reviewer note about ambiguous neighboring concepts. Include ‘retry same request’, ‘repeat new action’, ‘resume saved progress’, ‘restart from beginning’, ‘replay recorded event’, ‘redeliver identical message’ and ‘reconcile uncertain status’ as separate entries. Test them in actual sentences, not just as isolated glossary lines.

Machine translation and AI tools can help generate alternatives, find inconsistencies and draft first versions. They cannot establish a system’s undocumented idempotency behavior simply by predicting likely wording. A human or verified specification must determine what the product actually guarantees. Use automated systems as candidate generators and checkers, not as witnesses to hidden execution. Evaluate accuracy, omission, overtranslation, mistranslation and terminology consistency as separate categories rather than blending them into a single ‘sounds natural’ score.

Quality gates: when a translation is ready to publish

• Source meaning is explicit: the reviewer can separate the original action, another attempt, a new intentional action and the known outcome.
• The target identifies the right actor and object: no hidden transfer of responsibility from software to user or user to software.
• Status wording is evidence-grounded: unknown, pending, delivered, acknowledged, processed and completed are not interchanged.
• Identity is protected: any retry token, request identifier, original reference or untranslatable key is preserved.
• Duplicate controls are stated with the correct criterion: logical request identity, not mere resemblance.
• Scope and time are preserved: only, after, until, no more than, selected items and checkpoints remain attached to the right actions.
• Negative and conditional warnings survive: especially ‘do not retry’ and ‘verify before resubmitting’.
• The target has passed an uncertain-commit test, a genuine new-operation test, a partial-completion test and a delayed-acknowledgment test.
• A native-language reviewer can explain what a reasonable reader is supposed to do without inventing a promise.
• A domain owner has signed off on any technical claim the translation alone cannot establish.

Frequently asked questions about retry, replay and duplicate prevention

1. Is retry the same as repeat?

No. Retry commonly means another attempt to complete a prior intended operation after difficulty. Repeat may mean creating another separate result. The context and documented service contract decide the correct sense.

2. What is an idempotent operation in plain language?

It is an operation whose intended effect after several identical requests is the same as after one request, under its specified semantics. This does not guarantee identical response text or absence of all secondary activity.

3. Does HTTP POST always create duplicates?

No. POST is not defined as idempotent by the HTTP standard, but an application can provide its own safe-retry contract, such as a unique request identifier. Read the specific API documentation.

4. Can a timeout mean success?

Yes. A result may be committed while the response is lost. Translate a timeout as uncertainty unless the source explicitly and reliably establishes a final status.

5. Is resend different from redeliver?

Often. Resend may describe sending again, potentially as a new send operation. Redeliver describes delivering a message again, often with the same original message identity. Product terminology may refine this distinction.

6. What does resume actually promise?

Continuation from supported saved progress or an interruption point. The existence and exact scope of the checkpoint must be established from the product behavior.

7. Does restart erase earlier effects?

Not necessarily. Restart may begin a process again without undoing completed external actions. Clarify state retention and reset rules rather than translating a guess.

8. Why does replay need a warning?

Because replaying a recorded event in a test environment differs from rerunning an external real-world effect. The target should preserve the environment and any side-effect boundaries.

9. Why not deduplicate identical-looking requests?

Because a user may intentionally make two identical purchases, reports, donations or jobs. The equivalence criterion must reflect logical intent, not just equal fields.

10. Does acknowledgment prove completion?

It proves only the stage the protocol says it proves. A receipt acknowledgment and a completed business transaction are not automatically the same.

11. What is exponential backoff?

A retry approach in which waiting intervals grow according to a policy. Translate the source’s actual schedule, attempt limits and exceptions rather than assuming a specific formula.

12. What does ‘up to three retries’ mean?

At most three additional retry attempts in ordinary wording, although documentation may define counts differently. Verify the intended counting rule for a technical specification.

13. Is ‘exactly once’ always literal?

The guarantee is meaningful only within a specified scope and assumptions. A transport’s delivery promise need not cover every downstream side effect or publisher duplicate.

14. What if a source string simply says ‘Try again’?

Inspect where it appears and what the button actually does. A short UI label may need adjacent state text or a warning to avoid a dangerous assumption.

15. Can two target expressions be correct?

Yes, if both preserve the same scope, stage, effect and implied reader action. Equivalence is about operational meaning, not a single mandatory word.

16. Should technical identifiers be translated?

Usually not when they are opaque machine tokens. Preserve identifiers and translate their explanatory labels as instructed by the resource contract.

17. Can translation solve a broken product design?

It can expose a contradiction but cannot certify behavior that the product does not document. Raise a localization issue and request an owner decision.

18. Is retry safe for payments?

Do not assume so. Follow the payment provider’s documented idempotency and status-verification process; a missing confirmation alone does not justify a new charge.

19. Is a partial batch a failure?

It is a mixed outcome if some items succeeded and others did not. Translation should communicate item-level progress rather than imply everything failed or completed.

20. How do I translate ‘failed items only’?

Preserve both ‘failed’ and ‘only’. The phrase prohibits including completed items, which may have irreversible effects if rerun.

21. What is the best reviewer question?

Ask: if the first attempt secretly succeeded, would the target instruction create an unintended second result? Then test the opposite case of genuine failure.

22. What if the source distinguishes ‘queued’ from ‘processed’?

Keep the distinction. Queued means awaiting the processing stage; it does not promise that the item has already been processed or settled.

23. Can a redelivered message be processed twice?

It can be processed again unless the consumer design prevents unwanted duplicate effects. Delivery guarantees and processing guarantees should be evaluated separately.

24. How does translation memory help?

It can preserve reviewed term choices and warning phrasing, but must be checked when an operation’s identity, time or state constraints change.

25. How does English grammar relate to this?

Aspect, modality, conditionals, negation and reference tracking matter when distinguishing completed actions from possibilities and commands. The specialist English owner covers the wider grammar.

26. How does vocabulary learning relate to this?

Vocabulary work builds lexical knowledge and contrastive meanings. Translation adds cross-language operational decisions and reader-effect testing to that foundation.

27. Can a retry be automatic?

Yes, when supported by the application’s policy. Translate whether the system or user initiates the retry, and what conditions limit it.

28. What should a translator do if there is no specification?

Record uncertainty, avoid unsupported guarantees and seek an authoritative product or domain review before release. Do not manufacture operational truth.

29. Why does the article use many unrelated environments?

A meaning distinction is robust only when it transfers beyond one software button. Different domains expose different costs of a duplicated or missed action.

30. Where should I study next?

Return to the translation root for the complete map. Use the preceding change-operation chapter for update verbs, and the protected Vocabulary and English hubs for their specialist learning questions.

Research notes, authoritative terminology and limits

The sources below support the standards and conceptual boundaries discussed here. They do not certify the behavior of the hypothetical interfaces in our teaching cases. Technical guarantees are versioned and product-specific; always check an implementation’s current documentation when making operational commitments. These sources were consulted for this chapter on 6 November 2026.

• IETF HTTP Semantics, RFC 9110, section 9.2.2
• AWS Builders’ Library, Making retries safe with idempotent APIs
• Google Cloud Pub/Sub, Exactly-once delivery
• MQM Council, Core Quality Typology
• W3C, Internationalization Tag Set (ITS) 2.0

The MQM framework helps classify whether a target message has lost, added or distorted source meaning. W3C ITS 2.0 describes internationalization metadata including terminology, translatability and provenance. The engineering references explain idempotency and the scope of retry or message-delivery guarantees; the article uses them to build a translation method rather than to suggest that every platform behaves identically.

Next routes: back to the translation owner, sideways only for genuine specialist needs

The navigation spine is Master Art of Translation | The Complete System for Moving Meaning Between Languages. This chapter is its retry-and-duplicate-prevention child. Read Change-Operation Fidelity — Add, Append, Replace, Merge, Patch, Upsert and Delete when the unresolved question is which mutation occurs before any retry; read the present chapter when the unresolved question is what another attempt or delivery actually means. The two mechanisms complement rather than replace each other.

If your difficulty is learning meanings, collocations, synonyms and retrieval across a language system, continue to the protected Vocabulary Learning Hub; it owns vocabulary learning, not this specialist translation workflow. If your difficulty is English tense, modality, sentence boundaries, reading or writing, use How English Works | The Complete Map and Learning Routes. Those protected pages retain their own ownership and content; the present chapter only routes readers to them where relevant.

A final operational check fits on one line: same intention or new intention; known result or uncertain result; same identity or new identity; saved progress or new start; delivery or effect; authorized retry or prohibited duplicate? If the target-language reader can answer those questions the same way as the source-language reader, the translation has preserved something more important than a synonym: it has preserved the intended action.