For any rule base application, a fact model is needed to drive the rules. The fact model typically overlaps with the applications domain model, but in general it will be decoupled from it (as it makes the rules easier to manage over time).
There are 2 ways to to do this: you can upload jar files containing classes which your application and the rules both use, or you can use models that are declared along with the rules.
When a JAR is uploaded, it will add import statements to the package configuration (you can then review and change them).
Using declared models, you will see an editor like the following:
In here you can define types, and add fields (each field has a type). The type of a field is suggested by a list (but this list is not exhaustive):
These fact models can be used like normal fact objects, however the way you create them is different (as they are not on your applications classpath). To create these objects, they are available from the RuleBase instance.
// Retrieve the generated fact type
FactType cheeseFact = ruleBase.getFactType( "org.drools.generatedbeans.Cheese" );
// Create a new Fact instance
Object cheese = cheeseFact.newInstance();
cheeseFact.set( cheese, "type", "stilton" );
The "cheese" object above can then be inserted into working memory just like a normal POJO based fact.
Note that the namespace of the declared type is the package
namespace where it was declared (in the above case
org.drools.generatedbeans).
Why would you chose declared types over JAR files: generally this reinforces the fact that the model "belongs" to the rulebase, rather then the application, and allows the model to have a lifecycle separate from the application. It also removed the hassle of keeping jar files in sync between rules and the applications that use the rules.