
Assumptions that may be encoded:
0. Limits on matching expressiveness. Specifically, how many parameters can we match and what to do if we get ambiguity in matching. For example, a Token with 3 parameters of the same type with a token spec in the heuristics with 2 parameters. It is ambiguous how to interpret these and should be flagged as an error on input unless we handle the case.

Questions:
0. What are the semantics of near and how do we support them - if at all?
1. Are pruning options available for intervals? If so, how expresssed and how handled in the code?
2. What happens whn there is no intersection between available values and the restricted set defined in the Heuristics file for pruning? SHould cause an inconsistency. Does the code do that? We should test it.

General pattern for testing of a specification (for no branch, variable decisions, token decisions and object decisions):
0. Make sure the macth is precise for the given element
1. Make sure the match is correct with respect to alternatives that might be close or far from being matched. Specifically, there should be alternatives and it should not get a hit for these alternatives. Proves the matching is correctly selective.
2. Make sure the selection of a decision obeys the priority calculations.
3. Make sure the choice ordering is respected by both direct inspection and by trying out the paths through the decisions manager.
4. Make sure the choice pruning is respected by both direct inspection (query for choices returned) and by trying out through the decisions (using assign/retract calls directly and testing choices as you go).
Variable Decisions

Variations in matching to consider:
0. Default case.
1. Based on predicate only
2. Based on predicate and parameter binding
3. Based on predicate and token relation: Any, Before, After (are there others). Include cases of additional qualification by parameter.
4. Behavior when inheritance is considered. If a rule is written on Foo.pred1 and we get a token of type Baz.pred1 (where Baz extends Foo) then we should be getting a match. However, we should consider the case where there is a MORE SPECIFIC rule that can also fire. We are encoraching on new requirements here possibly - do not want to get into that on HSTS code if we can avoid.

Error handling (many can be evaluated when interpreting input file agains the schema):
0. Parameter values not in type: Going(Hamburger) where Hamburger is not a location
1. Incorrect number of arguments: e.g. a predicate spec including a parameter argument when non exists.
2. Choices include more elements that are defined for the type and choices include elements that are not defined for the type at all.
3. Choices include elements repeated. Should be flagged as an error on input. Should not lead to trying out those values.
4. The case where the parameter index for either the no-branch or the variable heuristic is out of range.
