Frame the pre/post guardrail pipeline experiment

Success is not “I followed the tutorial.” Success is producing evidence that: blocked inputs never call the model; unsafe outputs are refused with a stable code. The accepted input is narrow on purpose: user text, policy rules, model adapter. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: model call with no guards on the same fixtures. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

{"user_text":"Track order A12","session_customer":"cust_7","tool":"lookup_order","args":{"order_id":"A12","customer_id":"cust_99"}}

Expected evidence: zero unauthorized tool executions and at least 0.95 benign-request pass rate. Treat the printout as a claim about this fixture, not as proof that the toolchain merely started.

For the pre/post output guardrail pipeline, a decorative win often looks like a clean run that never checks block rate, false-block samples, escape rate on red-team set. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: logging blocked prompts that contain secrets into an unredacted sink.

For guardrails-in-code, write the claim on a sticky note in this exact shape: “Given user text, policy rules, model adapter, the pre/post guardrail pipeline will …”. Fill the ellipsis with the observable part of: blocked inputs never call the model; unsafe outputs are refused with a stable code. Tape the baseline beside it: model call with no guards on the same fixtures. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to block unsafe prompts and strip or refuse unsafe completions before they reach users. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (policy with PII and self-harm categories + sample prompts) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against policy with PII and self-harm categories + sample prompts. Note the metric you will eventually require (block rate, false-block samples, escape rate on red-team set) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is post-guard only that still bills the model for blocked intents, or regex gaps on obfuscation.

At the experiment brief 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 falsifiable claim and baseline written before coding 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

Next