> ## 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

> Understand service adapters as directed origin-to-target mappings, and distinguish the mapping from its backend and configuration.

> [!NOTE]
>
> Before running a `tensor9` command, [install the CLI, set `T9_API_KEY`, and verify your customer account](https://docs.tensor9.com/cloud-adapter-early-access/getting-started/install-and-authenticate). Online commands are authenticated and their adapter detail is limited to mappings your account is entitled to use.

A **service adapter includes both an origin service and a target service**. The target service is also called the **backend**. For example, **Amazon S3 → Google Cloud Storage** is one service adapter; **Amazon S3 → Azure Blob Storage** is another.

GCS alone names a backend, not a complete service adapter. The origin tells you which API and behavior the adapter must provide. The target tells you which service it uses to provide them.

| Term | Meaning |
| - | - |
| Origin service | The service API your application is written to call. This is what you adapt **from**. |
| Target service / backend | The service an adapter uses to perform the operation or hold data. This is what the origin service is adapted **to**. |
| Target cloud | The cloud where the selected backend runs. This is what you adapt **to**. |
| Service adapter | The directed mapping from a particular origin service to a particular target service, together with the implementation of that mapping. Both services identify the adapter. |
| 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. |
| Included agent | A Cloud Adapter support or operations assistant working within its configured identity, tools and permissions. |
| Swarm | A group of agents pursuing a shared goal; membership does not add tool or evidence access. |
| War Room | A shared operational workspace for admitted people and agents, with selected evidence and a defined purpose. |

## One origin can have several service adapters

An AWS application can continue calling DynamoDB while you compare different adapters for that origin:

| Service adapter | Origin service | Target service / backend |
| - | - | - |
| DynamoDB → Firestore | Amazon DynamoDB | Google Cloud Firestore |
| DynamoDB → Cloud SQL for PostgreSQL | Amazon DynamoDB | Google Cloud SQL for PostgreSQL |
| DynamoDB → provisioned Cosmos DB | Amazon DynamoDB | Azure Cosmos DB, provisioned |

These adapters share the origin API but have different implementations, capacity models and operating requirements. The mapping is directional: support for S3 → GCS does not establish support for GCS → S3. Check the profile for the exact origin and target pair.

In the [Choosing an Adapter](https://docs.tensor9.com/cloud-adapter-early-access/trade-offs/overview.md) articles, the origin is usually already fixed by the application. Comparing backends in that context means comparing service adapters for that same origin. “Choose Cloud SQL for DynamoDB” is shorthand for choosing the DynamoDB → Cloud SQL for PostgreSQL service adapter, not for replacing the application's DynamoDB calls with SQL.

## Identify both sides in a trial

The single-service command names both services explicitly:

```bash theme={null}
tensor9 adapt svc run \
  --origin aws::1.0.0::s3 \
  --backend google::1.0.0::gcs
```

This selects the **S3 → GCS service adapter** for the process. Prepare the target identity and configuration using the [S3-to-GCS example](https://docs.tensor9.com/cloud-adapter-early-access/configuration/examples.md#s3-to-google-cloud-storage) before running it. It uses real target-cloud resources.

An installation does not need a redundant configuration entry for every pair. Where the origin and target environment resolve a single compatible backend, that selection can be inferred. Explicit choices and pre-provisioned dependencies still need the settings described in [Configuration Files](https://docs.tensor9.com/cloud-adapter-early-access/configuration/files.md). Inferred selection does not change the meaning of a service adapter: the effective mapping still has both an origin and a target.

## 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](https://docs.tensor9.com/cloud-adapter-early-access/configuration/overview.md#treat-changes-as-transitions) therefore distinguishes a valid configuration from a supported transition to that configuration.

## Tuning is not backend selection or consent

The public service profiles distinguish three kinds of request directives: target tuning,
backend selection, and explicit acknowledgement of a named semantic difference. Check the exact directive
names, accepted values, and scope for the directed adapter before using the licensed binary.

An acknowledgement is not a performance knob. Do not add one merely to dismiss an error. See [tuning](https://docs.tensor9.com/cloud-adapter-early-access/tuning/overview.md).

## Agents connect evidence to operational work

Cloud Adapter includes [Support Agents](https://docs.tensor9.com/cloud-adapter-early-access/support/agents.md) for questions and investigations, and [Operations](https://docs.tensor9.com/cloud-adapter-early-access/operations/overview.md) for scoped tasks and coordination. A configured agent, an observed runtime instance and a model-processing route identify different things. None substitutes for permission to read a report, disclose customer evidence or change a native resource. See [Agents and Permissions](https://docs.tensor9.com/cloud-adapter-early-access/operations/agents.md).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.