Workflow:Guardrails ai Guardrails LLM Output Validation
| Knowledge Sources | |
|---|---|
| Domains | LLMs, Validation, AI_Safety |
| Last Updated | 2026-02-14 12:00 GMT |
Overview
End-to-end process for adding input and output validation guards to LLM API calls using the Guardrails framework with validators from Guardrails Hub.
Description
This workflow outlines the standard procedure for wrapping LLM calls with configurable validation guards. It covers installing the framework and validators, configuring a Guard with one or more validators and on-fail actions, wrapping an LLM API call (OpenAI, Cohere, Anthropic, or any LiteLLM-supported provider), and handling validation outcomes. The Guard object orchestrates the full validation lifecycle: it calls the LLM, parses the output, runs all attached validators, and applies corrective actions (reask, fix, filter, refrain, noop, or exception) when validation fails.
Usage
Execute this workflow when you need to ensure that LLM-generated text meets quality, safety, or compliance requirements before being consumed by your application. Typical triggers include: needing to detect and block toxic language, checking for competitor mentions, enforcing regex patterns, validating PII absence, or applying any other content policy to LLM outputs. This workflow supports both input validation (checking prompts before they reach the LLM) and output validation (checking responses after the LLM generates them).
Execution Steps
Step 1: Install Guardrails and Configure CLI
Install the Guardrails Python package and configure the CLI with an API key from Guardrails Hub. This establishes the connection to the Hub ecosystem for downloading validators and enables optional features like metrics reporting and remote inference.
Key considerations:
- Requires Python 3.10 or greater
- A free API key from Guardrails Hub is required for validator installation
- Configuration is stored locally and persists across sessions
Step 2: Install Validators from Hub
Select and install the appropriate validators for your use case from Guardrails Hub using the CLI. Each validator has a unique Hub URI (e.g., hub://guardrails/regex_match) and is installed into the current Python environment. Multiple validators can be installed to compose validation pipelines.
Key considerations:
- Each validator is a separate pip-installable package pulled from the Hub
- Validators cover categories including content safety, format compliance, PII detection, and semantic checks
- Some validators use ML models and require additional dependencies; others are lightweight and static
Step 3: Create a Guard with Validators
Instantiate a Guard object and attach one or more validators using the use or use_many methods. Each validator is configured with parameters (e.g., regex pattern, threshold) and an on-fail action that determines what happens when validation fails (exception, fix, filter, refrain, reask, or noop).
Key considerations:
- Validators are executed sequentially in the order they are attached
- The on-fail action controls the corrective behavior per validator
- Guards can be named for identification in server mode and telemetry
Step 4: Wrap LLM API Call with Guard
Invoke the Guard as a callable, passing the LLM model name and messages. The Guard handles the full lifecycle: calling the LLM provider via LiteLLM, receiving the response, and routing it through the validation pipeline. Alternatively, use Guard.parse to validate pre-existing LLM output as a post-processing step.
Key considerations:
- The Guard callable supports any LiteLLM-compatible model string (e.g., "gpt-4o", "anthropic/claude-3", "ollama/llama2")
- Custom LLM wrappers can be passed as callables for non-standard providers
- The num_reasks parameter controls how many correction attempts the Guard makes
Step 5: Handle Validation Outcome
Process the ValidationOutcome returned by the Guard. The outcome contains the raw LLM output, validated output (with corrections applied), a boolean indicating whether validation passed, and any error information. Use this to decide how your application proceeds: display the validated output, retry with different parameters, or escalate the failure.
Key considerations:
- ValidationOutcome.validation_passed is the primary success indicator
- The validated_output may differ from raw_llm_output if fix or filter actions were applied
- Guard history (guard.history) provides detailed trace of all validation steps and reasks