DMN14 — First (and priority) hit policy are unpredictable with partial input

A decision table with a hit policy of FIRST uses rule order to decide its output, but only among those rules which have an output. This works fine when the input is complete, but becomes unpredictable when input is partial. Higher priority rules (earlier in the order) may not have an output yet while lower priority rules do, even when higher priority rules may generate an output in the future when more input become available. This makes the FIRST hit policy (the same goes for PRIORITY) not usable in a context where the decision logic will be run on partial, incrementally expanded input (e.g. an interactive expert system).

When reading the description for the FIRST hit policy in the spec, I get the feeling that the OMG is opposed to having rule order play a role in the evaluation of a decision table. I realize there are ways around using rule order by using different hit policies and separating the logic into multiple decision tables, but I do believe that that would not improve the understandability of the logic. Having the rule order play a role in the evaluation of a decision table can definitely make them more self-contained (decision tables are smaller and/or logic is less spread out), and therefore easier to write and understand in some cases. But an implementation that uses rule order needs to be predictable, even on partial input.

Therefore I would like to propose an addition to the existing hit policies: ELIMINATE (or at least i think that term describes it well).

The ELIMINATE hit policy evaluates a decision table's rules in order:

• If a rule is validated (it matches), it produces an output and evaluation is stopped
• If a rule is invalidated (it will never match, even as more input becomes available), evaluation continues with the next rule (i.e. it is eliminated)
• If a rule cannot be invalidated (because input is partial), evaluation is stopped and the table produces no output
• A decision table with a hit policy of ELIMINATE can only ever produce a single output

I hope you will consider adding this to the spec in some form or another, since it would make working with dmn in a context of incrementally expanding input a lot easier.

Hit policies work as designed with partial data

The decision services designed using DMN are meant to be stateless. Therefore when the partial data is submitted the first hit table behaves correctly, given the partial data. When the more complete data is submitted, it behaves differently but still correctly. The fact that the table behaves differently given different submitted data sets seems completely reasonable and we don't see the need for another hit policy.