# Experiences and resources (/docs/studios/experiences-and-resources)

A [Studio](/docs/studios/overview) turns governed intelligence into things a
person opens and uses. Those things have a shape. A Studio is made of
**experiences**, and an experience is made of **resources**. Get this one
distinction right and the rest of the model follows.

## Experience and resource [#experience-and-resource]

These two are easy to conflate, so keep the line sharp.

* An **experience** is a container: a topic, a workflow, or a module, such as
  "Advanced Machine Learning Models" or "Our Billing Service." It groups related
  content but is not itself the content.
* A **resource** is the item inside an experience: the actual thing a person
  reads, asks, or works through.

<Callout intent="note" title="Container, not content">
  One experience holds many resources. When you are deciding where something
  belongs, ask whether it is the shelf or the thing on the shelf. The experience
  is the shelf.
</Callout>

```text
Experience: Our Billing Service
 |-- Resource: Webhook retry expert   (AI Expert)
 |-- Resource: Refund policy           (Note)
 '-- Resource: Onboarding walkthrough  (Quest)
```

## The four resource types [#the-four-resource-types]

Every resource has exactly one type. The type decides how the resource behaves
and how a frontend renders it.

| Type        | What it is                            | Drawn from the graph as                                 |
| ----------- | ------------------------------------- | ------------------------------------------------------- |
| `AI_EXPERT` | An interactive expert you can ask     | Answers carrying the reasoning and evidence behind them |
| `AI_NOTE`   | Informational or educational content  | A written explanation grounded in governed decisions    |
| `QUEST`     | A task-based or challenge-driven flow | A guided path with each step checked against policy     |
| `PODCAST`   | Audio content                         | A narrated summary generated from the same record       |

The types matter because a Studio is not a generic CMS. Each type is a different
way of consuming the [reasoning and memory
graph](/docs/collective-intelligence). An AI Expert answers a question on
demand; a Note presents a settled explanation; a Quest walks someone through a
process; a Podcast narrates it. The knowledge underneath is the same governed
record. The resource type is how it is served.

### Why an AI Expert is more than a chatbot [#why-an-ai-expert-is-more-than-a-chatbot]

An `AI_EXPERT` resource answers from the graph, so its replies can show the
claims and evidence behind them and inherit the corrections your team already
made. That is the difference between a chatbot that guesses and an expert that
[explains why](/docs/govern/understand). The same governed memory that made the
decision trustworthy is what makes the answer trustworthy.

## How a Studio is put together [#how-a-studio-is-put-together]

Experiences and resources sit inside the wider Studio model. The full hierarchy:

```text
AI Studio (Publication)
 |-- Experiences
 |     '-- Resources (AI Expert, Note, Quest, Podcast)
 |-- Creator and co-creators
 |-- Collections (group experiences)
 '-- Metrics and Activity
```

* **Creator and co-creators** are the humans who own the Studio. The creator
  owns it; co-creators collaborate with a role (such as editor or reviewer) and
  a status (invited or accepted). Their corrections are what keep the content
  honest over time.
* **[Collections](/docs/studios/collections)** group experiences into ordered
  sets, such as a learning path or a course.
* **Metrics and activity** track engagement (views, likes, shares, bookmarks)
  and power ranking and personalization.

For the entity definitions and the API fields behind each of these, see [Core
Concepts](/docs/getting-started/core-concepts).

## Flattened and nested responses [#flattened-and-nested-responses]

The API returns this content in two shapes, and the right one depends on what
you are building.

* **Flattened** returns one row per resource, with the parent experience
  repeated on each row. It looks redundant, and that is the point: a frontend
  can render the rows as a flat list with no joining. Use it for feeds, search
  results, and discovery pages.
* **Nested** keeps resources inside their experience. Use it for a detailed
  experience view where the grouping is what matters.

Turning these responses into a UI (feeds, cards, rendering by resource type) is
the subject of the [Content modeling](/docs/guides/content-modeling) guide.

## Next steps [#next-steps]

<Cards>
  <Card title="Collections" href="/docs/studios/collections" description="Group experiences into ordered, governed collections." />

  <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="Map experiences and resources onto feeds and pages." />

  <Card title="Core Concepts" href="/docs/getting-started/core-concepts" description="The entity model and API fields behind the content." />
</Cards>