Translate text — the call is stateless, your translations are not

A translate endpoint is stateless. You send it a string, it sends one back, and it remembers nothing about either — it doesn't need to, because translating a sentence requires no memory of the last one. That cleanliness is real, and it's also the trap, because it quietly suggests that your translations are stateless too: disposable strings you can always regenerate. They aren't. The translation is rented and forgettable; the things around it are stateful, owned, and the actual product, and this note is about the gap between those two facts.

Rent the call — it isn't the product

Start by giving the translate call its due and then setting it aside. A modern translation API — a hosted service, or an LLM asked to translate — is good, cheap, and a commodity. It's the same rented intelligence as text generation, swappable the day a better or cheaper one appears, and you should rent it without sentiment. The translation build idea asks a different question from this one — whether translation is a standalone business, and answers mostly no, it's a module more than a SaaS. This note asks what you own the moment you use the capability at all: when you rent that call, what is the durable thing you must keep — the part that's yours precisely because the stateless API will never hold it for you?

The state the API refuses to hold

Three things, and the provider holds none of them.

The source text. The original is yours, and everything else is rebuildable from it while it's rebuildable from nothing. Keep the German and discard the English and you've kept the derivative and thrown away the asset.

The binding between source and translation. The API hands you a German string; it has no idea that string is the translation of this specific English paragraph, this version of it, translated on this day. That mapping — source to target, with the version it was made from — is yours to record, and it's the difference between a maintainable set of translations and a pile of orphaned strings nobody can trace back to what they were supposed to mean.

The staleness signal — the real one. Sources change. Someone edits the English, and at that instant the German is wrong, and the translate API cannot tell you so, because it never knew the two were related. Knowing which translations have gone stale because their source moved is not a feature of any translation service. It's a product capability you build on top of the binding you chose to keep — and it's the thing the build idea means when it says the review-and-freshness layer is the product and the translate call is the commodity beneath it.

There's a fourth rule that protects all three: never let a re-run overwrite a translation a human has already corrected. Once a person has reviewed and fixed the machine's output, that target is worth more than anything the API would return on a second call, and blindly re-translating destroys real work. So the system translates only what's missing or stale, and leaves reviewed rows untouched — which is only possible because you kept the binding and the freshness signal that tell it which rows those are.

What this looks like lived, honestly

CompanyGraph runs a translation service built on exactly this seam, and it's worth marking which half is proven and which is the frontier. The proven half: it translates only the rows that don't yet exist in a target language, and it never overwrites a target-language row that's already there — so a manual edit is safe, and re-running the whole thing is always safe. That's the binding-and-don't-clobber discipline working in production: the provider executes the translation, the record of what maps to what and what's already been reviewed stays at home. The frontier half, named plainly: automatic staleness detection — flagging a translation the moment its source changes — is the piece this note calls the actual product, and it's the known next step rather than a shipped feature. The binding is kept; the freshness signal built on top of it is the part still to build. That's the honest shape of "lived" here: the ownership is real, the hardest layer is the one still ahead.

What breaks when it's hacked in

The failure is the one every capability in this set shares, in its translation-shaped form: the provider becomes the only thing the work is anchored to. Keep the translated strings but not the binding, and when the English changes nobody can tell which German went stale — the site is now wrong in one language and no signal exists to say so. Let the re-run overwrite reviewed rows, and a quarter of human correction vanishes on a routine refresh. Keep only the translations and lose the sources, and you can't re-translate when you switch providers. In every version the translate call kept working perfectly the entire time — the strings were always there, always fluent — which is exactly what makes the rot invisible until a customer reads a page that's been quietly wrong in their language for six months.

Where it shows up

It shows up in any product that lives in more than one language, with the translation build idea as the sharpest case. And one layer down it's the same shape as the rest of this set: owning the documents a search index is rebuilt from is the same instinct aimed at a corpus, and owning what stays yours when a model is rented is the same instinct aimed at generation. Rent the translation; own the source, the binding, and the signal that tells you when a translation has stopped being true. That's part of the foundation for the same reason the payment record and the file index are: the capability is theirs to provide, but the meaning — and whether it's still current — is yours to keep.