As you see, most flags are policy-based. Let’s see what it means.
Each policy is a rule, which applies to a certain scenario. Like, block breaking can be regulated by a list of policies, which only allow breaking certain blocks.
For this, the policies have discriminator fields to filter the scenario they apply to. Based on the discriminator fields the policy either applies to the event or not. If so, then the Effect field is used, otherwise not.
If their Final property is enabled (set to true), then the output of their Effect property cannot be overwritten by later policies.
This Effect property can be Allow or Prevent; so when a certain event happens, the policies get evaluated, and in the end, the event is either allowed or prevented.
Most flags are policy-based, which means, that they regulate a certain aspects through a defined list of policies.
As we saw, each policy applies to a certain scenario and may want to Allow or Prevent a certain event. For a flag, each policy on the list gets evaluated in their given order (except when a policy has its Final field enabled, then it stops evaluating).
The last result (Allow or Prevent) will determine if the flag cancels the event or not. In case none of the policies covered the case, the Default field will get used, which has either Allow or Prevent as its value.
So, if an event should be handled by the flag, but the Effect is not specified by any given policy, this will decide what Effect to use as a fallback. Notice, that if the Final property is not enabled, this can still be overwritten by later policies.
In case the Effect property of a policy is a list of sub-policies, then they get evaluated in a similar fashion, in their given order, yielding either Allow or Prevent in the end. This can be used to write nested-if like structures to decide whether to allow or prevent some events on a zone.