When we talk about the basic unit of a product in a Prophet model, many might instinctively think of policy features, benefits, or input files. But technically, a product is a collection of selected formulas — which, in Prophet, are known as variables. This means the way we manage and structure variables plays a critical role in determining the quality and maintainability of a Prophet model.
In general, Prophet variables can be grouped into two major categories: input variables and core variables. Most Prophet users understand this technical distinction. But a common question arises: “How do we decide whether a variable should be classified as an input or core variable?”
Input vs. Core Variables: A Practical View
While there are no strict rules, a useful rule of thumb is this:
- Input variables: should be those that are product-feature specific—they differ across products.
- Core variables: should represent standard logic or assumptions that apply across all or most products.
Let’s take sum assured as an example. We typically have two sum assured variables in Prophet:
- Initial Sum Assured, e.g., “INIT_SA_PP”, usually read directly from model point files.
- Current Sum Assured, e.g., “CURR_SA_PP”, which may vary over time depending on product type.
For most models, “INIT_SA_PP” follows a consistent definition — so it’s suitable as a core variable. But “CURR_SA_PP” often varies by product. For instance, a Mortgage Reducing Term Assurance (“MRTA”) product may use a reducing pattern based on monthly or yearly rest logic. Hence, it should be defined as an input variable.
Why the Classification Matters
One key difference between these two types is how changes propagate:
- When you update a core variable in the library, all products using it will automatically adopt the latest version.
- But if you update an input variable, each product retains its own version of the formula—unless updated individually.
That’s why you should always take extra care before switching a variable from input to core or vice versa. A backup of your workspace is strongly recommended before making such changes. A wrong move could lead to unintended consequences or loss of existing configurations.
Indicator Expressions: Controlling Scope with Precision
Even core variables sometimes need product-specific logic. For example:
- Premium income logic differs between single premium and regular premium products.
- Fund-related variables (e.g., account balances) only apply to universal life or investment-linked products.
This is where Indicator Expressions come in handy. For each variable, you can define an expression that tells Prophet when and for which product types to include that formula:
- Use “ALWAYS” for formulas that apply to all products.
- Use expressions like “UNIV_LIFE OR INVST_LINK” for more specific inclusion.
Secondary Input Variables: A Subtle but Powerful Tool
Some input variables don’t have an Indicator Expression at all — and that’s NOT a mistake. These are known as secondary input variables. They’re only included in a product if another input variable directly uses them.
This approach is particularly useful for interim or helper variables, such as those used to derive surrender values that are only relevant to a few products. Rather than assigning product-specific indicators, letting them cascade through their dependencies makes the model leaner and easier to manage.
Conclusion
A well-structured Prophet model starts with a disciplined approach to variable management. By properly classifying variables, using indicators smartly, and leveraging techniques like secondary input variables, you can ensure your model remains scalable, maintainable, and ready to support a variety of reporting and business needs — whether for monthly valuation, IFRS17, or product development.
