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

# Core Concepts

> The mental model behind to11: the Organization, Workspace, and Project hierarchy, the gateway and its routing primitives, and the observability data plane.

This page is the single reference for how to11 is organized. Other pages link here rather than redefining these terms.

## The hierarchy

to11 organizes everything into a three-level hierarchy. Access, roles, and settings all hang off these levels.

```text theme={null}
Organization        your company or team — owns members, roles, and API keys
  └─ Workspace      a product area or environment family — groups related projects
       └─ Project   a single application or service — owns providers, routes, environments, and traces
```

* **Organization** — The top-level tenant. Members, roles, and API keys live here. See [Platform](/docs/platform/overview).
* **Workspace** — Groups related projects under one organization. Workspaces can be renamed, archived, and made discoverable to the rest of the org.
* **Project** — Where the work happens: provider connections, routing, environments, and the traces you observe.

## The gateway

The gateway is the runtime that sits between your application and your LLM providers. You point your SDK at it, and it routes the request, applies inline security, and emits telemetry. See [Deploy](/docs/deploy/overview).

## Providers, targets, and routes

Inside a project, a few primitives describe where traffic can go and how the gateway chooses:

* **Provider** — a connected model vendor (OpenAI, Anthropic, and others) together with the credential the gateway uses to reach it. See [Providers](/docs/deploy/concepts/providers).
* **Target** — a specific model on a provider, paired with the credential to call it: the concrete endpoint a request can land on. See [Targets](/docs/deploy/concepts/targets).
* **Route** — a named mapping from a model name to a strategy over one or more targets: send everything to one target, split traffic by weight, or fall back on failure. See [Routes](/docs/deploy/concepts/routes).
* **Function** — a task alias (like `summarize`) that points at a route, so your application names the job instead of the model. See [Functions](/docs/deploy/concepts/functions).

For the simplest setup you touch none of this — connect one provider and call its models by name. Routes and functions are there when you want to manage model choice centrally instead of in application code. See [Routing](/docs/deploy/routing/overview).

## The observability data plane

Every request through the gateway — and any spans you send directly — lands in a shared data plane you query from the dashboard. This is what powers traces, metrics, and dashboards. See [Observe](/docs/observe/overview).

## How the pieces fit

```text theme={null}
Your app ──SDK──▶ Gateway ──▶ LLM provider
                    │
                    └──telemetry──▶ Observability data plane ──▶ Dashboard
```

## Next steps

<CardGroup cols={2}>
  <Card title="Quickstart" icon="rocket" href="/docs/get-started/quickstart">
    Send your first traced request.
  </Card>

  <Card title="Platform" icon="building-2" href="/docs/platform/overview">
    Manage your organization, members, and access.
  </Card>
</CardGroup>