Sentinel provides execution traces to better understand the execution of a policy.

When using the Sentinel CLI, traces are shown
on policy failure during apply or test, or when the -trace flag is
explicitly specified. For Sentinel-enabled applications, traces are optional
and may require special configuration to enable. Most Sentinel-enabled
applications log traces on failure.

Note: We're actively improving Sentinel tracing in each release
to provide better data and improve readability. The exact format of a
trace may not match the Sentinel version embedded in the application you're
using, but the data should be similar.

The least-nested values are all rules. It begins with the
value of that rule (TRUE or FALSE) followed by the location and name
of the rule. Notice that the main rule is false, the is_open_hours
rule is true, and the is_weekday rule is false.

We know that main requires bothis_open_hours and is_weekday to be
true, so based on the trace, we can tell that main failed because
is_weekday was false. We can then go to the definition of is_weekday
in the source and determine the logical failure.

The trace also breaks down more complex logical expressions. Notice that
is_open_hours is split into the two sides of the and, but is_weekday
has no values under it. Because is_weekday is itself a single boolean
expression, the failure isn't repeated. But for is_open_hours, you can also
see the result of each side of the boolean expression.

The Sentinel runtime sometimes optimizes away executions completely. This
can result in a trace being incomplete. If you don't see a rule or boolean
expression within the trace, it means the runtime didn't execute it at all.

Notice that the expression 10 < 5 is not present in the trace.
Since 42 > 40 is true, the entire or can be short-circuited and
the result is known to be true. Remaining parts of the expression are not
executed and are therefore not present in the trace.