Case Study · active
Making context reviewable in GenAI translation and validation
An anonymized account of how structured study context, deterministic checks, and human judgment can make AI-assisted translation, and the checking of it, more useful.
- Context
- A translation can be linguistically plausible and still be wrong for a particular study. What the text is for, and who it is speaking to, changes what it has to say, and none of that is visible in the sentence itself.
- The move
- I treated context as explicit, reviewable data rather than hidden prompt text, then combined semantic model judgment with deterministic checks for exact markers and document structure. The same context drafts a translation and checks one, and the workflow kept evidence and human judgment at the decision point.
- Evidence
- A design that holds on real material: context visible and governed, exact constraints protected by code, findings that carry the evidence behind them, and the person keeping the decision.
- What it shows
- In a GenAI system, more context is not automatically better. The useful move is to make the decisive context visible, test whether it changes the judgment, and protect exact rules with code.
Translation quality is not always visible in the sentence in front of you. The same wording can be acceptable in one study and misleading in another, because what the text is for and who it is speaking to change what it means. That holds whether you are drafting the translation or checking one that already exists.
That makes this more than a prompting problem. It is a workflow-design problem: what information should the system use, which parts should a model judge, which rules should code enforce exactly, and what evidence does a human reviewer need?
The design in one view
Study material
The brief, the questionnaire, and whatever the study already documents about itself.
A reviewable object, not prompt text
Assembled → Inspected → Corrected → Confirmed → Reused
Model-derived context stays a hypothesis until a person confirms it, and an edit invalidates the earlier confirmation rather than flowing silently into later decisions.
Exact invariants
Piping tokens, placeholders and structural markers are verified rather than judged.
A deterministic check can only lower a verdict, never raise it.
Meaning in context
Accuracy, tone, terminology and local usage, whether drafting new wording or judging wording that already exists.
Every finding cites its exact spans and states its uncertainty.
The person decides
A draft is a proposal, and a finding arrives with the evidence that produced it. Neither becomes an approval.
Turning context into part of the product
The first move was to stop treating context as extra prose hidden inside a prompt. I represented it as a structured object that could be assembled, inspected, corrected, and reused.
It held what a competent reviewer would want to know before judging the sentence, as named fields rather than prose. Working out which those are, and which only look useful, was the real work.
Model-derived context remained a hypothesis. A reviewer could inspect it, and a change invalidated the earlier confirmation rather than silently flowing into later decisions.
That turned out to be the reusable part. The same governed object that judges an existing translation now also drafts a new one, without being rebuilt for the second job. A prompt is spent when the call returns; context made explicit is inherited by whatever the system learns to do next.
Separating exact rules from semantic judgment
Some translation checks are interpretive: whether meaning, tone, or local usage has shifted. Others are exact: a piping token, placeholder, or structural marker must survive unchanged.
The design kept those responsibilities separate. Code checked the invariants. The model assessed meaning in context. Its findings had to point to the relevant source and translated spans, explain the concern, and express uncertainty. A person remained responsible for the final decision.
The same boundary governs what the system writes, not only what it checks. A draft that breaks an exact rule is withheld rather than offered, because the cheapest moment to catch that failure is before anyone reads it.
This avoided asking a probabilistic model to be the sole authority on facts that deterministic logic could verify more reliably.
Testing the context, not assuming it helps
I used controlled examples and ablation-style tests to ask a more useful question than “Does context help?”: which piece of context changes a decision, and does that change make sense?
The experiments exposed three practical lessons:
- More fields do not automatically produce a better judgment.
- Specific study demands matter more than generic background information.
- Context fields can conflict, repeat one another, or leak the answer into a test.
That changed the design goal from collecting as much context as possible to identifying the smallest, clearest set that supports a defensible review.
Outcome
It works, and it works on real material rather than on examples chosen to flatter it.
The shape is why. Context is visible and governed, exact constraints are protected by code, findings carry the evidence that produced them, and the person keeps the decision. Each of those costs something to honour, and together they are what make the output worth acting on.