A rule that should never fire, and a clear alarm when it does.
integrity.py · output · proof · check · try it in the playground
A bank keeps a simple promise: no account may have a negative balance.
A rule like that is an integrity constraint: not a way to derive new facts, but a condition the data must never break. If it is broken, we want to know at once, and know which record broke it.
Two accounts and the constraint:
fact(account('alice', 30))
fact(account('bob', -5))
contradiction(account(Owner, Balance), Balance < 0)
The last line reads: if some Owner has a Balance below 0, then
false — that is, the data contradicts itself.
'false'
And the program stops with exit code 65.
An exit code is the number a program hands back to whatever started it;
0 means “all fine”. peye uses 65 to say “a false was derived: the data
breaks a constraint”. A script or pipeline can notice that and stop.
The alarm comes with its reason:
false — rule 3, with Owner = bob, Balance = −5.Alice’s account does not appear: it played no part in the violation.
Even an alarm can be checked. The checker confirms that:
Verdict: checked. All 3 steps verified, nothing taken on trust. The proof is valid; it is the data that is wrong.
python -m peye examples/integrity.py; echo "exit code: $?"
python -m peye --proof examples/integrity.py
Change Bob’s balance to fact(account('bob', 5)) and run again: nothing is
printed, and the exit code is 0.
A good constraint fails loudly and explains itself. Here the run stops with a distinct exit code, and the checked proof points straight at Bob’s −5.