Guards
A guard is a policy evaluated before an action is reserved — or read (see Policies: everything is a policy). Guards form an ordered list, declared on the skill and, in addition, on a playbook task. A task can add guards; it never removes any.
| guard | does | example |
|---|---|---|
form | values the person gives (data, not a policy). A field marked identifies: true also identifies the room (declared identifier) | {address: {type: text, required: true}, phone: {type: phone, identifies: true}} |
check | the tenant validates | check: checkFormationEligibility |
update | a datum set after the previous guards (same) | update: {price: quoteFormation} |
require | a condition that must hold | {require: "$item.fields.amount <= $params.max_amount"} |
permission | who can take this action | {permission: {profiles: [manager, rh]}} |
policy | a reusable policy: rule (a condition, a budget) or smart | {policy: fraude}, {policy: remboursements-du-jour} |
approval | a person approves, with one click, before the reservation | {approval: {role: support-manager}, when: "$item.fields.amount > 50"} |
step_open — the playbook's order — is not declared: the playbook applies it on its own.
Each guard can carry when: (when it applies), and the attributes of any policy:
name, effect, mode, reason.
The evaluation order
Set by the platform. Within a phase, the order you declared.
| phase | content | why at this rank |
|---|---|---|
| 1 | identity, profiles, permission, sub-identity | fast, deterministic |
| 2 | the playbook's order (step_open) | same |
| 3 | the provenance of arguments (set_by), form, require | same |
| 4 | budgets (rule, with a counter), smart policies | more costly, but does not touch the tenant's tools |
| 5 | check | calls the tenant: never for an action already refused |
| 6 | update | the final datum (the price) |
| 7 | approval | last: the person approves the final action, with its price |
| 8 | reserved |
A read goes through phases 1 to 4.
Three answers
The decision point always answers one of the three:
- allowed — the action is reserved (or read);
- refused, with a reason readable by the person and by the agent ("choose the dishes first");
- a human must decide — the action goes pending, in the inbox of the role concerned.
Each answer is written to the log, with the rules evaluated.
A smart policy can only tighten
A smart policy can ask for a human. It can never turn a refusal into an approval. A business refusal is never decided by the model alone: only the security classes (injection, recipient out of scope) can refuse directly. See Policies.