loading x elements...

In this example you will learn:

  • How to improve on the Rules and Programs from the previous part of the tutorial.

To do so, we take the point of view of a different developer, who has encountered the Rules and Programs from the previous page, and wants to improve on them. Everything option this page is uploaded by tutorial_developer_improved.

For the purpose of this tutorial, we assume that we have no way to change what was uploaded by tutorial_developer_basic. In practice you would be able to write to the authors of the original code and collaborate, but let's assume that that didn't work. This tutorial demonstrates how you can improve on what is already there, even without the cooperation of the author who's content you want to improve.

An example Scenario Plan demonstrating the Rules and Programs on this page can be found here. As before, after starting the Scenario, you need to type 'predict' or 'forecast' or some other variant of this keyword in the chatbox in order to trigger these Rules.

This improved Scenario can now also handle Excel files. The following Excel file can be used as an example to test the prediction: Download

The Task

We are going to make many small improvements in different areas of the task.

Some of these improvements will be cooperative with existing Rules, others will be in competition with existing Rules.

The Symbols

The following Symbols will be used by the Rules and Programs below:

Improvement 1: A hotfix for the text analysis

Did you notice the flaw in the Rule Enrich-user-input-text-keyword-extraction?

The Rule only reacts to the last instance of a ?user_input_command_file Tag. This will be fine most of the time, but if you pay close attention to the way Elody prioritizes its executions, you will note that the user can actually make several inputs before Elody checks which Rule to apply next. If this happens, the Rule will only react to the last input of the user, and ignore the rest.

Unfortunately, Enrich-user-input-text-keyword-extraction was not written to be easy to repair by other users. Therefore, our only hope is to write another Rule that completely replaces Enrich-user-input-text-keyword-extraction.

The Rule we define here will deactivate Enrich-user-input-text-keyword-extraction, as well as any Options generated by it. It then replaces the functionality of Enrich-user-input-text-keyword-extraction with a better version that works on every user input, not just the last one. Note that we keep the Program which was called by Enrich-user-input-text-keyword-extraction, we just change when it is called.

Now you may wonder: If I can just write a Rule that shuts down somebody else's Rule, isn't that dangerous? What prevents other people from shutting down my own rules?

The answer is fairly simple: Elody decides which Rules get executed at all based on the Rules' ratings and the user's security parameters. If someone writes a Rule that hurts more than it helps, simply downvoting it will be enough to ensure it doesn't do any harm. If Elody allows a Rule to execute, that Rule is free to do whatever it wants without restriction. But if it abuses this privilege, it will simply be downvoted until it becomes irrelevant. Rules with higher rating execute first, so if two Rules are in direct competition with each other, the one with higher rating will be run first and can deactivate the other.


The AI Elody is currently under development.

Currently, the decision whether or not to allow a Rule is rather straightforward and depends only on the Rule's rating.

Later on, Elody will be able to make automated statistical inferences about the way different Rules have interacted in the past and the reputations of and relationships between the developers who approve or disapprove of a Rule.

Improvement 2.1: An alternate way to extract a timeseries from a file

The Rule Enrich-extract-required-timeseries-from-file from the last page reacts to .csv files and extracts a timeseries from them in the correct format. We now add another Rule and Program that reacts to .xlsx (Excel) files instead.

This Rule/Program pair uses the same Symbols as Enrich-extract-required-timeseries-from-file and is fully cooperative with it.

The Program used here is much better than the Program used by Enrich-extract-required-timeseries-from-file. It is actually able to extract tables that appear anywhere in an excel file. It also creates not one but several Options, so that the user can choose which interpretation is correct in case there is ambiguity. Each of them has a confidence between 0.4 and 0.9, depending on some traits of the extracted timeseries. See the Best Practices for an explanation of this range of confidence values.

Unfortunately however, the output files generated by this Program have the wrong format to be used by Do-make-simple-timeseries-prediction, the Rule responsible for performing the prediction. It's output format is that of a Python Pandas file instead of a CSV file. A problem like this can occur very often in practice, since programs often differ in the types of files they support. In this case of course, the mismatch is intentional so that the next step of the tutorial can explain how to fix it.

Improvement 2.2: Converting filetypes as needed

As explained above, there is a mismatch of datatypes. Rule Do-make-simple-timeseries-prediction expects a CSV file, but the above Program generates a Python Pandas file instead.

We fix this with two additional Rules and one Program: The first Rule recognizes and points out that a different format is needed (by generating a Tag). The second Rule reacts to that Tag and executes a Program to convert data types. Both steps could also be done in a single Rule, but it is cleaner this way because splitting it into separate Rules makes it easier for other developers to interact with these Rules.

Note that this program also puts info_timeseries_x_axis_name and info_timeseries_y_axis_name Tags on the newly generated file. These don't actually get used by any of the Programs introduced so far. However, they might be helpful for other developers who want to expand on this task. At this point, it would make sense to contact the creator of these existing Rules and Programs and notify them of this oversight. If that program's creator does not react to this, you can also create a Hotfix- rule to fix it for them. It is also highly recommended to open a thread in the forum to discuss these kinds of formatting questions, so that everyone can rely on each other.

Improvement 3: A better visualization

Next, we want to implement a better way to visualize the result of the prediction.

Because asking the user to choose a way to visualize things might be seen as annoying, the choice of visualization is done completely in the background. The superior visualization generated by this program is created as an option that is hardcoded as a slightly higher confidence than the one generated by Present-predicted-timeseries. As a result, Elody will always pick it first.

Note that this visualization doesn't actually look any better than the one it replaces, since this is only for demonstration purposes. In fact, the visualization is the same, but implemented as an 'html' message_component instead of a 'plot' message_component. This allows for much greater customization: Using the HTML message_component you can embed entire websites with fully functional Javascript in a Message.

One additional feature this visualization has is that it allows you to rate the Programs responsible for the prediction and the visualization. While requests to rate a Rule are automatically shown in Developer Mode each time a Rule is executed, this feature actually presents a way to rate a Rule or Program outside of Developer Mode. Since most non-technical users will never use Developer Mode, this allows you to collect feedback from end users.


This example is used to rate the Programs, not the Rules. The rating of Programs doesn't currently affect anything, but it's nice to have a summary of how users rate your contributions. This may be changed in the future as Elody is improved.

Improvement 4: Unifying different Options

The Options which timeseries to present to the user look different depending on which Program created them. The Program from the previous page used a simple 'text' message_component, while the one on this page uses an 'html' message_component.

A non-uniform look might confuse the user, so we add another Rule that goes through all the Options and replaces the simple 'text'-based ones with 'html' based ones.

This Rule demonstrates how reserve_ tags can be used and the Program demonstrates how to deactivate and replace Options from inside a Program.

We need to make sure that the Option created by this Rule only runs once all the Options it is supposed to operate on have been created. To this end, it waits until all reserve_file_during_data_extraction Tags have been !nullified (tagged with !nullify).

Using a reserve_ Tag is not strictly necessary here: You could also rely on the relative weights of Options to make sure that other options execute first.

However, it is good practice to use a reserve_ Tag when you are not sure what might be involved in some of the preconditions you are waiting for. After all, it is possible that one of the preconditions involves a complicated process that includes creating an Option with a low enough confidence to be shown to the user. If this was the case, then the summarizing Option would execute before all the things it is supposed to summarize have been created.