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.


1

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.

2

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.

3

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.

4

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.

5

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.

6

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

chevron-rightToo many assumptions in the library become hard to managehashtag

Use tags and naming conventions, and focus the central library on assumptions that are shared across multiple variables or branches.

chevron-rightUsers override assumptions directly in variableshashtag

Encourage a practice of updating the library and then refactoring variables, rather than introducing local copies that diverge.

chevron-rightUnclear which version of an assumption is currently usedhashtag

Maintain a simple change log and consider adding effective date information in notes or tags for major revisions.


Last updated