nemoguardrails.types
Public LLM types for NeMo Guardrails.
This module defines the stable, public dataclasses and Protocols that make up the LLM interop surface for NeMo Guardrails. The types are implemented as plain Python dataclasses (not Pydantic) so they remain lightweight and introduce no additional runtime dependencies for downstream integrators.
The public surface defined here is stable across minor versions: breaking
changes are reserved for major version bumps. Custom LLMModel and
LLMFramework implementations should import the relevant types from
this module so they stay aligned with the canonical definitions.
Module Contents
Classes
Data
API
Create a ChatMessage from a dict.
Accepts both the canonical nested tool call format
({"function": {"name": ..., "arguments": ...}}) and the legacy
flat format ({"name": ..., "args": ...}). JSON string arguments
are parsed automatically. Role aliases like “bot”, “human”, and
“developer” are mapped to canonical Role values. Unknown keys are
captured into provider_metadata.
Protocol for pluggable LLM framework backends.
Each framework (LangChain, LiteLLM, etc.) implements this protocol to
provide a factory for creating LLMModel instances and managing
its own set of providers.
model_kwargs carries all provider-specific configuration. Framework
implementations extract what they need (e.g. LangChain pops mode
to choose between chat and text completion models).
Release all framework-owned resources and clear all registered state.
Implementations should close any pooled connections, clear registered providers, and return the framework to its initial state. Callers can continue using the instance after reset; new resources will be created on demand.
Protocol that all LLM backends must implement.
Adapters wrap provider-specific SDKs (LangChain, LiteLLM, OpenAI, etc.) behind this interface so the core pipeline remains framework-agnostic.
prompt accepts either a plain string or a list of ChatMessage
objects. Adapters convert ChatMessage to whatever their SDK expects.
**kwargs are forwarded to the underlying SDK (e.g. temperature,
max_tokens).
Implementations must be async generator functions (use yield).
Bases: enum.Enum