> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getnovaplan.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Core concepts

> The handful of ideas that make everything else in Novaplan click.

A few concepts run through the whole platform. Learn these once and every screen reads clearly.

## Budget versions

A **budget version** is a named container for a plan: its forecast window, assumptions, headcount, revenue, and derived GL all live inside one version. You always work in the context of exactly one version, and a selector at the top of the app tells you which one.

* The **live** version (unlocked) is where active planning happens. Edits land immediately and the engine recomputes downstream.
* A **locked** version is a frozen snapshot. You compare against it but cannot edit it.

A typical workspace carries several versions side by side: a "2026 Plan" you locked at the start of the year, a "Rolling Forecast" you update every month, and maybe an "Aggressive Hiring" scenario you are stress-testing.

<Note>
  A version's label year is just a label. Plans are driven by the forecast window (the start and end month you set), not by the version's name. A live Rolling Forecast can carry a label of 2025 while it covers 2026, so always reason from the window, not the title.
</Note>

## Actuals vs forecast

Novaplan keeps **actuals** (what actually happened, immutable, append-mostly) strictly separate from **forecast** (what the engine projects, regenerated on every run). They live in different tables with different identifiers and different audit rules. Reports stitch them together at the boundary month, so you see one continuous line from history into projection without the two universes ever mixing.

Why the separation matters: an actual posted in March never changes when you re-run the forecast, and a forecast for next March is free to update on every run without disturbing anything you have already closed.

## The two universes: GL and domain

Every number you see lives in one of two universes, joined by a bridge.

| Universe   | What it holds                                                                                                              | Who reads it                                       |
| ---------- | -------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------- |
| **Domain** | Rich, per-entity records: employees and their fully loaded cost components, ARR events per account, contracts and pipeline | Headcount and revenue planning surfaces            |
| **GL**     | General ledger rows by account, department, and period                                                                     | Every dashboard, P\&L, and budget-vs-actual report |

The domain universes are where you plan with real-world objects (a person, an open req, a subscription). The **GL universe** is the common ledger that all reporting reads. Headcount and revenue each **derive into the GL** through a bridge, so a dashboard built on the GL always reflects your latest people and revenue plans without anyone re-keying numbers.

This is also why a domain figure and a GL figure for "the same thing" can differ slightly: GL P\&L can include accruals, contractor spend, and recruiting fees that the per-employee cost model does not. That gap is the universe difference, not an error.

## Dimensions

Departments, entities, GL accounts, products, channels, and regions are **dimensions**. They are the axes that power every filter, group-by, and pivot across the app. Admins manage how raw data from your source systems maps onto canonical dimensions in **Admin, then Dimensions**.

Identity is resolved by ID, not by name, so an upstream rename (a department relabeled in your HRIS) never scrambles your hierarchy.

## Scenarios

A **scenario** is a what-if layered on a version. Change a few assumptions (hiring pace, growth rate, attrition) and compare the result against the base without ever disturbing the base. Scenarios let you ask "what if we hold hiring flat?" and see the cost impact side by side before you commit. See [Scenarios](/planning/scenarios).

## Lock levels

Locking freezes a version so its numbers cannot drift after a cycle closes. When a version is locked, its data is served from a snapshot taken at lock time, so historical comparisons stay stable forever. Lock levels let you freeze progressively, from external-facing data only up to everything:

| Lock level   | What it freezes                                                               | Use it when                                                                             |
| ------------ | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| **Revenue**  | The revenue and ARR universe                                                  | You have signed off the topline but are still adjusting cost                            |
| **External** | Everything you share outward (revenue plus the figures reported to the board) | The board package is out and must not move, but internal working numbers can still flex |
| **All**      | The entire version, every universe                                            | A cycle is fully closed and the version is now a permanent reference                    |

A concrete example: you present the 2026 Plan to the board in January and lock it at the **external** level. From then on, every "plan vs actual" report reads the board figures from the snapshot, so the variance story stays honest even as your live Rolling Forecast keeps moving. When the year fully closes, you raise the same version to **all** and it becomes a permanent baseline.

<Tip>
  Lock-awareness is automatic. Planning surfaces route reads to the snapshot when a version is locked and to live data when it is not, so you never have to check a lock flag yourself.
</Tip>