Category: Temporal Reasoning

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 #5 : Temporal Attributes in Interviews

Temporal Reasoning #5 : Temporal Attributes in Interviews

In the final part of this mini-series, the OPA Hub Website continues to look at Temporal Reasoning and in this particular chapter discusses the display of Temporal Attributes data in the Interview experience.

If you missed any of the previous parts of the series, they are here:

So now that the we have a bit of understanding of how these data elements work, what about displaying them in a good way to the end user in the Interview. Well, part of the answer is hidden in part four of this series. We cannot actually display temporal attributes for data entry in an Interview (so conversion comes in very handy).

Let’s be more specific. Using the project from the previous chapter, in 18C, when an attempt is made to display the temporal information on a Screen, various things happen that underline the some important concepts:

Temporal Attributes in Interviews Animation OPA 12Please excuse the retro-style animated GIF above. But the demonstration above illustrates the fact that Temporal attributes and their change-points are complex data types that cannot be handled in a “normal” way. The one exception to the above is if you have a Temporal attribute whose values are the Goal of the interview, then an Explanation will display the data in a coherent way:

OPA 12 - Viewing Temporal Attributes in Interviews

If your project is using RuleScript and your data is pre-seeded, then potentially you could access it by deriving a string value which is a concatenation of the different values and displaying that attribute using a label control.

