The same model writes your content and your competitor's.
Your decisions about wording already exist, in delivered files and with the people who made them. OnePlatform turns those decisions into structured data your own tools can query.
Where those decisions are now
Your company already decided how to say it.
Four of those decisions were made last week, by four people who did not talk to each other.
| A translator settles a term | Which of three correct German words your company uses, and the two it does not. |
| The team in Lisbon writes the page | In Portuguese, from scratch. Their wording becomes the version, and it was never a translation of anything. |
| Legal rejects a phrasing | In one market, while approving it in another. The reason exists; the record of it does not. |
| A reviewer fixes what the LLM produced | Rewrites the two sentences that were wrong, ships the file, and moves on to the next one. |
Add the style guide marketing wrote, the terminology technical documentation keeps separately, and the naming the product team settled two releases ago. Each decision was made by the person responsible for it, and each one ends up in a delivered file, a shared document or one person’s spreadsheet.
From translators to models
No system in your stack can read those decisions.
The style guide sits in a shared document. The terminology sits in a spreadsheet on one laptop. The reason legal refused a phrasing sits in a mail thread from March.
That worked while a translator was the only one who needed them. A person asks a colleague. Now the one writing your German is a model, and a model asks nothing.
These are the questions it cannot ask.
Which term does this business unit use for that component, and which two did it reject?
Which phrasing did legal clear for Germany and refuse for Austria?
What changed when the spec was revised, and who signed it off?
Is this still current, or did we replace it two releases ago?
How your tools reach it
Your tools read the same language data through three surfaces.
Your account holds terminology, translation memory, style guides, review decisions and quality signals. Your systems ask what your company already approved before they generate anything.
Your assistant calls terminology as a tool while it drafts, in whatever editor your team already uses. It gets the approved term for that market, the variants your company turned down, and the date someone approved it.
What it takes to hold that data
Five systems stand behind one lookup.
Your agent asks one question and gets one answer. These five keep that answer correct.
Your team ships the storage layer in a sprint
The work is a schema, a lookup endpoint and an import script. That is the part that lands in the estimate, and it makes building look cheaper than buying.
InDesign, SCORM and XML files do not store simple segments
Your code has to pull out what should be translated, keep the tags untouched, and put the file back so it still opens in the tool it came from. Each new format starts the work again.
Somebody in legal refuses a phrasing for Austria
The person who refused it has to record the reason that week. Nobody has that in their job description, and no schema changes that.
The product team replaces a term
Your service keeps returning the old one, because nobody is assigned to update it. Each market moves further from what the company decided, and nobody reports it, because nothing looks broken.
Reviewers in eight markets approve wording every week
They need to see the text in context, change it and approve it. A pull request cannot do that, and the interface that can is a product on its own.
What it takes to run
Unlimited users, isolated tenant, your own models.
Unlimited users. Freelancers, in-country reviewers and whole departments cost the same as a handful of each. A reviewer left outside the system still makes decisions. They land in an email instead of in your data, and the next project never sees them.
Isolated per tenant. Sealed to your account, and never used to train anything outside it.
Business units on one record. Separate administrators, cost centres and billing, over shared language data. Where a unit needs its own terms, you separate them inside one termbase instead of running two.
Your own approved models. Connect the AI your company has already cleared, rather than the one we happen to prefer.
Single sign-on. Because you were going to ask on the second call.
Before the technical call
Questions
We write a lot of content natively, not as translations. Does any of this apply?
Terminology and style are not properties of a translation — they are properties of how your company speaks, and they apply to Portuguese written in Lisbon exactly as they do to Portuguese translated from English. Getting natively written content structured into the record is project work rather than an upload.
How do our agents actually use this?
Through the MCP server, which exposes terminology as tools an assistant can call, read and write. Your tool does the generating; we hold what it stands on.
Why not just put our documents in a vector database?
Similarity retrieval answers what looks related. The question here is what you are allowed to say, and no distance metric knows that a term was rejected for that market or superseded two releases ago. In practice the two sit together: the index finds candidates, the record says which are authoritative.
What happens when we change models?
Nothing in the record moves. It sits outside the model and applies to whatever is generating. A prompt-based glossary is a property of the model you happen to be using this quarter.
Our translation runs through an agency. Does that have to change?
Not to begin with. Most engagements start by bringing that stream in, because it is the one with a budget and an owner — but the record is the point, not who performs the translation.
How does the data stay ours?
Isolated to your tenant, never used to train anything outside it, and exportable in the standard interchange formats — not a proprietary dump, but files a competing system can open.
Bring your stack, and your files.
The useful first conversation is not a demo of our interface. It is your CMS, your repository or your assistant, a look at where the record would sit in it — and what you already have in eight languages that could go in on day one.