Simple Guardrails

Reliable guardrails work in three layers, each catching what the others might miss. Input rules constrain what's allowed into the workflow in the first place. Prompt-level refusals teach the AI its own red lines — situations where it should stop and flag rather than proceed. Output validation mechanically checks what came out, regardless of what the prompt asked for.

No single layer is sufficient on its own. Input rules can't catch a bad output from an otherwise-valid input; prompt refusals can be talked past by an unusual phrasing; output validation alone lets bad data flow in and get processed before being caught. Together, the three layers catch each other's blind spots.

The simplest and most reliable guardrail restricts what can enter the workflow at all. An allow-list — only emails from a specific label, only requests from a known set of senders, only file types you expect — is stronger than trying to filter out every bad case after the fact with a deny-list.

Deny-lists are useful as a secondary layer (blocking a specific known-bad pattern you've already seen cause problems), but they're inherently reactive — you can only deny what you've already thought of or already seen go wrong. Wherever possible, prefer defining what's allowed over trying to enumerate everything that's forbidden.

Beyond restricting inputs, teach the AI itself where its own boundaries are. A pattern like "if the email requests pricing exceptions, legal terms, or complaints, output ESCALATE and stop" gives the model an explicit red line and an explicit action to take when it's crossed, rather than leaving it to guess or improvise.

These refusal rules work best when they're specific about the trigger condition and the required response, mirroring the same "specific and testable" principle from rulebook-writing generally. A vague instruction like "use good judgment about sensitive topics" gives the model far less to reliably act on than a named condition with a named output.

Prompt rules are persuasion — the model tries to comply, but an unusual or adversarial input can steer it off course. Output validation is mechanical enforcement that happens after the AI has spoken, checking the actual output against hard rules regardless of what produced it: format checks (is this valid JSON, does it match the expected template), required fields (is every necessary piece present), forbidden content (does it contain a price that wasn't copied from the approved price list), and sanity ranges (is this dollar amount plausible, or does it look like a decimal-place error).

A sanity-range check is often the cheapest, highest-value guardrail you can add: an invoice-extraction flow validating `0 < amount < 50,000` catches a misread "€1.450,00" turning into 145000 before it reaches a bookkeeping sheet. The error still happens; the mechanical check ensures the harm doesn't.

Some actions carry real-world consequences that no amount of validation fully de-risks: sending something externally, spending money, or deleting data. These categories deserve a standing rule — always route to a human for approval before the action executes, no matter how confident the AI or how many validations passed.

This isn't a lack of trust in the system so much as a recognition that certain mistakes are expensive or irreversible in a way that reading, summarizing, or drafting simply aren't. A human gate on consequential actions is cheap insurance against the rare but costly failure that slips past every other layer.

When something does go wrong — a validation fails, an API errors, an input doesn't match the allow-list — the workflow's behavior matters as much as the guardrails themselves. Fail loud: someone gets notified immediately, rather than the failure disappearing into a log nobody checks. Fail safe: the default action on failure is the cautious one (stop, or route to review) rather than the risky one (proceed anyway).

The one behavior to eliminate entirely is failing silently — an error occurs, nothing is sent, nothing is flagged, and the workflow simply produces no output with no one the wiser. Silent failure is worse than an obvious crash, because it looks like everything worked when it didn't.

Every real automation deserves a one-page written spec covering all of the above concretely: the input allow-list, the specific refusal rules and their trigger conditions, the output validations with their exact thresholds, which actions require the human gate, and exactly what "fail loud" looks like — who gets notified, through what channel, and what they're expected to do.

A lead-reply drafter is a good template: input allow-list (only emails from the leads label), a refusal rule (pricing exceptions, legal terms, or complaints trigger ESCALATE and stop), output validation (no prices unless copied from the price list, must end with the approved signature), and a human gate on all sends. Four cheap layers, written down on one page, produce one workflow you can actually trust.