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

# Projects

> Spin up isolated workspaces within your organization to test changes safely and replicate a validated setup elsewhere.

A **project** is a self-contained workspace within your organization. Creating one gives you a blank console: no pipelines, filters, patients, or configuration carried over from other projects. Use it to test changes safely (for example in a dev environment) before replicating a validated setup elsewhere, or to keep distinct workflows separate altogether.

Projects are managed under **Settings > Projects**, separate from day-to-day console work but easy to reach when you need to create, switch, or clean one up.

## Switching projects

A project selector sits in the sidebar for every org member, not just admins, so it's always visible which workspace you're in, even when the sidebar is collapsed. Opening it lists your organization's active projects (the default project is labeled) and switches your whole console view when you pick one. A "Manage projects" link at the bottom takes you to the full Settings page.

## Creating a project

Add a new project at any time from **Settings > Projects**. It starts completely empty: no pipelines, filters, or data carried over. This is the typical first step of a dev-to-prod workflow: build and validate a setup in a dev project with test patients, then move to production once it's ready.

Each project has a **project ID** (a slug, auto-derived from the name and editable at creation): the handle you pass to the SDK via `project=` and the `X-Olira-Project` header. See [Accessing patient state](/read-data/accessing-patient-state) for how this is used from the SDK.

## Duplicating a project

Duplicating an existing project copies its full configuration, platform config, pipeline templates, and cohort definitions, but never patients, logs, or patient state. This supports the dev-to-prod workflow directly: once a dev project's setup is validated, duplicate it into a new project instead of rebuilding from scratch.

## Deleting a project

Deletion is intentionally friction-full to prevent accidental loss:

1. Select delete on a project.
2. A warning dialog explains that the project moves to the Deprecated list, fully intact and restorable.
3. A second dialog requires you to type the project's exact ID to confirm. This reinforces that the action affects the full project.
4. Once confirmed, the project is not immediately erased. It moves to the **Deprecated** list.

The default project cannot be deleted; there is no delete option for it in the Console.

## The Deprecated list

Deleted projects land in a Deprecated section of the same Projects settings page. From there, you have two options:

* **Restore**: bring the project back, fully intact with its prior configuration.
* **Permanently delete**: type the project's exact ID to confirm, then remove the project and its data for good. No recovery path. This is blocked while the project still has patients; remove them first.

This gives you a safety net against accidental deletion, while still allowing a clean, final removal when a project is truly no longer needed.

## What's project-scoped vs organization-level

| Project-scoped (isolated per project)             | Organization-level (shared across projects) |
| ------------------------------------------------- | ------------------------------------------- |
| Patients                                          | Members, roles, invites                     |
| Event logs                                        | API keys                                    |
| Patient state (stable, event-driven, memory)      | Integrations                                |
| Views and summary snapshots                       | Org schema registrations                    |
| Cohorts                                           | Billing and org settings                    |
| Platform config (event types, templates, modules) |                                             |
| Pipelines and population view templates           |                                             |
| Historical ingestion jobs                         |                                             |

A new project starts with none of the project-scoped items above. Duplicating a project copies only the configuration rows (platform config, pipeline templates, cohort definitions), never patients, logs, or patient state.

## Summary

| Action                                                | Result                                                     |
| ----------------------------------------------------- | ---------------------------------------------------------- |
| Create                                                | New, empty project                                         |
| Duplicate                                             | Full copy of an existing project's configuration           |
| Delete (warning + type-to-confirm)                    | Moves the project to the Deprecated list                   |
| Restore (from Deprecated)                             | Reactivates the project as-is                              |
| Permanently delete (from Deprecated, type-to-confirm) | Erases the project for good; blocked while patients remain |

<Note>
  A project is not an organization: members, invites, API keys, integrations, and billing stay
  org-level. It's also not a cohort: cohorts group patients within a project for views and
  analysis, while patients in different projects share nothing.
</Note>

See [Accessing patient state](/read-data/accessing-patient-state) for how project scoping works from the SDK, and the [Projects reference](/reference/sdk/index) for `create_project`, `duplicate_project`, and related method docs.