> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # The tenant-owned compliance model: one page, every gate > The mental model every Orbit compliance page assumes you already hold — Orbit is the conduit and you own the gates, every control defaults open except the one platform-global federal dialing window that fails closed, and compliance-health scores are signals to read, never enforcement to rely on. # The tenant-owned compliance model Every page in the Compliance group — the [posture map](/compliance/posture-overview), the [posture FAQ](/compliance/posture-faq), the [per-topic FAQ](/compliance/topic-faq), and each deep guide — assumes the same mental model: **Orbit carries your traffic, but you carry the compliance decisions.** The platform is the conduit; the gates are yours. This page is the one-place anchor for that model so the deep pages can each get on with their topic instead of reasserting it. This page describes how Orbit's platform controls are structured. It is **not legal advice.** Which laws apply to your traffic, and what posture is adequate, depends on your jurisdiction, your recipients, and what you send. Confirm with qualified counsel. ## Why "tenant-owned" — Orbit is the conduit, you own the gates Orbit's role is deliberately narrow: it routes your messages and calls and **executes the gates you set**. The carve-out matters more than the mechanics. Opt-in lists, dialing windows, suppression scopes, residency choices, country blocks — each of those is a business decision whose correct answer differs per tenant, per use case, per jurisdiction. A platform that decided them for you would either be too strict (blocking traffic you lawfully could send) or too loose (exposing you to a liability priced against *your* business, not the platform's). So the platform ships the control surface and you set the posture. That is also the reason every gate is **tenant-formable**: every control in the map accepts the posture you configure for your account, and a different account in a different line of business takes a different posture through the same knobs. The enforcement machinery runs uniformly; the policy it enforces is yours. ## The sole platform-global hard rail: the federal dialing window There is exactly **one** control the platform owns outright, for all tenants, with no opt-out flag: the **US federal TCPA voice dialing window** — 8 AM–9 PM recipient-local for outbound calls to +1 recipients. Why this one has no tenant opt-out when everything else does: the statutory exposure on an out-of-window call is assessed per call against whatever platform the call went through, not against the tenant whose setting was wrong. Every other gate carries a risk of misconfiguration you are able to price yourself, so the control is yours to disable. The federal window carries a liability that is **not yours to waive**, so the control is not yours to disable. It is the only control on the platform with that posture — everything else below is tenant-owned and default-open. The deep reference for its window math, its fail-closed timezone behavior, and its error codes lives on the [TCPA federal voice guard](/concepts/tcpa-federal-voice-guard) page; this page just states where it sits in the model. ## Defaults-open semantics for everything else Every other compliance control — quiet hours, DNC and spam and consent checks, GDPR data-residency, country blocks, frequency caps, sender-ID country rules — ships **off** and stays off until you switch it on. Two consequences follow: * **Fail-open on infra trouble.** A gate whose risk is yours to price must not silently black-hole your outbound because an infra hiccup made your configuration unreadable. Tenant-owned gates resolve that trade to **allow** (a `skip` policy) by default. An unreadable timezone at your own quiet-hours gate lets the send through and logs it — it does not refuse. * **Fail-closed only where the platform owns the rail.** The federal dialing window is the one gate that resolves an unresolvable input to **refuse**. An unresolvable recipient timezone on a +1 voice send is blocked on that path even at 2 PM somewhere inside the nominal window — without a timezone, the platform can't prove the call sits inside the window, and the per-call penalty floor is too high to guess. That pair of defaults — fail-open for tenant-owned gates, fail-closed for the sole platform rail — is the whole semantics of the model. When you read the [posture map](/compliance/posture-overview) you're reading which toggle lives where and which default it takes; when you read the [posture FAQ](/compliance/posture-faq) or the [per-topic FAQ](/compliance/topic-faq) you're reading how that model answers a recurring operator question. ## A compliance-health score is a signal, not a gate The platform computes a rolling **compliance-health score** per tenant — a 0–100 rollup of the controls it can see you configuring and the send-time events your traffic raises. Read it as a **checking** instrument, not an enforcement one: a score never blocks, never permits, and never substitutes for a counsel-reviewed posture. It exists so "did I actually wire in the things I intend to have wired in?" has a number you can watch over time and alert on when it drops. The machinery — which controls feed the rollup, what the [dashboard tile](/compliance/compliance-health) reads back, and how to route a score drop — lives on its own page. The concept only states what kind of object it is: **indication**, never enforcement. ## Read the model, then the deep page Each assertion above points at the page that owns it — the model is the anchor; the deep pages carry the knobs, error codes, and runbook routes: * [Posture overview](/compliance/posture-overview) — the toggle map across every tenant-owned control, the five reference postures, and the couple of surfaces the platform does not let you toggle. * [Posture FAQ](/compliance/posture-faq) — the platform-level questions operators land on once they've read the map: why an enabled toggle may not be blocking yet, what defaults open, what fails open versus closed. * [Per-topic FAQ](/compliance/topic-faq) — the questions a compliance officer asks per regulatory lens: who owns the decision, how long the external approval takes, what to do when a trigger event lands. * [Trust Center evidence pack](/compliance/trust-center-evidence-pack) — how procurement reviews read that posture as evidence, and how to pre-build the binder before the questionnaire arrives. * [TCPA federal voice guard](/concepts/tcpa-federal-voice-guard) — the one rail that is *not* tenant-owned, in full: the window math, the error codes, the RMD prerequisite, and the state overlays. * [Compliance health scores](/compliance/compliance-health) — the score definition, the dashboard tile, and the vs enforcement caveat, in operational detail. The internal posture — the rules the platform's own builders hold themselves to when they add a gate — lives in the repository's `.claude/rules/compliance.md`; it isn't a customer surface and it changes on a different cadence than these docs. The customer-facing model is, in full: **you own the gates, one rail refuses, one rollup watches.**