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

# Architecture

> How Oximy's shared platform connects Visibility, Relay, and Sidekick while preserving independent product boundaries.

Oximy separates observation, decision-making, and execution. This lets a company adopt one product without requiring Oximy to control every part of its AI stack.

## Platform layers

### Data sources

Oximy can receive data from first-party integrations, organization-managed endpoints, browser extensions, local collectors, model traffic, and product APIs. Each source has a different coverage and privacy profile.

### Shared control plane

The platform connects workspace identity, organization structure, access, policy, integrations, billing, audit history, and product configuration. It provides consistent context without collapsing all product data into one undifferentiated surface.

### Product services

* **Visibility** attributes activity, usage, spend, adoption, and risk.
* **Relay** evaluates and applies model-routing decisions.
* **Sidekick** manages collaborative threads, artifacts, memory, tools, and execution.

### Customer systems

Oximy connects to existing identity providers, model providers, gateways, SaaS tools, local environments, and cloud infrastructure. The architecture is designed to add control around these systems rather than require their replacement.

## The operating loop

```mermaid theme={null}
flowchart LR
    sources["Company AI activity"] --> visibility["Visibility<br/>See it"]
    visibility --> sidekick["Sidekick<br/>Run it"]
    sidekick --> relay["Relay<br/>Route it"]
    relay --> models["Customer-selected models"]
    sidekick --> visibility
    relay --> visibility
```

This product loop operates today. Visibility establishes what is happening.
Sidekick provides a governed place to perform work. Relay controls model
selection underneath that work and other model traffic. Resulting activity
returns to Visibility.

## Deployment models

<Tabs sync={false}>
  <Tab title="Oximy Cloud" icon="cloud">
    Oximy operates the control plane and data plane in Oximy Cloud. This is the simplest deployment when the customer does not require its data plane to run in its own environment.
  </Tab>

  <Tab title="Customer VPC" icon="server">
    Oximy runs in a customer-controlled virtual private cloud. This keeps the deployment inside infrastructure governed by the customer.
  </Tab>

  <Tab title="Hybrid" icon="cloud-cog">
    The Oximy control plane runs in Oximy Cloud while the data plane runs in the customer’s cloud. The customer retains control of the infrastructure that processes and stores its data while Oximy operates shared configuration and product management.
  </Tab>
</Tabs>

<Info>
  The hosting model changes the infrastructure boundary, not the product model. Visibility, Sidekick, Relay, and the shared platform capabilities remain available across the supported deployments.
</Info>

## Independent adoption

Each product has a useful standalone architecture:

* Visibility can observe activity without Relay or Sidekick.
* Relay can route traffic without Visibility or Sidekick.
* Sidekick can run with provider and harness choices selected by the customer.

Connections between products add context and automation, but they are not prerequisites for standalone use.

## Trust boundaries

The exact trust boundary depends on the selected deployment:

* An integration grants scoped access to a provider or application.
* An endpoint or browser component observes only configured sources.
* Relay can observe traffic, return a routing decision, or proxy the request.
* Sidekick can execute through local or cloud environments with different credential boundaries.

Document these boundaries during implementation. See [Data sources](/docs/platform/data-sources), [Security and privacy](/docs/platform/security-privacy), and [Deployment](/docs/platform/deployment).