# Naming & Structure (High Level) This article gives practical rules for naming and structuring models in Model Reef so they stay readable as they grow. You will learn how to: * Name models, branches, variables and drivers. * Keep structure aligned with how the business is actually run. * Make models easy for other people to read and review. * Avoid common naming and organisation pitfalls. These are guidelines, not hard rules, but following them will make large models easier to live with. ## 1. Naming models A **model** should be named so that someone else can tell what it is for without opening it. Good patterns include: * `Company Name - Group Model - FY2025` * `Client Name - SaaS Model - Base Case` * `Fund I - Portfolio Forecast - Q3 2024` * `Project Alpha - Project Finance Model` Avoid vague names like `New Model`, `Copy of Model` or `Test` once a model becomes important. When you use scenarios, treat each scenario as a separate model and name them explicitly, for example: * `Company Name - Base Case` * `Company Name - Downside Case` * `Company Name - Upside Case` This keeps scenario comparisons clear in dashboards and reports. ## 2. Structuring branches to match how you manage the business Branches should reflect how you think about the business operationally and how you report it. Common branch patterns: * By legal entity * Parent Group * Entity A * Entity B * By division or business line * Group * Division - Retail * Division - Online * Division - Wholesale * By geography * Group * Region - UK * Region - Europe * Region - US * By store, site or project * Group * Store - Sydney * Store - Melbourne * Store - Brisbane Pick a primary dimension that matches how you usually review performance. You can still use categories and naming to represent secondary dimensions. Use clear, stable names. For example, prefer `Store - Sydney` over `Store 1` so future readers know what that branch represents. ## 3. Naming variables Variables should be named so that you can search and understand them quickly. A simple pattern that works well is: Type - Category - Qualifier Examples: * `Revenue - Subscriptions - UK` * `COGS - Hosting - Cloud Provider A` * `Opex - Marketing - Paid Search` * `Staff - Engineering - Salaries` * `Asset - Plant - Line 1 Upgrade 2025` * `Liability - Loan - Bank A Term Facility` Guidelines: * Start with the variable type so that sorting and search group similar items. * Use plain language for categories and qualifiers. * Avoid cryptic abbreviations unless they are standard in your organisation. * Use dates in names sparingly for one off items like specific capex. If you inherit models from others, you can progressively rename variables as you touch them to improve clarity without changing behaviour. ## 4. Naming drivers Drivers usually represent assumptions that may be shared across many variables. Make that intent clear in the name. Patterns: * `Driver - Volume - Units Sold - UK` * `Driver - Price - Subscription - Standard Plan` * `Driver - Growth - Revenue - Base Case` * `Driver - Wage Inflation` * `Driver - FX - USD to GBP` Guidelines: * Include `Driver` in the name or tag field so it is easy to spot in search. * Make it clear what the driver is applied to (for example which region, plan or product). * Distinguish between base case and scenario specific drivers if you keep them in the same model. Because drivers live in the Data Library, good naming and tagging make it much easier to reuse existing assumptions rather than creating duplicates. ## 5. Categories and sub categories Categories and sub categories control how variables show up in reports, not how they behave. Use them to create clean layouts in P\&L, Balance Sheet and Cashflow, for example: * `Revenue` * `Revenue - Subscriptions` * `Revenue - Services` * `COGS` * `COGS - Direct Costs` * `Opex` * `Opex - Marketing` * `Opex - Operations` * `Opex - G and A` Guidelines: * Keep the category scheme consistent across branches. * Avoid mixing fundamentally different items in one category. * Do not use category as a substitute for branch or variable naming. If you get categories right early, your standard reports and custom packs will be much easier to build and maintain. ## 6. Structuring for templates and reuse If you expect to reuse model patterns across clients or business units, design structure with templates in mind: * Use consistent branch layouts for similar businesses. * Use the same variable naming patterns across models. * Store reusable drivers (for example inflation, FX) in clearly named Data Library entries. * Build standard dashboards and reports that assume a common structure. This allows you to: * Clone models or templates for new entities quickly. * Compare performance across businesses more easily. * Reduce onboarding time for new team members. ## 7. Avoiding common pitfalls A few anti patterns to avoid: * Using branches for everything\ Branches should represent meaningful organisational units, not every small dimension. Use categories, variable names and drivers for finer detail. * Embedding meaning only in free text notes\ Notes are helpful, but try to capture primary meaning in names, branches and categories first. * Overusing generic names\ Names like `Revenue 1` or `Cost A` are hard to search and understand later. Be explicit. * Letting naming drift over time\ Periodically tidy names and categories as the model evolves. Small cleanups prevent big refactors later. ## 8. Example: pulling it all together For a multi store retail business, you might end up with: * Model name: `Retail Group - 3 Store Model - FY2025`. * Branches: `Store - Sydney`, `Store - Melbourne`, `Store - Brisbane` under `Group`. * Variables: * `Revenue - Retail Sales - Store Sydney` * `COGS - Merchandise - Store Sydney` * `Opex - Rent - Store Sydney` * `Staff - Store Team - Store Sydney` * Drivers: * `Driver - Volume - Transactions - Store Sydney` * `Driver - Price - Average Basket - Store Sydney` The same pattern repeats for each store, making the model easy to read, extend and compare. ## Where to go next Once you are comfortable with naming and structure, continue with: * [Importing and Data Inputs](/help/importing-and-data-inputs.md) to see how to populate a model from your existing files and systems. * The [Core Modelling](/how-tos/core-modelling.md) how tos for step by step recipes. * [Workspace and Organisation](/help/workspace-and-organisation.md) if you plan to manage many models and templates. --- # 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/getting-started/naming-and-structure-high-level.md?ask= ``` 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.