> ## 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 > Coordinate vendor, customer and Tensor9 responsibilities for service adapters in a BYOC deployment. 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. Tensor9 BYOC support helps software vendors investigate the service adapters running in their customers' environments. The vendor understands the application; the customer controls the environment and access; Tensor9 helps explain and investigate the adaptation between origin and target services. You do not need to establish fault before asking for help. This section describes service-adapter support and what its SLAs cover. It is not an availability promise for your entire application, the BYOC control plane or every resource in a customer appliance. Your signed agreement defines the coverage that applies. ## Know the exact service adapter A service adapter includes an origin and target service. DynamoDB to Firestore and DynamoDB to Spanner are different service adapters, even if the application uses the same AWS SDK for both deployments. Use the [BYOC service catalog](/byoc/service-adapters/catalog) to find the selected mapping and supported operations. Distinguish calls that pass through an adapter from native protocols and resources that are mapped without a runtime adapter. A fabric SLA does not cover a path that never enters that fabric. ## Who does what The vendor is Tensor9's customer for the BYOC product; the vendor's customer hosts the appliance. Agree on who owns each operational task before a production rollout. | Area | Software vendor | Hosting customer | Tensor9 | | ---------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | Application fit | Identify required operations and behavior; test each offered target mapping. | State environment, security and data constraints. | Explain mappings and documented trade-offs; help select an adapter. | | Target resource tuning | Determine workload needs and propose settings. | Approve budgets and customer-controlled changes; maintain native resource access. | Help interpret tuning controls and verify adapter behavior. | | Target service health | Observe application impact and correlate failures. | Observe native service health, quotas, permissions and resource capacity; coordinate the provider relationship. | Help separate target symptoms from adapter-caused failures. | | Adapter fabric | Maintain supported application requests and release context. | Maintain agreed infrastructure prerequisites and authorize access. | Investigate covered routing, authorization evaluation, translation, coordination and response behavior. | | Incident handling | Open and coordinate the case; provide sanitized request and release evidence. | Provide permitted target observations and approve live actions. | Investigate the supplied evidence and agree safe next steps. | | Data and recovery | Define application recovery and idempotency requirements. | Maintain the agreed target backup, retention and recovery arrangements. | Explain adapter semantics and investigate deviations from documented behavior. | The exact division between vendor and hosting customer may differ by contract. Record it explicitly; do not assume that owning a cloud account also makes its owner responsible for selecting the application's adapter or implementing the application's retry policy. ## The standard adapter support boundary The standard model covers the Tensor9 fabric between an origin request entering the covered adapter path and the origin-shaped response leaving it. That path can include substantial work before a target call, between several calls and after the target responds. Native target processing is a separate dependency. The adapter's latency and availability commitments do not replace Google Cloud, Microsoft Azure or another provider's terms. They also do not become an end-to-end application SLA. See [Service Levels](/byoc/support/service-levels). Do not classify an entire failed request as a provider issue merely because a native call occurred. An adapter can cause a bad target request, apply the wrong mapping or mishandle a valid response. Those are adapter issues to investigate. A native provider delay does not excuse unrelated Tensor9 processing delays on the same request. Support remains available when the boundary is unclear. Failure attribution determines how the applicable commitment is evaluated, not whether the vendor may report a problem. ## Example: one application, two customer environments An `orders-api` release uses DynamoDB. One customer runs it on Google Cloud with Spanner; another runs it on Azure with provisioned Cosmos DB. The vendor needs to validate conditional writes, query behavior and recovery for both directed mappings. The Spanner customer monitors the native database's capacity and query behavior. The Cosmos DB customer monitors RU consumption, throttling and partition distribution. The same application-level symptom can have different causes in the two environments. Tensor9 helps inspect the selected profile, interpret tuning and investigate what an adapter did. Evidence from one customer deployment does not establish the cause in the other. Keep the app release, appliance, adapter version, target mapping and time window with each report. Read the [DynamoDB to Spanner](/byoc/support/service-adapter-slas#dynamodb-spanner) and [DynamoDB to Cosmos DB](/byoc/support/service-adapter-slas#dynamodb-cosmosdb) terms alongside the [DynamoDB service reference](/byoc/service-adapters/aws/databases-storage/dynamodb). ## Scaling the fabric and the target An SLA-backed production fabric and a target database have distinct scaling limits. Adding target capacity does not remove every adapter bottleneck; adding adapter replicas does not remove target throttling or serialized work for a hot key. Define the supported workload by the origin operations your application completes, their sizes and feature modes, not only pod counts or target RPC rates. A batch API can generate many native calls, and a conditional update can require more adapter work than a simple read. The applicable agreement must identify the supported deployment, workload envelope and limits. A successful test-appliance request alone does not qualify production scale. See [Scaling and Limits](/byoc/support/scaling-and-limits) and the consolidated [service-adapter SLA tables](/byoc/support/service-adapter-slas). ## Work within the customer's access controls Use [Explain and diagnostic evidence](/byoc/service-adapters/debugging/overview) before requesting invasive access. BYOC uses the same service-adapter Explain protocol as Cloud Adapter; the customer does not need to install a separate product for an investigation. Customer approval, authorized report ownership and evidence-handling rules still apply. Opening a support case does not grant unrestricted access, authorize a write or allow customer data to leave the environment. Use the existing [operations security](/byoc/fundamentals/operations/security) and [break-glass](/byoc/fundamentals/break-glass) procedures when live access is needed. ## Coverage and contact Use your agreed support channel, or [contact Tensor9](https://www.tensor9.com/contact/). Your agreement defines response and escalation terms; no universal support response time is established here. If your application needs an arrangement extending beyond the standard adapter boundary, discuss it with Tensor9. Any additional scope must be agreed explicitly rather than inferred from the underlying cloud provider's SLA. [Getting Help](/byoc/support/getting-help) provides a step-by-step incident handoff for vendors and hosting customers.