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

# Ownership and continuity

> How Oximy approaches portability, provider independence, migration, and business continuity.

Your company does not fully control an AI system if it cannot inspect it, move it, export it, or continue operating without the vendor.

Oximy is designed around company ownership of the architecture that matters: data, context, workflows, provider relationships, routing policy, and the outputs people create.

<Info>
  Ownership includes an exit path. Oximy supports both assisted export and migration, even when a capability is not exposed as a self-service dashboard action.
</Info>

## Ownership by design

Company control should include:

* Data and activity history.
* Threads, artifacts, and reusable work.
* Memory and organizational context.
* Skills, agents, and workflow definitions.
* Provider accounts and model choices.
* Routing policies and evaluation history.
* Connector configuration and identity mappings.
* Audit records required for internal continuity.

## Model and provider independence

Oximy separates company context from the model that processes a request. Relay supports customer-selected providers and candidate models. Sidekick is designed to work across models and execution systems.

Changing a provider should not require abandoning the company’s accumulated workflows and knowledge.

## Export and migration

Customers can export the data and configuration represented across Oximy, including:

<AccordionGroup>
  <Accordion title="Visibility data" icon="eye" defaultOpen>
    Export activity, reports, organizational context, and identity mappings.
  </Accordion>

  <Accordion title="Sidekick work" icon="sparkles">
    Export threads, artifacts, memory, skills, agents, and workflows.
  </Accordion>

  <Accordion title="Relay configuration and history" icon="route">
    Export policies, router configuration, traffic history, and model evaluations.
  </Accordion>

  <Accordion title="Shared platform configuration" icon="layers">
    Export integrations, audit history, and shared platform configuration.
  </Accordion>
</AccordionGroup>

Not every export is currently exposed as a self-service dashboard action. Oximy supports assisted export and migration so access to company data is not limited by what is visible in the dashboard.

Provider credentials remain customer-controlled and can be reconnected to another architecture rather than transferred as readable secrets.

## Business continuity

<AccordionGroup>
  <Accordion title="Service disruption" icon="triangle-alert" defaultOpen>
    Continuity covers recovery, access to critical data and configuration during an incident, recovery objectives, and escalation paths.
  </Accordion>

  <Accordion title="Provider or model outage" icon="unplug">
    Business-critical workflows should have a fallback that does not depend on one model or provider.
  </Accordion>

  <Accordion title="Oximy unavailability" icon="cloud-off">
    Continuity planning defines which workflows continue, how critical data and configuration remain accessible, and how the customer operates through an Oximy service interruption.
  </Accordion>

  <Accordion title="Migration or termination" icon="move-right">
    Oximy supports transition beyond the normal subscription period when needed to preserve access to customer data, workflows, and the underlying provider architecture.
  </Accordion>
</AccordionGroup>

Where a workflow is business-critical, define a fallback that does not depend on a single model, provider, or Oximy service path.

Oximy supports both continued operation planning and transition assistance. The goal is not merely to hand over an archive, but to help the customer preserve access to its data, workflows, and underlying provider architecture during migration.

## Three kinds of commitment

Keep these forms of commitment explicit:

| Commitment             | What it means                                           |
| ---------------------- | ------------------------------------------------------- |
| Product guarantee      | Behavior implemented and testable in the product        |
| Operational commitment | A documented support, recovery, or transition procedure |
| Contractual commitment | An obligation stated in the customer agreement          |

This documentation describes the platform commitment. Exact export formats, retention periods, recovery objectives, support duration, and service levels are documented for the intended deployment and contract.