Data sovereignty & model routing
How the model router keeps a sovereign tenant's documents away from third-party model providers — and why where your ANALYTICS goes is a separate question with its own control.
The model router chooses a backend on two independent axes: the tier (quality vs. sovereignty — a data-residency decision) and the model class (reasoning vs. generation — a capability/cost decision, nudged by the Review Level).
| Tier × class | Backend → model |
|---|---|
| quality · reasoning | Anthropic → Claude Opus (adaptive thinking) |
| quality · generation | Anthropic → Claude Sonnet |
| sovereignty · reasoning | Ollama → local reasoning model (configurable) |
| sovereignty · generation | vLLM → DiffusionGemma (falls back to local reasoning) |
| vision / OCR (sovereign) | Local Gemma 4 (native multimodal) |
| fast open-weight (opt-in) | Cerebras → Gemma 4 (cloud, ultra-fast, BYOK-friendly) |
The sovereignty guarantee
A sovereignty-tier call NEVER touches a cloud provider. Misconfiguring a sovereign lane to point at a cloud backend throws at startup rather than leaking. Even OCR fails closed — a sovereign tenant's scanned pages are transcribed by a local vision model, never sent to cloud OCR.
Per-call token and cost metering is aggregated per review, and a per-review budget with a circuit breaker caps runaway spend. Promotion of local models into reasoning slots is gated on evaluation results, so quality is proven before it is trusted.
A guarantee about models is not a guarantee about analytics
Everything above is about where your documents are processed. There is a second question, and it has a different answer: where does LexCore's own operational data go — the product analytics that count how often a feature is used, and the error reports produced when something breaks?
Those carry no document text. They do carry your tenant identity, so an offshore analytics service would learn which firms use which features and how often. That is client-adjacent information leaving the jurisdiction, even though no contract does.
Two boundaries, set independently
You can choose cloud models under a data-processing agreement AND require that LexCore's own analytics and error reports never leave the country. They are separate controls. On an in-country deployment the analytics service is self-hosted inside your own network — no third party is engaged at all, so there is nothing to add to a sub-processor register.
This is enforced rather than promised. A telemetry or error-reporting destination outside the boundary makes the application refuse to start, rather than starting and quietly sending. It is checked before anything can be transmitted, and the behaviour is tested by deliberately pointing it at an external host and confirming the refusal.
Notification email is egress too, and it is the one most easily overlooked: matter notifications and deadline reminders carry matter subject lines and client addresses. LexCore can send them through a mail service self-hosted on your own infrastructure, so that traffic need not pass through a third-party sending platform at all — again removing an entry from the sub-processor register rather than documenting one.
Related technical documentation
Deployment modes: cloud, sovereign & hybrid
Same code, different data boundary. Choose where AI runs by tenant and by matter.
Bring Your Own Key & self-hosting
Use your own model provider account, or run the whole stack behind your own infrastructure.
Data privacy & the no-training policy
Your documents are never used to train public models, and Nigerian data-protection handling (NDPA 2023) is built into the platform.