Troubleshooting Tips

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

Helpful hint to reduce issues

1. Testing your rule after each change can help to identify problems early

2. Versioning your map regularly, after your testing is successful, provides a good checkpoint that you can return to in the event of introducing issues (remember to add a note in the description that describes your changes).

Why am I not getting a result?

There are two reasons for not getting a result:

No result can be found

The reasoning engine has processed all the logic and data correctly, but has been unable to find or infer a fact to answer the query.

If using a Rainbird agent, such as Quick Query, you will receive the message "Sorry, I’ve been unable to find an answer to your question!”. If you are using the API directly, you will receive an empty result array like the example below.

{"result":[],"sid":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}

An error has occurred

In some scenarios the reasoning engine can experience a technical issue and responds with an error.

This will be slightly different depending on how you are interacting with the engine:

Try Query or published agents will display “Unfortunately Rainbird has been unable to process the goal against the current Knowledge Map.”

Quick Query and the API will respond with an HTTP error code.

Quick Query

These errors 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.

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

Break a rule down to the core relationships and test them individually

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.

Change all conditions in a rule to be optional, run a query and check the evidence tree

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.

When Using Comparative Expressions

Often when comparing values in an expression, it is easy to have values that are outside of a range. 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. Additional rules can be created to handle exceptions outside of the required ranges.

When Using External Data Sources

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.

When Using Mathematical Functions

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.