Architecture · how a request stays sovereignThe plumbing the homepage omits

Arabic in, Arabic out — and the border in between.

The landing page shows the outcome; this page shows the mechanism. Every sovereign stage below runs on a verified GPU inside Saudi Arabia. The only stage that can cross a border is the frontier model, and only when a tenant explicitly turns it on.

01أ

Arabic in

The renter sends an Arabic prompt to api.dcp.sa/v1 — OpenAI-compatible.🇸🇦 KSA

02◇

Verified routing

The router picks a provider that just passed a live reachability + inference probe for the requested model — earned-online, never claimed-online.🇸🇦 KSA

03◆

Model runs in-Kingdom

An Arabic-first or open model executes on a verified Saudi GPU over the WireGuard mesh. Sovereign by default.🇸🇦 KSA

04🌐

Frontier (opt-in only)

A cross-border frontier model (e.g. DeepSeek) runs ONLY if the tenant explicitly enabled it — billed on a separate invoice line, logged distinctly.🌐 opt-in

05أ

Arabic out

The response returns to the renter. For sovereign requests, nothing left the Kingdom at any point.🇸🇦 KSA

06◷

Settled in SAR

Only successful inference is billed — atomic, idempotent, server-measured, in Saudi Riyal.🇸🇦 KSA

Why it's not just a translation pipeline

The translation steps are an internal convenience — your data and your model choice never leave the Kingdom for sovereign requests.

Arabic-first models (ALLaM-class) run natively. The optional Arabic↔English bridge exists only to let you reach the broader open-model catalog when you want it — it runs on the same in-Kingdom GPUs, not on a foreign service. Frontier cross-border models are the single exception, gated behind per-tenant opt-in and billed separately.

01in_kingdom_default

Sovereign requests touch only verified Saudi GPUs.

02frontier_opt_in

Cross-border models are off until a tenant turns them on.

03pdpl_audit_trail

Every route is logged for residency compliance.

Want the API details? The renter docs cover endpoints, auth, and billing.Read the docs →