Fail closed: the one rule that runs through every layer
One rule runs through every layer of Kav: when something can't be evaluated cleanly, it denies — never guesses yes.
Most systems have a rule like this somewhere. Few apply it everywhere, and the gap between "mostly fail closed" and "always fail closed" is exactly where a real incident tends to live.
The rule, stated plainly
An unevaluable rule condition does not match. A missing entitlement denies. A budget overrun returns the declared fallback and raises an alert. A stub — an integration that isn't wired up yet — fails closed rather than pretending to succeed. There is no fail-open path anywhere in this platform, by design.
Why this is a top-level rule, not a coding guideline
A fail-open eligibility check in a municipal system, or in any system handling another organization's customer data, is a data-exposure bug — not a bug that happens to expose data, but definitionally one. Making "fail closed" one of the handful of rules that override everything else means every other design decision has to defer to it, rather than being weighed against it case by case.
Where it shows up concretely
A rule-engine condition that can't be evaluated returns "no match," never "match." A capability call with a missing or unresolvable entitlement is denied, not allowed pending review. A refusal in this platform always has a name — a specific gate that closed — rather than one general "something went wrong," which is what makes a refusal something a team can count, alert on and fix.
What a customer experiences
Occasionally, a slower or more cautious answer than a fail-open system would have given. Never a wrong yes.