Our policy logic allows for some powerful, but potentially confusing rules.

• A policy is composed of one or more "OR'ed" rules.
• A rule is composed of one or more "AND'ed" conditions
• Within each rule, a given criteria may appear exlusively in a single condition. Within that condition, this criteria can be  have multiple "ORed"instances with different matchings. 
• Most of the matchings allow for regex specification

This logic can allow for  multiple methods to describe the same idea, especially when regex is involved.

In addition, there can be confusing positive/negative logic scenarios:

• In most cases  a policy triggers because something in your specification matches a predefined condition. For example, you "ADDED" a privileged Linux capability , or simply your contaoner name matches a given pattern.  
• In other cases , a policy triggers because something is missing .  For example, your YAML is missing a readiness probe,  a required annotation is missing, or you did not specify the required DROP capabilities
• Further, some conditions have both positive and negative forms. For example, Privileged escalation is "Allowed" or "Not allowed"

It is requested that we expand on this logic and provide examples

Related  https://issues.redhat.com/browse/ROX-32020 bug that was found when using  a complex logic. It might  have been avoided if documentation led the user to a simpler solution.