I look after one of the services at a company that's been translating things for forty years. The engine behind it now reads medical records and contracts and hands them back as structured JSON — fields you can drop straight into a database.
People hear that and assume it's a pivot. A translation company that bolted on a document-AI product to chase the moment.
It wasn't a pivot. It was translation, taken too seriously to stop at the obvious.
The part that was always there
Localization has a quiet habit most people outside it never notice. Whatever format the work arrives in — Word, Excel, PDF, subtitles, a plain text file — you don't process the format. You convert it into one neutral interchange format, do the language work on that, and convert it back. The standard for that interchange has existed for years; the industry settled it long ago.
So "handle any document format" was never something we had to invent. It was the floor we already stood on. Plain text isn't special in that world — it's just one more format, the one with a .txt on the end. A PDF and a single sentence go through the same door.
I want to be clear that this came first, and from the industry, not from us. It matters for the rest of the story.
The part that actually changed
On top of that floor, translation did one narrow thing: take a chunk of source-language text, hand back the same meaning in another language.
For years we did that by wiring up machine-translation engines — each one a dedicated language-mapping machine and nothing else. Then generative AI arrived, and the realization was small and total at the same time. This new kind of engine didn't map languages; it took an instruction. Translation is just this: here is some text, here is an instruction, return the result. "Translate to Japanese" is one instruction. "Fix the grammar" is another. "Make this more formal." "Summarize it." The engine was never really translating. It was applying an instruction to a segment and giving the segment back.
Once you see that, "translation" stops being the thing the engine does — it becomes one value of a parameter. What we had been calling translation was a narrower operation that had been living inside a much larger one all along. We'd just never had a reason to name the larger one.
The target stopped being a language
The next step was smaller and stranger. If the engine only applies an instruction, the result doesn't have to be text in another language. It can be a shape you define.
It's easier to see than to say. Inside, a unit of work is just a source and a target:
{
"source": "No prior history of diabetes.",
"target": ""
}
Ask it to translate, and the target comes back as a sentence:
{
"source": "No prior history of diabetes.",
"target": "糖尿病の既往なし。"
}
Ask it to structure, and the request is identical. The only thing that changes is the shape I let target hold:
{
"source": "No prior history of diabetes.",
"target": {
"condition": "diabetes",
"history": false
}
}
Same envelope, same engine. The one thing that moved is what target is allowed to be — a string, or a structure I defined.
That is still the operation translation was always performing: moving meaning from one form into another. The target "language" is a schema now instead of Japanese. Internally we eventually gave this capability a name — StructFlow — but the engine never changed to earn it. We just injected a schema where the target text used to go.
Where the two meet
Here is the part that still feels like a small trick.
Because the format-agnostic floor was already there — any document in, any document out — the moment the operation became "give me a structure," it could structure anything. A scanned contract, a spreadsheet of customer reviews, a Word file: all of it was already being turned into neutral segments to be worked on. Now those segments could come back as structured data instead of a translation.
We didn't build a document-structuring product. We pointed a forty-year-old pipe at a new instruction.
Two things keep it honest
It would be easy to dress this up after the fact. Two things stop me.
The first: structuring a contract and translating a sentence run the same code. There is no translation engine and a separate structuring engine inside. There is one engine that takes a segment and an instruction, and the instruction and the output shape are the only things that differ.
The second is my favorite. We have a feature that refines a finished translation — pass after pass, catching the mistranslations and the dropped clauses, leaving a note on each change. It used to run on its own hand-written prompts. We rebuilt it on the structuring engine; now it is that engine, called up to six times — each pass hands it a segment and asks for a structured result: the revised translation, plus a note. The oldest thing we do, translation, now runs on top of the newest. The origin sits on the destination.
The actual lesson
None of this was on a roadmap. Nobody decided to enter the document-AI market. We took one definition seriously — translation is moving meaning from one form into another — and refused to stop at the form everyone expects.
Generalize the thing you actually do, far enough, and you don't get a better version of that thing. You get a different one — and if you're lucky, you reach it standing on infrastructure someone already built and proved, so it costs almost nothing.
Forty years of translation will make any company look like a translation company. But translation was only ever a special case of something larger — moving meaning from one form into another — and it was just the first market anyone had found for it.
Built with Claude (Opus).
Top comments (0)