# Naming (Drivers)

This article describes how to name **drivers** in Model Reef so they are easy to understand and reuse across variables and branches.

You will learn:

* What driver names should communicate.
* Naming patterns for economic, operational and modifier drivers.
* How to distinguish driver names from variable names.
* How to keep the Data Library tidy as the number of drivers grows.

***

## 1. What a driver name should communicate

A driver name should answer three questions:

{% stepper %}
{% step %}

### What is this measuring?

For example: Price, Volume, Conversion, Wage Inflation, FX.
{% endstep %}

{% step %}

### At what level is it defined?

For example: Global, Entity, Division, Product, Region.
{% endstep %}

{% step %}

### How is it used?

For example: price, volume, rate, percentage, index.
{% endstep %}
{% endstepper %}

Examples:

* `Driver - Price - SaaS Seat - Global`
* `Driver - Volume - Active Users - UK`
* `Driver - Conversion Rate - Free to Paid - Online`
* `Driver - Wage Inflation - AU`
* `Driver - FX Rate - GBP to USD`

When you see a driver in a formula, the name alone should make it clear what it means.

***

## 2. Recommended naming pattern

A helpful pattern is:

Driver - \[Type] - \[Subject] - \[Qualifier]

Where:

* Type describes the general nature of the driver, for example `Price`, `Volume`, `Rate`, `Inflation`, `Index`, `FX Rate`.
* Subject is what it applies to, for example `SaaS Seat`, `Store Footfall`, `Engineer Salary`.
* Qualifier gives geography, segment or scope, for example `Global`, `UK`, `Enterprise`, `Retail`.

Examples:

* `Driver - Price - Subscription - Enterprise`
* `Driver - Volume - Orders - Online`
* `Driver - Rate - Churn - SME`
* `Driver - Inflator - Rent - Global`
* `Driver - FX Rate - EUR to GBP`

This pattern keeps all drivers grouped together when sorted by name and remains readable in formulas.

***

## 3. Differentiating drivers from variables

Although drivers are often Data Library backed series just like variables, they serve a different purpose.

To keep this clear:

* Prefix driver names with `Driver -` (or a similar consistent tag) so they are easy to recognise in autocomplete lists.
* Use nouns that reflect input behaviour rather than financial statement outcomes, for example `Churn Rate` rather than `Lost Revenue`.
* Avoid naming drivers in a way that looks like P\&L lines, to reduce confusion.

Variables then tend to have names like `Revenue - Subscriptions - UK`, while drivers look like `Driver - Price - Subscription - UK`.

***

## 4. Scope and reusability in driver names

If a driver is intended to be **global** or used across many branches, make that clear:

* `Driver - Wage Inflation - Global`
* `Driver - FX Rate - USD to GBP`
* `Driver - Market Growth - SaaS`

If a driver is specific to one branch or context, capture that as well:

* `Driver - Price - Retail - Store Sydney`
* `Driver - Utilisation - Engineers - Entity A`

This helps others understand whether they can safely reuse a driver in their part of the model.

***

## 5. Notes, tags and descriptions

For important drivers, combine good names with:

* **Notes** explaining how the driver should be used and where it came from.
* **Tags** to group related drivers, for example `Inflation`, `FX`, `Market`, `Scenario`.
* **Data source references** if the driver is imported from an external API or file.

Names tell the short story. Notes and tags provide the longer context and make review easier.

***

## 6. Renaming drivers safely

Like variables, drivers can be renamed without breaking formulas:

* References in formulas are tracked via internal IDs, not just the text name.
* When you rename a driver, any variable or chart that uses it will continue to work and will simply show the new name in the formula editor and legends.

This makes it safe to improve naming as driver usage becomes clearer over time.

***

## 7. Common driver naming pitfalls

Avoid:

* Very generic driver names, for example `Rate`, `Factor`, `Adjuster`. These become impossible to distinguish at scale.
* Drivers with similar names but different scopes and no clear qualifier.
* Using codes only, for example `DRV_101`, unless accompanied by a readable name.

If drivers are not clearly named, it becomes hard to audit how a forecast is built, which undermines trust in the model.

***

## Related articles

* [Loan/Interest Sensitivity Planning](/use-cases/real-estate-and-property/loan-interest-sensitivity-planning.md)
* [Build an Acquisition Case vs Base Case](/how-tos/investment-and-transactions/build-an-acquisition-case-vs-base-case.md)
* [Drivers, Variables & Timing](/help/drivers-variables-and-timing.md)
* [Naming & Autocomplete](/syntax/variables-syntax/naming-and-autocomplete.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/help/building-your-model/naming-drivers.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.