Skip to main content
Prerequisites: pip install "mellea[hf]" for local inference; Apple Silicon or CUDA GPU recommended. Guardian Intrinsics work via LocalHFBackend (local HuggingFace inference) or OpenAIBackend pointed at a Granite Switch endpoint. Guardian Intrinsics evaluate LLM outputs for safety and quality using LoRA adapters loaded directly into a HuggingFace backend — purpose-built for evaluation tasks, not general-purpose generation.
Generation vs evaluation: Guardian Intrinsics evaluate content; they do not generate responses. Your session’s generation backend (Ollama, OpenAI, etc.) is unchanged. A separate LocalHFBackend instance handles evaluation only.
Set up the evaluation backend once and reuse it across all checks in your application:

Check response safety

guardian_check() returns a float score from 0.0 (no risk) to 1.0 (risk detected) for the last message from a given role in the conversation:
Scores below 0.5 are safe; scores at or above 0.5 indicate risk detected.

Pre-baked criteria

CRITERIA_BANK contains 10 pre-baked criteria strings from the Granite Guardian model card. Pass the key name as the criteria argument:
Run multiple checks against the same context by iterating over the keys:

Check user input

Pass scoring_schema="user_prompt" to evaluate the last user message before generation — useful as an input gate to block unsafe or jailbreak prompts:
scoring_schema accepts a key from SCORING_SCHEMA_BANK ("assistant_response" — the default; "user_prompt"; "last_turn"; "tool_call") or any custom yes/no schema string.
Migrating from target_role? Use scoring_schema="user_prompt" in place of target_role="user", and scoring_schema="assistant_response" (the default) in place of target_role="assistant". The old parameter still accepts values but emits DeprecationWarning.

Custom criteria

Pass a free-text criteria string in place of a CRITERIA_BANK key to perform domain-specific checks:
Migrating from GuardianRisk? Most enum values map directly to a CRITERIA_BANK key: CRITERIA_BANK also adds "context_relevance", which has no GuardianRisk counterpart. For SEXUAL_CONTENT or any other custom category, pass a descriptive free-text string as the criteria argument (see Custom criteria above).

Policy compliance

policy_guardrails() checks whether a scenario complies with a natural-language policy and returns "Yes" (compliant), "No" (non-compliant), or "Ambiguous":
"Ambiguous" is returned when the scenario does not contain enough information to determine compliance with certainty.

Factuality detection

factuality_detection() evaluates whether the assistant’s response is factually consistent with the documents in context. The context must contain source documents added via ChatContext().add(Document(...)), a user question, and the assistant’s answer. This differs from guardian_check(criteria="groundedness"), which expects documents attached to the assistant message via Message(..., documents=[...]) — see Build a RAG Pipeline. Returns "yes" if the response is factually incorrect (contains unsupported or contradicted claims), or "no" if it is factually correct:
Note: "yes" means factuality issues were detected — the response is incorrect. "no" means the response is factually consistent with the context. This is easy to misread; test against == "yes" to catch errors.

Factuality correction

factuality_correction() generates a corrected version of the assistant’s response grounded in the provided context. Pass the same context used for detection. The function returns whatever the model emits — typically the corrected response text; the model may emit the literal string "none" when no correction is needed, but this is a model-side convention rather than an API contract. Always gate the call on a positive factuality_detection() result:

Limitations

Guardian Intrinsics return a numeric score (or label string) rather than a Requirement instance, so they cannot be passed to m.validate() or wired into RepairTemplateStrategy the way the deprecated GuardianCheck could. The practical workaround is to call guardian_check() (or another Intrinsic) manually after generation and re-invoke m.instruct() with an additional requirement when the score crosses your threshold. A Requirement-backed wrapper is tracked in #1071. Guardian functions also do not emit mellea.requirement metrics — see Observability and metrics for details.
Full example: docs/examples/intrinsics/guardian_core.py demonstrates guardian_check() against five CRITERIA_BANK keys (harm, social_bias, groundedness, function_call, answer_relevance) plus a custom free-text criterion, all against a single LocalHFBackend. Companion examples in the same directory: factuality_detection.py, factuality_correction.py, and policy_guardrails.py.
See also: Intrinsics | LoRA and aLoRA Adapters | Tutorial: Making Agents Reliable