Content revision 4e771eaf0390cc87b6c7c6fd8469f3508f6ceeec7119472e6c1ccf17e2e1e5d2

## Making the configuration rules reusable

Insurance Product Configuration Engine
Source ID playbook:the-idea
Original https://www.henryw.me/#/playbook#the-idea

The required interface depended on combinations of product choices and conditions. I represented each relevant combination as a business scenario, with rules specifying the components it needed. This gave the engine a sequence it could evaluate, first establishing which scenarios applied, then selecting their screens and fields. Many products reuse the same definitions, conditions and components. Maintaining separate rules for each product would mean revising the same logic in several places whenever a shared requirement changed. I organised these into linked libraries, where each shared definition could be maintained once. Decision tables record which product values satisfy a scenario and which UI components it requires. Product specification The questions, allowed values and conditional inputs used to describe a product's requirements.

UI components The reusable screens, fields, and interface components available in the app. Decision tables The conditions that map specification values to the UI-component requirements for each business scenario. The engine follows product specification → business scenarios → UI-component requirements . The team can follow the same path backwards to see which scenario selected a screen or field and which product values made that scenario apply. The mapping gives them a way to inspect the generated configuration and the rules behind it. A new product can reuse the existing definitions with a different set of values. When a shared condition changes, the team can revise its decision table and regenerate the affected configurations. Keeping these rules outside the VBA code also makes that part of the engine accessible to the people maintaining the requirements.