# Keep telephony with the provider. Keep evidence in the operating loop.

> OpenOS governs campaign intent, consent, provider configuration, evidence, exceptions, and outcomes while the selected voice provider owns live delivery, media, retries, and concurrency.

## Key Specifications
- **Target Audience:** Voice operations, support leadership, and technology teams
- **Primary Inquiry:** How can voice enter SOI without OpenOS pretending to be the carrier?

## Core Architecture & Mechanism
### 1. Approve intent
Define the workflow or campaign, audience, consent basis, and required approval controls.

### 2. Preflight
Validate the configured provider deployment, credentials, and operational readiness.

### 3. Execute
The provider owns live calling, media, retries, and concurrency within its contract.

### 4. Reconcile
OpenOS records attempts, evidence, exceptions, normalized outcomes, and follow-through.

## Frequently Asked Questions
### Q: Does OpenOS carry the audio?
A: The preferred managed-provider contract keeps live media and delivery with the provider. Some legacy or controlled paths have different implementation boundaries, which are scoped explicitly.

### Q: Can we use our existing provider?
A: Potentially, through an available adapter or a scoped API/provider implementation. Availability is validated during the deployment design.

## Claim Boundaries
- OpenOS does not claim to replace the telephony or managed voice provider.
- Provider publication, credentials, consent, recording policy, and production acceptance are prerequisites.
- Advanced live transfer is not represented as universally available.

---
Canonical Reference: https://www.openost.com/channels/voice