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

# Key Concepts

> Origin APIs, backends, adapters and their configuration scopes.

| Term                          | Meaning                                                                               |
| ----------------------------- | ------------------------------------------------------------------------------------- |
| Origin service                | The service API your application is written to call. This is what you adapt **from**. |
| Backend service               | The service an adapter uses to perform the operation or hold data.                    |
| Target cloud                  | The cloud where the selected backend runs. This is what you adapt **to**.             |
| Service adapter               | An implementation of a particular origin-service-to-backend mapping.                  |
| Cloud adapter                 | A collection of service adapters for one origin-to-target cloud direction.            |
| Cloud adapter configuration   | Shared installation settings independent of an individual service adapter.            |
| Service adapter configuration | Settings for one particular service adapter.                                          |
| Tuning tag                    | An origin-request tag that supplies a supported target-native field choice.           |

## Selection is not compatibility

A backend choice identifies where a service's operations will be implemented. It does not promise complete support for the origin API. Read the operation coverage and differences for the selected mapping, including the behavior on which your application depends.

The service reference under each cloud in the sidebar lists the mappings available for Cloud Adapter.

## Read a mapping in the right order

When evaluating a service, read the mapping from left to right:

1. **Origin API:** the service and operation your client sends.
2. **Backend:** the target service that performs the work or stores data.
3. **Identity:** the credentials that authenticate the origin caller and the separate identity used for backend access.
4. **State:** resources, data, keys and policies that must survive restarts or upgrades.
5. **Evidence:** response headers, target state and the documented error behavior.

The order matters. A backend name is not an operation guarantee, and an accepted request is not proof that a write reached the target.

## Configuration is not a migration

A configuration file describes desired settings. Moving persistent data from one backend to another is a separate operation. Editing a backend name cannot, by itself, copy data or preserve resource identities.

The [configuration lifecycle](/cloud-adapter/operations/overview) therefore distinguishes a valid configuration from a supported transition to that configuration.

## Tuning is not backend selection or consent

The request directive namespaces have different purposes:

* `t9:tuning:<path>` supplies a supported backend field.
* `t9:backend` selects a backend where that mechanism is supported.
* `t9:ack:*` records explicit acknowledgement of a named semantic difference.

An acknowledgement is not a performance knob. Do not add one merely to dismiss an error. See [tuning](/cloud-adapter/tuning/overview).