Documentation Index

Fetch the complete documentation index at: https://docs.aifabrix.ai/llms.txt

Use this file to discover all available pages before exploring further.

Enterprise LLM governance

Prev Next

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
  • call and embed capabilities 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

  1. Publish an LLM provider Connected System (shared call / embed schema).
  2. Domain Enterprise Knowledge for LLM regenerates the unified service datasource under the MCP parent.
  3. Runtime resolves call and embed through CIP to the selected child provider binding.
  4. 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

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.