A Policy is the same thing you build on Access → Policies in Studio, written as an expression. Reusable rules get a name; validate checks every condition before anything is sent.

Facts you can read

P.auth, P.record, P.input, P.request, P.credential and P.env are paths into what a rule can see (the same facts as in Facts a rule can check). Use attribute access: P.auth.user_id, P.record.owner_id, P.request.ip.

Comparisons

These mirror the operators on Comparisons and checks. The trailing underscore on in_ avoids Python’s in keyword.

Ready-made checks

Combining

Python’s and, or and not don’t work on conditions. Use &, | and ~, and put each comparison in parentheses: (P.auth.plan != "free") & P.authenticated().

Using a policy

A Policy can be passed anywhere a rule is accepted: a table’s operations, a bucket’s read_policy, a route’s policy, a subscription’s condition. policy.condition gives the bare condition for combining (mine.condition | staff.condition).

Names are checked

Referencing a policy that doesn’t exist, or a role in P.role(...) that isn’t defined (when roles are managed here), is caught by pawabase validate. See Writing rules and Recipes for what to build.

Roles

Name sets of permissions.

Access rules

The concepts.