Tag: Temporal Reasoning

Mythbuster : Temporal Reasoning

Mythbuster : Temporal Reasoning

This post started life in an elevator, as a conversation with someone who has been working with Intelligent Advisor for about a year now, and who struggled a bit with Entities and Relationships, but who generally speaking was quite comfortable with building rules and calculations. The business had presented a new requirement, and upon seeking advice from a colleague, it became clear that Temporal Reasoning was needed.

The individual was, to put it simply, quite stressed. Temporal reasoning had been presented as some sort of magical, dangerous thing. “You probably won’t need this for much, so let’s just leave it for now” was how it had been mentioned originally. And this mystery had grown over time. It’s complicated!!! It’s weird!!!

So I wanted to spend 20 minutes or so chatting about it. And this is the conversation I had, reproduced in WordPress Post format. I hope it helps others who are perhaps wondering about temporal reasoning or are struggling with the concept.

In Intelligent Advisor, everything is temporal, if you want it to be. Consider the following simple rule:

the benefit amount = the number of children * the rate

So, if you have two children and the rate is 300, then the benefit amount is 600. Check it in the Debugger!

Great. But you have two children today, maybe tomorrow you will have three. And didn’t the rate change a few times over the years?. Both of these changes illustrate the fact that your rule, as it currently stands, works fine for static values – but these values change over time. So what does it take to change your rule into a magic, wonderful temporal rule?


Your rule remains as it is. The input data and the output data change. So let’s do it. Change the input information for the number of children (feel free to change the dates or number of children).

Temporal Reasoning Input Image

In the above example, I’ve added three children (who are now most definitely adults!) according to their dates of birth. The number of children starts at 0, and continues from there. So now our benefit amount looks like this, assuming that the rate does not change :

Temporal Reasoning Output Image

The benefit amount has become (tada!) a temporal attribute. Not really. It’s the attribute value that is now temporal. Your attribute could always handle it, you just didn’t use it before. Now let’s go and change the rate as well. Edit the rate input value in the Debugger:

Temporal Reasoning Final Image

Obviously feel free to change the dates and the rate values. Now your rule is 100% temporal – two sets of input values, and a set of output values. No rule modification required. And that’s the beauty of Intelligent Advisor reasoning – whether you need temporal reasoning or not, it’s right there ready to go.

Guest Post : Time Based Reasoning Worked Example

Guest Post : Time Based Reasoning Worked Example

It’s with great pleasure that I introduce you to Evert Fernandes, CTO at Magia Consulting UK Ltd. A self-confessed OPA geek, Evert has stepped up and written this article about Time Based Reasoning (and hopefully some more ) for the OPA Hub Website. Thank you Evert and…over to you!

Time Based Reasoning (TBR) – also known as Temporal Reasoning – is one of those subjects that new OPA developers tend to struggle with. It’s a more advanced subject that – once mastered – can provide huge benefits to your project.

In this article I will try to explain what TBR is, present a use case and provide a walk-through on turning the use case into rules.

So, what exactly is Time Based Reasoning?

Time Based Reasoning allows the rule developer to create rules that include attributes which contain values that are subject to change over time.

It is able to conclude rules like:

  • What’s the amount of daily benefit the citizen was entitled to on June 26th, 2017?

Time Based Reasoning Worked Example

Let’s have a look at the following use case:

“How much benefit is the citizen entitled to between 01-01-2017 and 31-12-2017 (inclusive)”

The following rules apply:

  • If the person is not married, the daily allowance is $10. If the person is married the allowance is $14
  • The person can only claim benefit if the daily income is less than $200.

For the sake of simplicity, we will only look at a binary relationship status, married and single. The real world is more nuanced and complicated, but feel free to expand on this example. 😉

As you can see, the mix of variables already creates quite a complex and fluid situation, especially considering that any of the variables are subject to change over the period in question (01/01/2017 – 31-12-2017).

So, let’s start by looking at the first element and create some rules:

OPA 12 - Time Based Reasoning Worked Example 1

There are a number of things happening in these rules, let’s take a closer look.

