Yes. Sometimes I think a good way to organize an enterprise system would be to make a trivial CRUD "layer" (no validations there) and then write a bunch of Prolog-clause-like rules. The rules would be the big and interesting part of the system, of course. The system would have to be intelligent enough so that, for performance reasons, after input, only the rules that could possibly affect the input would be run. But then in my modest experience these systems are so complex that sometimes for a simple new input you have to validate a whole bunch of things.

I currently develop health care related software here in Brazil. Total chaos. Once I was talking to a doctor, and he said engineers think mostly about the patterns but doctors think mostly about the exceptions. I think the same applies to business. The doctor in question of course liked our system but had a huge list of feature requests (to treat exceptions).

Totally. I used to write event handling rules for the Tivoli Enterprise Console, which used a Prolog dialect and a godawful DSL based on prolog.

I had a ton of fun doing it... basically you had to write rules to normalize SMTP traps from various vendors, and take action based on them. Network vendors did all sorts of bizarre things -- one ATM would periodically send a "Interface Down" event, with an attribute set that meant that the "Down" event actually meant up!

The hard part was actually doing anything with the events. The regime in charge of my division had a deep seated fear of automatic actions, even actions as simple as opening a trouble ticket.

It was written in Smalltalk.