Build Scenario Aware Data Overrides

This guide explains how to design scenario aware data overrides in Model Reef. Because scenarios are implemented as separate models rather than internal branches, you manage overrides by combining a stable Base Case with scenario-specific copies and clearly marked changes.

The objective is to test different futures without losing track of the original assumptions.

Before you start

You should have:

• A Base Case model that you trust and want to preserve.

• A list of assumptions that you might override in scenarios, for example:

  • Revenue growth rates.

  • Margin assumptions.

  • Capex plans.

  • Discount rates.

• Familiarity with the Data Library and central assumption design.

If needed, review:

• Build a Central Assumption Library

• Build a Multi Scenario Comparison (A vs B vs C)

What you will build

By the end of this guide you will have:

• One Base Case model containing your central assumption library.

• One or more scenario models copied from the Base Case.

• A convention for tagging overridden assumptions in each scenario.

• A process for comparing scenario outputs back to the Base Case.

1

Step 1: Freeze and document the Base Case

Before creating overrides:

• Finalise your Base Case model.

• Ensure central assumptions live in the Data Library with clear names and tags.

• Document key assumptions in notes, such as:

  • Base growth rates.

  • Target margins.

  • Planned investment programmes.

  • Funding structure.

This model will remain unchanged so that you can always refer back to it.

2

Step 2: Create scenario models from the Base Case

For each scenario you want to test (for example Upside, Downside, or alternative strategies):

• Duplicate the Base Case model.

• Rename the copy clearly, such as:

  • Company - Scenario - Upside.

  • Company - Scenario - Downside.

  • Company - Scenario - Cost Restructure.

• Confirm that the new model runs correctly and that all Data Library entries are present.

Each scenario model starts with the same assumptions as the Base Case.

3

Step 3: Establish an override tagging convention

Within each scenario model, use a tagging or naming convention to signal overrides, for example:

• Add a tag OVERRIDE to any Data Library entry that differs from the Base Case.

• Include scenario names in notes for overridden entries, for example Overridden in Upside scenario: higher growth in core product.

• Keep original assumption names the same across scenarios so that you can line them up later.

This helps you see at a glance which assumptions were changed in each scenario.

4

Step 4: Apply scenario specific overrides

In a given scenario model:

• Identify the assumptions you intend to change:

  • Revenue growth drivers.

  • Cost per unit.

  • Capex schedules.

  • Discount rates or terminal growth rates.

• Edit the relevant Data Library entries or variables:

  • Update values and schedules directly.

  • Add notes explaining why the override was made.

Avoid making structural changes unless the scenario explicitly represents a structural shift. That keeps scenario comparisons cleaner.

5

Step 5: Compare scenario outputs to the Base Case

Once overrides are applied:

• Review P&L, Balance Sheet, Cashflow and Cash Waterfall in the scenario model.

• Export key metrics from both Base Case and scenario models:

  • Revenue.

  • EBITDA.

  • Cash and debt.

  • Valuation metrics (NPV, IRR, Money Multiple).

• Build a comparison view (for example in an external sheet or document) showing Base vs Scenario, with differences attributed to the overridden assumptions.

This lets you interpret scenario results in terms of the specific changes you made.

6

Step 6: Maintain scenario discipline over time

As the Base Case evolves:

• Decide whether to:

  • Update scenario models by re-creating them from the new Base Case, then reapplying overrides, or

  • Incrementally update scenarios in line with selected Base Case changes.

• Keep a simple record of:

  • Which Base Case version each scenario is based on.

  • What override set defines each scenario.

This helps prevent scenarios from drifting away from the underlying business reality without being noticed.

Check your work

• The Base Case remains intact and clearly documented.

• Each scenario model has a defined set of overrides and nothing more.

• Overrides are clearly tagged or documented so you can find them quickly.

• Differences in outputs between scenarios and Base Case can be traced back to specific override sets.

Troubleshooting

Too many overrides make scenarios hard to understand

Limit overrides per scenario to a small number of high impact assumptions and use additional scenarios if necessary for different themes.

Scenario models become stale as the Base Case changes

Establish a regular process for refreshing scenarios after major Base Case revisions, including documenting which Base Case version they are linked to.

Stakeholders confuse scenarios with updated forecasts

Label scenario models clearly and explain that they are designed to explore alternative futures, not to replace the central forecast unless explicitly decided.

Related guides

• Multi-Plant Consolidated Forecasting

• Driver Scenario Interactions

• Limitations of Public API Data

• Scenario Selector