# Collections (/docs/studios/collections)

A [Studio](/docs/studios/overview) holds many
[experiences](/docs/studios/experiences-and-resources). A **collection** is how
you group them into something with a shape and an order: a learning path, a
course, a curated reading list. Where an experience answers "what is this piece
of content," a collection answers "what should someone go through, and in what
order."

## What a collection does [#what-a-collection-does]

A collection is a curated group of experiences scoped to one Studio. It lets you:

* **Group related experiences** so they read as one journey rather than a loose
  pile.
* **Set the order** the experiences appear in, and keep that order stable.
* **Control visibility**, so the right audience sees the collection and no one
  else does.

<Callout intent="note" title="Collections group experiences, not resources">
  A collection orders experiences. The experiences themselves order their own
  resources. If you want to sequence individual items (an AI Expert, then a Note),
  that lives inside an experience, not in the collection above it. See
  [Experiences and resources](/docs/studios/experiences-and-resources).
</Callout>

## Ordering [#ordering]

The order of experiences in a collection is preserved. This is what makes a
collection usable as a path: the first experience is the starting point, and
each one follows the last in a sequence you control. Reordering the collection
reorders the journey, and the new order is what every viewer sees.

Only eligible experiences can be added to a collection. An experience must be
published and must belong to the same Studio as the collection. You cannot pull
an experience from another Studio into the order.

## Visibility [#visibility]

Every collection carries a visibility setting that decides who can open it. It
follows the same model as the Studio itself.

| Visibility | Who can see it                     |
| ---------- | ---------------------------------- |
| `public`   | Anyone, no authentication required |
| `private`  | The owner only                     |
| `team`     | Members of the workspace           |
| `org`      | Anyone in the organization         |

Visibility is enforced together with the publication's own access rules. A
public collection on a public Studio is reachable without signing in; a team
collection requires workspace membership; a private collection is the owner's
alone. The full rules, including how publication visibility and user role
combine, are in [Permissions](/docs/guides/permissions).

<Callout intent="warning" title="The Studio's visibility comes first">
  A collection cannot widen access beyond its Studio. If the publication is
  private, marking a collection public does not make it reachable to the world.
  Access is always the publication's rules and the collection's visibility taken
  together.
</Callout>

## Worked example: a learning path [#worked-example-a-learning-path]

A Studio that documents your platform groups its experiences into an onboarding
path:

```text
Collection: New engineer onboarding   (visibility: team)
 |-- Experience: Our architecture       (start here)
 |-- Experience: The billing service
 '-- Experience: Deploying safely        (finish)
```

Set to `team` visibility, the path is visible to everyone in the workspace and
no one outside it. The order is fixed, so a new hire works through architecture
before deployment, not the other way around. Because each experience draws on
the governed [reasoning and memory graph](/docs/collective-intelligence), the
path teaches what the system actually decided and why, not a hand-written
approximation that drifts out of date.

## Working with collections in the API [#working-with-collections-in-the-api]

Collections are a first-class API resource. You can list them, create and update
them, set their ordered experiences, and fetch the collections for a given
Studio by its `url`. The endpoints, request shapes, and status codes are in the
[API Reference](/docs/api-reference/overview), and the parameters for filtering
and paging lists are covered in
[Search and filtering](/docs/guides/search-and-filtering).

## Next steps [#next-steps]

<Cards>
  <Card title="Experiences and resources" href="/docs/studios/experiences-and-resources" description="The content model a collection groups." />

  <Card title="Studios overview" href="/docs/studios/overview" description="How a Studio turns the governed graph into experiences." />

  <Card title="Content modeling" href="/docs/guides/content-modeling" description="Build playlists, courses, and paths from collections." />

  <Card title="Permissions" href="/docs/guides/permissions" description="How visibility and access rules combine." />
</Cards>