> ## 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. # How Support Works > Understand the adapter support boundary, your target-service responsibilities and how to get help. These pages describe Tensor9's standard service levels. Your signed agreement determines the SLAs, covered adapters and operations, limits, remedies and support terms that apply to your deployment. Cloud Adapter support covers the service adapter between your application's origin API and its selected target service. Tensor9 helps you select that adapter, understand its behavior, tune supported settings and investigate requests. You do not need to prove which system is at fault before asking for help. A service adapter is a directed pair, such as S3 to Google Cloud Storage or DynamoDB to provisioned Cosmos DB. A commitment for one pair does not automatically apply to another backend, every operation of the origin service, or every deployment shape. ## The standard support model The standard model separates the Tensor9 request path from the native target service. Your application remains responsible for its workload and the target resources it uses; Tensor9 remains responsible for the adapter behavior covered by your agreement. | Area | Your responsibility | Tensor9's role | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Adapter selection | Identify the operations, consistency, ordering and recovery behavior your application needs. Validate the selected pair with representative requests. | Explain the available mappings, documented differences and suitable alternatives. | | Target tuning | Choose target resource settings, partitioning, indexes, capacity and budgets appropriate to the workload. Verify the resulting target resources. | Help interpret supported tuning controls and investigate whether the adapter applied them correctly. | | Adapter request path | Supply supported requests and maintain the agreed deployment prerequisites. | Investigate routing, authorization evaluation, translation, coordination and response handling. Apply the commitments for the covered deployment and operations. | | Native target service | Monitor target latency, throttling, permissions, quotas, availability and resource health. Manage your provider relationship. | Help correlate target observations with adapter evidence and determine where a problem arose. | | Customer-controlled infrastructure | Maintain the agreed network, identity, quota and resource permissions. Approve spending and access. | Identify the infrastructure conditions needed by the supported deployment and help investigate deviations. | | Incident evidence | Preserve request identifiers, time windows and sanitized context; authorize access or tests when required. | Work through the evidence with you, including cases where the cause is initially unknown. | A target capacity setting is not an adapter capacity setting. For example, a provisioned Cosmos DB container's RU/s maximum controls the target resource. It does not specify how many conditional DynamoDB updates the adapter can complete each second. See [Scaling and Limits](/cloud-adapter/support/scaling-and-limits). ## What the adapter boundary includes The boundary does not end permanently when the first target request is sent. An origin operation can require work before the target call, between several target calls and after the target responds. The adapter commitments cover Tensor9 processing in those stages: interpreting the origin request, evaluating authorization, translating operations, coordinating work and producing the origin-shaped response. Native target-service processing is a separate dependency. See [Service Levels](/cloud-adapter/support/service-levels) for measurement boundaries and attribution. A target error is not automatically outside Tensor9's responsibility. If an adapter defect constructed the wrong request, applied a tuning directive incorrectly or mishandled a valid response, the fact that a target service participated does not excuse the defect. Conversely, a correct translation cannot make a target quota increase or a native provider outage disappear. ## Example: S3 to Google Cloud Storage Suppose an application's `PutObject` requests become slow. Preserve a few request identifiers and compare the same time window across the application, adapter and Google Cloud Storage observations. * Slow request preparation or response handling belongs in the adapter investigation. * Native storage latency, target permissions and account quotas belong in the target investigation. * Retries, object sizes and client upload time can change the application's observed latency without representing the same change in adapter processing. Tensor9 can help investigate all three. The applicable SLA determines which measured part of the path is covered, not whether you may open a support request. Read the [S3 to GCS SLA example](/cloud-adapter/service-catalog/aws/databases-storage/s3#sla-s3-gcs) and [S3 tuning guide](/cloud-adapter/tuning/aws-s3). ## Example: DynamoDB to provisioned Cosmos DB For an `UpdateItem` workload on an `orders` table, record whether requests use conditions, the item sizes, key distribution and selected indexes. Those details affect the adapter's work and the native request load. Inspect the actual Cosmos DB container's RU consumption, throttling and partition distribution. An account-wide average can hide pressure on one partition. If the native resource needs more capacity or a different data layout, you own that choice with Tensor9's help. If the adapter introduces unexpected calls or does not honor documented behavior, that is an adapter issue to investigate. Do not assume that increasing either target RU/s or adapter replicas necessarily resolves both bottlenecks. Use the [DynamoDB to Cosmos DB SLA example](/cloud-adapter/service-catalog/aws/databases-storage/dynamodb-table#sla-dynamodb-cosmosdb), [trade-offs](/cloud-adapter/trade-offs/aws-dynamodb) and [tuning guide](/cloud-adapter/tuning/aws-dynamodb) together. ## Coverage follows your deployment and agreement An SLA-backed production deployment, a self-operated cluster and a local single binary have different operating boundaries. Starting the binary in a quickstart does not activate a production availability or scaling commitment. Check the deployment, exact operation set, workload limits, measurement window and remedies in your agreement. The [service-adapter SLA tables](/cloud-adapter/support/service-adapter-slas) bring the pair-specific terms together. API compatibility, a measured maximum operating rate, an availability objective and an incident response time are different statements. None should be inferred from another. If you need an arrangement extending beyond the standard adapter boundary, [contact Tensor9](https://www.tensor9.com/contact/) to discuss it. Any additional coverage must be defined in your agreement; it is not included by implication in the standard model. ## Ask for help Use your agreed support channel, or [contact Tensor9](https://www.tensor9.com/contact/). Include the business impact and the smallest useful evidence bundle. Response and escalation terms come from your support agreement; this article does not establish a universal response-time commitment. [Getting Help](/cloud-adapter/support/getting-help) walks through safe evidence collection with `tensor9 explain` and `x-t9-explain`.