What they have in common
Four things, and the last two are the hard ones.
Eligibility, claims and tax look like different businesses. As decisions they are the same decision, and the part that makes them expensive is never the arithmetic.
The rule is already written down
A statute, a policy wording, a plan document, a rate table. The authority exists and someone maintains it. It simply is not executable, so it gets translated into code by hand — once, and then never again in step.
The answer has consequences
A payment is made or withheld. Someone is covered or is not. This is not a recommendation a person reviews; it is the decision, and something downstream acts on it immediately.
The date is part of the question
The rule that applies is the one in force on the date of the event, not the one in force today. A system that knows only the current rules answers last year’s question wrongly, and confidently.
Someone asks again, later
An appeal, an examination, an audit, a dispute. Years later, and rarely the person who decided. The answer has to be reproduced rather than remembered or reconstructed.
Application code handles the first two well and the last two not at all. That is the whole argument for compiling the rule into a versioned package instead: the date and the audit become properties of the artifact rather than features somebody has to remember to build.