The idea here is that constraints could span across multiple tables via chains of foreign keys. It might not be a new idea but i haven't seen any implementations yet (unless you count triggers).
transfer_table(id, user, src, dest, amnt), amnt > 10000.0 -> auth_table(id, man), managed_by_table(user, man).
If you wanted to express that for a transfer involving more than 10,000 dollars that it must have been approved by the user's manager. Basically any logical formula can be used as a constraint. It's also possible to express basic temporal constraints like
+user_pass_table(user, pswd1), user_pass_table@prev(user, pswd2) -> pswd1 != pswd2.
So that says if the user's password has changed, and the user had a password in the previous transaction, they cannot be the same password.
So the main difference is then that my version is SQL based: alter table transactions add constraint c_amount check (amount > 10000 -> auth.name = user.man.name) # or something similar, where you refer to other tables via a chain of foreign keys.
Another extra feature is that you can use aggregators in constraints in case of a one to many relationship: https://github.com/gsvigruha/cosyan/blob/master/src/main/res...
We also allow constraints over aggregations. Though our syntax does require giving the result of the aggregation a temporary "table" name so that it can be used as part of the constraint.
It seems like your DB is basically a Datalog version of what im trying to do in SQL.