Troubleshooting – Tips for Troubleshooting

Tips for Troubleshooting

Here are a few tips for troubleshooting any issues you may experience when building a Rainbird Knowledge map.


As obvious as it may sound, the best way of solving any problems you may face in Rainbird is to prevent them from happening in the first place. This takes the form of building with a clear goal in mind, testing your rules after each change and versioning your map often. Adhering to these principles will make building in Rainbird easier in the long run but if you do find yourself with a map that is not behaving the way it should, here are a few tips to help you out.


Understanding the difference in messages when running a query and not getting a result

There are two messages that can be displayed in Rainbird if you do not get an answer:


“Sorry, I’ve been unable to find an answer to your question!”


The sorry message is displayed when the query has been run and cannot determine any answers based on the conditions that were provided. It is unable to match, infer or ask the user for an answer:


“Unfortunately Rainbird has been unable to process the goal against the current Knowledge Map.”


The ‘unfortunately’ message appears when Rainbird has been unable to finish running the rule to generate an answer. This can happen for several reasons, for example; there is a mathematical expression in a rule that is dividing a number by zero, Rainbird has hit the time limit or query depth limit for a rule. Another reason may be that the rule does not contain a ‘%O’, meaning that any objects that may have been generated cannot be assigned to a value.


Understanding these differences can help to determine what the best course of action is to solve any problems you may have.

Rules in Rainbird are made up of conditions and condition expressions. If a rule is not generating any results it may be that one of the conditions (which may be a rule itself) is not generating any objects. By running each of the conditions separately from the main query, you may be able to determine which condition is not generating any results as it should. 

You can change the behaviour of each of the conditions in the rule to be optional. This will mean that if an answer is generated with a lower certainty because one of the conditions has not been met, you are able to view the evidence tree to determine which condition has not been satisfied. Note however that if none of the conditions are met then no answer will be given and so you will not be able to access the evidence tree.

Often when comparing values in an expression, it is easy to have values that are outside of a range. Be sure to include all possible values that you are comparing an object to in an expression (e.g. see Building with Number Concepts). If for example you are comparing a number value to see if it is greater than 10, you need to consider how the map will handle values smaller than 10 or 10 itself.

When a rule relies on external data it is useful to run a query that is used in the datasource to ensure that data is being received by Rainbird correctly and in the format you expect.

It is often required to build rules that will use number values in calculations. Ensure that your rule can handle numbers such as zero. In some circumstances you may need to divide a figure by a number concept. If that number concept is equal to zero the rule will break. You may need to add a condition that ensures the figure is not equal to zero or another rule that handles if the concept is equal to zero.

These points should be used as a starting point for determining where any problems with your map logic may occur. For further information on building in Rainbird please refer to the topics pages found in Community.

Article Feedback form
Did you find this article useful?

Version 1.02 – Last Update: 25/03/2021