Rules form the basis of a policy by representing behavior that is either passing or failing. Rules are a first class language construct in Sentinel. A policy can and should be broken down into rules to aid with readability, testability, and performance.
Readability: A policy that is broken down into rules can be read more easily. The logic becomes clearer to see for policy writers when they come back to it.
Reportability: When tracing is enabled, rules form the foundation of the data returned. All evaluated rules are added to the trace with the data the rule evaluated to, and their position within policy or module source files.
Testability: Policy testing is built on asserting the values of rules. By breaking logic down into rules, you're able to more effectively test your policies.
Performance: Rules are only evaluated on demand, and are also only evaluated once. This means that a rule referenced multiple times only has a one-time performance cost. For complex logic, this could result in improved performance.
An example usage of rules is shown below:
Rules can also contain non-boolean data. This can be useful for passing more detail to the caller than an opaque boolean value would be able to communicate.
Details about rules and their behavior can be found in the language reference. Rules have important behavior so we recommend reading the language reference on rules. Rules will be used throughout the remainder of the documentation.