Writing policy rules that hold up

Most policy documents are written for humans who can ask a manager. Rules have to survive without one.

Start from what can go wrong

List the five worst things your agent could do, refund beyond the cap, cancel a dispatched order, promise a delivery date, skip identity verification, share another customer's data. Those are your first DENY rules.

Make every condition checkable

"Within a reasonable window" is not a rule. "Within 30 days of delivery_date" is. If a condition cannot be evaluated from the transcript, the trace or a tool result, rewrite it.

Pair REQUIRE with the claim

A REQUIRE rule should tie an action to the statement that implies it: refund_order must precede any refund confirmation. This is what catches claimed-not-executed cases automatically.

Set severities honestly

Reserve the highest severity for money, data and compliance. If everything is critical, the release gate becomes noise and gets bypassed.

Version and review

Bump the policy version whenever the business rule changes, and keep the old version attached to historical runs so past results remain interpretable.

What to take from this

• Write DENY rules for the worst outcomes first.
• Every condition must be mechanically checkable.
• Honest severities keep the gate credible.