Build 02 / Governed Marketing Localisation
Translation AI
A protected enterprise translation workflow for serious marketing teams. Translation AI now combines an operator workspace, pilot evidence workflows, governance controls, deterministic backend contracts, and a closed Stage 37 backend planning spine.
Greg's take
Translation AI was deliberately prevented from becoming another attractive front end with an improvised backend attached later.
The staged programme forced the contracts, evidence, governance, failure boundaries, integration map, and runtime responsibilities to be defined before production data or provider execution was introduced.
Stage 37 matters because it closes that planning spine. We now know what the private runtime must own, what must remain reviewable, where provider behaviour must be evidenced, and which production controls still need to be earned.
The next phase is not add an API call. It is the controlled conversion of the proven operator and governance model into a private owned-content runtime without losing the safety and evidence structures already built.
Build milestones
Advanced build status through Backend Stage 37.
Operator Product
Protected review workspace, evidence views, safety review, request history, pilot batch operation, and human approval points.
Pilot Evidence
Pilot evidence pack, batch workflow, dashboard summary, and enterprise client-facing demonstration narrative are established.
Governance Layer
Protected terminology, QA preservation checks, provider evidence, controlled execution, and no-public-demo policy are established.
Backend Spine
Deterministic configuration, manifests, contracts, loader wiring, orchestration planning, integration mapping, and closure readiness are complete for this phase.
Production Runtime
Private owned-content ingestion, provider execution, secure storage, observability, deployment controls, and operational recovery remain future gates.
Pl8ypus AI Content Ops
Product Phase 1 is the controlled design of a private owned-content runtime, not a completed runtime feature.
The problem
Translation tools do not automatically create usable marketing assets.
Protected terms get changed
Product names, claims, merge fields, URLs, disclaimers, and campaign structure can be changed by a model unless the workflow protects them before translation.
Review happens without evidence
Teams often see the translated output, but not the rules used, terms protected, QA result, or model behaviour that produced it.
Assets break during rebuild
Copy and paste workflows are fragile. The translation may be good, but the working asset can still be broken when it returns to the campaign platform.
Decisions are lost
Approved phrases, rejected wording, QA notes, and reviewer decisions often disappear into email threads instead of becoming reusable memory.
What it does
A controlled operating layer for AI-assisted localisation.
Translation AI is not a prompt wrapper. The core idea is to wrap the model in operations: structured payloads, protected fields, language-specific translator agents, provider evidence, glossary handling, request logging, QA gates, human approval, and a recoverable version trail.
Structured payloads
The model receives segments, protected terms, formatting rules, glossary matches, prompt version, rules version, and output requirements as controlled input.
Language-specific agents
Each target language can have its own rules, approved phrasing, terminology behaviour, and quality controls under one orchestration layer. This is the quality-control architecture, not a generic translate button.
Protected terminology
Names, links, placeholders, claims, tracking fields, and structural markers are isolated before translation so the model cannot freely rewrite them.
QA gates
Output is checked for protected term preservation, links, placeholders, structure, language target, and confidence before review.
Provider evidence and request logs
Every translation request can carry provider, prompt/rules version, protected-term result, warning state, and human review status so reviewers know what happened before approving an asset.
Human approval
Generated output is held before use. The system records review status instead of pretending machine output is automatically approved.
Versioned evidence
Source file, generated output, approved output, QA report, prompt version, and rules version can be captured for traceability and rollback.
Workflow evidence
The build is designed as an operating system for localisation, not a one-off translation step.
A marketing asset moves through a controlled spine from approved source, to orchestration, to language-specific translation, to QA, to reviewed output, to versioned archive.
Click to enlarge
Illustrative workflow panel for the governed Translation AI build.
Operational value
The value is not only faster translation.
The value is fewer broken assets, fewer lost decisions, better evidence, and a localisation workflow that can be trusted by marketing operations.
Less manual rebuild risk
Extracts translatable content, routes it through a controlled structure, and rebuilds usable assets without repeated copy and paste work.
Controlled terminology
Product names, trademarks, merge fields, URLs, approved phrases, and restricted claims are protected before the translator agent receives the payload.
Traceable decisions
Source asset, generated output, QA result, approval status, prompt version, and rules version can be captured against a version-controlled record.
How it works
A controlled spine from approved source asset to platform-ready working asset.
01
Controlled input
Approved source assets enter through a controlled route first, with future support for terminal, GitHub, and repository-triggered workflows.
02
Orchestration
A server-side route controls validation, payload construction, rules injection, language-agent routing, QA coordination, and archive writes.
03
Translation and reconstruction
Language-specific translator agents return structured segments. The builder layer reconstructs the asset without breaking layout or protected fields.
04
Storage and retrieval
The planned archive model keeps source, output, QA reports, prompts, and rules traceable so approved phrases and language preferences can be reused later.
Pipeline flow
Structured translation requests replace copy and paste prompting.
Source asset registered
The system receives a structured marketing asset, validates the request, and identifies the asset type, source language, target language, and metadata.
Structured payload created
The model receives segments, protected terms, formatting rules, glossary matches, prompt version, rules version, and output requirements.
Language-specific translator runs
The language router assigns the job to the right translator agent. The agent returns translated segments while preserving structure and controlled terms.
QA gate and human approval
Automated checks validate protected terms, links, placeholders, structure, language target, and confidence score before human approval.
Archive, evidence, and rollback
Source, generated output, approved output, QA report, prompt version, and rules version are captured in the evidence model so every job can be traced and recovered.
Language-specific translation layer
Language-specific agents, not one generic language switch.
Each target language can have its own translator agent, rules, approved phrasing, terminology behaviour, and quality controls. The orchestrator supervises every agent so no language workflow operates outside the governed process.
Evidence / Governance
Designed to stop unsafe output before it becomes real marketing work.
Boundaries the AI cannot cross
> Cannot auto-approve translated assets
> Cannot bypass QA or human approval
> Cannot rewrite protected product claims
> Cannot store secrets in frontend code
> Cannot run uncontrolled provider calls
> No public-facing demo surface
Evidence the system records
> Source file and source commit
> Prompt version and rules version
> QA result and confidence score
> Approved asset and rollback reference
> Backend planner and readiness refs
> Product phase transition refs
Technical build stack
Lightweight interface. Serious orchestration spine.
Frontend
The interface remains replaceable. The durable value sits in the orchestration, payload, governance, QA, memory, and archive model.
Orchestration
Server-side orchestration keeps secrets out of the browser and gives the workflow a clean control point.
Model layer
The model is a replaceable service. The durable value is the governed workflow wrapped around it.
Current build stage
Advanced build: Backend planning spine closed.
Status
Ready for private runtime design
Translation AI has reached Backend Stage 37. The protected operator product, pilot evidence workflows, governance model, deterministic runtime contracts, integration maps, and backend readiness planners are now established.
The project has completed the architecture and evidence-building phase required to define the first private product runtime. It is not being presented as a finished production system.
Now complete
Operator workspace, provider evidence, request log, safety review, side-by-side review, pilot batch workflow, pilot dashboard, and mock-safe preview are established for the evidence phase.
Backend spine
Worker-safe configuration, static manifests, parity checks, protected-term runtime design, QA annotation structures, read-only Tanya loader wiring, runtime contracts, integration maps, and closure planning have reached Stage 37.
Next
Product Phase 1: Pl8ypus AI Content Ops private owned-content runtime design. Provider execution, production data integrations, tenant isolation, deployment controls, and operational monitoring remain controlled future gates.
Speaking angle
A live AI build story people can understand in five minutes.
Before
Manual localisation drag
Teams lose time copying, pasting, checking links, protecting merge fields, chasing versions, and rebuilding the same campaign in several languages.
During
Orchestrated AI run
The orchestrator prepares the job, language agents translate the controlled segments, and QA checks the parts that marketing operations cannot afford to break.
After
Review-ready output
The team receives working translated assets, QA evidence, and a versioned trail that makes review, approval, rollback, and reuse easier.
Next evolution
From closed planning spine to private owned-content runtime.
Operator product and pilot evidence
Protected workspace, provider evidence view, request log, safety review, pilot batch workflow, pilot dashboard summary, evidence pack, and enterprise client-facing narrative.
Governance model
Enterprise client-first private direction, protected terms, QA preservation checks, human review points, provider evidence capture, controlled execution, and no uncontrolled model usage.
Backend Stage 37 closure
Deterministic configuration, manifests, runtime contracts, loader wiring, integration maps, evidence envelopes, routing planners, and backend readiness planners are closed for the simulated planning phase.
Product Phase 1: Pl8ypus AI Content Ops
Private owned-content runtime design for GitHub and website content ingestion, owned content review workflow, and future Brevo email draft adapter boundaries.
Production runtime controls
Provider execution, secure persistence, data integrations, deployment controls, monitoring, recovery, and client deployment remain future controlled gates.
Greg's take
A translation platform is not automatically the answer. Sometimes it is the right answer. Sometimes it is a large system bought to fix a smaller workflow problem.
The risk is paying for a full translation operating model when the actual pain is simpler: files move slowly, terms get changed, reviewers lack evidence, and campaigns wait.
This build is about proving the smaller controlled layer first. If the company still needs the full platform later, fine. But then the decision is made with evidence, not panic.
Smartcat option and ROI case
Platform versus controlled internal layer.
Smartcat is a serious enterprise translation platform. It offers AI translation, localisation workflows, human review options, file handling, vendor support, and broader translation management capability. That makes it a valid benchmark. It also means the buying decision is bigger than the immediate problem many marketing teams are trying to solve.
Translation AI is aimed at a narrower but valuable gap: recurring marketing assets that need fast translation, protected terminology, evidence, and human review control. The question is not "can we build Smartcat?" The question is "can we remove enough manual cost, delay, review effort, and platform dependency from the marketing translation workflow to justify a controlled internal AI layer?"
| Decision area | Smartcat-style platform | Translation AI internal workflow |
|---|---|---|
| Best fit | Large-scale or multi-domain localisation across products, markets, and vendor networks | Recurring marketing asset translation with fast turnaround, protected terms, and internal review control |
| Cost profile | Platform subscription plus per-word or per-project vendor costs. Can scale to $25,000-$120,000+ annually at enterprise tier | Infrastructure cost only through Cloudflare Workers and AI API calls. No per-word or platform licence cost. Build cost is a one-time investment |
| Marketing asset control | Good, but configured within platform constraints. File types, review states, and workflows depend on platform support | Fully customizable. Asset structure, protected terms, QA criteria, and review states are defined by the team |
| Protected terms | Glossary and termbase features available. Quality depends on how well configured and maintained | Protected-term handling is designed into the payload and review flow. Violations surface at the QA gate, not after the fact |
| Evidence and audit trail | Project-level reporting and audit features available at higher tiers | Evidence is built into the output. Every translation carries provider, QA result, review status, and rollback path |
ROI model
The assumptions below are illustrative. Replace with actual figures to size the business case.
Platform benchmark
Annual Smartcat-style platform cost, if purchased
Actual cost depends on tier, seats, volume, and vendor marketplace usage. These are reference figures, not quotations.
Manual workflow savings
Time saved per translated marketing asset
Time saved covers file preparation, vendor handoff, review coordination, protected term corrections, upload, and rework.
Conservative case
Translation AI pays for itself if it saves enough manual handling and review time to avoid or reduce platform spend and remove recurring translation bottlenecks.
Stronger case
Translation AI becomes valuable when it shortens campaign turnaround, reduces rework, protects brand and legal terminology, and gives reviewers enough evidence to approve faster.
Enterprise case
If the company would otherwise buy or expand a full TMS mainly for recurring marketing assets, a controlled internal layer could save tens of thousands annually while preserving the option to use a TMS for complex localisation needs.
Greg's take
A translated asset is not automatically a usable asset. Somebody still has to know what changed, what terms were protected, what the model touched, and whether a human needs to review it before it goes near a campaign.
That is the part most translation workflows hide. They show the output and skip the evidence. The model translated it, so it must be fine. Nobody checks whether a product name was protected. Nobody checks whether the confidence was high enough. Nobody checks what the QA gate actually said.
This build puts the evidence back in. Protected terms are handled before translation output is trusted, not reviewed after the asset has already moved downstream. The QA gate is explicit. The review state is recorded. A human can see exactly what happened before the asset gets used.
A model that translates well is not the same as a translation system. The difference is the layer around the model call: structured payloads, protected terminology, review states, and a clear record of what happened and who approved it.
Want to discuss the Translation AI build?
For architecture conversations, speaking opportunities, or collaboration around governed AI localisation workflows.