Plan a model deployment: boundaries and pool shape

Choose the smallest model pool in which every selectable route satisfies the workload’s hard boundaries. Confirm first that the workload is inside the documented scope and limits. A human review step does not make an excluded use available.

Map non-negotiable boundaries

Record the requirements that can disqualify a route before you compare scores:

• permitted providers, accounts, contracts, subprocessors, processing locations, retention, deletion, and human access;
• required response formats, input types, context sizes, languages, Tools, and document sources;
• acceptable latency, cost, quota, availability, recovery, and safe failure behavior; and
• who can approve a boundary change, apply it, verify it, and stop new work.

A Tenant separates logical authorization, configuration, usage, cost, Tasks, and Tenant-scoped resources inside one deployment. It does not create a separate provider account, credential, runtime, storage system, or physical region. Use a separate account, credential, storage boundary, or deployment when the requirement needs one.

Choose the pool shape

Every route in the pool must satisfy every hard requirement of every workload that can reach it. Split the pool when one selectable route would violate a boundary or essential application contract.

For a customer-hosted deployment, Run the Platform in your infrastructure explains the installation agreement and how to start it.

Choose models for the work

Choose models by the hardest representative requests that can reach the pool. Compare model classes first, then qualify named models on your own work:

• Complex or long work: large models with very long context windows give you room for long requests and substantial reasoning, at a higher cost and possibly a higher latency than a pool of small models. Use workload evidence to justify that expense; a simple classification does not necessarily need it.
• Frequent orchestration or quick decisions: small models can suit repeated short decisions at a lower cost, but they can struggle with difficult reasoning. Any enabled route can receive a hard request: qualify these models on the hardest cases, or use the Strictly separated specialist work pool shape above. A pool of only small models can fail a long request with LLM_CONFIG_CONTEXT_TOO_SMALL. Measure latency instead of assuming it from model size.
• Focused domain work: use task capabilities and benchmark evidence to identify relevant evidence, then qualify candidates on your own domain. Strong domain results do not establish suitability for every other request that can reach the pool.

Create from preset lists the current presets in the Duale AI catalog. A preset fills the route form with its context window and listed USD prices. Those values are configuration, not a quote for your provider account.

Keep at least one model whose context window fits the largest request your workload sends. A request that fits none fails with LLM_CONFIG_CONTEXT_TOO_SMALL; other model-configuration failures use LLM_CONFIG_UNAVAILABLE. Handle pool failures states the response to each.

Check route fit and independence

For each route, verify:

Route settings owns the supported provider types and fields. Understand model routing explains how Duale AI chooses a route.

Route names and configuration order do not define primary and fallback roles. One Task can make several provider requests; neither their order nor a request to every route is guaranteed. Retries keep the Task’s original deadline.

Configure each independently selectable endpoint as a separate route with a stable, unique model_name inside the Tenant. Two routes are not independent for a failure they share through a provider account, quota, gateway, network path, credential, endpoint health state, or upstream host. Record the shared boundary instead of describing the routes as fully independent.

Create a disabled evaluation route

1. Open the Dashboard for the target deployment and select the Tenant. The Tenant selector does not switch deployments.
2. Grant only the required configuration actions. Reading a route never returns a credential value; create and update actions can set or replace it. Access needed to change a route lists the actions.
3. Open Settings → LLM Providers, then choose Create or Create from preset. A route defaults to enabled when the field is absent. Turn Enabled off before the first standalone save. For a preset, select Detach to edit for Enabled, turn it off, then save.
4. Set the stable model_name, human display_name, provider-facing model_id, endpoint or location, capabilities, limits, USD prices, and required credential. Review every effective field supplied by a preset, including Benchmarks. Use Task capabilities and benchmark evidence to assess which measurements are relevant to your work.
5. Follow Qualify and enable the route to enable the candidate for evaluation and check the application contract before production enablement.

Saving validates the configuration shape. It does not contact or qualify the provider, and missing evidence does not quarantine an enabled route.

Verify before production

Approve the plan only when:

• every selectable route satisfies the workload’s hard boundaries and essential outcome contract;
• tests cover the supported result, safe failure, deadline, and each distinct failure domain used for a resilience claim;
• the complete processing and human-access path supports every locality or hosting claim;
• each route, credential, provider dependency, change owner, verifier, rollback, and stop control is named; and
• the plan allows time for a saved change to apply before anyone relies on it.

Record a hard requirement as met or not applicable with a reason. Do not approve a missing hard boundary. Assign owners and record the change defines the proportional record for material changes.