Purpose
Large language model providers are normal Connected Systems. When a provider publishes, Enterprise Knowledge regenerates a unified LLM service under shared LLM governance. Platform services and Role Assistants call that governed surface — they do not invent a default vendor SDK path. Consume access still follows Operational Trust (for example Everyone for call/embed) — see AI Fabrix roles.
LLM provider Connected System → Unified LLM Enterprise Knowledge → call / embed capabilities → CIP
Boundary: regenerating unified LLM Enterprise Knowledge must not change Role Assistant Draft / Active / Suspended, and LLM call / embed are not Role Assistant business capabilities. See Role Assistant status and availability.
Why it matters
Organizations often run more than one model provider. A shared governance path keeps:
- Credentials on the provider Connected System and secret store
callandembedcapabilities on a shared child schema- Selection explicit when multiple providers are published
- Fail-closed routing when a default selector is required but missing
Assistants use the governed LLM surface for model access. Admins bind providers and selectors. Integrators publish provider systems like any other Connected System. Publishing a provider does not make Role Assistants Active.
How it works
- Publish an LLM provider Connected System (shared
call/embedschema). - Domain Enterprise Knowledge for LLM regenerates the unified service datasource under the MCP parent.
- Runtime resolves call and embed through CIP to the selected child provider binding.
- When two or more providers are published, operators set the default selector for internal portal and product callers; external MCP callers pass the selector when required.
Chat and embedding model defaults come from the selected connection catalog — not from ad hoc product environment overrides for model ids.
Admin vs assistant-facing
| Audience | What they do |
|---|---|
| Integrator | Scaffold, authenticate, publish, and certify the provider Connected System |
| Admin / operator | Ensure the default selector is set when multiple providers are bound; monitor trust |
| Role Assistant / end user | Use governed work and business capabilities; model access goes through the unified LLM surface — not as RA capability rows |
Cross-link Build AI contract and CIP when exposing call / embed on Business Entities: Configure AI contract and CIP execution.
Example
A tenant publishes one embedding-capable provider first. Internal callers omit a selector and the platform routes to that sole binding. Later a second provider is published. Until operators set the default selector, internal routing fails closed with a configuration error listing allowed keys — rather than silently picking a vendor.
Business value
Unified LLM Enterprise Knowledge keeps model access inside Operational Trust and CIP evidence. It prevents each assistant feature from growing a private SDK integration and keeps multi-provider choice explicit.
Related
- Role Assistant status and availability
- Enterprise MCP
- System basics and kind
- Configure subscriptions
- Configure AI contract
Limits
Available providers, model catalogs, and selector enforcement vary by deployment. This page describes product governance; it does not list lab vendor names or require hand-uploaded platform folders for the unified LLM system.