Guarding Inputs and Outputs

The Pedal Point assistant is well prompted and well tested, and one day it still says something it should not: a made-up discount code, a rude reply to an abusive customer, a paragraph of legal advice. Prompts shape behaviour most of the time. Checks in code catch the rest, every time.

The rule

Check what goes in and what comes out; the model sits in between.

Think of the model as an unpredictable component wrapped in predictable ones.

Input guards run before the model:

• Length limits. Reject or trim huge inputs that waste tokens or hide attacks.
• Moderation. Many providers offer content moderation endpoints or models that flag harassment, hate, self-harm or violent content. Run them on user messages.
• Scope check. A small, cheap classification step decides whether the request is about bikes and orders. Off-topic requests get a polite redirect without calling the big model.

Output guards run before anyone sees the answer:

• Moderation again. The model's own text can be harmful too.
• Schema validation. For structured output, parse and check every field.
• Grounding checks. If the answer quotes an order status or a price, compare it with the tool result or the source document.
• Blocked content. Reject replies that mention discount codes that do not exist or promise refunds.

Every guard needs a safe failure path: a polite refusal, a fallback message, or a handoff to a person. A guard that just crashes is not safe.

Two more constraints are cheap and effective: limit the maximum output length, and use fixed choices (like categories) wherever your code acts on the answer.

The shortcut

Draw the pipeline as guard → model → guard, and for every failure you can imagine, name which guard catches it.

The trap is asking the model to police itself: "do not say anything harmful". Keep that line, but never let it be the only check.

Drills

Answer fast — trust the rule.

Remember

• Check what goes in and what comes out; the model sits in between.
• Guard → model → guard, and name the guard for every failure.
• Every guard needs a safe failure path.