First of all, a rule table has been created (ALT + Z) to determine the daily allowance amount based on marriage status, $14 when married and $10 when single. The single status is implied by the ‘otherwise’ conclusion, i.e. the person is single because the person is not married.

The second rule calculates the total allowance over the time period, starting on January 1st 2017 and ending on January 1st 2018. The reason the end date is January 1st 2018 and not December 31st 2017 is because the end date is not included, so we simply add a day.

The function is called IntervalDailySum and takes in three parameters:

  • The start date (inclusive) of the period over which the calculation needs to take place;
  • the end date (exclusive) of the period over which the calculation needs to take place;
  • the rule text of the attribute over which the total daily allowance over the period needs to be calculated.

In this example, we provide hard coded values for the start and end dates. In the real world, the start and end dates will most likely come from date attributes.

We now need to test the rules. In order to do this, we start the OPM debugger and head to the data tab:

OPA 12 - Time Based Reasoning Worked Example

As you can see, not a lot is happening here. Let’s give the citizen a marital status by setting the value of ‘The citizen is married’ to ‘True’.

OPA 12 - Time Based Reasoning Worked Example

So far, so good. We have a marital status and OPA is able to work out the total allowance (365 days x $14 = $5110).

Let’s now assume that the person was single at the start of 2017, got married on March 1st 2017 and was single again on September 1st 2017 (don’t worry, they’re still friends! 😉).

How do we enter that data? OPA provides a handy feature called ‘Change Points’ to handle this.

Let’s reset the value for the citizen marital status:

OPA 12 - Time Based Reasoning Worked Example

Click on ‘Change Points’:

OPA 12 - Time Based Reasoning Worked Example

What this allows us to do is to take the attribute and set different values for different slices of time.

You can use ‘Add’ to add a new change point. Once a new point is created, you can set the date and value at that point in time.

Let’s add two change points. One on March 1st 2017 with a value of True and the other on September 1st 2017 with a value of False. Use the Date picker below the change point list to pick the dates.

OPA 12 - Time Based Reasoning Worked Example

The eagle eyed among you may have spotted that I’ve set the value at the top to ‘False’.

