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

# Data sources

> The collection paths Oximy uses to build a source-agnostic view of company AI.

No single integration can describe all AI activity. Oximy combines complementary data sources so companies can choose the coverage and deployment model that fits their environment.

<AccordionGroup>
  <Accordion title="First-party integrations" icon="plug" defaultOpen>
    Provider and application integrations supply account, seat, usage, billing, and model data directly from supported systems. They are usually the fastest way to establish official usage and spend.

    Integration coverage reflects the APIs and permissions exposed by each provider.
  </Accordion>

  <Accordion title="Endpoint agent" icon="laptop">
    An organization-managed endpoint component attributes AI activity at the network layer without requiring application teams to add an SDK or modify every tool.

    Administrators control deployment, capture configuration, ignored sources, redaction, version policy, and device health.
  </Accordion>

  <Accordion title="Browser extension" icon="panel-top">
    The browser extension provides visibility into web-based AI activity. It complements endpoint collection when browser context or browser-specific deployment is important.
  </Accordion>

  <Accordion title="Local collector" icon="hard-drive">
    The collector reads configured local artifacts that are not fully represented in web or provider data, including coding sessions, local agent activity, skills, and MCP server usage.

    Organizations scope the local sources included in collection.
  </Accordion>

  <Accordion title="Relay traffic" icon="route">
    When Relay observes or handles a model request, it records routing, model, token, latency, cost, error, source, and conversation context according to the selected mode and workspace configuration.
  </Accordion>
</AccordionGroup>

## Conversation context

Visibility uses conversation content, not only traffic metadata. Content is required to understand what work is happening, connect activity to use cases, detect recurring patterns, and provide meaningful organizational context.

This makes the collection boundary important. Administrators choose the sources and deployment model, and should define access, redaction, retention, and data-plane requirements before rollout.

<Info>
  A domain name, model name, or token count can show that AI was used. Conversation context is what lets Visibility explain the work, identify recurring patterns, and connect activity to organizational decisions.
</Info>

## Choose sources by outcome

| Outcome                         | Typical sources                                      |
| ------------------------------- | ---------------------------------------------------- |
| Official licenses and spend     | First-party integrations                             |
| Shadow AI discovery             | Endpoint agent and browser extension                 |
| Local coding and agent activity | Local collector                                      |
| Model-level cost and routing    | Relay traffic                                        |
| Organization-wide attribution   | Multiple sources resolved through the identity graph |

The endpoint agent, browser extension, local collector, first-party integrations, and Relay traffic are separate sources. Organizations can combine them based on the coverage they need.