Documentation Index
Fetch the complete documentation index at: https://docs.uselayerup.com/llms.txt
Use this file to discover all available pages before exploring further.
19 — Deployment topology & tenancy.
Layerup runs in three primary topologies: tenant-private cloud, on-prem (or hybrid), and sovereign cloud. Each topology preserves the same architectural contract; differences are in where the substrate runs, where the data lives, and where the model endpoints sit.19.1 Private cloud topology
Fig. 19.1 — Private cloud topology. Substrate, audit chain, and tenant data live entirely inside the tenant’s cloud account.19.2 On-prem / hybrid topology
Fig. 19.2 — On-prem topology. Hybrid path is via a tightly scoped bridge gateway; egress is allowlisted by region and provider.19.3 Sovereign / regulated topology
For tenants subject to data-sovereignty constraints, the substrate runs in a sovereign cloud zone with no cross-zone egress. Models are restricted to in-zone providers, in-zone OSS hosts, or tenant-private fine-tunes. The Model Gateway’s region pin enforces this on every call.19.4 Tenancy isolation guarantees
- Tenant data is in tenant-owned storage; no shared object store across tenants.
- Tenant audit chains are separate; cross-tenant audit reads are impossible by routing.
- Tenant prompts, retrieval corpora, fine-tunes, evals are in tenant-owned stores.
- Substrate workers are tenant-pinned in private cloud; pooled only inside one tenant.
- Cross-tenant operator access requires purpose-tagged break-glass and is recorded on the affected tenant’s chain (§15.8).
19.5 BYOK
Customer-managed keys are the default for high-sensitivity tenants. Encryption keys originate in tenant HSM / KMS; the substrate uses them via standard envelope-encryption flows. Key rotation, key destruction, and key-level audit are tenant-controlled.19.6 Region pinning enforcement
Each tenant declares one or more regions; the substrate enforces region pinning at:- storage layer (object store and database region constraints),
- worker scheduler (workers run only in pinned regions),
- Model Gateway router (rejects cross-region routes per §12.6),
- egress allowlist (no outbound traffic outside pinned regions).
19.7 DR posture
Disaster recovery is per-tenant, with three classes:| Class | RPO | RTO | Pattern |
|---|---|---|---|
| Bronze | ≤ 24h | ≤ 24h | Daily snapshot · cold restore |
| Silver | ≤ 1h | ≤ 4h | Continuous replication · warm standby |
| Gold | ≤ 5m | ≤ 30m | Active-active · multi-zone in pinned region |
19.8 Egress allowlist
The substrate has no general egress. The only outbound paths are:- Approved provider endpoints (in pinned regions only).
- Tenant SoR adapters (tenant-supplied addresses).
- Tenant identity provider (SAML/OIDC).
- Tenant audit/telemetry collectors.
- Optional anchoring target for the audit chain (§17.2).
19.9 Configuration as data
Every deployment artefact — agent definitions, mappings, tools, prompts, models, policies — is versioned configuration data, not code. Promotion across environments is by content-hash promotion, not by re-build.19.10 Multi-region federation pattern
Global insurers run in many regions at once. The substrate’s deployment unit for that shape is the regional cell: a self-contained, region-pinned instance of every plane, federated by a thin cross-region governance plane that holds only metadata that must be shared (release versions, drift signals, incident rollups, audit anchors, kill-switch fan-out). Data, runs, and effects stay in their region. Fig. 19.10 — Multi-region federation. Three regional cells, each a complete substrate; one cross-region governance plane carrying only metadata. Data and runs never cross regions; governance signals do.What stays in the region
- Every byte of ingested signal (Documents, transcripts, EvidenceSpans, attachments).
- Every Ontology object instance and its lineage graph.
- Every AgentRun, Decision, Reasoning Trail, Action, AuditEvent.
- Every model endpoint call — routing is region-pinned (§12.6).
- Every retrieval index in the RAG Knowledge Base (§8.13).
- Per-region SLO measurements, drift sigma, error budgets.
What flows to the cross-region governance plane
- Release / version pins (which agent / tool / model / mapping versions are in use per cell).
- Drift signal summaries (sigma values; never the underlying samples).
- Incident roll-ups (typed incident IDs and severity; not the underlying data).
- Kill-switch fan-out (so a region or platform-scope kill propagates).
- Audit chain anchor mirrors (the public-anchor pointer; tenant chain stays in-region).
Sovereignty matrix
Each region cell can be configured per the carrier’s sovereignty requirements. The substrate’s contract is identical across configurations; the configuration domains differ.| Configuration | Hosting | Identity | Models | Audit anchor |
|---|---|---|---|---|
| Standard private cloud (per region) | Carrier VPC in region | Carrier IdP | Tier A / B / C | Region-local + optional public anchor |
| Sovereign cloud | Sovereign-cloud zone | Carrier IdP federated against sovereign IdP | Tier B / C only by default | Sovereign-cloud anchor |
| Air-gapped / on-prem | Carrier on-prem fleet | Carrier IdP | Tier B / C only | On-prem WORM + optional internal anchor |
| Regulated tenancy (e.g. financial, health) | Region-local with FIPS / FedRAMP profile | Carrier IdP + step-up | Tier-restricted by approval list | Region anchor + regulator export |
Per-region SLO & drift roll-up
- SLO measurements are emitted per cell; the governance plane shows a per-region dashboard, not a single global dashboard with hidden regional tails.
- Drift sigma is computed per cell against the cell’s own baseline and aggregated as a summary; aggregation never replaces per-cell signals for routing decisions.
- An incident in one cell does not page operators in another cell unless the cross-region governance plane raises a typed cross-region incident.
- Capacity planning is per cell; spillover between cells is not implicit and requires a tenant-approved config change.