Op 23-08-12 21:52, Ricardo schreef: I haven't done it yet at this time (no examples, no docs), but it should be relatively easy to do in the new selector architecture (5.5.0.Beta1+), by implementing a MoveIteratorFactory, a stronger alternative to a simple MoveListFactory: public class ... extends MoveIteratorFactory { public Iterator<Move> createOriginalMoveIterator(ScoreDirector scoreDirector) { ((DroolsScoreDirector) scoreDirector).getWorkingMemory().getQueryResults(...) ... } ... // implement other 2 methods correct too } There's a big pitfall however: That WorkingMemory is used for to do and undo every step that is evaluated (to enable the huge speed bonus of incremental score calculation). So when you add a (forward chained) rule for move generation in that WM's RuleBase, it can (and will) slow down every score calculation... However, if you add (backward chained) queries instead, that should have no performance impact. I haven't experimented with this yet and I welcome any feedback if you're doing experiments with this. Long term solution: When I implement multi-threaded solvers (depending on how much time I get for Planner this will be sooner or later - it is a massive change), there will be a WM that is used for move selection only. So, we 'll be able to add (forward chained) rules on that, without slowing down the score calculation. After the feature "multi-threaded solvers", I 'll add official support for "move generation by DRL".