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

# Scenario

Scenarios let you branch a model into named versions so you can try changes safely, compare outcomes, and merge approved changes back into Main Scenario.

![](https://mintcdn.com/oculon/2ze9UxHD5qWqzavK/images/getting-started/scenario.png?fit=max\&auto=format\&n=2ze9UxHD5qWqzavK\&q=85\&s=672d24648b0c034633d8c98e39813dbd)

Use Scenarios when you need:

* Safe experimentation without changing the live model
* A locked baseline (budget, board plan, approved forecast)
* A review workflow (draft → review → merge)

## Key concepts

* Main Scenario: the default “live” branch. It is always available and cannot be deleted.
* Scenario: a branch derived from Main (or duplicated from another scenario).
* Overrides: scenario-specific changes that differ from the inherited baseline.
* Inheritance / auto-sync: when enabled, non-overridden values continue to follow Main Scenario.
* Merge: directional operation that applies only overrides from a source scenario into a destination scenario.

## Common tasks

### 1) Create a new scenario

1. Open the Scenario switcher (top bar).
2. Select New Scenario.
3. Give it a clear name (example: “FY26 Base – Draft” or “Headcount Cut – Alt”).
4. You’ll land in the new scenario.

Tips:

* Use naming that encodes purpose and lifecycle (Draft/Review/Locked).
* Avoid duplicates; if you need iterations, add a suffix (v2, Apr, etc.).

### 2) Switch scenarios

1. Open the Scenario switcher.
2. Pick a scenario from the list.

Expected behavior:

* The active scenario should be visible at all times.
* Your editing context follows the active scenario.

### 3) Make changes safely

When you edit in a non-main scenario, changes should remain isolated to that scenario until you merge.

If you’re unsure where you are:

* Check the active scenario label before editing.
* If the product shows visual cues (badges/colors), treat them as authoritative.

### 4) Compare scenarios

Use Compare to review how a scenario differs from Main (or another baseline).

Use cases:

* “What changed vs Main?”
* “What’s the variance vs our locked budget scenario?”

### 5) Duplicate a scenario

Duplicate creates a new scenario using the current effective state of an existing scenario.

Use this when:

* You want to continue planning from an approved baseline.
* You want a new branch without disturbing the existing one.

Expected behavior:

* The duplicate should include the source’s effective values.
* Identity fields (created by/time) are new for the duplicate.

### 6) Merge changes

Merge moves overrides from a source scenario into a destination scenario (often Main).

Steps:

1. In the source scenario, choose Merge Changes.
2. Select the destination scenario.
3. Confirm the merge.

Expected behavior:

* Merge is directional.
* You cannot merge a scenario into itself.
* Only overrides are merged (not a full snapshot).
* A merge should create an audit/history event.

## Scenario settings (how to interpret them)

### Auto-sync from main

* ON: your scenario keeps inheriting changes from Main, except where you’ve made overrides.
* OFF: your scenario stops receiving new Main changes; it becomes more “frozen.”

Good defaults:

* Exploratory scenarios: Auto-sync ON
* Baselines/approvals: Auto-sync OFF

### Allow Changes (Editability)

* ON: permitted users can edit the scenario.
* OFF: scenario is read-only (locked).

Enforcement expectations:

* UI edits should be blocked when OFF.
* API/import/job/agent writes should also be blocked.

### Allow Merging (Mergeability)

* ON: scenario can be used in merge flows per permissions.
* OFF: merge should be disabled.

Note: Some products interpret this as “can be a merge source.” If that’s the case, it controls merging from this scenario, not necessarily merging into it.

### Who can view (Visibility)

* All Members: visible to everyone in the workspace.
* Only Admins: restricted visibility.

Expected behavior:

* Restricted scenarios should not appear in the switcher for unauthorized users.
* Direct links must still enforce permissions.

## Rules of thumb

* Treat Main Scenario as the safe, default “truth” branch.
* Use a dedicated scenario for risky experiments.
* Lock scenarios that represent approved states.
* Merge intentionally, and prefer merging small, understood override sets.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.