Guardrails are product decisions

Guardrails are product decisions with a safety vocabulary.

That is the part teams sometimes miss. A guardrail is not a magic layer you add after the product is designed. It defines what the product will do, refuse, explain, log, route, and escalate.

I usually ask three questions before I trust a guardrail:

1. what is blocked
2. what is allowed
3. what happens next

If the answer is vague, the boundary is too vague to trust. If the answer is broad enough to block ordinary work, the guardrail is broken product design with a safety label on it.

Concrete examples help here. A guardrail on a code assistant might block repository writes outside the workspace and route risky edits through a diff review. A guardrail on a support assistant might allow drafting but block sending without approval. A guardrail on a content tool might log every refusal and preserve the prompt that triggered it so the team can inspect false positives later.

The refusal text, the allowed-action scope, and the logs should tell the same story. If they do not, the product is hiding the decision in three different places.

The shape can be almost embarrassingly simple in code. A moderation check can return allow, block, or review, and each branch can map to a visible product action. The complexity lives in the policy, not in the number of states. That is usually the right place for it.

type GuardrailDecision = "allow" | "block" | "review"

function decide(request: string): GuardrailDecision {
  if (request.includes("export all customer data")) return "review"
  if (request.includes("ignore previous instructions")) return "block"
  return "allow"
}

That is only a toy, but the product logic is the same thing at a larger scale. The guardrail decides whether the request continues, gets inspected, or stops. The important part is that the user can see the outcome and the team can explain why it happened.