Every engineering team that integrates localization eventually asks the same question, usually after the first production incident: what actually happens between "submit this content" and "get translated content back," and how much of that path can we control programmatically? Vendor sales decks answer this with buzzwords. They don't answer it with a data model. Without a data model, you can't design a pipeline, you can only design a workaround.
The argument here is narrow and practical: the way a localization platform structures its core objects, folders, projects, orders, review levels, tells you immediately whether it was built to be called by systems or requested by people. A platform built around tickets and project managers will have a data model that reflects that: loosely typed statuses, review steps buried in UI workflows, no queryable audit trail. A platform built as infrastructure will expose a hierarchy that maps cleanly onto how engineering teams already think about work: a namespace, a unit of content, a unit of execution, and a gate that can be opened or closed without touching anything upstream.
Ollang's documentation frames this explicitly. Conceptual documentation for the Ollang Project Management Dashboard covers the Folder → Project → Order hierarchy and why it matters, and the broader concepts reference spans Folders, Projects, Orders, Levels, Workflows, Review Gates, LSPs, QC, BYOK, and more. Read that documentation before you write a single line of integration code, because it determines how your pipeline will shard work, retry failures, and report status back to whatever system is asking for it, your CMS, your CI job, or an agent acting on your behalf.
The hierarchy as the operational backbone
Three objects do the structural work.
Folder is the namespace. It is how you organize projects for a product line, a market rollout, or a client account, the container that keeps a thousand orders from becoming an unsearchable flat list. Every project carries a folder reference for this reason: the Retrieve All Projects response includes an identifier of the folder associated with the project for organization purposes.
Project is the unit of content, the source asset and its metadata, independent of what you do with it. You upload once, then execute against it repeatedly. The upload endpoint is intentionally source-agnostic: it supports video, audio, documents, spreadsheets, and VTT subtitle files, and it returns a projectId used to create orders. That separation matters for pipeline design, a single project can spawn multiple orders (different languages, different modalities, different review depth) without re-uploading the source every time.
Order is the unit of execution, a specific translation job against a project, with its own type, target languages, and status. Order creation creates one or more translation orders for a project, supporting order types including closed captions, subtitles, document translation, AI dubbing, and studio dubbing. Each project also tracks the number of orders related to it, though that field may not be present in all responses, a small detail, but it tells you the object model treats order count as derived data rather than something you have to compute client-side.
This three-layer structure is the backbone the rest of the system hangs off. It is documented as platform concepts rather than UI screens. The vendor expects you to reason about it as a schema rather than a workflow you click through. Full field-level detail is in Ollang's API documentation.
Level 1 review gates: routing without reshaping the pipeline
The part of this model that matters most to an engineering lead is the review gate, because it is the one decision point where "AI-only" and "human-reviewed" content diverge, and in most platforms that divergence means rebuilding your integration. Ollang treats it as a flag on the existing order object rather than a fork in the pipeline: you can add a Level 1 review gate to any order to route output to Ollang-managed linguists or your own LSPs and editors.
Practically, this means the shape of your pipeline call doesn't change based on quality tier. Whether an order resolves purely through AI translation or gets routed to a linguist, Ollang's own managed pool or an LSP relationship you already have, is a routing decision made at the order level, not an architectural one made at the integration level. That is the difference between needing a separate system for human-reviewed content and flipping a parameter.
The human review path is its own endpoint, callable independently after the fact: Request Human Review for an Order triggers a manual review by a professional linguist, and eligibility is scoped, the order should be a completed or delivered order that you have access to and is eligible for human review. It returns no content on successful request (HTTP 204 status code), which is an implementation detail if you're writing client code that expects a payload back, you're not polling this call for a result, you're polling the order itself.
The upgrade path can also be reversed, a cancel-human-review endpoint exists for orders that were routed to review but no longer need it, which matters if your pipeline auto-escalates based on a QC score and needs to walk that decision back.