Guardrails: Inline validator support #1247
Description
Is your feature request related to a problem?
Guardrail entries in an LLM config can only reference a saved validator_config_id, preventing direct definition of validators and requiring deletion to disable, which loses setup.
Describe the solution you'd like
- Allow guardrail entries to be a
validator_config_idor an inline validator spec (type,on_fail, per-type params). - Restrict inline
typetogender_assumption_bias,pii_remover,profanity_free,topic_relevance_llm. - Add an
is_enabledflag (defaulttrue) to both entry types. Disabled entries remain saved but are not fetched or sent. - Send validators in config order to the guardrails service. Include
stageon inline specs and removeis_enabledto comply with validator schemas.
Original issue
Is your feature request related to a problem?
Guardrail entries in an LLM config blob (input_guardrails / output_guardrails) can only reference a validator_config_id saved in the guardrails service. A validator cannot be defined directly in the config, and the only way to turn one off is to delete it from the config version, which loses its setup.
Describe the solution you'd like
- Let each guardrail entry be either a
validator_config_idreference or an inline validator spec (type,on_fail, per-type params). - Restrict inline
typetogender_assumption_bias,pii_remover,profanity_free,topic_relevance_llmfor now. - Add an
is_enabledflag (defaulttrue) to both entry kinds. Disabled entries stay saved in the config version but are never fetched or sent to the guardrails service. - Send validators to the guardrails service in config order. Stamp
stageon inline specs and stripis_enabled, since the service's validator schemas forbid extra fields.
Comments: Implemented in #1245.
Activity
[-]Guardrails: Support inline validators and is_enabled[/-][+]Guardrails: Inline validator support[/+]