Skip to main content
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.
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.

​
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:

Visibility data

Export activity, reports, organizational context, and identity mappings.
Export threads, artifacts, memory, skills, agents, and workflows.
Export policies, router configuration, traffic history, and model evaluations.
Export integrations, audit history, and shared platform configuration.
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

Service disruption

Continuity covers recovery, access to critical data and configuration during an incident, recovery objectives, and escalation paths.
Business-critical workflows should have a fallback that does not depend on one model or provider.
Continuity planning defines which workflows continue, how critical data and configuration remain accessible, and how the customer operates through an Oximy service interruption.
Oximy supports transition beyond the normal subscription period when needed to preserve access to customer data, workflows, and the underlying provider architecture.
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: 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.