<commit_before><?xml version="1.0" encoding="UTF-8"?>
<section>
  <title>WorkingMemory</title>

  <para>The working memory is basically the rule engine, with all the rules
  loaded, ready to go. It holds references to all data that has been
  "asserted" into it (until retracted) and it the place where the interaction
  with your application occurs. Working memories are stateful objects. They
  may be shortlived, or longlived. If you are interacting with an engine in a
  stateless manner, that means you would use the RuleBase object to create a
  newWorkingMemory for each session, and then discard the working memory when
  finished (creating a working memory is a cheap operation). An alternative
  pattern is a working memory that is kept around for a longer time (such as a
  conversation) - and kept updated with new facts.</para>

  <section>
    <title>Facts</title>

    <para>Facts are objects (beans) from your application that you assert into
    the working memory. Facts are any java objects which the rules can access.
    The rule engine does not "clone" facts at all, it is all
    references/pointers at the end of the day. Facts are your applications
    data.</para>
  </section>

  <section>
    <title>Assertion</title>

    <para>"Assertion" is the act of telling the working memory about the
    facts. WorkingMemory.assertObject(yourObject) for example. When you assert
    a fact, it is examined for matches against the rules etc. However, no
    actions are taken until you call "fireAllRules()" after you have finished
    asserting your facts.</para>
  </section>

  <section>
    <title>Retraction</title>

    <para>Basically the reverse of Asserting. When you retract a fact, the
    working memory will no longer track that fact, and any rules that were
    dependent on that fact will not be activated. Note that it is possible to
    have rules that depend on the "non existence" of a fact, in which case
    retracting a fact may cause a rule to activate (see the "not" and "exist"
    keywords).</para>
  </section>

  <section>
    <title>Modification</title>

    <para>If the rule engine has to know when a fact has changed, as rules
    that depend on that fact may have to be triggered again. You modify a fact
    to tell the rule engine that its state has changed.</para>
  </section>

  <section>
    <title><indexterm>
        <primary>Logical Assertion</primary></indexterm>
	</title>

    <para>
	In a regular assertion, you need to explicitly retract a fact. In logical assertions, the fact that was asserted will be automatically retracted when
	the conditions that asserted it in the first place are no longer true (its actually cleverer then this, if there are no possible conditions that could support the logical assertion, only then will it be retracted). 
	</para>

	<para>
		This sounds confusing but its not really. Logical assertions are a powerful form of truth maintenance. A logically asserted fact can be thought of as a proxy for all the conditions that cause the rule it belongs to to be true. This means that you can use a logically asserted fact in a condition in other rules, without including all the conditions that triggered the logical assertion (meaning that all those conditions are not repeated everywhere). Logically asserted facts are like other facts, nothing special, you can even use "not" to check for the non existance of a logically asserted fact.
	</para>

	<section>
		<title>Example scenario</title>
		<para>
			An example may make things clearer.
			Imagine a credit card processing application, processing transactions for a given account (and we have a working memory accumulating knowledge about a single accounts transaction). The rule engine is doing its best to decide if transactions are possibly fraudulent or not. Imagine this rule base basically has rules that kick in when there is "reason to be suspicious" and when "everything is normal". </para>
		<para>
			Of course there are many rules that operate no matter what (performing standard calculations etc). 
			Now there are possibly many reasons as to what could trigger a "reason to be suspicious": someone notifying the bank, a sequence of large transactions, transactions for geographically disparate transactions, or even reports of credit card theft. Rather then smattering all the little conditions in lots of rules, imagine there is a fact class called "SuspiciousAccount". </para>
		<para>
			Then there can be a series of rules whose job is to look for things that may raise suspicion, and if they fire, they simply assert a new SuspiciousAccount() instance. All the other rules just have conditions like "not SuspiciousAccount()" or "SuspiciousAccount()" depending on their needs. Note that this has the advantage of allowing there to be many rules around raising suspicion, without touching the other rules. When the facts causing the SuspiciousAccount() assertion are removed, the rule engine reverts back to the normal "mode" of operation (and for instance, a rule with "not SuspiciousAccount()" may kick in which flushes through any interrupted transactions). 
		</para>
		<para>
			If you have followed this far, you will note that truth maintenance like logical assertions allows rules to behave a little like a human would, and can certainly make the rules more managable.
	</para>

	</section>
  </section>



  <section>
    <title>Globals</title>

    <para>Globals are a named objects that can be passed in to the rule
    engine. Most often these are used for static information, or services that
    are used in the RHS of a rule, or perhaps a means to return objects from
    the rule engine.</para>
  </section>

  <section>
    <title>Property Change Listener</title>

    <para>If your fact objects are java beans, you can implement a property
    change listener for them, and then tell the rule engine about it. This
    means that the engine will automatically know when a fact has changed, and
    behave accordingly (you don't need to tell it that it is modified). There
    are proxy libraries that can help automate this (a future version of
    drools will bundle some to make it easier).</para>
  </section>

  <section><commit_msg>updated logicals<commit_after><?xml version="1.0" encoding="UTF-8"?>
<section>
  <title>WorkingMemory</title>

  <para>The working memory is basically the rule engine, with all the rules
  loaded, ready to go. It holds references to all data that has been
  "asserted" into it (until retracted) and it the place where the interaction
  with your application occurs. Working memories are stateful objects. They
  may be shortlived, or longlived. If you are interacting with an engine in a
  stateless manner, that means you would use the RuleBase object to create a
  newWorkingMemory for each session, and then discard the working memory when
  finished (creating a working memory is a cheap operation). An alternative
  pattern is a working memory that is kept around for a longer time (such as a
  conversation) - and kept updated with new facts.</para>

  <section>
    <title>Facts</title>

    <para>Facts are objects (beans) from your application that you assert into
    the working memory. Facts are any java objects which the rules can access.
    The rule engine does not "clone" facts at all, it is all
    references/pointers at the end of the day. Facts are your applications
    data.</para>
  </section>

  <section>
    <title>Assertion</title>

    <para>"Assertion" is the act of telling the working memory about the
    facts. WorkingMemory.assertObject(yourObject) for example. When you assert
    a fact, it is examined for matches against the rules etc. However, no
    actions are taken until you call "fireAllRules()" after you have finished
    asserting your facts.</para>

    <para>Drools uses an IdentityHashMap – if an instance is asserted twice
    then it returns the previous fact handle – i.e. it ignores the second
    assertion for the same fact. Once </para>
  </section>

  <section>
    <title>Retraction</title>

    <para>Basically the reverse of Asserting. When you retract a fact, the
    working memory will no longer track that fact, and any rules that were
    dependent on that fact will not be activated. Note that it is possible to
    have rules that depend on the "non existence" of a fact, in which case
    retracting a fact may cause a rule to activate (see the "not" and "exist"
    keywords).</para>
  </section>

  <section>
    <title>Modification</title>

    <para>If the rule engine has to know when a fact has changed, as rules
    that depend on that fact may have to be triggered again. You modify a fact
    to tell the rule engine that its state has changed.</para>
  </section>

  <section>
    <title><indexterm>
        <primary>Logical Assertion</primary>
      </indexterm></title>

    <para>In a regular assertion, you need to explicitly retract a fact. In
    logical assertions, the fact that was asserted will be automatically
    retracted when the conditions that asserted it in the first place are no
    longer true (its actually cleverer then this, if there are no possible
    conditions that could support the logical assertion, only then will it be
    retracted).</para>

    <para>This sounds confusing but its not really. Logical assertions are a
    powerful form of truth maintenance. A logically asserted fact can be
    thought of as a proxy for all the conditions that cause the rule it
    belongs to to be true. This means that you can use a logically asserted
    fact in a condition in other rules, without including all the conditions
    that triggered the logical assertion (meaning that all those conditions
    are not repeated everywhere). Logically asserted facts are like other
    facts, nothing special, you can even use "not" to check for the non
    existance of a logically asserted fact.</para>

    <para>Normal assertions are said to be “STATED” (ie The Fact has been
    stated - just like the intuitive concept). You cannot logically assert
    fact, that is already STATED (it has no effect - it only needs to be
    STATED once that is). If you logically assert something and then later
    normally assert the same fact then that the fact that was logically
    asserted is changed to STATED (ie becomes a normal non logically asserted
    fact). </para>

    <section>
      <title>Example scenario</title>

      <para>An example may make things clearer. Imagine a credit card
      processing application, processing transactions for a given account (and
      we have a working memory accumulating knowledge about a single accounts
      transaction). The rule engine is doing its best to decide if
      transactions are possibly fraudulent or not. Imagine this rule base
      basically has rules that kick in when there is "reason to be suspicious"
      and when "everything is normal".</para>

      <para>Of course there are many rules that operate no matter what
      (performing standard calculations etc). Now there are possibly many
      reasons as to what could trigger a "reason to be suspicious": someone
      notifying the bank, a sequence of large transactions, transactions for
      geographically disparate transactions, or even reports of credit card
      theft. Rather then smattering all the little conditions in lots of
      rules, imagine there is a fact class called "SuspiciousAccount".</para>

      <para>Then there can be a series of rules whose job is to look for
      things that may raise suspicion, and if they fire, they simply assert a
      new SuspiciousAccount() instance. All the other rules just have
      conditions like "not SuspiciousAccount()" or "SuspiciousAccount()"
      depending on their needs. Note that this has the advantage of allowing
      there to be many rules around raising suspicion, without touching the
      other rules. When the facts causing the SuspiciousAccount() assertion
      are removed, the rule engine reverts back to the normal "mode" of
      operation (and for instance, a rule with "not SuspiciousAccount()" may
      kick in which flushes through any interrupted transactions).</para>

      <para>If you have followed this far, you will note that truth
      maintenance like logical assertions allows rules to behave a little like
      a human would, and can certainly make the rules more managable.</para>
    </section>
  </section>

  <section>
    <title>Globals</title>

    <para>Globals are a named objects that can be passed in to the rule
    engine. Most often these are used for static information, or services that
    are used in the RHS of a rule, or perhaps a means to return objects from
    the rule engine.</para>
  </section>

  <section>
    <title>Property Change Listener</title>

    <para>If your fact objects are java beans, you can implement a property
    change listener for them, and then tell the rule engine about it. This
    means that the engine will automatically know when a fact has changed, and
    behave accordingly (you don't need to tell it that it is modified). There
    are proxy libraries that can help automate this (a future version of
    drools will bundle some to make it easier).</para>
  </section>

  <section>
{'fraction_non_alphanumeric': 0.052263498270416604, 'fraction_numerical': 0.0004511956685215822, 'mean_word_length': 3.604916897506925, 'pattern_counts': {'":': 2, '<': 141, '<?xml version=': 2, '>': 141, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3957586', 'n_tokens_mistral': 3321, 'n_tokens_neox': 3175, 'n_words': 1932}