> For the complete documentation index, see [llms.txt](https://docs.unitlab.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unitlab.ai/documentation/datasets/dataset-lifecycle-and-recovery.md).

# Dataset lifecycle and recovery

Dataset lifecycle operations can affect multiple projects and releases. Review dependencies first, preserve version history, and make the intended future behavior explicit.

The UI exposes rename, add files, attach to project, archive, and delete actions.

Automation adds:

* create from folder or asset IDs;
* add sources;
* inspect unpublished changes;
* publish a version with a title;
* list versions;
* list items for the current state or a specific version;
* preview attachment counts;
* attach the latest or an exact version;
* list and detach a project source.

Video attachments can require an explicit frames-per-second value. Both preview and commit validate this rule so an operator can discover the requirement before creating the project copy.

### Upload Data from a project

Project **Upload Data** uses the plain mixed-data uploader and has no destination-folder picker:

1. The user uploads one or more mixed files.
2. One upload action creates one Batch Queue.
3. Files land in the project’s own data under the project name.
4. The first upload lazily creates the project’s own folder and own-data dataset.
5. Unitlab waits for the batch to become quiet, then auto-publishes one new version for that upload batch.
6. The project Datasets view refreshes.

Project-side auto-publish applies only to the project’s own uploads. Uploading into a workspace Data Assets folder instead creates an unpublished change that still requires an explicit Publish version.

### Attach Data to a project

The project-side Attach Data modal has **Folders** and **Datasets** tabs; there is no loose Assets tab. Organize loose assets into a folder or dataset first.

1. The user opens **Attach Data**.
2. The user selects a workspace folder or a published dataset version.
3. Sources already fully attached are pre-checked, locked, and labeled Attached. This state is evaluated per version, so attaching v1 does not block v2.
4. Unitlab previews item and deduplication counts.
5. Commit clones the frozen version into the project as Unassigned data without re-uploading the files.
6. The newly attached items are selected automatically.
7. The Assign Members modal opens so annotator/reviewer assignment can continue immediately.

Attaching a folder first resolves it through a folder-backed dataset and frozen version. Attaching another project’s data includes only that project’s own source data; sources that were merely attached into that project do not cascade into the next project.

### Project dataset cards, View Source, and Detach

The project’s own data and every attached version appear as uniform dataset cards. Root-card actions include:

* **View Source** — opens the underlying project dataset, folder, or frozen version without mutation;
* **Detach** — removes that source from this project only.

Detach shows source name, asset count, and annotation count. By default it archives the project copies while preserving annotations. The user can explicitly choose **Clear annotations**, which requires a stronger confirmation. Re-attaching restores the archived project rows and kept histories instead of creating duplicates. Other projects and the Data Assets source remain unchanged.

### Dataset versus folder

A folder answers, “Where did these files come from?” A dataset answers, “Which controlled collection are we using for this experiment or project?” One source folder may feed several datasets; one dataset may combine multiple source folders and selected exceptions.

### Use this in production

* Duplicate when a new operating purpose needs an independently governed lineage.
* Restore when the existing lineage remains correct and a recoverable state should return to use.
* Detach only after reviewing active project tasks, assignees, comments, issues, and release dependencies.
* Retain stable IDs, version notes, affected project IDs, owner, reason, and reconciliation counts in the record.

{% hint style="warning" %}
Do not use lifecycle changes to erase evidence of a bad membership decision. Correct the lineage with an explicit new version or documented recovery action.
{% endhint %}