How the guardrails work

The guardrail engine is why Formo Support can sit on a live store without inventing order numbers. It runs on every assistant turn before the visitor sees a reply.

Preflight (before the model)#

• Length cap (2,000 characters per message)
• Unicode normalisation and zero-width stripping
• Prompt-injection screen: flag and reframe, never a hard block
• Conversation length cap (30 messages)

Postflight (15 checks)#

Any block routes to the human path. Check 15 is a warning only.

1. The assistant explicitly requested a human.
2. Response empty or under 20 characters.
3. Model confidence below your threshold.
4. Groundedness below your threshold (verifier).
5. Verifier returned unsupported claims.
6. Order numbers in the reply that are not in tool evidence.
7. Tracking numbers not present in tool evidence.
8. A specific date asserted when no tool was called.
9. Refund offered above max refund £.
10. Discount offered above max discount %.
11. Banned phrase used.
12. Link to a domain outside the allow-list.
13. Assistant scaffolding leaked (“as an AI”, “system prompt”).
14. Unfilled placeholder text ([insert…], {{…}}).
15. Reply exceeds max reply words (warning).

Groundedness verifier#

A second, cheaper call on the same provider (your fast model) scores the draft against this turn’s tool evidence. If no tools ran, it checks policy claims against your written policy text instead.

Dry Run#

Generation still happens. The visitor sees copy.dryRunNotice. Activity stores the draft, tool JSON, and which checks fired. This is how you watch it for a week before trusting Live.

Activity is the proof#

Open Dashboard → Activity. Each conversation shows outcome (Answered / Escalated / Blocked / Dry run). The detail drawer lists:

• full transcript
• every tool name and result
• failures and warnings by check number
• token counts and estimated GBP cost

If a reply was blocked, you can see exactly which rule fired.