> ## 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.

# Deployment Topology & Tenancy

> Three primary topologies: tenant-private cloud, on-prem/hybrid, and sovereign cloud. Each preserves the same architectural contract. Multi-region federation via regional cells.

# 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

```mermaid theme={null}
flowchart TB
  subgraph T [Tenant private cloud]
    GW[Ingest gateway]
    DP[Data plane]
    ON[Ontology store]
    RT[Reasoning runtime]
    LP[Logic plane / tools]
    AC[Action plane]
    AD[(Audit chain)]
    TM[(Telemetry)]
  end
  subgraph M [Model gateway region]
    MR[Router]
    PR1[Provider A]
    PR2[Provider B]
    PR3[Tenant fine-tunes]
  end
  subgraph S [Tenant systems of record]
    SOR1[Policy admin]
    SOR2[Claims]
    SOR3[Billing/GL]
    SOR4[Document mgmt]
  end
  GW --> DP --> ON --> RT
  RT --> LP --> AC --> S
  RT --> MR
  MR --> PR1 & PR2 & PR3
  AD -.- GW & DP & RT & LP & AC
  TM -.- GW & DP & RT & LP & AC & MR
```

*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

```mermaid theme={null}
flowchart TB
  subgraph DC [On-prem datacentre]
    GW[Ingest gateway]
    DP[Data plane]
    ON[Ontology store]
    RT[Reasoning runtime]
    LP[Logic plane / tools]
    AC[Action plane]
    AD[(Audit chain)]
    OSS[Self-hosted OSS models]
  end
  subgraph CL [Tenant cloud / partner]
    BR[Bridge gateway]
    PROV[Approved provider endpoints]
  end
  subgraph S [On-prem systems of record]
    SOR1[Policy admin]
    SOR2[Claims]
    SOR3[Billing/GL]
  end
  GW --> DP --> ON --> RT
  RT --> LP --> AC --> S
  RT --> OSS
  RT -. egress allowlist .-> BR
  BR --> PROV
  AD -.- GW & DP & RT & LP & AC
```

*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.

```mermaid theme={null}
flowchart TB
  subgraph CG [Cross-region governance plane]
    CG1[Release pin registry]
    CG2[Drift signal aggregator]
    CG3[Incident roll-up]
    CG4[Kill-switch fan-out]
    CG5[Audit anchor mirror]
  end
  subgraph EU [Region cell — EU]
    EU1[Ingestion]
    EU2[Ontology]
    EU3[Runtime]
    EU4[Model gateway]
    EU5[Action plane]
    EU6[Audit + Telemetry]
  end
  subgraph US [Region cell — US]
    US1[Ingestion]
    US2[Ontology]
    US3[Runtime]
    US4[Model gateway]
    US5[Action plane]
    US6[Audit + Telemetry]
  end
  subgraph APAC [Region cell — APAC]
    AP1[Ingestion]
    AP2[Ontology]
    AP3[Runtime]
    AP4[Model gateway]
    AP5[Action plane]
    AP6[Audit + Telemetry]
  end
  CG -. release pins .-> EU
  CG -. release pins .-> US
  CG -. release pins .-> APAC
  EU -. drift / incident / audit anchor .-> CG
  US -. drift / incident / audit anchor .-> CG
  APAC -. drift / incident / audit anchor .-> CG
  CG -. kill switch fan-out .-> EU
  CG -. kill switch fan-out .-> US
  CG -. kill switch fan-out .-> APAC
  classDef cell fill:#fff,stroke:#111,color:#111;
  classDef gov fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111;
  class EU,US,APAC cell;
  class CG gov;
```

*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.

From the carrier's standpoint, the multi-region federation pattern is what makes
"global rollout" tractable: each new region is a new cell, configured to its
sovereignty profile, federated against the same governance plane — not a fresh
platform installation with bespoke integrations.