Page Comparison

Why does the typology configuration cfg look different from the rule configuration cfg?

A rule processor (defined by its id) is closely paired with its configuration (defined by the cfg): the configuration works for that rule processor and no other, and the rule processor won’t won't work with another rule processor’s processor's configuration.

A typology processor is a generic “engine” processor. It is not paired with a specific typology the way a rule processor is - it is intended to work for multiple, if not all, typologies. The typology configuration needs another way to reference the specific typology that will be scored by the typology processor. For that reason, the cfg attribute is subdivided in the same way as the id into name and a version parts. And remember we can have multiple parallel typology processors if we need them, so the id describes the specific typology processor and its version (for routing purposes), and the cfg describes the specific typology and the version of its configuration.

What does “every possible outcome” mean?

A rule processor must always produce a result, and only ever a single result from a number of possible results. The rule result will always fall into one of the following categories: error, exit or band/case. Results across all the classes categories are mutually exclusive and there can be only one result regardless of the category. Results are uniquely identified via the subRuleRef attribute:

• ".err" is reserved for the error condition, of which there will only ever be one;

• exit conditions are prefaced with an ".x" and there may be many;

• bands/cases are typically sequentially numbered (and ".00" is reserved in cases) and will always have at least two.

The rule processor must produce one of these results (identified by the result’s subRuleRef) and when it does, the typology processor must be configured via a typology configuration to “catch” that specific subRuleRef. If the rule processor produces a result that the typology processor can't process, the typology processor won't be able to complete the evaluation of that specific typology or the channel that contains the typology or the transaction that contains the channel: the evaluation will "hang". For this reason alone the exit conditions must be represented in the typology configuration and interpreted in the typology processor, even if the interpretation is non-deterministic (false, with a zero weighting), but some (few!) exit conditions actually also have deterministic results that have a weighting.