Once your hard-coded eligibility and entitlement rule implementations are in place, you can use a top-down approach to replace these hard-coded implementations with real logic appropriate to your product. As you drill down, you may create new hard-coded lower-level implementations, which (depending on your factoring of rule sets) might be handed-off to multiple developers for further implementation.
For example, the "Lone Parent" Benefit outlined in Example might initially be implemented as "always eligible".
The next step in implementing the eligibility calculation for "Lone Parent" Benefit would be to replace the "always eligible" calculation with (in pseudo-code, and assuming relevant timeline operations):
These new attributes would each initially be hard-coded to be "true forever". The top-down process can then undergo another iteration and the implementations of these new attributes each changed from the hard-coded "true forever" into real implementations, possibly with further new attributes which are initially hard-coded; e.g. the childInEligibleAgeRange could apply date logic to the child's date of birth, but that date of birth could initially be hard-coded instead of coming from a propagated rule class for an entity or evidence type.