THE FREE LIFE PLANNER

By Andrew Dougherty

FRDCSA Project

The Free Life Planner is a decision support system (DSS) that helps
one reason about and decide what to do given one's situation
(so-called Practical Reasoning).

In order to achieve this, it employs a 'rule'-based system.

* Keep in mind that the sense of 'rule' here isn't 'law/regulation',
  'normative example', or 'prescribed guide', or even a 'law of
  physics', but rather has a specific technical meaning, i.e. a Prolog
  rule.  I.e. it's not 'telling you what to do,' but rather is a piece
  of flexible logic that is used in thinking.  So for instance, a rule
  might be: I generally fall asleep quickly.  Prolog rules make use of
  'facts,' not facts in the legal fact finding sense, but just again
  Prolog-specific data that is used in inference.
  
In our case, what we want to do is have the AI read lots of documents,
and distill general rules that govern thinking from those documents.

For instance, given this text:

"Your body can’t digest protein without fat, and you can develop
protein poisoning without it." ... "The survival lesson here is that
fat is much more precious in a survival situation than most would
think, because it allows you to digest lean meats."

---

https://getpocket.com/explore/item/four-survival-myths-that-could-get-you-killed?utm_source=pocket-newtab)

It is possible to use an encoding of this tendency into a commonsense
logical 'rule':

<code>
and(possible(developsAilment(proteinPoisoning,Person))) :-
	isa(Person,person),
	isa(Meat,meat),
	hasProperty(Meat,lean).
	isa(Event1,eatingEvent),
	doneBy(Event1,Person)
	consumedObject(Event1,Meat),
	neg(
	    holdsIn(
		    timeIntervalInclusiveFn(now),
		    and(doneBy(Event2,Person),
			isa(Event2,eatingEvent),
			consumedObject(Event2,Object),
			hasProperty(Object,fatty)))).
</code>

What this rule is saying is that "If a Person eats lean meat, and does
not eat anything fatty along with it, it's possible that they will
develop protein poisoning."

It's ironic that I was unaware of this, and was eating a lot of
protein for weight lifting, as well as as much lean meat as I could.
So, clearly, not everyone knows all the things that apply to what they
are doing.  Therefore, encoding all of these tendencies into the Free
Life Planner can help people to avoid potentially disasterous effects.

Let's look at how the FLP would apply this 'rule' to a person's life.

As for eating, that's a facet of life that falls under the aegis of
the FRDCSA's Gourmet Meal Planner.  So, the way the Meal Planner works
is it tracks the state of your pantry, the available food items, and
your dietary health requirements, and constructs a set of constraints
that the user can manipulate to create, even as they go, a meal plan.
One 'rule' for instance is that some people don't like to eat the same
food again within a given timeframe.  So, not only do the 'rules'
pertain to what is healthy, they pertain also to the person's
subjective preferences.

Here is a PDDL 2.2 temporal planning domain describing eating.

/var/lib/myfrdcsa/codebases/internal/verber/data/worldmodel/templates/mealplanning/caloriesingle/current/caloriesingle.d.verb

<code>
(:durative-action consume
  :parameters (?agent - agent ?product - product ?instance - instance ?supplier - supplier)
  :duration (= ?duration 0.1)
  :condition (and
 	      ;; (at start (not (isReplete ?agent)))
 	      (at start (owns_ia ?instance ?agent))
 	      (at start (notConsumed ?instance))
	      (at start (instanceFn ?product ?instance))
	      (at start (isNotReplete ?agent))
	      )
  :effect (and 
	   (at end (consumed ?instance))
	   (at end (not (notConsumed ?instance)))
	   (at end (consumedByAgent ?instance ?agent))
	   (at end (increase (intake total_fat grams ?agent) (nfact total_fat grams ?product)))
	   (at end (increase (intake saturated_fat grams ?agent) (nfact saturated_fat grams ?product)))
	   (at end (increase (intake cholesterol milligrams ?agent) (nfact cholesterol milligrams ?product)))
	   (at end (increase (intake sodium milligrams ?agent) (nfact sodium milligrams ?product)))
	   (at end (increase (intake total_carbohydrate grams ?agent) (nfact total_carbohydrate grams ?product)))
	   (at end (increase (intake dietary_fiber grams ?agent) (nfact dietary_fiber grams ?product)))
	   (at end (increase (intake calories calories_u ?agent) (nfact calories calories_u ?product)))
	   (at end (assign (actions) (+ (actions) 1)))
	   )
  )
</code>

What we would do is encode the advice into the PDDL domain.  In order
to not burden the consume action, we can create a guard action by
defining a fluent (consumedProteinSafely ?agent ?instance) and make
that the effect of the guard action *and* also the precondition of the
'consume' action, as follows:

<code>
(:durative-action consume-protein-safely
  :parameters (?agent - agent ?product - product ?instance - instance ?supplier - supplier)
  :duration (= ?duration 0.0)
  :condition (and
	      (at start
	       (and
		(not (lean ?instance))
		(comsumedByAgent ?agent ?instance)))
	      )
  :effect (and 
	   (at end (consumedProteinSafely ?agent ?instance))
	   )
  )
</code>

And then simply add (consumedProteinSafely ?agent ?instance) as a precondition to the 'consume' action.

Note, for this example, I didn't get into the temporal semantics very
deeply, but the final system would.

Now, one might think it would be difficult to develop these rules, but
there are a couple considerations.

First consideration is that the E2C program can do a roughshod
translation of English into CycL.

<code>
[the, shopper, drank, the, pepsi]
(thereExists ?shopper4675
(and (isa ?shopper4675 (FrequentPerformerFn Shopping ) )
 (thereExists ?pepsi6
  (and (isa ?pepsi6 PepsiCola )
   (and (occursDuring ?drank7550 Past )
    (and (isa ?drank7550 DrinkingEvent )
     (performedBy ?drank7550 ?shopper4675 )
     (consumedObject ?drank7550 ?pepsi6 ) ) ) ) ) ) )
</code>

See also https://frdcsa.org/~andrewdo/projects/E2C.txt

Second consideration is that it is highly important to get these
'rules' into the system, so that people can have the benefit of them.

Here are a few more examples of such rules:

<code>
scheduleTask(flp,Person,checkBatteriesOnAllFireAlarmsInHome(Person,Home)) :-
	residesInDwelling(Person,Home),
	mostRecentEvent([Y-M-D,H:Mi:S],happens(checkBatteriesOnAllFireAlarmsInHome(_Person,Home),[Y-M-D,H:Mi:S])),
 	getCurrentDate(CurrentDate),
	deltaTime([Y-M-D],Duration,CurrentDate),
	Duration = days(Days),
	Days > 182.
</code>

Which says:

"If the last time someone or something checked the batteries in a home
was more than 182 days ago, schedule each household member to check
all the batteries in the house."