> ## 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. # Enterprise Scale & Federation > For the global CTO: how the substrate operates across geography, LOB, workflow, and systems at enterprise scale — all on one substrate, with sub-linear marginal cost per addition. # 23 — Enterprise scale & federation. This section is for the global CTO who needs to underwrite scale before commitment. It answers four questions explicitly. **Across geography**: how does the substrate operate in many regions at once, with sovereignty and SLOs intact? **Across LOB**: how does it serve every line of business on the same substrate? **Across workflow**: how does it serve underwriting *and* claims *and* servicing *and* billing *and* compliance *and* distribution on the same runtime? **Across systems**: how does it orchestrate every system the carrier already runs without replacing any of them? ## 23.1 Federation reference The federation diagram below is the canonical picture of Layerup at enterprise scale: one substrate, four scaling axes, every workflow domain, every LOB, every region, every system of record, all governed by the same compliance & control surface and the same audit chain. ```mermaid theme={null} flowchart TB subgraph SUR [Carrier surfaces] SUR1[Customer mobile / web] SUR2[Operator consoles] SUR3[Broker and agent portals] SUR4[Email / chat / phone / SMS] SUR5[Partner APIs] end subgraph LU [Layerup substrate] subgraph WF [Workflow execution] WF1[Underwriting agents] WF2[Claims agents] WF3[Servicing agents] WF4[Billing and finance agents] WF5[Compliance and risk agents] WF6[Distribution and audit agents] WF7[Risk engineering agents] WF8[Reinsurance and treaty agents] end subgraph PL [Shared platform planes] PL1[Multimodal ingestion] PL2[Data abstraction and ontology] PL3[Agent runtime and reasoning] PL4[Model fabric] PL5[Action plane] PL6[Compliance and control] PL7[Audit and lineage] end WF1 --> PL WF2 --> PL WF3 --> PL WF4 --> PL WF5 --> PL WF6 --> PL WF7 --> PL WF8 --> PL end subgraph SOR [Carrier systems of record] SOR1[Policy admin] SOR2[Claims platform] SOR3[Billing / GL] SOR4[Document mgmt] SOR5[Partner registries] SOR6[Reinsurance / treaty] SOR7[BI and analytics] end subgraph REG [Regions] REG1[EU cell] REG2[US cell] REG3[APAC cell] REG4[Sovereign / on-prem cell] end SUR --> LU LU --> SOR LU -. deployed across .-> REG classDef cell fill:#fff,stroke:#111,color:#111; classDef hub fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111; class SUR,SOR,REG cell; class LU,WF,PL hub; ``` *Fig. 23.1 — Layerup at enterprise scale. One substrate. Eight workflow domains. Seven shared planes. Every system of record. Every region. The four scaling axes (geo, LOB, workflow, system) all manifest on this one figure.* ## 23.2 Four scaling dimensions **Axis 1 · Geography** — Each new region is a new cell (§19.10). Same software, same ontology, same runtime, same control layer, configured to the region's sovereignty profile. Cross-region governance plane carries metadata only. New region cost ≈ provisioning + config. Not platform redevelopment. **Axis 2 · Line of business** — LOB-specific extensions live as branches off the canonical Ontology trunk (§5.5). Personal Auto, Homeowners, Commercial Property, Workers' Comp, Marine, Specialty / E\&S, Life, Health, Reinsurance — all on the same 28-object trunk. New LOB cost ≈ branch authoring + LOB-specific tools. Not platform redevelopment. **Axis 3 · Workflow** — The same Orchestrator + Specialist Worker + Reasoning Trail + Verifier loop (§10) serves every workflow domain. New workflow cost ≈ agent definition + tool registry * verifier rule pack. Not new runtime, not new model fabric, not new control layer. **Axis 4 · System** — Every carrier system of record is a SoR adapter (§14.4) inside the integration plane (§3.7). New system cost ≈ adapter authoring + mapping authoring + idempotency contract. Carrier systems are never replaced. ## 23.3 Workflow catalog by domain The substrate is workflow-domain-agnostic. Below is a non-exhaustive catalog of workflow domains the same Layerup substrate serves. Every entry runs the same ingestion, ontology, runtime, control, action, audit, telemetry stack — the only differences are the agent definitions, tool registries, verifier rule packs, and SoR adapters in use. | Domain | Example agent classes | Primary SoR adapters | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | **Claims** | Loss-notice intake, severity triage, coverage adjudication, fraud signal review, subrogation candidate, payment readiness, reserve update, exception triage | Claims platform, billing, document mgmt, partner registries, reinsurance | | **Underwriting** | Submission intake, appetite-fit triage, broker-of-record reconcile, risk classification, pricing draft, binding authority check, fac requirement check | Policy admin, broker portal, partner data, ratings APIs, reinsurance treaty | | **Servicing** | Endorsement intake, mid-term change adjudication, billing inquiry, address / coverage change, document re-issue, customer correspondence drafting | Policy admin, billing, document mgmt, customer portal | | **Billing & Finance** | Premium reconciliation, payment exception, broker commission audit, refund / write-off draft, GL exception triage, treaty cession reconcile | Billing, GL, treaty / reinsurance, broker registries | | **Compliance & Risk** | Regulator filing intake, sanctions / screening review, market-conduct review, regulatory exception triage, audit response drafting | Policy admin, claims, billing, document mgmt, regulator filings | | **Distribution** | Broker onboarding KYC, broker performance review, distribution audit, agency channel reconcile, partner-data quality | Broker / agent registries, partner APIs, billing | | **Risk Engineering** | Loss-control survey intake, recommendation drafting, mitigation tracking, on-site report extraction, premium impact estimate | Policy admin, document mgmt, GIS / hazard data, reinsurance treaty | | **Reinsurance & Treaty** | Cession determination, bordereau review, treaty exception triage, fac risk file drafting, retrocession reconcile | Policy admin, claims, treaty / reinsurance, broker / cedant registries | ## 23.4 Repeatability mathematics Why scaling on Layerup is sub-linear in cost: each new (region, LOB, workflow, system) tuple reuses the substrate's shared planes; only the configuration domains change. The substrate's marginal cost equation is below; concrete values are tenant-specific and not part of the architectural contract. ```text theme={null} cost(region_n+1) ≈ provisioning(cell) + config(region) // platform code is shared cost(LOB_n+1) ≈ branch_authoring + tool_pinning // ontology trunk is shared cost(workflow_n+1) ≈ agent_definition + verifier_rule_pack // runtime is shared cost(system_n+1) ≈ adapter_authoring + mapping_authoring // ingest / action shape is shared total = first_deployment + Σ(marginal costs) ≪ first_deployment × N for any nontrivial N ``` The carrier's first workflow is the most expensive; every subsequent workflow is materially cheaper because it reuses the substrate. The same property holds for new regions, new LOBs, and new SoR adapters. This is the property a global CTO is buying. ## 23.5 Indicative rollout shape A typical enterprise rollout follows a shape rather than a fixed schedule. Specific durations are tenant-dependent and not part of the architectural contract; the *shape* is. | Phase | Scope | What ships | | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | **Phase 0 · Substrate stand-up** | One region cell, identity federation, ingestion gateway, audit chain, model fabric Stage 1–6 for one capability lane. | Substrate ready for the first agent. | | **Phase 1 · First workflow** | One workflow in one LOB in one region. Full ontology branch, agents, tools, verifier, action adapters. | End-to-end production pattern proven. | | **Phase 2 · Adjacent workflow / LOB** | Add a second workflow domain or a second LOB in the same region. | Reuse of substrate planes demonstrated; marginal cost validated. | | **Phase 3 · Multi-region** | Stand up a second region cell; cross-region governance plane active. | Multi-region federation pattern in production. | | **Phase 4 · Enterprise scale** | N regions × M LOBs × K workflows; SoR adapter coverage across the carrier's stack. | Substrate operating as the carrier's AI work plane. | ## 23.6 Day one vs. year three | Dimension | Day one | Year three | | --------------- | ------------------------------- | ---------------------------------------------------------------------------------------------- | | Regions | 1 cell | N cells, federated | | LOBs | 1 ontology branch | M branches on shared trunk | | Workflows | 1 workflow domain | Multi-domain (claims, UW, servicing, billing, compliance, distribution, risk eng, reinsurance) | | Agents | Few agent classes | Many agent classes, all under same governance | | Tools | Domain-specific registry | Shared registry with domain-specific extensions | | Models | Tier A primary, Tier B fallback | Tier A / B / C mix per lane, customer-owned where justified | | SoR adapters | Core systems | Full carrier stack including registries, reinsurance, BI | | Audit / lineage | Per-tenant chain | Per-tenant chains, anchored, cross-region governance roll-up | | Kill switch | Tenant scope | Tenant + region + workflow + agent + tool granularities exercised | | Operating cost | Front-loaded | O(*configurations*); marginal cost per addition is small | Layerup's bet on year three is not "we will build more workflow tools." It is **"we will be the substrate your AI workflows live on, no matter how many you add, no matter what region they run in, no matter which systems they federate with."** Workflows are configurations on the substrate. The substrate is the product.