// RuleScript(myString) <- (temporalBankBalance)
function FindHighest(global) {
	console.log("Starting RuleScript");
	var v = global.temporalBankBalance;

		console.log("Base Value of v " + v._baseValue);
		var idx,
		maxVal = null;
		var myString = "";
		console.log("Length of Temporal Array " + v._changeValues.length);

	if (v._changeValues.length <= 0) {
		global.myString = "No Temporal Values";
	} else {
		console.log("Getting Temporal Values");
		for (idx = 0; idx < v._changeValues.length; idx++) { var changeValue = v._changeValues.valueAt(idx); if (changeValue != null && (maxVal == null || changeValue > maxVal))
				maxVal = changeValue;
		global.myString = global.myString + changeValue + ";";


But given that RuleScript is experimental, that it’s use cases are highly controlled this would be a very bad idea. Plus it would only work if the temporal values were pre-seeded into the Interview, which renders it all very complex.

So what is plan B? It might be to use something like the Entity Container Extension that we have previously looked at (which would imply using the conversion technique mentioned in part four).

If you are looking for a quick and dirty way to get at the Temporal values, even though the JavaScript Extensions do not actually support them today, the values are still accessible. They can be accessed using something like this. I have not published this as a download since the snippet below is very primitive.


 * Richard Napier The OPA Hub Website August 2018
 * Educational Example of Custom Container with a Timeline inside
 * I will remember this is for demonstration and educational purposes only
	customLabel: function (control, interview) {
		if (control.getProperty("name") === "xTimeline") {

			return {
				mount: function (el) {
					var script_tag_addition = document.createElement('script');
					script_tag_addition.setAttribute('src', '${resources-root}/js/timeline.min.js');
					script_tag_addition.setAttribute('type', 'text/javascript');
					var stylesheet_tag_addition = document.createElement('link');
					stylesheet_tag_addition.setAttribute('href', '${resources-root}/css/timeline.min.css');
					stylesheet_tag_addition.setAttribute('rel', 'stylesheet');
					stylesheet_tag_addition.setAttribute('type', 'text/css');

					var myDiv = document.createElement("div");
					myDiv.setAttribute("class", "timeline");
										myDiv.setAttribute("data-mode", "horizontal");
					var myDivWrap = document.createElement("div");
					myDivWrap.setAttribute("class", "timeline__wrap");

					var myDivChild = document.createElement("div");
					myDivChild.setAttribute("class", "timeline__items");
					// Don't do this, it relies upon the temporal attribute
					// being the only one in Global exposed on the page as a %label%
					var myTemporal = []
					myTemporal =[0].instances[0].attributes[0].value.changePoints
						for (var i in myTemporal) {
							var iterateDIV = document.createElement("div");
							iterateDIV.setAttribute("class", "timeline__item");
							iterateDIV.setAttribute("id", i);
							var iterateDIVContent = document.createElement("div");
							iterateDIVContent.setAttribute("class", "timeline__content");
							$('.timeline__item[id="' + i + '"]').append( "GBP "  + myTemporal[i].value + " on " + myTemporal[i].date)
				update: function (el) {},
				unmount: function (el) {
					var myDiv = $(".timeline");



The above snippet relies upon a jQuery plugin to display the data. This gives something like this, a visual timeline on the left of this page:

Temporal Attributes in Interviews JavaScript Extension

Of course there are hundreds of Timeline plugins, each more sophisticated than the other, on the Internet.

We hope that this series has brought to light some of the key features of temporal reasoning, and thanks to Orlando who suggested this series in the first place. Have a good day and see you soon!


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!


OPA – Entities Adventures #10 Temporal Reasoning

OPA – Entities Adventures #10 Temporal Reasoning

Temporal Workshop

And so we come to the tenth, and final (for the time being) post in this hopefully useful and entertaining series for learners of Oracle Policy Automation. In this episode we will discuss the concept of Temporal Reasoning and apply it to the Workshop example we have been using since the beginning of the series.

What is this temporal stuff?

To give you a simple example, our Workshop has a variety of elements to it that change over time :-

  • Cars in the Workshop
  • Mechanics
  • Car Storage Cost

And of course, these pieces of data might need to be analysed and calculated over time. This is a common thing in business of course. Generally software tries to handle this by having “data points” – snapshots of data – but usually they are not very good at handling “periods of time” – where you don’t have data for each day or other time period  but you expect to have to calculate as if you did. Say for example you have a person who receives money from the state. They receive it on a weekly basis. We need to calculate from their date of first receipt, until today. So we need to be able to “span the time period” and calculate the figures. And that is pretty cool.

How does it work in Policy Automation? – an example

In Policy Automation, we need first to understand how the data is entered. Let’s focus on the storage costs – cars that are left in the Workshop are charged at a daily rate to the customer, for storage, once they are left more than 3 days. In addition, the storage charge is a percentage of the value of the vehicle. Finally, storage of more than 10 days gets a higher rate.

So let us work up an example. Assume two cars being worked on in the Workshop. One of the them arrives in the Workshop on September 11, the other on September 1. Today is September 17. So how much storage should we charge? To make matters more realistic, we can say that the first ten days are charged at 9% of the car’s residual value, the next ten days at 11%, and beyond that a punitive 15% since the car has really been here too long.

OPA - Daily Cost of Storage Temporal Example

]In the above example we introduce some new Attributes (the cost of the car’s storage and the date of the car’s arrival) respectively currency and date types, and the function TemporalBefore().

From the Function Reference we see that TemporalBefore (date) is explained thus:

Returns a Boolean attribute that varies over time and is true before a date and false on and afterwards.

So essentially our cost will be calculated using the car’s residual value * 0.09 for as long as TemporalBefore(AddDays(the date of the car’s arrival, 10)) is TRUE.

There are other versions of this function to handle things like “on or before” or similar calculations for “after” or “on or after” dates. Visualising the data in the debugger makes it clearer how this is working. Don’t forget to right-click the cost of the car’s storage in the Debugger window and choose Show in Temporal Visualisation.

[vc_single_image image=”” img_size=”full” alignment=”center”]Now we can see the cost of storage incurred based on the car residual value and the arrival date of the car, according to the different values over time. But perhaps you didn’t see what you were expecting – the actual total cost as of today. So let us introduce this into the mix:-

In the following screenshot, note we have added new “total cost” and “current daily cost” Attributes.

As a demonstration we are using the ValueAt() function to get the current value charged today (according to our table of values).

We are also using the IntervalDailySum(start, end, value) to calculate the total amount payable to date.

OPA - Car Storage Cost Rates and Total Temporal Function Example


Now that we have the total cost of the storage, we can go ahead and work out if the car storage has exceeded the residual value of the car.

And so we come to the end of this 10 part series, designed to give you some more fun examples of working with Entities. For those of you who are reading this after taking the OPA Essentials Class with me, I hope you enjoyed them.

What Next?

For the next series of posts we will be looking at teasing questions that might help you prepare for the certification. After that, get ready for more function examples and fun with Oracle Policy Automation.


Policy Automation – Jargon Busting – Temporal Reasoning

Policy Automation – Jargon Busting – Temporal Reasoning

Temporal Reasoning

Temporal Reasoning in Policy Modelling is the capacity to deal with Change Points and data that varies over time. For those of you who are familiar with the Siebel CRM, a similar concept was introduced to Siebel Public Sector 8.2 called “Effective Dating” for certain components that needed to be configured in this way (for example, the case of a person who changes their name, effective 1/1/2014). They had a name before and they had a name after. So the attribute or field name is the same, the value changes however over time.

To illustrate the point and observe the capabilities of Policy Modelling briefly, create a new Project and call it “TimeTravel”.

In the project, add a New Word Document. As is often the case in these brief examples, for the sake of speed we are skipping over items that we do not need to mention here, specifically some best practices have been sacrificed in the name of speed.


Type the text above and make sure you select “the cash” and click the “Add Attribute” button and create an attribute of type Currency. Do the same for the “the last good day” attribute but make sure you have created it as type Date. The Attribute Editor button will let you review your work.


Now Compile the Word Document. So far it would appear that there is nothing very special about our project, save the use of a new Function called WhenLast(date, condition). Now let us complete the exercise. In the Policy Modeller, Build and Debug (without Screens) or just press F5. The usual screen will appear. We will enter some information into the debugger. Double-click “the cash” to enter the value. And proceed in the following fashion:


Click the Change Points button, and proceed to enter a series of Values for different dates. Make sure one of them is over 100, and make the most recent one less than 100. You are providing the raw data that the “WhenLast()” function requires. When did you last have 100 $ (or whatever your regional currency setting is) in your bank account? The last good day is designed to be inferred from the data you are entering.


So in the case above, there are various dates and figures. Now we can see in the debugger :

Temporal Result 1

If we right click “the cash” we can select the “Show in Temporal Visualisation” option, and click the “Temporal Visualisation” tab in the Debugger. Notice the display, and how the initial value entered (77 in the case above) is used to seed the attribute with its initial value, and the other numbers are entered according to their change points. If you remove the 77 from “the cash” Value field, you can choose “uncertain” or “unknown” instead.

Temporal Result 2

Clearly such a simple example cannot do justice to the different Temporal Reasoning functions but where data is presented for analysis with change points, now you know to consult the Temporal Reasoning section of the documentation.

Logo by Southpaw Projects LLC