good luck with that; interpretation make things like this very difficult, if not impossible.

I agree that this would be nice, however. as a non-lawyer and someone who considers themself to be not a "real" developer (even though I write software every day) I have often wondered how alike law and code are, really, when it comes to defining intent via a keyboard.

I would prefer it if any change to the IRS rules must be accompanied by a reference implementation and lots of tests.

Tell me how you will write a unit test for determining the percentage of your utilities that is deductible on Schedule C.

Or a unit test that determines whether the discussion during a meal with a customer was "substantially about business matters".

What percentage of US citizens expense business meals? This is all about automating the simple cases.

Anything more complex is an input to the system, the system can still be tested.

You're conflating determination of factual and legal questions (out of scope) with modeling the decision tree (in scope and useful).

The function you ask about would be "getDeductiblePercentage()," and the unit tests would return various hard coded numbers. Actually determining that value for a real taxpayer is still hard.

Being able to show how information flows through the US tax code would be useful, even if it doesn't solve all the problems that arise from its intricacy.

The interpretation aspect isn't solvable in code, but it's representable. That's what I was getting at with the Boolean comment. A branch point might be "bool answerUnanswerableQuestion()" and the unit tests would mock it as true and then false. Even if the question isn't deterministically answerable in real life, at least the code can show what happens when it is answered.