declarative_policy 1.0.0 → 1.1.0

data/doc/caching.md

@@ -1,4 +1,302 @@
 # Caching
 
-**TODO**: see https://gitlab.com/gitlab-org/declarative-policy/-/issues/11
+This library deals with making observations about the state of
+a system (usually performing I/O, such as making a database query),
+and combining these facts into logical propositions.
 
+In order to make this performant, the library transparently caches repeated
+observations of conditions. Understanding how caching works is useful for
+designing good policies, using them effectively.
+
+## What is cached?
+
+If a policy is instantiated with a cache, then the following things will be
+stored in it:
+
+- Policy instances (there will only ever be one policy per `user/subject` pair
+  for the lifetime of the cache).
+- Condition results
+
+The correctness of these cached values depends on the correctness of the
+cache-keys. We assume the objects in your domain have a `#id` method that
+fully captures the notion of object identity. See [Cache keys](#cache-keys) for
+details. All cache keys begin with `"/dp/"`.
+
+Policies themselves cache the results of the abilities they compute.
+
+Policies distinguish between facts based on the type of the fact:
+
+- Boolean facts: implemented with `condition`.
+- Abilities: implemented with `rule` blocks.
+- Non-boolean facts: implemented by policy instance methods.
+
+For example, consider a policy for countries:
+
+```ruby
+class CountryPolicy < DeclarativePolicy::Base
+  condition(:citizen) { @user.citizen_of?(country.country_code) }
+  condition(:eu_citizen, scope: :user) { @user.citizen_of?(*Unions::EU) }
+  condition(:eu_member, scope: :subject) { Unions::EU.include?(country.country_code) }
+
+  condition(:has_visa_waiver)    { country.visa_waivers.any? { |c| @user.citizen_of?(c) } }
+  condition(:permanent_resident) { visa_category == :permanent }
+  condition(:has_work_visa)      { visa_category == :work }
+  condition(:has_current_visa)   { has_visa_waiver? || current_visa.present? }
+  condition(:has_business_visa)  { has_visa_waiver? || has_work_visa? || visa_category == :business }
+
+  condition(:full_rights, score: 20) { citizen? || permanent_resident? }
+  condition(:banned) { country.banned_list.include?(@user) }
+
+  rule { eu_member & eu_citizen }.enable :freedom_of_movement
+  rule { full_rights | can?(:freedom_of_movement) }.enable :settle
+  rule { can?(:settle) | has_current_visa }.enable :enter_country
+  rule { can?(:settle) | has_business_visa }.enable :attend_meetings
+  rule { can?(:settle) | has_work_visa }.enable :work
+  rule { citizen }.enable :vote
+  rule { ~citizen & ~permanent_resident }.enable :apply_for_visa
+  rule { banned }.prevent :enter_country, :apply_for_visa
+
+  def current_visa
+    return @current_visa if defined?(@current_visa)
+
+    @current_visa = country.active_visas.find_by(applicant: @user)
+  end
+
+  def visa_category
+    current_visa&.category
+  end
+
+  def country
+    @subject
+  end
+end
+```
+
+This is a reasonably realistic policy - there are a few pieces of state (the
+country, the list of visa waiver agreements, the list of citizenships the user
+holds, the kind of visa the user has, if they have one, the current list of
+banned users), and these are combined to determine a range of abilities (whether
+one can visit or live in or vote in a certain country). Importantly, these
+pieces of information are re-used between abilities - the citizenship status is
+relevant to all abilities, whereas the banned list is only considered on entry
+and when applying for a new visa).
+
+If we imagine that some of these operations are reasonably expensive (fetching
+the current visa status, or checking the banned list, for example), then it
+follows that we really care about avoiding re-computation of these facts. In the
+policy above we can see a few strategies that are taken to avoid this:
+
+- Conditions are re-used liberally.
+- Non-boolean facts are cached at the policy level.
+
+## Re-using conditions
+
+Rules can and should re-use conditions as much as possible. Condition
+observations are cached automatically, so referring to the same condition in
+multiple rules is encouraged. Conditions can also refer to other conditions by
+using the predicate methods that are created for them (see `full_rights`, which
+refers to the `:citizen` condition as `citizen?`).
+
+Note that referring to conditions inside other conditions can be DRY, but it
+limits the ability of the library to optimize the steps (see
+[optimization](./optimization.md)). For example in the `:has_current_visa`
+condition, the sub-conditions will always be tested in the order
+`has_visa_waiver` then `current_visa.present?`. It is recommended not to rely
+heavily on this kind of abstraction.
+
+## Re-using rules
+
+Entire rule-sets can be re-used with `can?`. This is a form of logical
+implication where a previous conclusion can be used in a further rule. Examples
+of this here are `can?(:settle)` and `can?(:freedom_of_movement)`. This can
+prevent having to repeat long groups of conditions in rule definitions. This
+abstraction is transparent to the optimizer.
+
+## Non-boolean values must be managed manually
+
+The condition `has_current_visa` and the more specific
+`has_{work,business}_visa` all refer to the same piece of state - the
+`#current_visa`. Since this is not a boolean (but is here a database record with
+a `#category` attribute), this cannot be a condition, but must be managed by the
+policy itself.
+
+The best approach here is to use normal Ruby methods and instance variables for
+such values. The policy instances themselves are cached, so that any two
+invocations of `DeclarativePolicy.policy_for(user, object)` with identical
+`user` and `object` arguments will always return the same policy object. This
+means instance variables stored on the policy will be available for the lifetime
+of the cache.
+
+Methods can be used for the usual reasons of clarity (such as referring to the
+`@subject` as `country`) and brevity (such as `visa_category`).
+
+## Cache lifetime
+
+The cache is provided by the user of the library, passing it to the
+`.policy_for` method. For example:
+
+```ruby
+DeclarativePolicy.policy_for(user, country, cache: some_cache_value)
+```
+
+The object only needs to implement the following methods:
+
+- `cache[key: String] -> Boolean?`: Fetch the cached value
+- `cache.key?(key: String) -> Boolean`: Test if the key is cached
+- `cache[key: String] = Boolean`: Cache a value
+
+Obviously, a `HashMap` will work just fine, but so will a wrapper around a
+[`Concurrent::Map`](https://ruby-concurrency.github.io/concurrent-ruby/1.1.4/Concurrent/Map.html),
+or even a map that delegates to Redis with a TTL for each key, so long as the
+object supports these methods. Keys are never deleted by the library, and values
+are only computed if the key is not cached, so it is up to the application code
+to determine the life-time of each key.
+
+Clearly, cache-invalidation is a hard problem. At GitLab we share a single cache
+object for each request - so any single request can freely request a permission
+check multiple times (or even compute related abilities, such as
+`:enter_country` and `:settle`) and know that no work is duplicated. This
+allows developers to reason declaratively, and add permission checks where
+needed, without worrying about performance.
+
+## Cache sharing: scopes
+
+Not all conditions are equally specific. The condition `citizen` refers to
+both the user and the country, and so can only be used when checking both the
+user and the country. We say that this is the `normal` scope.
+
+This is not always true however. Sometimes a condition refers only to the user.
+For example, above we have two conditions: `eu_citizen` and `eu_member`:
+
+```ruby
+  condition(:eu_citizen, scope: :user) { @user.citizen_of?(*Unions::EU) }
+  condition(:eu_member, scope: :subject) { Unions::EU.include?(country.country_code) }
+```
+
+`eu_citizen` refers only to the user, and `eu_member` refers only to the
+country.
+
+If we have a user that wants to enter multiple countries on a grand European
+tour, we could check this with:
+
+```ruby
+itinerary.countries.all? { |c| DeclarativePolicy.policy_for(user, c).allowed?(:enter_country) }
+```
+
+If `eu_citizen` were declared with the `normal` scope, then this would have a lot of cache
+misses. By using the `:user` scope on `eu_citizen`, we only check EU citizenship
+once.
+
+Similarly for `eu_member`, if a team of football players want to visit a
+country, then we could check this with:
+
+```ruby
+team.players.all? { |user| DeclarativePolicy.policy_for(user, country).allowed?(:enter_country) }
+```
+
+Again, by declaring `eu_member` as having the `:subject` scope, this ensures we
+only check EU membership once, not once for each football player.
+
+The last scope is `:global`, used when the condition is universally true:
+
+```ruby
+  condition(:earth_destroyed_by_meteor, scope: global) { !Planet::Earth.exists? }
+
+  rule { earth_destroyed_by_meteor }.prevent_all
+```
+
+In this case, it doesn't matter who the user is or even where they are going:
+the condition will be computed once (per cache lifetime) for all combinations.
+
+Because of the implications for sharing, the scope determines the
+[`#score`](https://gitlab.com/gitlab-org/declarative-policy/blob/2ab9dbdf44fb37beb8d0f7c131742d47ae9ef5d0/lib/declarative_policy/condition.rb#L58-77) of
+the condition (if not provided explicitly). The intention is to prefer values we
+are more likely (all other things being equal) to re-use:
+
+- Conditions we have already cached get a score of `0`.
+- Conditions that are in the `:global` scope get a score of `2`.
+- Conditions that are in the `:user` or `:subject` scopes get a score of `8`.
+- Conditions that are in the `:normal` scope get a score of `16`.
+
+Bear helper-methods in mind when defining scopes. While the instance level cache
+for non-boolean values would not be shared, as long as the derived condition is
+shared (for example by being in the `:user` scope, rather than the `:normal`
+scope), helper-methods will also benefit from improved cache hits.
+
+### Preferred scope
+
+In the example situations above (a single user visiting many countries, or a
+football team visiting one country), we know which is more likely to be useful,
+the `:subject` or the `:user` scope. We can inform the optimizer of this
+by setting `DeclarativePolicy.preferred_scope`.
+
+To do this, check the abilities within a block bounded
+by [`DeclarativePolicy.with_preferred_scope`](https://gitlab.com/gitlab-org/declarative-policy/blob/481c322a74f76c325d3ccab7f2f3cc2773e8168b/lib/declarative_policy/preferred_scope.rb#L7-13).
+For example:
+
+```ruby
+cache = {}
+
+# preferring to run user-scoped conditions
+DeclarativePolicy.with_preferred_scope(:user) do
+  itinerary.countries.all? do |c|
+    DeclarativePolicy.policy_for(user, c, cache: cache).allowed?(:enter_country)
+  end
+end
+
+# preferring to run subject-scoped conditions
+DeclarativePolicy.with_preferred_scope(:subject) do
+  team.players.all? do |player|
+    DeclarativePolicy.policy_for(player, c, cache: cache).allowed?(:enter_country)
+  end
+end
+
+```
+
+When we set `preferred_scope`, this reduces the default score for conditions in
+that scope, so that they are more likely to be executed first. Instead of `8`,
+they are given a default score of `4`.
+
+## Cache keys
+
+In order for an object to be cached, it should be able to identify itself
+with a suitable cache key. A good cache key will identify an object, without
+containing irrelevant information - a database `#id` is perfect, and this
+library defaults to calling an `#id` method on objects, falling back to
+`object_id`.
+
+Relying on `object_id` is not recommended since otherwise equivalent objects
+have different `object_id` values, and using `object_id` will not get optimal caching. All
+policy subjects should implement `#id` for this reason. `ActiveRecord` models
+with an `id` primary ID attribute do not need any extra configuration.
+
+Please see: [`DeclarativePolicy::Cache`](https://gitlab.com/gitlab-org/declarative-policy/blob/master/lib/declarative_policy/cache.rb).
+
+## Cache invalidation
+
+Generally, cache invalidation is best avoided. It is very hard to get right, and
+relying on it opens you up to subtle but pernicious bugs that are hard to
+reproduce and debug.
+
+The best strategy is to run all permission checks upfront, before mutating any
+state that might change a permission computation. For instance, if you want to
+make a user an administrator, then check for permission **before** assigning
+administrator privileges.
+
+However, it isn't always possible to avoid needing to mark certain parts of the
+cached state as dirty (in need of re-computation). If this is needed, then you
+can call the `DeclarativePolicy.invalidate(cache, keys)` method. This takes an
+enumerable of dirty keys, and:
+
+- removes the cached condition results from the cache
+- marks the abilities that depend on those conditions as dirty, and in need of
+  re-computation.
+
+The responsibility for determining which cache-keys are dirty falls on the
+client. You could, for example, do this by observing which keys are added to the
+cache (knowing that condition keys all start with `"/dp/condition/"`), or by
+scanning the cache for keys that match a heuristic.
+
+This method is the only place where the `#delete` method is called on the cache.
+If you do not call `.invalidate`, there is no need for the cache to implement
+`#delete`.

data/doc/defining-policies.md

@@ -74,7 +74,7 @@ condition(:owns) { @subject.owner == @user }
 condition(:has_access_to) { @subject.owner.trusts?(@user) }
 condition(:old_enough_to_drive) { @user.age >= laws.minimum_age }
 condition(:has_driving_license) { @user.driving_license&.valid? }
-condition(:intoxicated, score: 5) { @user.blood_alcohol < laws.max_blood_alcohol }
+condition(:intoxicated, score: 5) { @user.blood_alcohol > laws.max_blood_alcohol }
 condition(:has_access_to, score: 3) { @subject.owner.trusts?(@user) }
 ```
 
@@ -108,8 +108,7 @@ Rules are conclusions we can draw based on the facts:
 rule { owns }.enable :drive_vehicle
 rule { has_access_to }.enable :drive_vehicle
 rule { ~old_enough_to_drive }.prevent :drive_vehicle
-rule { intoxicated }.prevent :drive_vehicle
-rule { ~has_driving_license }.prevent :drive_vehicle
+rule { intoxicated | ~has_driving_license }.prevent :drive_vehicle
 ```
 
 Rules are combined such that each ability must be enabled at least once, and not
@@ -130,6 +129,33 @@ access the `@user` or `@subject`, or any methods on the policy instance. You
 should not perform I/O in a rule. They exist solely to define the logical rules
 of implication and combination between conditions.
 
+The available operations inside a rule block are:
+
+- Bare words to refer to conditions in the policy, or on any delegate.
+  For example `owns`. This is equivalent to `cond(:owns)`, but as a matter of
+  general style, bare words are preferred.
+- `~` to negate any rule. For example `~owns`, or `~(intoxicated | banned)`.
+- `&` or `all?` to combine rules such that all must succeed. For example:
+  `old_enough_to_drive & has_driving_license` or `all?(old_enough_to_drive, has_driving_license)`.
+- `|` or `any?` to combine rules such that one must succeed. For example:
+  `intoxicated | banned` or `any?(intoxicated, banned)`.
+- `can?` to refer to the result of evaluating an ability. For example,
+  `can?(:sell_vehicle)`.
+- `delegate(:delegate_name, :condition_name)` to refer to a specific
+  condition on a named delegate. Use of this is rare, but can be used to
+  handle overrides. For example if a vehicle policy defines a delegate as
+  `delegate :registration`, then we could refer to that
+  as `rule { delegate(:registration, :valid) }`.
+
+Note: Be careful not to confuse `DeclarativePolicy::Base.condition` with
+`DeclarativePolicy::RuleDSL#cond`.
+
+- `condition` constructs a condition from a name and a block. For example:
+  `condition(:adult) { @subject.age >= country.age_of_majority }`.
+- `cond` constructs a rule which refers to a condition by name. For example:
+  `rule { cond(:adult) }.enable :vote`. Use of `cond` is rare - it is nicer to
+  use the bare word form: `rule { adult }.enable :vote`.
+
 ### Complex conditions
 
 Conditions may be combined in the rule blocks:

data/doc/optimization.md

@@ -0,0 +1,277 @@
+# Optimization
+
+This library cares a lot about performance, and includes features that
+aim to limit the impact of permission checks on an application. In particular,
+effort is made to ensure that repeated checks of the same permission are
+efficient, aiming to eliminate repeated computation and unnecessary I/O.
+
+The key observation: permission checks generally involve some facts
+about the real world, and this involves (relatively expensive) I/O to compute.
+These facts are then combined in some way to generate a judgment. Not all facts
+are necessary to know in order to determine a judgment. The main aims of the
+library:
+
+- Avoid unnecessary work.
+- If we must do work, do the least work possible.
+
+The library enables you to define both how to compute these facts
+(conditions), and how to combine them (rules), but the library is entirely
+responsible for the scheduling of when to compute each fact.
+
+## Making truth
+
+This library is essentially a build-system for truth - you can think of it as
+similar to [`make`](https://www.gnu.org/software/make/), but:
+
+- Instead of `targets` there are `abilities`.
+- Instead of `files`, we produce `boolean` values.
+
+We have no notion of freshness - uncached conditions are always re-computed, but
+just like `make`, we try to do the least work possible in order to evaluate the
+given ability.
+
+For the interested, this corresponds to
+[`memo`](https://hackage.haskell.org/package/build-1.0/docs/src/Build.System.html#memo) in
+the taxonomy of build systems (although the scheduler here is somewhat smarter
+about the relative order of dependencies).
+
+## Optimization is reducing computation of expensive I/O
+
+In the context of this library, optimization refers to ways we can:
+
+- Expose the smallest possible units of I/O to the scheduler.
+- Never run a computation twice.
+- Indicate to the scheduler which computations should be run first.
+
+For example, if a policy defines the following rule:
+
+```ruby
+rule { fact_a & fact_b }.enable :some_ability
+```
+
+The core of the matter: if we know in advance that `fact_a == false`, then we do not need to compute
+`fact_b`. Conversely, if we know in advance that `fact_b == false`, then we do
+not need to run `fact_a`. The same goes for `fact_a | fact_a`.
+
+In this case:
+
+- The smallest possible units of I/O are `fact_a` and `fact_b`, and the library
+  is aware of them.
+- The library uses the [cache](./caching.md) to avoid running a condition more
+  than once.
+- It does not matter which order we run these conditions in - the scheduler is
+  free to re-order them if it thinks that `fact_b` is somehow more efficient to
+  compute than `fact_a`.
+
+## The scheduling logic
+
+The problem each permission check seeks to solve is determining the truth value
+of a proposition of the form:
+
+```pseudo
+any? enabling-conditions && not (any? preventing-conditions)
+```
+
+If `[a, b, c]` are enabling conditions, and `[x, y, z]` are preventing
+conditions, then this could be expressed as:
+
+```ruby
+(a | b | c) & ~x & ~y & ~z
+```
+
+But the [scheduler](../lib/declarative_policy/runner.rb) represents this
+as a flat list of rules - conditions and their outcomes:
+
+```pseudo
+[
+  (a, :enable),
+  (b, :enable),
+  (c, :enable),
+  (x, :prevent),
+  (y, :prevent),
+  (z, :prevent)
+]
+```
+
+They aren't necessarily run in this order, however. Instead, we try to order
+the list to minimize unnecessary work.
+
+The
+[logic](https://gitlab.com/gitlab-org/declarative-policy/blob/659ac0525773a76cf8712d47b3c2dadd03b758c9/lib/declarative_policy/runner.rb#L80-112)
+to process this list is (in pseudo-code):
+
+```pseudo
+while any-enable-rule-remains?(rules)
+  rule := pop-cheapest-remaining-rule(rules)
+  fact := observe-io-and-update-cache rule.condition
+
+  if fact and rule.prevents?
+    return prevented
+  else if fact and rule.enables?
+    skip-all-other-enabling-rules!
+    enabled? := true
+
+if enabled?
+  return enabled
+else
+  return prevented
+```
+
+The process for ordering rules is that each condition has a score, and we prefer
+the rules with the lowest `score`. Cached values have a score of `0`. Composite
+conditions (such as `a | b | c`) have a score that the sum of the scores of
+their components.
+
+The evaluation of one rule results in updating the cache, so other rules might
+become cheaper, during policy evaluation. To take this into account, we re-score
+the set of rules on each iteration of the main loop.
+
+## Consequences for the policy-writer
+
+While interesting in its own right, this has some practical consequences for the
+policy writer:
+
+### Flat is better than nested
+
+The scheduler can do a better job of arranging work into the smallest possible
+chunks if the definitions are as flat as possible, meaning this:
+
+```ruby
+rule { condition_a }.enable :some_ability
+rule { condition_b }.prevent :some_ability
+```
+
+Is easier to optimise than:
+
+```ruby
+rule { condition_a & ~condition_b }.enable :some_ability
+```
+
+We do attempt to flatten and de-nest logical expressions, but it is not always
+possible to raise all expressions to the top level. All things being
+equal, we recommend using the declarative style.
+
+#### An example of sub-optimal scheduling
+
+The scheduler is only able to re-order conditions that can be flattened out to
+the top level. For example, given the following definition:
+
+```ruby
+condition(:a, score: 1) { ... }
+condition(:b, score: 2) { ... }
+condition(:c, score: 3) { ... }
+
+rule { a & c }.enable :some_ability
+rule { b & c }.enable :some_ability
+```
+
+The conditions are evaluated in the following order:
+
+- `a & c` (score = 4):
+  - `a` (score = 1)
+  - `c` (score = 3)
+- `b & c` (score = 3):
+  - `c` (score = 0 [cached])
+  - `b` (score = 2)
+
+If instead this were three top level rules:
+
+```ruby
+rule { a }.enable :some_ability
+rule { b }.enable :some_ability
+rule { ~c }.prevent :some_ability
+```
+
+Then this would be evaluated as:
+
+- `a` (score = 1)
+- `b` (score = 2)
+- `c` (score = 3)
+
+If `a` and `b` fail, then `3` is never evaluated, saving the most
+expensive call.
+
+The total evaluated costs for each arrangement are:
+
+| Failing conditions | Nested cost     | Flat cost     |
+|--------------------|-----------------|---------------|
+| none               | 4 `(a, c)`      | 4 `(a, c)`    |
+| all                | 3 `(a, b)`      | 3 `(a, b)`    |
+| `a`                | 6 `(a, b, c)`   | 6 `(a, b, c)` |
+| `b`                | 4 `(a, c)`      | 4 `(a, c)`    |
+| `c`                | 4 `(a, c, c=0)` | 4 `(a, c)`    |
+| `a` and `b`        | 4 `(a, c, c=0)` | 3 `(a, b)`    |
+| `a` and `c`        | 6 `(a, b, c)`   | 6 `(a, b, c)` |
+| `b` and `c`        | 4 `(a, c, c=0)` | 4 `(a, c)`    |
+
+While the overall costs for all arrangements are very similar,
+the flat representation is strictly superior, and does not even need to
+rely on the cache for this behavior.
+
+### Getting the scope right matters
+
+By default, the outcome of each rule is cached against a key like
+`(rule.condition.key, user.key, subject.key)`. (For more information, read
+[caching](./caching.md).) This makes sense for some things like:
+
+```ruby
+condition(:owns_vehicle) { @user == @subject.owner }
+```
+
+In this case, the result depends on both the `@user` and the `@subject`. Not all
+conditions are like that, though! The following condition only refers to the
+subject:
+
+```ruby
+condition(:roadworthy) { @subject.warrant_of_fitness.current? }
+```
+
+If we cached this against `(user_a, car_a)` and then tested it
+against `(user_b, car_a)` it would not match, and we would have to re-compute
+the condition, even though the road-worthiness of a vehicle does not depend on
+the driver. See [caching](./caching.md) for more discussion on scopes.
+
+Because more general conditions are more sharable, all things being equal, it is
+better to evaluate a condition that might be shared later, rather than one that
+is less likely to be shared. For this reason, when we sort the rules,
+we prefer ones with more general scopes to more specific ones.
+
+### Getting the score right matters
+
+Each condition has a `score`, which is an abstract weight. By default this is
+determined by the scope.
+
+However, if you know that a condition is very expensive to run, then it makes sense
+to give it a higher score, meaning it's only evaluated if we really need
+to. On the other hand, if a condition is very likely to be determinative, then
+giving it a lower score would ensure we test it first.
+
+For example, take two conditions, one which queries the local DB, and one
+which makes an external API call. If they are otherwise equivalent, calling
+the database one first is likely to be more efficient, as it might save us needing
+to make the external API call. Conditions that are
+[pure](https://en.wikipedia.org/wiki/Pure_function) can even be given a value of
+`0`, as no I/O is required to compute them.
+
+```ruby
+condition(:local_db) { @subject.related_object.present? }
+condition(:pure, score: 0) { @subject.some_attribute? }
+condition(:external_api, score: API_SCORE) { ExtrnalService.get(@subject.id).ok? }
+
+# these are run in the order: pure, local_db, external_api
+rule { external_api & pure & local_db }.enable :some_ability
+```
+
+The other consideration is the likelihood that a condition is determinative. For
+example, if `condition_a` is true 80% of the time, and `condition_b` is true
+20% of the time, then we should prefer to run `condition_a` if these conditions
+enable an ability (because 80% of the time we don't need to run `condition_b`).
+But if they prevent an ability, then we would prefer to run `condition_b` first,
+because again, 80% of the time we can skip `condition_a`. This consideration is
+more subtle. It requires knowing both the distribution of the condition, and
+the consequence of its outcome, but this can be used to further optimize the
+order of evaluation by marking some conditions as more likely to affect the
+outcome.
+
+All things being equal, we prefer to run prevent rules, because they have this
+property - they are more likely to save extra work.