which consists of a predicate that is used to test the context in which the rule is being evaluated. This check is done after the rule's prelude section, where values are declared, so that it has the benefit of any computation needed to create or manipulate the context. The predicate of the conditional is optional, so it is possible to write a rule that always fires because its selector always selects. However, most interesting rulesets will contain rules that only fire under certain circumstances. The following example shows a simple KRL rule: rule good_morning { select when pageview url #example.com# if morning() then notify(“Welcome!”, “Good morning!”) } This rule would send a “good morning” notification to visitors of any page in the archives of a web site (as denoted by the URL path) if it's morning where the user is. Events and evented systems Events are the notification of a detectable condition in a computer system. The detectable condition will typically be seen as a state change. These are three required parts of event detection and notification: A change of state A process notices the state change The process sends a notification of the state change Notifications are data transfers, not transfers of execution control. This is one of the hallmarks of evented systems that distinguishes them from other types of systems. Interrogatory-style systems use a request-response mode of interaction: “Will you do this?” Imperative-style systems use an RPC mode of interaction: “Do this!” In contrast, event interactions are declarative, stating only that a specific state change happened: “This happened”. Because they are declarative, event notifications impose the semantics of what an event means on the processor rather than a generator. The event generator doesn’t know how a given processor will interpret the event. What’s more, it is not even required that an event processor take any action whatsoever. Each processor is free to interpret the event independently of other processors and generators in the system according to its context and particular purpose. The event generator “raises an event”; in other words, it sends a notification that a state change occurred. The event processor “listens for” or “handles” these events. References External links KRL Documentation Kinetic Rules Engine, the open-source implementation hosted on GitHub Articles on KRL at Phil Windley's blog Programming languages