Summary
Guardrail and safety responses should not be silent or opaque. Users and operators must see why a request was blocked or flagged, with reason, confidence, evidence, and remediations for trust and debuggability.
Problem to solve
Current guardrail/injection/PII blocks are not always explainable. This erodes developer/operator trust and hinders incident learning or auditing.
Proposed solution
- Structured error messages: rule fired, evidence, confidence, recommended fix
- Guardrail hit explanations in logs and UI (optionally in user response)
- Audit log of blocks and triggers (for incident review, see related ticket)
Alternatives considered
- Silent or minimal errors
- External custom tooling for log analysis
Who benefits?
Priority / impact
- Improves trust and adoption
- Enables root-cause and proactive engineering
Additional context
Best practices: explainable AI/ML, GDPR/art. 22 requirements for explainability.
Summary
Guardrail and safety responses should not be silent or opaque. Users and operators must see why a request was blocked or flagged, with reason, confidence, evidence, and remediations for trust and debuggability.
Problem to solve
Current guardrail/injection/PII blocks are not always explainable. This erodes developer/operator trust and hinders incident learning or auditing.
Proposed solution
Alternatives considered
Who benefits?
Priority / impact
Additional context
Best practices: explainable AI/ML, GDPR/art. 22 requirements for explainability.