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

# Give the space a mission

> Tell it what it is for, and how skeptical to be. It changes what gets kept and how it is read back.

[← All use cases](/use-cases/overview)

<div className="uc-examples"><a className="uc-api" href="/api-reference/models">API reference</a></div>

## The scenario

Two spaces with identical contents should not behave identically. A space of
incident postmortems wants literal, cautious reading. A space of customer
conversations wants inference — reading between the lines is the job.

**What this recipe shows that no other does:** a space has a *disposition*, and
it is readable.

## Step 1 — Read the profile

```python theme={null}
profile = client.get_space_profile(space_id="incidents")
print(profile["mission"])
print(profile["disposition"])
```

You get back two things:

* **`mission`** — what this space is for, in prose. It rides along with
  extraction and synthesis, so it shapes what is considered worth keeping.
* **`disposition`** — three dials: `skepticism`, `literalism`, `empathy`.

## What the dials actually mean

| Dial           | Low                                | High                                                  |
| -------------- | ---------------------------------- | ----------------------------------------------------- |
| **skepticism** | Takes statements at face value     | Treats claims as claims, keeps the hedge              |
| **literalism** | Infers intent, reads between lines | Keeps what was said, not what was meant               |
| **empathy**    | Records facts                      | Keeps the emotional register — frustration, hesitancy |

A support space usually wants low literalism and some empathy: "the customer was
clearly fed up" is the useful memory, not a transcript. A postmortem space wants
the opposite, because an inferred cause recalled later as fact is how one
incident becomes two.

## Step 2 — Read it before you trust a synthesis

Disposition explains answers that otherwise look like bugs. A space that keeps
hedges will answer "they *said* the migration was complete" where a
low-skepticism space answers "the migration was complete" — and only one of
those is safe to act on.

When a synthesis reads oddly confident, check the profile before you blame
recall.

## Evals

1. Record the same ambiguous statement into two spaces with different profiles —
   something like *"I think we probably shipped it last week."*
2. Ask both what happened.
3. The literal space should keep the hedge; the inferring one should commit.
   If they answer identically, the profile is not doing what you think and the
   rest of your tuning is built on a wrong assumption.

## Guardrails

<Warning>
  **Disposition is not a safety control.** A high-skepticism space still stores
  what it was told; it is a reading style, not a filter, and it will not stop a
  false statement from being recalled.
</Warning>

* **The profile is per space**, so it is another reason to split by audience —
  see [One space or many?](/use-cases/one-space-or-many).
* **Do not echo the resolved profile back as your own config.** What you read
  includes platform defaults; writing those back as explicit overrides pins the
  space to today's defaults forever.
* **A mission is not a prompt.** It biases what is kept and how it is read; it
  does not instruct the model to answer in a particular way. For that, use
  [extraction guidance](/use-cases/teach-it-your-vocabulary).