Skip to main content

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.

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

Multi-region federation

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.

Multi-LOB ontology

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.

Multi-workflow runtime

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.

Multi-system orchestration

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.
DomainExample agent classesPrimary SoR adapters
ClaimsLoss-notice intake, severity triage, coverage adjudication, fraud signal review, subrogation candidate, payment readiness, reserve update, exception triageClaims platform, billing, document mgmt, partner registries, reinsurance
UnderwritingSubmission intake, appetite-fit triage, broker-of-record reconcile, risk classification, pricing draft, binding authority check, fac requirement checkPolicy admin, broker portal, partner data, ratings APIs, reinsurance treaty
ServicingEndorsement intake, mid-term change adjudication, billing inquiry, address / coverage change, document re-issue, customer correspondence draftingPolicy admin, billing, document mgmt, customer portal
Billing & FinancePremium reconciliation, payment exception, broker commission audit, refund / write-off draft, GL exception triage, treaty cession reconcileBilling, GL, treaty / reinsurance, broker registries
Compliance & RiskRegulator filing intake, sanctions / screening review, market-conduct review, regulatory exception triage, audit response draftingPolicy admin, claims, billing, document mgmt, regulator filings
DistributionBroker onboarding KYC, broker performance review, distribution audit, agency channel reconcile, partner-data qualityBroker / agent registries, partner APIs, billing
Risk EngineeringLoss-control survey intake, recommendation drafting, mitigation tracking, on-site report extraction, premium impact estimatePolicy admin, document mgmt, GIS / hazard data, reinsurance treaty
Reinsurance & TreatyCession determination, bordereau review, treaty exception triage, fac risk file drafting, retrocession reconcilePolicy 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. 
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.
PhaseScopeWhat ships
Phase 0 · Substrate stand-upOne 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 workflowOne 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 / LOBAdd a second workflow domain or a second LOB in the same region.Reuse of substrate planes demonstrated; marginal cost validated.
Phase 3 · Multi-regionStand up a second region cell; cross-region governance plane active.Multi-region federation pattern in production.
Phase 4 · Enterprise scaleN 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

DimensionDay oneYear three
Regions1 cellN cells, federated
LOBs1 ontology branchM branches on shared trunk
Workflows1 workflow domainMulti-domain (claims, UW, servicing, billing, compliance, distribution, risk eng, reinsurance)
AgentsFew agent classesMany agent classes, all under same governance
ToolsDomain-specific registryShared registry with domain-specific extensions
ModelsTier A primary, Tier B fallbackTier A / B / C mix per lane, customer-owned where justified
SoR adaptersCore systemsFull carrier stack including registries, reinsurance, BI
Audit / lineagePer-tenant chainPer-tenant chains, anchored, cross-region governance roll-up
Kill switchTenant scopeTenant + region + workflow + agent + tool granularities exercised
Operating costFront-loadedO(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.