Did you check the docs?
Is your feature request related to a problem? Please describe.
check_async() currently runs input rails only (it extracts the last user message and evaluates it). There is no way to use /v1/checks to evaluate a bot/assistant response against output rails. Callers who need to check LLM-generated content for safety before returning it to users must use generate_async() or build their own rail invocation.
Describe the solution you'd like
Add a rail_types parameter to check_async() (and expose it in the /v1/checks request schema) that lets callers specify which rail types to run, e.g.:
["input"]: current default, check user messages against input rails
["output"]: check assistant messages against output rails
["input", "output"]: run both
Describe alternatives you've considered
Callers use generate_async() with output rails; this works but defeats the purpose of a lightweight check-only API.
Additional context
Parent issue: #2014
First PR: #2013
Did you check the docs?
Is your feature request related to a problem? Please describe.
check_async()currently runs input rails only (it extracts the last user message and evaluates it). There is no way to use/v1/checksto evaluate a bot/assistant response against output rails. Callers who need to check LLM-generated content for safety before returning it to users must usegenerate_async()or build their own rail invocation.Describe the solution you'd like
Add a
rail_typesparameter tocheck_async()(and expose it in the/v1/checksrequest schema) that lets callers specify which rail types to run, e.g.:["input"]: current default, check user messages against input rails["output"]: check assistant messages against output rails["input", "output"]: run bothDescribe alternatives you've considered
Callers use
generate_async()with output rails; this works but defeats the purpose of a lightweight check-only API.Additional context
Parent issue: #2014
First PR: #2013