# 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.

***

{% stepper %}
{% step %}

### 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}

{% step %}

### 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.
{% endstep %}
{% endstepper %}

***

## 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

<details>

<summary>Too many assumptions in the library become hard to manage</summary>

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

</details>

<details>

<summary>Users override assumptions directly in variables</summary>

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

</details>

<details>

<summary>Unclear which version of an assumption is currently used</summary>

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

</details>

***

## Related guides

* [Mine/Well Production Forecasts](/use-cases/mining-energy-and-natural-resources/mine-well-production-forecasts.md)
* [Default Valuation Assumptions](/help/stock-ticker-fundamentals/default-valuation-assumptions.md)
* [Depreciation](/help/financial-outputs-and-valuation/depreciation.md)
* [Formula Modal](/syntax/understanding-the-interface/formula-modal.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.modelreef.io/how-tos/data-workflows-and-automation/build-a-central-assumption-library.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.