Architecture

Cloud Adapter is a runtime translation layer between software that speaks an origin cloud API and the native services selected for its target environment. The request path stays inside your environment. The local Tensor9 CLI configures and operates that runtime, but does not proxy application traffic.

​

The request path

Each request crosses three adapter stages:

1. API endpoint. Your existing SDK, CLI or infrastructure tool sends an origin-shaped request to the configured Cloud Adapter endpoint.
2. Service adapter. The selected origin-to-backend mapping interprets the request and translates its supported behavior.
3. Target client. Cloud Adapter calls the native target service using the backend identity configured for that mapping.

The response follows the reverse path. Cloud Adapter translates the target result into the origin API’s response shape. When emitted, diagnostic response headers can supply correlation identifiers or narrowly defined request-effect evidence. A cloud adapter is therefore composed of service adapters. Each service adapter owns one origin-service-to-backend mapping; the cloud adapter gives those mappings one operating boundary for a particular origin-to-target direction.

​

The operations path

The local Tensor9 CLI reads the installation’s configuration, validates changes and coordinates setup and updates. Configuration has two scopes:

• Cloud adapter configuration defines settings shared by the installation, such as its origin and target clouds, networking and deployment shape.
• Service adapter configuration selects a backend and supplies the settings needed for one service mapping.

Both scopes feed the runtime, but neither sits in the application request path. This separation lets the CLI stop after an operation while the adapters continue to serve traffic. See Configuration and Deployment. Cloud Adapter’s included agents extend this operational workflow. Support Agents investigate questions using permitted configuration and request evidence. Operations with Agents gives tasks an owner, tool scope, budget and verification record; War Rooms coordinate admitted participants and selected evidence. These activities remain separate from application request serving. Agent identity, native tool authority, model processing and evidence sharing each retain their own permissions.

​

Identity and trust boundaries

Cloud Adapter crosses distinct security boundaries. Treat them separately: An origin-shaped request does not inherit permission to the target service. Likewise, a target-cloud credential does not decide who may call the adapter. Apply least privilege independently at each boundary and keep provisioning credentials separate from runtime credentials.

​

Where state lives

Application data belongs to the selected target service. For example, an S3-to-Cloud Storage adapter stores objects in Cloud Storage; it does not keep a second object copy inside Cloud Adapter. Configuration is another durable input. Keep it under review and change control, because changing a backend can change data ownership and migration requirements even when the file remains syntactically valid.

​

How deployment mode changes the topology

Both modes use the same service implementations. What changes is where the serving runtime runs: A mode does not expand a service mapping’s operation coverage. The in-memory emulator is separate from both modes. See deployment modes for current availability and the pending local launcher. An investigator with the original request owner’s IAM credentials can use the signed SDK report retrieval flow against the published t9 endpoint and signing region. Decode the outer AWS JSON response’s body string to read the rendered report. This diagnostic read neither starts an adapter nor changes the original operation.

​

Observe a request

Use tensor9 explain to inspect the directed service profile without contacting a deployment. To preview one deployed request, send a normal IAM/SigV4-authenticated request to the synthetic AWS endpoint with a signed x-t9-explain control and explicit mode Explain. The completed preview returns a native ExplainedNotPerformed service error and a report ID; retrieve the explanation separately through the dedicated synthetic AWS t9 service, with SigV4 signing name t9 and its configured endpoint and region. During live diagnosis, combine the report with the adapter’s response headers, runtime logs and the resulting target-service state.