Snapshots

​

Overview

A Snapshot is a complete, frozen copy of a simulation model at a point in time. Think of it as “Save As” for a model: not a diff or a delta, but a self-contained version the engine can simulate on its own, no matter what the live working model looks like later. Snapshots are how you keep simulation reproducible. Once a Snapshot exists, you can re-run it, hand it to a teammate, or compare it against another configuration in an Experiment — the configuration won’t drift while you keep editing the live model.

​

What’s Inside a Snapshot

A Snapshot embeds everything needed to re-run the configuration. Nothing is referenced by name — there’s no risk of a library item changing under it. Editing a library item — an entity, constant, lookup table, or schedule — does not affect existing snapshots. The snapshot carries its own frozen copies. This is what makes runs against a snapshot reproducible.

​

Saving a Snapshot

Click the disk icon in the Modeler’s top bar. The tooltip reads “Save current work as snapshot.” The dialog (titled Create Snapshot, with a Camera icon) has two fields:

• Snapshot Name (required) — short, descriptive. Placeholder: “e.g., Before adding resources”
• Description (optional) — explains what’s changed since the last save. Placeholder: “Describe what changes were made…”

Click Create Snapshot to commit. The Snapshot is immediately available everywhere it’s needed — the snapshot history picker, and the Add snapshot dropdown inside any Experiment. Snapshots saved from the disk icon are treated as your authored artifacts. Dexter won’t overwrite one of yours when iterating in chat — instead it creates a new snapshot of its own. If you want Dexter to keep iterating freely on a configuration, ask it to save the snapshot itself (“save a snapshot of this configuration”) and it’ll work in that one going forward.

​

Loading and Removing a Snapshot

The history icon next to the disk button opens the snapshot picker — it only renders when at least one snapshot exists for the current model. The tooltip shows the current count (e.g., “7 snapshots”). The picker has a search box (“Search snapshots…”) that filters live as you type, and rows grouped by recency (Today, Previous 7 Days, etc.).

• Click a row to load that Snapshot onto the canvas. Toast: “Snapshot loaded successfully.”
• Hover a row to reveal a trash icon.

Clicking the trash icon opens a confirmation dialog: “Delete Snapshot — Are you sure you want to delete ‘{name}’? This action cannot be undone.” There’s no undo after confirmation.

​

Autosaves

ProDex automatically captures an autosave snapshot every time you load a snapshot — preserving whatever state the live model was in before the load wiped it. Autosaves appear in the same picker as named Snapshots, with filenames like autosave-2026-05-06t1651307687010000.json. You can load or delete them just like any other Snapshot. Autosaves are deduplicated by content hash, so loading the same snapshot twice in a row doesn’t pile up identical autosaves. There’s currently no UI to trigger autosaves manually or configure their behavior — they fire on load and only on load.

​

Asking Dexter to Manage Snapshots

You can have Dexter save, list, and delete Snapshots from chat without leaving the page you’re on. Prompts that work:

• “Save the current state as a snapshot called baseline-4-techs with description Pre-expansion baseline.” — creates a new named Snapshot.
• “Show me the snapshots on this model.” — lists them as a markdown table.
• “Delete the snapshot baseline-4-techs.” — removes it.

Dexter’s delete is immediate and has no confirmation step. Use specific names rather than vague references like “delete the old one” — Dexter will act on its best guess. For careful deletion, use the picker UI directly.

​

Snapshots in Experiments

Snapshots are the unit of comparison in Experiments. Open the Experiments section, pick an experiment, and the Snapshots sidebar lets you add Snapshots from the same model side by side. Hit Run and ProDex simulates each Snapshot in parallel and lays the KPIs out for comparison. Since each Snapshot embeds its own schedule, an experiment row doesn’t separately select a schedule — the snapshot already carries the timing it should run against. To compare the same model under two demand profiles, capture two snapshots while each schedule is active and add both to the experiment.

​

Snapshots vs. The Live Working Model

The live working model is what you edit on the canvas — every drag, drop, and field change writes to it. Snapshots are frozen copies; they don’t change when the working model changes afterward. Experiments only run against Snapshots, never against the live model directly — that’s the guarantee that makes a comparison reproducible. Snapshots aren’t branches, though: there’s no merge-back operation. If a Snapshot represents a configuration you want as your new baseline, apply those changes to the working model manually.

​

Snapshots and Monte Carlo

A Monte Carlo batch sweeps random seeds against whatever model + schedule configuration is loaded at queue time. Snapshots are the natural way to pin that configuration: load the snapshot you want to evaluate, queue Monte Carlo against it, and every seed runs against the same frozen model. The configuration is captured at queue time, so editing the model afterwards doesn’t affect the in-flight batch.

​

When to Save a Snapshot

Use Snapshots as deliberate save points, not just rolling backups:

• Before significant changes. Restructuring routing, changing capacities, altering processing times — snap first so you have a clean baseline to compare against.
• When you have a known-good configuration. A model tuned to match observed floor data deserves a named save; it’s your reference point for everything that follows.
• Before running an experiment. Experiments compare Snapshots — pin the configurations you want to compare with names you’ll recognize weeks later.
• At natural milestones. End of a calibration cycle, after incorporating new production data, before a product mix shift.
• Before sharing results. Each run traces back to the Snapshot it was simulated from — that’s your audit trail.

Snapshots are immutable once saved. The same validation limits apply at capture time — invalid models can’t be snapshotted.