Ship and explain the pre/post guardrail pipeline

A shippable lab artifact includes: how to run it, the metric result (block rate, false-block samples, escape rate on red-team set), the failure you can still reproduce (post-guard only that still bills the model for blocked intents, or regex gaps on obfuscation), the security gate for logging blocked prompts that contain secrets into an unredacted sink, and a rollback note. The user decision it supports remains: block unsafe prompts and strip or refuse unsafe completions before they reach users.

release: candidate
baseline: stable
gates:
  primary_metric: "unsafe action escape rate"
  required: "zero unauthorized tool executions and at least 0.95 benign-request pass rate"
  security_regression: pass
  staging_probe: pass
  telemetry_signal: "guardrail_decision_total"
rollout:
  canary_percent: 5
  rollback_on: "critical failure or sustained SLO breach"
owner: on-call-ai-platform

Expected evidence: zero unauthorized tool executions and at least 0.95 benign-request pass rate. Store this beside the fixture version so scores remain meaningful after content changes in guardrails-in-code.

State operating limits for the pre/post guardrail pipeline in plain language: fixture size, offline vs live dependencies, and what would require a new eval set. Shipping guardrails-in-code is honest scoping, not maximal confidence language.

Fill this table in your notes for the pre/post guardrail pipeline:

• Proved on policy with PII and self-harm categories + sample prompts: …
• Unproved beyond the fixture: …
• Metric that blocks release: block rate, false-block samples, escape rate on red-team set
• Failure still reproducible: post-guard only that still bills the model for blocked intents, or regex gaps on obfuscation
• Security gate: logging blocked prompts that contain secrets into an unredacted sink
• Rollback: …

Ship the narrative only when the unproved list is honest. Reviewers trust narrow claims that support block unsafe prompts and strip or refuse unsafe completions before they reach users more than maximal language that collapses under the first production oddity.

Hand your ship note to a peer and ask them to recreate a proved/unproved ship note with rollback without watching you type. If they cannot, your evidence is still tribal knowledge. Tighten the run command and the metric line until a stranger can validate the pre/post guardrail pipeline against policy with PII and self-harm categories + sample prompts.

At the mastery and shipping stage for guardrails-in-code, the job is narrower than finishing a product demo. You are creating one progressive evidence piece about policy with PII and self-harm categories + sample prompts that later pages inherit without redefining success. Keep that fixture small enough to inspect by hand, keep outputs copy-pasteable as text, and refuse to narrate this baseline as if it were a production SLA: model call with no guards on the same fixtures.

For this page specifically, success looks like a proved/unproved ship note with rollback while still centering the user decision to block unsafe prompts and strip or refuse unsafe completions before they reach users. If you cannot point to a file, command, or assertion that proves that for the pre/post guardrail pipeline, stay on this page instead of advancing.

Cheatsheet: prompt injection defense

Previous