Instead of writing it as a truth table, write it as a state machine. I would translate that as follows:

1. Do I have name? Y -> 2, N -> 10
2. Do I have email? Y -> 3, N -> 13
3. Do I have add? Y -> 4, N -> 7
4. Does email exist? Y -> 5, N -> 6
5. Warn that email exists
6. Add email to DB
7. Does email exist? Y -> 8, N -> 9
8. Remove email
9. Warn that email doesn't exist
10. Do I have email? Y -> 11, N -> 12
11. Warn that name is empty
12. Warn that name and email are empty
13. Warn that email is empty

Now, you want to know how to programatically do this from a data structure? Well, there are state machine modules on CPAN. I'm not going to suggest one cause I've never used them.

If you don't want to go that route, I would suggest using sub generators and a hash table of paths.

As an aside - business logic is generally much more complicated than a truth table can represent. That's why state machines (and their little cousins flowcharts) are much better. They're something both business analysts and developers can understand and analyze for correctness and completeness.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.