Document intelligence Execution Gateway
Menaz is an execution layer built for document intelligence workloads. OCR services, multimodal models, OCR + LLM flows, and custom GPU execution paths are unified behind a single API surface. Users choose a method on each request, and the system treats that choice as an execution plan. With sync / async processing, provider abstraction, callback logic, and operational control layers, Menaz works not as a simple OCR service, but as an execution plane for document intelligence.
Document processing is often defined incorrectly. From the outside, the issue seems to be only OCR. In reality, the problem is larger.
Because real documents are not uniform. Some require only text, some require structure, some require correction, and some require directly structured output. Even the same document type may need a completely different processing path depending on quality, latency, and cost targets.
That is why, on the document intelligence side, the real issue is not choosing a single model. The real issue is building a system that can decide which execution path will work for which document.
Menaz emerged to solve this problem.
We did not build this area like a single-provider OCR service. We designed it with a multi-method, multi-provider, and multi-execution-path logic. That is why we see Menaz not as an OCR API, but as a Document Intelligence Gateway.
This field is no longer only an OCR field. Today, document processing is a broader problem space in which extraction, layout understanding, structured parsing, post-processing, and multimodal reasoning layers are discussed together.
In practice, this means the following: a single engine is often not enough. One document is handled through classical OCR, another requires OCR + LLM correction, and another flow directly requires a multimodal model.
And this is where the problem begins. Because this diversity is often not abstracted well. Every new need means a new endpoint, a new service, and a new integration. What eventually emerges is not a system that processes documents, but a pile that fragments as it grows.
This is exactly what Menaz is trying to solve.
The problem is not the absence of models. The problem is the absence of an execution layer.
On the document intelligence side, the real need is a decision and orchestration plane that sits between the client and the processing engines. When method selection, provider routing, synchronous / asynchronous flow, callback policy, job lifecycle, and execution control are not solved in the same place, the system fragments quickly.
That is exactly why Menaz exists.
Here, the word “gateway” is not decorative positioning. It describes what the system actually does. Menaz receives the request, carries it to the appropriate execution plan, selects the correct execution path, and delivers the result in a traceable way.
The goal is not to serve a single OCR engine. The goal is to make document processing workloads manageable from a single API surface.
On the Menaz side, the flow begins when the file is received by the system and ends with the delivery of results. But in between, there is not merely a single inference call. There is a controlled execution line.
In the first layer, the request is validated. The API key is not used only for access; it also carries the tenant context, the list of permitted methods, and the relevant policies. This way, from the very beginning the system solves not only the question “who arrived?” but also the question “under which rule will this request be processed?”
In the next step, the method is determined. Priority belongs to the method field inside the request. If this field is absent, the authorized method list on the API key comes into play. If needed, tenant defaults and system fallback logic are used. This makes the execution decision defined and traceable.
Once the method is resolved, the job is carried to the relevant execution path. Here, different OCR and LLM providers work under a common contract. Cloud OCR services, multimodal models, custom GPU endpoints, and unified model-serving flows are gathered behind the same API surface. What Menaz does is manage this heterogeneous structure without leaking it outward.
Not all document intelligence workloads are completed in the same amount of time. That is why the system does not operate in a single mode. Short jobs return synchronously. Long-running jobs are turned into jobs, placed into a queue, and their results are delivered later through polling or callback. This distinction makes the system both more resilient and more suitable for production workflows.
When the work is completed, the system does not merely return output. At the same time, it makes visible the status of the job, the method used, and its lifecycle. That is why surfaces such as retrieving job results, listing jobs, listing methods, and being able to cancel pending jobs are important.
The most critical abstraction in Menaz is the method.
Because in Menaz, a request is not merely a file upload call. It is also the answer to the question: “what kind of work will be done on this file?”
The user selects a method when sending the request. The system then treats that selection not merely as a parameter, but directly as an execution plan. This plan sometimes corresponds to a single provider. Sometimes it turns into an OCR + LLM correction chain. Sometimes it triggers a custom post-processing or adaptive selection flow.
This is where the real difference emerges. While presenting a single API to the outside world, it allows you on the inside to grow document processing logic in a fragmented but controlled way.
We see this clearly in the technical structure. Single-provider delegations, sequential OCR + LLM pipelines, special domain-focused methods, and conditional routing flows are all kept under the same contract. This turns Menaz from a simple endpoint into a real orchestration layer.
Menaz’s execution layer is not uniform.
The system does not connect only to third-party providers. It also works with our own GPU network and model-serving surface. Some methods go to cloud OCR providers, some to custom GPU endpoints, and some to the unified model-serving layer.
The purpose here is not merely to place different infrastructures side by side. The purpose is to carry different workloads to the appropriate execution path. Because on the document intelligence side, not every task is solved with the same cost, the same latency, and the same processing method.
That is why Menaz is not only an API surface. It is also an execution plane that routes document processing workloads to the correct execution path.
The moment you join Menaz, an isolated tenant structure is created for you. Your data remains private to you within this structure. In this way, you can manage your document intelligence flows on a shared infrastructure but within your own boundaries.
You can create multiple API keys on top of this structure. This makes it possible to separate each key for different teams, integrations, or usage scenarios. In this way, you can manage different workloads within the same organization without mixing them together.
The method-based operating logic is also one of the important parts of this enterprise structure. Because not every team or every integration needs the same processing path. Some require only OCR, some require OCR + LLM correction, and some want to work directly through a custom execution flow. Menaz can carry these different needs within a single structure, but in a controlled way.
In short, Menaz is not only an API that processes documents. It is a working layer that gathers different document intelligence needs within an institution into a single structure, but can manage them without mixing them together.
When designing Menaz, we approached security not as a separate item, but as a foundational approach distributed across the whole system. Document processing workloads are executed inside the system in a policy-controlled way; the access layers are shaped according to that sensitivity.
Tenant isolation is the first part of this structure. Each tenant operates within its own boundaries. API keys are issued within this context; which methods can be accessed, which defaults are valid, and which flows can be used are all determined within these boundaries. In this way, different customers running on the same infrastructure remain separated from one another.
The second critical layer on the security side is authorization. In Menaz, access is not handled only at the level of “did the request arrive?”; it also validates under which tenant context, with which permissions, and within which method boundaries the request will run. In this way, the execution layer becomes not only executable, but also controlled.
Rate limits and callback policies are also operational extensions of this security understanding. Because in production systems, security is not achieved only by closing access, but also by limiting and keeping the flow under control.
In short, security in Menaz is not a protection layer added afterward. It is a principle embedded directly into the system architecture.
For us, Menaz is not a finished service. It is a growing execution core.
Today, method-driven orchestration, multi-provider integration, custom GPU execution, and the sync / async delivery model are all unified within the same structure. Tenant-aware access and operational control layers also make this structure manageable in production environments.
Our goal is not to add one more model to the document processing space. Our goal is to establish a stronger standard for how document processing workloads are managed.
That is why we see Menaz not as an endpoint, but as the execution layer of document intelligence.
For more information about MENAZ, visit our website: https://menaz.ottomind.ai/