Concepts overview
Start here. The Concepts section holds the architecture models behind Devotel Orbit — 246 pages in ten subgroups. This page exists to order them for you, so use the decision band below once and then read outward from the page it hands you.
Each subgroup below carries a scope note, the entry points readers ask
for most, and a single read this first marker. If you already know
the page name you need, skip to the
full page index at the bottom.
How to read a concept page
Concepts, guides, and API reference pages answer different questions. A concept page describes a model: the lifecycle states or planes the platform holds, who owns each stage, and which invariants you must not break — for example the DLR planes in the DLR model or the consent states in consent and suppression. You read one to predict what a product will do, not to operate it. Headings on a concept page follow a steady pattern: the model first, the states and transitions that drive it, then the boundaries where it meets the products you configure. Pages in the concept family — like Delivery lifecycle — all follow that pattern, so once you have read one you know how to read the rest.- Reach for a guide when you need to do a task step by step, and for the API reference when you need the exact contract: endpoint, fields, and response shapes.
- The subgroup listing starts with the foundational pages and ends with the specialized ones, so if you are new to a model, read its first two pages before the rest.
Which message-status page to open
Four concept pages describe the outbound-message status machine, and from their titles they read as overlapping. Without an index, a reader reconciling statuses reads all four to find the one rule they came for — so one page, the single message-status map, exists to say which page owns which question.
Open on the map page when you want the
per-status owner table and the reader-friendly digest of the transition
rules in one place rather than four pages. It also settles the sibling
questions that come up most: debugging one message lives on the
per-message route-trace timeline, the
legal-transition rules live on the DAG page,
SMPP vocabulary lives on send-side DLR, and
email’s channel-specific outcomes live on the email lifecycle
page. Treat the map as a reader’s index: resolve the status there, then
jump straight to the page that owns the answer you need.
The subgroup map with scope notes
- Concepts overview — the landing group: what UCaaS, CCaaS, and CPaaS are, and the models that span every vertical. This is where cross-cutting platform models live: the shared data model with its envelope, identifiers, and idempotency rules, the operator observability map, and the provisioning and test-mode lifecycle. It also holds the signature models for status and attestation — org-scoped status, SLA attestation — and the sync real-time state model. Read this first: UCaaS, CCaaS, and CPaaS.
- Messaging & Routing — the largest subgroup: how outbound and inbound messaging reach a channel, from sender resolution through routing, status, and receipts. The flagship chain runs from sender resolution and least-cost routing through the message status DAG, the map that reconciles it, and the DLR family: DLR and MO pipeline, send-side DLRs, and two-planes DLR semantics. The numbering side sits here too through number lookup, alongside the SMPP edge, fallback planes, and cascade cost rules. The inbound media threat scan quarantine gate covers the inbound-attachment trust boundary inside this subgroup. Entry points: Choosing a sender construct, Sender resolution, and Inbound message routing. Read this first: Choosing a sender construct.
- Voice & Telephony — how calls are made and handled, and how the numbering lifecycle stands behind them. The flagship models are the voice call lifecycle, the Jambonz softswitch, the ACD queue model, and the dialer pacing model. A numbering cluster covers purchase to release, porting, reuse and aging, and hosted messaging; recording pairs the capture pipeline with the retention lifecycle. Entry points: Voice call lifecycle, The ACD queue model, and Number status map. Read this first: Voice call lifecycle.
- Delivery & Schedulers — the lifecycle views of scheduled sends, async workers, and operational posture. The flagships are the delivery lifecycle (queued to delivered), the scheduled-sending model, and the scheduler fleet model — with the campaign allocator and the on-call escalation and capacity reservation models beside them. Entry points: Delivery lifecycle, The scheduled-sending model, and Outbound send gating. Read this first: The scheduled-sending model.
- Identity, Tenancy & Access — how tenants, subaccounts, authentication, roles, teams, and domains come together. The flagships are tenant isolation — the boundary every other model inherits — the authentication and session model, roles, teams, and permissions, and the subaccount organization model. The long tail covers operator/admin planes, API-key rotation, federation, seat quotas, custom fields and domains, and the pre-send risk verdict. Entry points: Tenant isolation, Authentication and session model, and Roles, teams, and permissions. Read this first: Tenant isolation.
- Billing & Wallet — wallets, credits, charges, usage records, and pricing-rate resolution. The flagships are wallets, credits, and charges, the usage records feed that becomes the billing ledger, and pricing and rate resolution — the per-operator attribution chain finished by the MCC/MNC override. Spend-alert and cost-rollup models sit alongside them. Entry points: Wallets, credits, and charges, Usage records, and Pricing and rate resolution. Read this first: Wallets, credits, and charges.
- CDP & Intelligence — the customer-data pipeline: events, accounts, identity resolution, segments, scoring, conversations, and analytics. The flagships are the CDP event model, identity resolution, and the scoring and segment recompute pipelines. Conversation reading surfaces — conversations, interactions, and conversation intelligence — sit beside session replay, recommendations, decisioning, and the analytics rollup models. Entry points: The CDP event model, Identity resolution, and Conversations. Read this first: The CDP event model.
- AI & Automation — the agent stack: architecture, run and presence lifecycles, knowledge, flow execution, MCP, and evals. The flagships are the AI agent architecture, the agent run lifecycle, the knowledge pipeline, and the flow execution model; the hosted MCP server and A2A federation models extend the same stack outward, with QA evals and predictive routing at the tail. Entry points: AI agent architecture, Agent run lifecycle, and The knowledge-base ingestion pipeline. Read this first: AI agent architecture.
- Compliance, Send Controls & Rates — every control here is tenant-owned: consent, suppression, quiet hours, TCPA guardrails, rate limiting, warming, templates, verification, and trust. The flagships are the consent and suppression model, the voice pre-send gate chain, the omnichannel compliance matrix, and the rate-limit and cooldown taxonomy. The WhatsApp set — template lifecycle, quality, flows, and business calling — covers the family of registration-and-health gates; verification and trust-score models close the subgroup. Entry points: Consent and suppression, Rate-limit and cooldown taxonomy, and Sender warming and reputation. Read this first: Consent and suppression.
- Webhooks & Platform Models — webhook delivery and fan-out, idempotency, notifications, and the shared models that cut across the surface — biometrics, caller verification, exports, and campaign lifecycle. The flagships are webhook delivery semantics and idempotency and safe retries: the pair every integration depends on. Around them sit the fan-out event-sink and notification models, short-link and public-pixel behavior, the export families, marketplace and campaign lifecycles, and the shared verification stack — voice biometrics and KBA caller verification. Entry points: Webhook delivery semantics, Idempotency and safe retries, and Webhook fan-out. Read this first: Webhook delivery semantics.
Choose your starting subgroup
Match the job you are doing to the subgroup that covers it, then open its read this first page.
Once you have the subgroup, work outward from its read this first page
to the scope paragraph above, then to the full index below.