Build a Central Assumption Library
This guide describes how to use the Data Library as a central assumption library for your model. Instead of scattering assumptions across many variables, store them once in the Data Library and reference them consistently.
This approach makes the model easier to understand, audit and modify, especially in larger workspaces and multi-branch models.
Before you start
You should have:
A working model with at least basic revenue, cost and capex logic.
Some experience with drivers and variables.
A list of key assumptions that recur across the model, for example:
Inflation rates.
Wage growth.
FX rates.
Tax rates.
Unit or volume drivers reused across branches.
If you have not explored the Data Library yet, read:
Data Library overview
Drivers and Variables Overview
What you will build
By the end of this guide you will have:
A structured set of Data Library entries representing core assumptions.
Variables that reference these entries rather than hard coding values.
A clear naming and tagging convention for assumptions.
A process for updating assumptions in one place and propagating them across the model.
Identify shared assumptions
Review your model and list assumptions that appear in multiple places, for example:
General price inflation.
Wage escalation rates for different roles.
FX rates for cross-border revenues or costs.
Tax rates, such as corporate income tax or VAT.
Long-term growth rates for valuation.
These are candidates to move into the central assumption library.
Design a naming and tagging convention
In the Data Library, use names and tags that make assumptions easy to find. Examples:
Names:
Assumption - Inflation - General
Assumption - Wage Growth - Engineering
Assumption - FX - USD to GBP
Assumption - Tax Rate - Corporate
Tags:
ASSUMPTION
GLOBAL or BRANCH SPECIFIC
FX, TAX, LABOUR, PRICING
Agree conventions with your team so everyone uses the library consistently.
Create assumption series in the Data Library
For each identified assumption:
Create a Data Library entry with:
Appropriate type (often Modifier or Driver).
Frequency (monthly, quarterly or annual as needed).
Units (for example percent for rates).
Enter historical and forecast values where relevant:
You may keep some assumptions constant.
Others may change over time, such as inflation.
Document the rationale for each assumption using notes.
Refactor variables to reference the assumption library
Update variables that currently hard code values so they reference Data Library entries instead.
Examples:
Opex escalation:
Replace an in-variable growth percentage with a reference to Assumption - Inflation - General.
Wage growth:
Use Assumption - Wage Growth - Engineering for engineering staff variables.
FX conversions:
Use Assumption - FX - USD to GBP in formulas that translate foreign revenues to model currency.
This may take some initial effort, but it greatly simplifies maintenance later.
Use assumptions across branches
Because Data Library entries are model-wide, you can reuse the same assumptions across branches. Examples:
Apply the same inflation series to multiple branches representing regions that share a currency.
Use different wage growth assumptions for branches that map to different labour markets.
Use tags like GLOBAL or region-specific tags to signal where a given assumption should apply.
Implement a governed update process
To prevent accidental or confusing changes:
Decide who is allowed to edit central assumptions.
When updating an assumption:
Record the change in notes, including date and rationale.
Communicate material changes to users of the model.
If you want to test changes without affecting the main model, create:
A copy of the model for testing, or
Separate Data Library entries for scenario-specific overrides.
This keeps the central library trustworthy.
Check your work
Key assumptions appear in the Data Library, not scattered across variables.
Variable formulas reference these central entries consistently.
It is easy to answer the question "where does this assumption live" for any major driver.
Updating an assumption in one place has the expected effects across the model.
Troubleshooting
Related guides
Last updated