# Intelligent Orchestration Layer | AIM Previz https://aimpreviz.com/research/intelligent-orchestration [Previz](https://aimpreviz.com/) / [Research](https://aimpreviz.com/research) / Platform Architecture # Intelligent Orchestration Layer Abstracting Model Complexity for Professional Creative Workflows Published Jan 2026 · Updated Oct 2026 · 14 min read In Development Frames made in Previz **Contents 0** ## Abstract Professional creators face an overwhelming landscape of generative engines — image, video, 3D, audio, upscale, edit, relight — each with distinct capabilities, licensing terms, and compliance posture. Rather than exposing this complexity, we operate a single intelligent orchestration layer that abstracts engine selection entirely. Today the layer sits on top of **1,400+ engines spanning 6 modalities**, reached through our inference partnership. It picks the engine for every capability, can limit a production to the engine makers and jurisdictions its contract allows, writes a provenance receipt that names the engine where it was recorded and says unknown where it was not, and refunds a render that fails upstream. The creator focuses on the shot. The platform handles infrastructure. ## At a Glance 1,400+ Engines reachable 6 Modalities 0 Models trained on your material SHA-256 Provenance digest on export ## The Model Fragmentation Problem The generative AI landscape has exploded. Image generators, video synthesis, upscalers, style transfer, relighting, 3D — each with different strengths, weaknesses, and terms. A professional team today faces a daunting reality: - **Decision fatigue:** Evaluating dozens of engines per use case is unrealistic. Creators need to create, not run vendor assessments. - **Rapid obsolescence:** Model versions update weekly. Last month's best option may be deprecated today. - **Compliance complexity:** Pharmaceutical clients may prohibit certain training-data sources; defense contractors require specific security certifications; studios require data residency and named-vendor exclusions. - **Integration overhead:** Each API has different auth, rate limits, queueing semantics, and output formats. Managing this across a production pipeline is engineering work, not creative work. ## Architecture The shape every generation request is moving onto, stage by stage, before it touches an upstream engine: ``` ┌─────────────┐ ┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │ Creator │ → │ Policy │ → │ Capability │ → │ Engine │ │ Request │ │ Gate │ │ Matcher │ │ Adapter │ └─────────────┘ └─────────────┘ └──────────────┘ └──────┬───────┘ │ │ │ engine makers and modality, res, refund on their operators' seed, cost upstream failure jurisdictions │ ▼ ┌──────────────────┐ │ Usage record + │ │ Provenance Pack │ └──────────────────┘ ``` Today the gate runs inside the rendering functions and each capability chooses its engine in its own code. One shared route table that every room reads, with a record of every routing decision, is the work in build. The user never sees these stages. They see consistent results through a unified interface, and a provenance receipt on the other side that never guesses. ## The Case for Abstraction Professionals want outcomes, not model names. A cinematographer cares about the shot — the lighting, the angle, the mood — not which engine rendered it. This insight drives our architectural approach. Exposing model names also creates brittleness. When users build workflows around "Model X," they become dependent on that specific model's availability, pricing, and behavior. Our abstraction layer swaps backends as better options emerge — without disrupting any user workflow. This builds on related research in [The Creative Flow Imperative](https://aimpreviz.com/research/creative-flow-imperative) and [Cognitive Load Topology](https://aimpreviz.com/research/cognitive-load-topology). Every decision a creator doesn't have to make is mental energy preserved for creative work. ## The Opposing View "Why not just expose model pickers like the rest of the market?" It's a fair question. Power users in adjacent tools value granular control. Our answer is twofold. First, professional pre-visualization is a multi-shot, multi-day pipeline — not a single-image novelty. Choosing the right engine 400 times across a sequence is not a feature; it is a tax on the work. Second, engine pickers leak compliance posture into the UI. The moment a director can choose "Engine X," they can also choose a non-approved one — and the platform has shifted the burden of compliance onto a human who didn't sign the MSA. We chose the other path: enforcement at the architecture layer, optionality at the contract layer. ## What This Is Not Not a model marketplace We do not resell access to third-party engines. We operate a curated, contracted pool with negotiated terms. Not a router-for-hire The orchestration layer is not exposed as a public API. It exists in service of the creative product. Not training on user data Customer inputs, prompts, and outputs are never used to train any model — ours or any upstream vendor's. Enforced contractually. Not a model-agnostic gimmick Capability matching is real engineering. Wrong engine for the job produces wrong results, regardless of how slick the routing is. ## Walled Gardens for Compliant Data Enterprise clients operate under strict compliance regimes. The orchestration layer carries a per-production engine policy: which engine makers may run, judged by the jurisdiction of each maker's operator. Frameworks we map to include: - **SOC 2** — the control set is mapped for processing integrity, confidentiality and availability of inference traffic. A Type I engagement is planned. Nothing here is certified or attested today, and we say so in writing rather than by omission. - **ISO 27001** — used as a management framework for inputs, intermediates and outputs. Not a certification, and not currently being pursued as one. - **GDPR / CCPA** — data-subject rights and deletion on request, answered inside 30 days. Note the distinction that matters: the policy engine gates the JURISDICTION OF THE ENGINE'S OPERATOR, which is a different guarantee from where data is stored. Region pinning is not built, so no residency claim is made. - **EU AI Act tier classification** — machine generation is disclosed in the Terms and the Privacy policy. Per-inference tier logging is not built. - **Provenance manifest** — engine, inputs and edit ancestry recorded at creation, exportable per asset with a SHA-256 integrity digest. It is a checksum, not a signature: signing infrastructure is deliberately not held, so C2PA content credentials are designed and on the roadmap rather than shipped. The user experience is identical across configurations. Same controls, same workflow — only the engines a production may use differ. The gate is server-side code rather than a policy document; today it covers the rendering functions, and the remaining paths are being brought under it. ## Intelligent Routing Each capability's engine is chosen against four considerations. Today that choice lives in each capability's own code; moving it into one shared route table, so every room decides the same way and every decision is recorded, is the work in build. Request Analysis Resolution, motion complexity, style specification, identity locks, output format. Compliance Filter Per-production engine policy: jurisdiction and named-maker limits. Capability Match Which engines can actually deliver the requested output at quality, not which sound best. Resource Optimization Quality versus latency, throughput, and cost — within the production's credit budget. ## Failure & Fallback Behavior Upstream engines fail. They time out. They return rate-limit errors. They occasionally return junk. The orchestration layer is built on the assumption that the primary will fail some non-trivial fraction of the time. - **Fallback ladders** where a second engine can do the same job. The language-model capabilities step down a ladder today; render lanes join it as they move onto the shared route table. - **Slot polling for 429 errors** — transient rate limits are absorbed by an internal queue instead of escalated to the user. - **WaitUntil for long-running jobs** — high-resolution renders survive serverless timeouts by detaching to background workers and reconciling via realtime. - **Refund on failure** — a render that fails upstream is refunded once, by a single settler, rather than charged. ## Determinism & Reproducibility Production demands reproducibility. Generative engines are not fully deterministic, so the layer holds what it can: - **Recorded requests** — rooms that support a re-shoot record the exact request at render time, so a re-run replays it rather than reconstructing it. - **Declared engines** — every engine id is a constant in code, checked by a guard, so an engine changes by a deliberate swap rather than by a default moving somewhere else. - **Per-tenant version pinning** — in build for dedicated tenants; on the shared platform the declared engine is the pin. - **Continuity across a swap** — identity locks and style anchors travel with the request, and the drift check grades the result against what the production locked. Related research: [Repeatable Direction](https://aimpreviz.com/research/deterministic-generation) and [Continuity Lock](https://aimpreviz.com/research/continuity-lock). ## Audit Trail Every charged generation writes a usage record: who, which project, which credit action, and what it cost. Provenance Packs export per asset with an integrity digest, naming the engine where the room recorded one and saying unknown where it did not. The routing ledger in build adds one row per engine decision, in this shape: ``` { "request_id": "req_…", "tenant_id": "tnt_…", "user_id": "usr_…", "modality": "image | video | 3d | audio | upscale | edit", "engine_class": "image.cinematic.", "engine_version": "v…", "pool": "", "policy_preset": "open | us_only | western | exclude_cn | custom", "operator": "", "config_hash": "sha256:…", "seed": 1839204711, "latency_ms": 2840, "cost_credits": 12, "fallback_depth": 0, "manifest_digest": "sha256:… (an integrity checksum, not a signature)", "ts": "2026-06-12T10:42:19Z" } ``` ## Data Lifecycle - **Inference-only terms** with every upstream provider. No training on your material; zero retention where the provider offers it. - **Path-isolated storage** — assets live under tenant- and project-scoped paths, enforced by row-level security at the database layer, not by application code. - **Customer-managed keys** — a funded roadmap item for dedicated and VPC deployments, where the platform would never hold the unwrap key. Not held today; encryption at rest is inherited from the managed platform's key service. - **Right-to-delete** — a deletion request removes database records and every stored object under the tenant's paths, reporting the object count erased, and backups age out of the recovery window within 30 days. ## Walled-Garden Deployment Modes Shared SaaS · running today Multi-tenant. Path-isolated storage, RLS, shared inference pool. Fastest onboarding. Dedicated Tenant · in build Separate database, storage, and edge functions. Tenant-specific approved pool. Named-vendor exclusions enforced. VPC / Single-Region · roadmap Deployed inside a customer-controlled cloud account or region, with customer-managed keys and a network egress allowlist — all on the funded roadmap, not yet built. Air-Gapped / On-Prem · exploring Open-weight inference running on customer hardware. No external network. Full orchestration, no upstream calls. ## Benefits of the Abstraction Layer 1. **1. Future-proofing:** As better engines emerge — and they will — we swap backends without user disruption. No migration, no retraining, no workflow changes. 2. **2. Compliance by default:** A production's engine policy is applied by the gate, not by the person at the keyboard; users don't think about it. 3. **3. Simplified experience:** No engine dropdowns, no "which engine should I use?" decisions. Creatives focus on direction. 4. **4. Consistent interface:** The same visual controls work regardless of underlying engine. Camera, lighting, and composition tools remain stable as infrastructure evolves. ## Roadmap Direction, not a schedule. Where a certification or a deployment model is required for an engagement, the current status is confirmed in writing rather than read off a roadmap. Shipped Engine selection across 6 modalities behind a per-production engine-maker and jurisdiction gate. Per-project usage records. Provenance manifest with an integrity digest on export. In build One shared route table read by every room, with a record per routing decision. Dedicated-tenant deployment template. Tenant-managed engine version pinning. Planned VPC deployment. Customer-managed keys (BYOK) — planned, no KMS path today. Region-pinned storage. Signed C2PA content credentials. Exploring Air-gapped on-premise reference deployment. Open-weight inference parity for image and short-form video. ## Our Commitment We invest in interface, creative flow, and orchestration — not model hype. The AI engine landscape is commoditizing rapidly; today's breakthrough is tomorrow's baseline. We are not tied to any single image generator or video engine. As models evolve, so does our routing — transparently, without user disruption. The best infrastructure is invisible. The orchestration layer succeeds when professionals focus entirely on their creative work, trusting that the right engine is handling the right task — and that what it made is on record. Related research: [Studio Integration](https://aimpreviz.com/research/studio-integration), [Continuity Lock](https://aimpreviz.com/research/continuity-lock), [Repeatable Direction](https://aimpreviz.com/research/deterministic-generation), [Creative Flow Imperative](https://aimpreviz.com/research/creative-flow-imperative). Continue reading [Previous Encoding Cinematic Language](https://aimpreviz.com/research/encoding-cinematic-language) [Next Studio-Friendly Integration](https://aimpreviz.com/research/studio-integration) [All research](https://aimpreviz.com/research) [Try the platform](https://aimpreviz.com/signup)