In Rego, why is "every" never false?

According to the Open Policy Agent documentation, in Rego, every evaluates either to true or undefined. Why not true or false? What is it about Rego that suggests false is the wrong value? By comparison, the membership operator in always evaluates to true or false, which is more in line with my expectations for every.

I found this explanation of the difference between false and undefined but I did not find it enlightening.

> The difference between undefined and false is that undefined in Rego is not a value you can refer to in Rego (whereas false is just another JSON value.) With respect to how queries and rules evaluated, undefined and false behave the same. In order for a query to succeed (or for a rule to produce a value) ALL of the statements in the query (or body of the rule) must be true. In Rego, all values except undefined and false are considered true.

Clearly Rego is using undefined in a way that is different than other languages, where it usually indicates some kind of information is missing. For example, in JavaScript, if you refer to a variable that has been declared but has not been initialized, its value is undefined. In this Rego example, though, every is completely defined, but evaluates to undefined instead of false anyway.

So, in Rego, what is the philosophy behind the use of undefined and why does every evaluate to undefined instead of false?

It is the first time I heard about Rego so I went to their docs trying to help and I'll share what I understood.<br>

from this example here in the basics section:

>You can define a new concept using a rule. For example, v below is true if the equality expression is true.

v if "hello" == "world"

>If we evaluate v, the result is undefined because the body of the rule never evaluates to true. As a result, the document generated by the rule is not defined.

you can see how you should think in Rego, it is like you put v there and then execute the expression if it is "truthy" then v will receive true otherwise v won't be affected and it is undefined.

>Expressions that refer to undefined values are also undefined. This includes comparisons such as !=

v == true // undefined decision
v != true // undefined decision

>all values except undefined and false are considered true

so false is unique as undefined but the real difference is that

>false is just another JSON value

and Rego uses JSON comparison so it will be detected as JSON and then recognized as false that's why we want to give undefined instead so we avoid that.

I wondered about false and its use cases, I found this example here:

default allow := false

allow if {
    input.user == "bob"
    input.method == "GET"
}

allow if input.user == "alice"

here we initialize allow with the default keyword to false so even if it won't be affected by the condition it is false.<br>

>Without the default definition, the allow document would simply be undefined for the same input.

still cannot see if this is useful since:

>undefined and false behave the same. In order for a query to succeed (or for a rule to produce a value) ALL of the statements in the query (or body of the rule) must be true.

so I still can deal with allow as undefined
note: the above example is from the default keyword section.

another example is the one mentioned in the question, the membership operator in with the every keyword

I found it similar to this one:

v if "hello" == "world"

we just replaced if "hello" == "world" with the "the membership operator in" and v with every:

every server in site.servers {
  endswith(server.name, "-dev")
}

with the same logic, the result of the rule will be either true or false then every is either true or undefined.

the the membership operator in is a function it is not a concept to define like v and every, and it is designed to return true or false so we use it to define every, makes sense to me.