ruleset. Application variables are stored for the ruleset and are available to any entity executing the ruleset. Entity variable values are only visible to the entity for whom they were stored. Application variables are roughly analogous to class variables. Entity variables are like instance variables. Entity variables, in particular, are a very powerful concept since they provide KRL programmers with the ability to store persistent values without the headache of configuring, linking, and using a database for most things. Because a ruleset represents a closure over its entity variables, every ruleset potentially represents a persistent data object. Event-Condition-Action KRL is called an event condition action or ECA rule language because of the roles that those three fundamental parts of a rule play: Events – Events trigger specific things to occur. Events are like the trigger of the "gun"—the rule. Without the event to trigger the rule, nothing happens. Conditions – Conditions are similar to the safety of a gun. If the conditional expression does not return true, the rule does not fire. Just as a gun either shoots or doesn't shoot based upon the safety, there is no else statement on conditionals. If you want a rule to fire in the opposite case, you can use the not fired postlude to trigger another event, or you can have a rule with a conditional which tests for the opposite case. Actions – Actions are like the bullet coming out of the gun; they are the final result of the rule. A rule may have multiple actions. Besides a collection of rules, KRL rulesets also contain a meta section for specifying information about the ruleset, a dispatch section for providing clues about event salience, and a global section for global definitions. Each rule conforms to the pattern for ECA rule languages given above with some significant additions. The basic structure of a KRL rule is as follows: rule <name> { select when <eventexpr> pre { <declarations> } if <expr> then <action> fired { <effects> } else { <effects> } } Event expressions in the select statement declare the conditions under which the rule will be selected. Declarations in the rule prelude allow values to be calculated and store for use later in the rule Conditional expressions determine whether a selected rule fires. Actions can be either built-in or user defined and specify the action of the rule Statements in the rule's postlude