Choose the model used for document processing and a Role Assistant's Knowledge derivation, then verify the effective selection on a real job. Model configuration changes how a supported job reasons; it does not grant access to documents or activate a Role Assistant.
Read Enterprise LLM governance for provider routing and shared access controls. Keep provider connection, model selection and business-process acceptance as separate checks.
Prerequisites
- A published, usable LLM provider connection with the required models in its catalog.
- Permission to edit Dataplane environment runtime settings and, when needed, the selected Role Assistant's settings.
- A small approved document or existing derivation case for verification.
- The current provider and model choices recorded before changing them.
Confirm that the selected provider account can use the model. A model label in a catalog does not prove available quota, correct deployment naming or a successful provider call. Resolve those issues before comparing reasoning quality.
Where it lives
In the Dataplane, Environment Settings → Runtime settings → AI settings contains the provider, a read-only Default model, embedding and document-reasoning choices, and AI safety limits. The Role Assistant's settings contain its Document reasoning model override.
The default model comes from the selected provider catalog. It supplies decisions, AI Trust, intent and wording when no job-specific setting applies; this page does not offer a separate editable platform workflow-model field.
The separate Environment settings tab shows process configuration that is read-only there. Changing those deployment values requires the Controller and the applicable restart. Do not treat all configuration as immediately editable simply because runtime model settings can be saved in the portal.
How to set
- Open the target environment's runtime settings. Confirm the active LLM provider before choosing models; its published catalog supplies the available choices.
- Read Default model, then set Document reasoning model, or choose Default model in that selector to inherit it. This shared document choice is used for document onboarding and as the inherited choice for Knowledge derivation.
- Review the separate Embedding model and AI safety limits, then select Save runtime settings. Reopen the page and compare the saved choices. Changing the provider clears the embedding and document model fields, while retaining safety limits; select compatible models again.
- If one Role Assistant needs a different derivation model, open its settings and select Document reasoning model. This override is for that assistant's Knowledge derivation; it does not change document onboarding before an assistant is involved.
- Save the assistant setting and reopen it. To remove the override, select Inherit platform document reasoning model, save, and verify inheritance again.
- Run the representative verification below before expanding the change to other assistants or workloads.
Defaults and examples
| Job | Supported selection path |
|---|---|
| Document onboarding | Platform document reasoning model, then provider default |
| Role Assistant Knowledge derivation | Assistant document override, then platform document model, then provider default |
| Ordinary workflow reasoning | Provider catalog default in the current settings workflow; see the legacy exception below |
| Embedding | Separate embedding selection; not a document-reasoning override |
For example, one assistant can use a different derivation model while document onboarding retains the shared model. An older stored workflow-model override can still affect an assistant; inspect effective configuration when behavior differs from the current UI. Changing the document override does not clear that legacy setting.
AI safety limits
| Control | Default | Allowed range |
|---|---|---|
| Maximum input tokens | 32,000 | 4,096–128,000 |
| Maximum output tokens | 8,192 | 256–16,384 |
| Maximum prompt size (KB) | 512 | 64–2,048 |
| Request timeout (seconds) | 90 | 15–300 |
| Maximum transient retries | 2 | 0–3 |
| Concurrent interactive requests per process | 2 | 1–8 |
| Concurrent background knowledge and assistant updates | 1 | 1–2 |
Saved limits apply to newly admitted work; an already-running request keeps its captured limits. Lower applicable profile, model and server ceilings still win. Input capacity also reserves space for output and protocol overhead, so a model's advertised context size is not all available for input.
Interactive concurrency protects each API process. Background concurrency is a shared ceiling across workers; keep it at 1 until capacity is proven. Timeout applies to one provider attempt. Only transient failures retry; request-size and context failures do not.
These controls do not increase provider account token-per-minute quota. Reset overlay restores all runtime overlay defaults, not just one model field, and leaves process environment settings unchanged. Record other runtime choices before using it.
Validate
Use one permitted document-processing job and, if the assistant override changed, one supported Knowledge derivation case. Keep the environment, assistant, job/run reference, intended model and observed model together in the evidence.
Ask the operator to inspect the model-resolution log for the job: it records the job, model and selected level. Compare that with the saved settings. A successful save proves persistence, not which model ran; a retrieved document is not proof that Knowledge derivation occurred.
Repeat after clearing the assistant override to verify fallback to the platform choice. If safety limits changed, submit a new bounded request and check its applied limits or refusal reason; do not use an already-running job to test the new setting. Inspect the output for the intended business meaning and required source provenance. Restore the recorded settings if the change fails the agreed acceptance check, then repeat only the affected case.
Common mistakes
| Mistake | Correction |
|---|---|
| Document model assumed to control every AI call | Identify the job and its effective selection path |
| Provider changed without reviewing model names | Re-select compatible catalog values |
| Empty override treated as an error | Verify the inherited platform/default model |
| Successful save used as quality proof | Execute a representative job and inspect its result |
| Raising local limits to fix provider throttling | Check provider quota and workload concurrency separately |
Limits
Available controls and legacy settings depend on the installed version. This guide covers model selection, not provider quota increases, embedding migration or a guarantee of Knowledge reuse. Validate derivation and access boundaries independently; selecting a model does not establish that a complete document or Role Assistant workflow is production-ready.