> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.ovalbee.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ovalbee.com/_mcp/server.

# Datasets and versions

A **dataset** is a named set of assets: images or videos together with their annotations. Almost every node reads a dataset, writes one, or both. Labeling queues, train and validation splits, predictions, accepted and rejected work — they're all datasets.

A dataset doesn't copy files. It lists assets that live in the workspace's storage, so the same image can be a member of the source dataset, a labeling queue and the final training set at once without taking up space three times.

## What's in a dataset

* **Media** — images or videos.
* **Annotations** — one annotation per image or video, holding every object and tag on it. Annotations travel with their images: when a node samples, splits, filters or moves images, their annotations come along.
* **An ontology** — the class and tag vocabulary the annotations are written in. See [Ontologies](/concepts/ontologies).
* **Tags** on its assets, such as the split an image came from, for filtering.

## Versions

Datasets have **versions**. Version 1 is created with the dataset, and later versions are added on top: v2, v3 and so on. Nothing is ever merged into an older version or rolled back in place — the history only grows.

Most versions are added by nodes:

* **A node's own result.** When a node creates a dataset for its output, the first run creates it and every rerun adds a new version to it. The dataset keeps the node's name, and older results stay in its history instead of being overwritten.
* **Imports.** Each drop into [Import drag & drop](/node-library/nodes/import-ops-import-drag-and-drop) and each run of the Supervisely [Import images](/node-library/nodes/supervisely-import-images) node adds a new version of the destination dataset.

Nodes that reorganize data you pointed them at — moving images between datasets, removing assets, copying into a destination — change that dataset in place. The node pages in the Node Library say which kind each node is. A saved version is never written to: a node pointed at an older version as the dataset it writes into stops with an error and asks for the dataset itself.

## Latest or pinned

A dataset input in a node can refer to a dataset in two ways:

* **Latest.** Picking a dataset by its name follows the newest version; its version list names this choice *Latest* at the top. Each time the node runs, it uses whatever the newest version is at that moment.
* **Pinned.** Expand a dataset that has several versions and pick one. The node keeps using that exact version, however many are added later.
* **Wired from another node.** An input bound to another node's dataset output reads what that node hands on. A dataset the node created follows its newest version, the way latest does, even if a version of it is saved later. A node that passes a dataset on — a copy destination, a preview — hands it on the way it was given: latest stays latest and a pinned version stays pinned. The output of [Create version](/node-library/nodes/dataset-ops-create-version) is a saved version and always reads the same.

Use latest for work that should keep up with the data: training on a growing labeled set, labeling whatever arrives next, reporting on the current state. Pin a version when the point is that it doesn't change: a benchmark set that several models are compared on, a frozen validation split, a dataset a result was published from.

To freeze what a step reads, for example so a training run sees the same data every time, put a **Create version** node in front of it and wire its output into the step. Create version saves the dataset's current contents as the next version and passes that version on, while the dataset stays open for more work.

## Creating datasets

You rarely create a dataset on its own. In any dataset picker, type a new name and press **Create** — the dataset is created on the spot and the input refers to it. The [Dataset](/node-library/nodes/dataset-ops-dataset) node does the same as a standalone step, and is a good way to give a flow one place where its main dataset is chosen.

## Finding datasets

**Storage** in the main sidebar lists the workspace's datasets with their newest version, ontology, number of assets, size and tags. Click a dataset to see its assets.

Some datasets are **hidden** from this list because they're working state rather than results: the private queue of each labeler, the last-run snapshot some nodes keep next to their result, pools that nodes use to remember what they've already processed. They stay reachable from the nodes that use them.

In a flow, the dataset picker lists the datasets already used in the current flow first, then everything else under **From Other Flows**.

## When data is deleted

Deleting puts things in the **trash**: a flow, a dataset, a model, or data the nightly cleanup found unused. What is in the trash still counts toward your storage and can be restored. Deleting a flow also puts the data only that flow used in the trash with it, and restoring the flow brings that data back.

**Empty trash** on the Home page deletes everything in it for good and frees its space at once. Anything left in the trash for 30 days is deleted the same way on its own. Before you empty it, the trash lists what it holds, how much each item frees, when something last used it, and which live flows still use it and would break.

Every night, data that nothing has referred to for 30 days goes to the trash. Data lives as long as something refers to it: a flow that hasn't been deleted, through its nodes or its saved versions; a workspace template; a deployment; or a model version that is itself in use, through the data it was trained and evaluated on. An asset stays while a dataset version holds it.

Datasets and models are kept version by version. A node that follows *@latest* keeps whichever version is the newest today, so a version stays for 30 days after a newer one replaced it, and longer only if something refers to it by name. A model version with an [alias](/concepts/models) is never moved to the trash. Typical unused data is the output of earlier runs, old versions of datasets that a scheduled import grows, models retrained since, and files a failed upload left behind. In a workspace the cleanup is new to, nothing moves for the first 30 days, so it never moves something used the day before it started watching.

A training run or a live training session that saves a newer checkpoint drops the one it replaced from the model. The file of a checkpoint no model lists any more is deleted the next night, without going through the trash: nothing can use or restore it.

Files that live in your own buckets, outside OvalBee's storage, are never touched. All three periods are instance settings. See [Platform configuration](/administration/platform-configuration).

## Related pages

* [Assets and annotations](/concepts/assets) — what a dataset is made of.
* [Ontologies](/concepts/ontologies) — the vocabulary a dataset is pinned to.
* [References](/concepts/references) — binding dataset inputs to other nodes' outputs.