What this is saying is:

  • Until March 1st 2017, the value is False.
  • Between March 1st 2017 (inclusive and August 31st 2017 (inclusive), the value is ‘True’.
  • From September 1st 2017 and after, the value is ‘False’.

So, click ‘OK’ and let’s inspect the effect of our handiwork in the debugger:

OPA 12 - Time Based Reasoning Worked Example

There’s a lot more information here and one of the first things you’ll notice is that the total allowance has changed from $5110 to $4386.

If we break down the individual periods, you will see why:

  • January 1st – February 28th = 59 days x $10 (Single rate) = $590.
  • March 1st – August 31st = 184 days x $14 (Married rate) = $2576.
  • September 1st – December 31st = 122 days x $10 = $1220.

$590 + $2576 + $1220 = $4386!

Have a play with different dates and change points and you will find OPA is very good at working this stuff out for you.

OPA also offers a way to visualize this data. Right click the ‘the daily allowance for the citizen’ attribute and select ‘Show in Temporal Visualization’:

OPA 12 - Time Based Reasoning Worked Example

A new tab will appear top left named ‘Temporal Visualization’. If you click it, you will see:

OPA 12 - Time Based Reasoning Worked Example

This visualization confirms that we start off with $10/day, changing to $14/day from March 1st and changing back to $10/day on September 1st.

Time to complicate things a little by adding another variable to the mix in the shape of the daily income.

Let’s assume that the citizen started 2017 with a daily income of $150. Then later in the year the income rose to $250 and later yet, the income dropped to $180.

In order to deal with this new variable, we will change the rule that calculates the daily allowance to include the daily income for the citizen:

OPA 12 - Time Based Reasoning Worked Example

Remember that OPA will evaluate top down, so first it will check to see if the person is married and whether the daily income is less than $200. If this is false, it will check to see if the income is less than $200 and finally, if the citizen is not married and the daily income is greater or equal to $200, the ‘otherwise’ clause will apply.

Make sure the updated rule validates by pressing the ‘Validate’ button.

Now let’s start a debug session and have a look at the outcomes.

Start your debug session and navigate to the ‘data’ tab.

Supply the exact same values as the first example, making sure to set up the change points correctly.

Fun fact: Chances are that OPA still has your previous values in memory, saving you the need to re-enter them!

Check to see that you’re still getting the correct values.

You should see something like this:

OPA 12 - Time Based Reasoning Worked Example

Let’s set the value and change points for the daily income:

OPA 12 - Time Based Reasoning Worked Example

Click ‘OK’ and inspect the values in the data screen:

OPA 12 - Time Based Reasoning Worked Example

As you can see, the total allowance has now been set to $1926 (down from $4386).

We can have a look at what’s been happening in the Temporal Visualization tab.

Make sure the following attributes are shown by going to the debug data tab and right-clicking and selecting ‘Show in Temporal Visualization‘:

  • the daily income for the citizen
  • the citizen is married
  • the daily allowance for the citizen

Go to the ‘Temporal Visualization’ tab. You should see something like this:

OPA 12 - Time Based Reasoning Worked ExampleOPA 12 - Time Based Reasoning Worked Example

As you can see, there’s quite a bit going on here and the daily allowance for the citizen will vary based on marital status and income.

What you will hopefully be able to see is that, when it comes to dealing with changing circumstances, things can get quite complicated quite quickly. In the example we only dealt with two variables but throw in more variables and working out the right amounts would become very complex! Utilizing the out-of-the-box OPA temporal reasoning functionality allows you to manage the complexity of dealing with changing circumstances over time.

More information on Temporal Reasoning can be found in the OPA documentation:


or in the Function Reference:


Finally for those who were wondering, the daily amount that the user is entitled to on June 26th is…

OPA 12 - Temporal Reasoning Worked Example

OPA 12 - Temporal Reasoning Worked Examplewhich is $14!

Thanks to Evert for his time and excellent article abut Time Based Reasoning. Readers who what to look at more Time Based Reasoning articles can search here.

Until the next time. If you want to write for the OPA Hub Website, reach out via our Contact Page.

Temporal Reasoning in Oracle Policy Automation #4 : Time Travel

Temporal Reasoning in Oracle Policy Automation #4 : Time Travel

In this, the fourth part of our little series about Temporal Reasoning, we are going to look at the business of entering data. Specifically how users can enter the information they need during an interview. Thinking back to the scenario we have been discussing in the previous posts (part one, two and three) we need to enter information about our bank balance.

In a non-temporal world, entering the data would be as simple as entering a value in an input box. But we cannot have that, since there is no built-in capability to enter different values on different dates. Unlike some CRM systems like my old friend Oracle Siebel, there is no user interface element designed to facilitate the entry of temporal data.

So what options do we have. We can ask our users to enter data in row format, with each row representing a specific amount on a specific date. Put simply we can create an Entity and each instance can be converted into a temporal value. Let’s see how that works. Consider the following new Project with a simple data model:

Temporal Reasoning in Oracle Policy Automation 3

As you can do doubt see, a single entity has been added and a few attributes. In addition I have changed the default text provided for the Containment Relationship to make it more natural. For our purposes we are interested in the date and the currency attributes which will form the basis of our conversion. To make this easier, we are going to use an Excel table to infer instances of the bank balance entry using the following table:

Temporal Reasoning in Oracle Policy Automation 4

With this data we can now use one or other of the Temporal Reasoning functions that allow us to build temporal values from entity instances. As a first example, enter the following in a Word document in the project.

Temporal Reasoning in Oracle Policy Automation 5

The expression targets a new attribute, the temporal bank balance, which will be populated with the output of the TemporalFromStartDate function. The function takes the relationship as the initial argument, followed by the date attribute and our currency attribute. The result in the Debugger is this (note I have superimposed the Temporal Visualization from the Debugger on the Interview output) :

Temporal Reasoning in Oracle Policy Automation 6

Awesome. Our instances have become temporal values for our temporal attribute. But beware what this function is giving you. The implication of From Start Date is that any date prior to the first date in your Excel will show a temporal value of uncertain. Change the function to the following:

Temporal Reasoning Oracle Policy Automation 7

In this case, you are indicating that From the End Date of your instances, the temporal attribute will be uncertain.

Temporal Reasoning Oracle Policy Automation 8

If you have instances where there is both an end and a start date for each instance (which is not the case in our bank balance Excel table), you could also use this function to calculate when something was (for example) valid or invalid:

Temporal Reasoning Oracle Policy Automation 9

This of course assumes you have an entity, relationship and attributes that match the example above. It produces output like this:

Temporal Reasoning Oracle Policy Automation 10

In case you were wondering, you can reverse this process (go from temporal to instances) using a different method. In the final part of this series we will look at displaying the temporal data in cool ways.

Temporal Reasoning in Oracle Policy Automation #3 : Time Travel

Temporal Reasoning in Oracle Policy Automation #3 : Time Travel

Following on from the previous parts of this series (which looked at the basics of Temporal Reasoning and Temporal Functions), this third post continues our investigation of temporal calculations in general, this time with a focus on another series of functions and concepts, that are closely involved in using temporal data to calculate numeric or currency amounts.

In the previous chapter of this series, we saw how the functions such as WhenLast() give us the capability to investigate the temporal data at our disposal and find out what was happening on a given date, according to the information you have.

How much would I have saved if?

Taking the example from the previous post and turning it upside-down, we can use Oracle Policy Automation to find out how much money would could save if we had been good and put money in our bank account. There are two principles here :

  1. We need to know how much money we are willing to save
  2. We need to know how regularly we are willing to put it in the bank account.

In real life, you might say to me:

“Richard, if I saved $1 a day, every day, since the beginning of the year : – how much money would I have now?”

In Oracle Policy Automation we can ask the same sort of question.  And of course, get the answer. The key points here are the daily sum, and the date range. In a sense, you are creating your own change points daily in order to calculate the result.

Again, it probably will not surprise you to know that there are a whole raft of Temporal Reasoning functions that work in similar ways to this one.  Suppose you admit to me, that you cannot save money on the weekend, because you like to go out and spend it instead.

“Richard, if I saved $1 a day every week day since the beginning of the year:- how much money would I have now?”

Your familiarity with Oracle Policy Automation probably helps you guess that the function IntervalDailySumIf exists, so you decide to use it, as in the example below.

At first glance, this looks alright. But it really isn’t. The problem is a common one when imagining Temporal Reasoning. The Boolean attribute “you are not spending the money instead” is not going to be very useful, since it is not a temporal value. You get to set it once in the Debugger – not for every weekend:

So mixing a Boolean and our temporal calculation produces a not very useful result. But thankfully Oracle Policy Automation can help. It includes a function to let us know if a day is a weekday or not, based on a range of dates. It returns a set of values that illustrate the changes. It is another example of a temporal reasoning function.

In the above case, the day is a weekday returns a set of change points showing you the way:


In the next episode of this series, we will look at the display of Temporal data to the end user, in a way that is easily readable.

Have fun

Temporal Reasoning in Oracle Policy Automation #2 : Time Travel

Temporal Reasoning in Oracle Policy Automation #2 : Time Travel

Following on from the previous post, this short series is looking at temporal reasoning. In the initial post we investigated the basic principle of entering temporal data in the debugger and using a function such as ValueAt() to get the value of a temporal attribute on a given date.

Now that we have laid the groundwork, we can extend our range a little. The first scenario to discover requires us to have the data in the debugger just like last time, with data for the first few days in July. If you are not sure of the scenario then jump right back to chapter one.

When did you last have lots of money in your account?

I’m sure I’m not the only one who sometimes looks at my bank account and feels a little depressed! The bank balance seems to go down and down, then spikes up on pay day and down and down again. I often ask myself, when looking at something nice in a shop or showroom  – a car for example – when did I last have that kind of money?

Thankfully, Oracle Policy Automation is here to help answer that question and many others in relation to temporal data. The following function will hopefully illustrate this example:

OPA 12 - Temporal Reasoning Part Two 2

You can probably guess the idea. Working backwards from the current date, when did I last have a value greater than 1500 in the temporal bank balance. Now, if you have been using the same example data as me, this function will currently return a value of uncertain. That’s because none of the data in the debugger at the moment is greater than 1500. But if you add a new Change Point to the temporal bank balance, for example :

OPA 12 - Temporal Reasoning Part Two 3

Then your debugger should provide you with a more definite answer. In my case, you can see that June 14 I had a change to my bank balance and it was 1550. The next available change point is July 1, when the value was 1000. So when did I last have more than 1500 in my temporal bank account? Following the change point data, the last date I had that amount of money was June 30. You might suspect that I spent my money faster than that 🙂 but we can only work with the facts, and the change points are those facts.

It won’t come to you as a surprise that there are many functions in the Function Reference for finding out values, and one of them is described below. It belongs to a series of functions prefixed with Interval.

OPA 12 - Temporal Reasoning Part Two 4

This one, as the goal suggests, helps me find my lowest bank balance in the period between the start of the year and today, based on the information in the change points. It will obviously depend on your data, but you will probably have something like this.

OPA 12 - Temporal Reasoning Part Two 5

In the next post we will continue investigating members of this family of temporal reasoning functions.

Temporal Reasoning in Oracle Policy Automation #1 : Time Travel

Temporal Reasoning in Oracle Policy Automation #1 : Time Travel

A while ago I was asking a friend what was the most frustrating and complicated thing when they started working with Oracle Policy Automation. Temporal reasoning came up pretty quickly, and after speaking with other friends and colleagues it definitely ranks highly on the list of most people’s bugbears. There have been lots of excellent articles and posts about this subject on other sites, and in the final part of the series I will share a set of useful links. But we are going to examine the topic over the course of the next few posts on the OPA Hub Website.

But now, into the subject. Let’s first of all consider some of the basics. What is all this about. Consider the following situation: I ask you for your date of birth, so that I can find out how old you are.

If I ask you the question this time next year, then the answer will be of course, different. But nothing has changed in my input data. You still have the same date of birth. But the nature of the response is that it changes over time. If that didn’t make sense, then my favourite is definitely the most obvious one for many people. How much money do you have in your bank account? And did you have the same amount in there last week?

This bank account example usually does it for most people! And what is more, the bank account example allows us to consider the next part of the temporal puzzle. Open a new Project in Oracle Policy Automation and create a new attribute called the temporal bank balance, of type Currency. Start the Debugger. Enter a value of 1200 for the bank balance.

Temporal Reasoning in Oracle Policy Automation Introduction

But what does that value actually mean? When did you have that money in your account?

Let’s add some more data to our Debugger session. Open the Change points >> dialog and add three lines. This is where the magic happens. This data will help us begin to see the concept of temporal reasoning.

Temporal Reasoning in Oracle Policy Automation Change Points Debugger

Add three change points, for the first, second and third of July (1000, 1100, 1500) . Looking at the data, we can use some Oracle Policy Automation Functions to understand how this data is actually represented.

In a Word document, enter the following rules (note that the dates are based on the ones I suggested):

Temporal Reasoning in Oracle Policy Automation Rules 1

Return to the Debugger and let’s look at the values.

Temporal Reasoning in Oracle Policy Automation Debug Result

Observe the values for the  three days in July are perhaps exactly what you are expecting. The ValueAt function has provided you the value on the date you specified. The surprises perhaps are from the other two. The bank balance today (assuming today is a date after the third of July and that you used the same data as my example ) is listed as 1500. In this case, Oracle Policy Automation has found that the last change point was July 3rd, and gives you that value. In summary – according to the data you entered, there was no change after the 3rd. Finally, the amount on June 30th, outside the data points you gave, is the amount you entered in the debugger right at the beginning.

If you right-click the temporal bank balance, and select Temporal Visualisation, then click the Temporal Visualisation tab on the left, the data is displayed visually:

Temporal Reasoning in Oracle Policy Automation Final

So in this first post, we have learned how to enter temporal data, and we have used a new temporal reasoning function to get the value on a specific date. In the second part of the post series, we will look at some more typical cases using temporal data and some more functions. More details can be found online of course.

Thanks for reading and see you soon!


Logo by Southpaw Projects LLC