> ## 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. # Platform Topology > Layerup organised as eight horizontally cooperating planes plus three cross-cutting services. Each plane has a contract; planes communicate only across those contracts. # 03 — Platform topology — layered planes. Layerup is organised as eight horizontally cooperating planes, plus three cross-cutting services (Identity, Audit, Telemetry). Each plane has a contract; planes communicate only across those contracts. The diagram below is the canonical reference. ## 3.0 Reference platform stack Before zooming into the eight planes, here is the canonical end-to-end stack as a global CTO would draw it on a whiteboard. Six horizontal layers, each constructed from named components, anchored beneath the carrier's existing systems and above the customer experience surface. ```mermaid theme={null} flowchart TB subgraph EXP [User experience layer] EXP1[Customer mobile app] EXP2[Customer web portal] EXP3[Operator console] EXP4[Embedded surfaces] end subgraph WX [Workflow execution layer] WX1[Underwriting workflows] WX2[Claims workflows] WX3[Servicing workflows] WX4[Billing & finance workflows] WX5[Compliance & risk workflows] end subgraph ORCH [Orchestration & agent runtime] ORCH1[Orchestrator model] ORCH2[Specialist worker models] ORCH3[Reasoning trail] ORCH4[Tool registry] end subgraph DATA [Data abstraction & reasoning data] DATA1[Insurance ontology] DATA2[Lineage and replay] DATA3[RAG knowledge base] DATA4[Vector store] end subgraph INT [Multimodal ingestion & integration] INT1[Channel router] INT2[Agentic OCR] INT3[Voice transcription] INT4[Unified intake queue] INT5[SoR adapters] end subgraph CTRL [Compliance & control layer] CTRL1[Guardrail rules] CTRL2[PII and screening] CTRL3[QA model] CTRL4[Confidence scoring] CTRL5[Kill switch] end subgraph SOR [Carrier systems of record] SOR1[Policy admin] SOR2[Claims systems] SOR3[Billing / GL] SOR4[Document mgmt] SOR5[Partner registries] SOR6[Reinsurance & treaty] SOR7[BI / analytics] end EXP --> WX WX --> ORCH ORCH --> DATA ORCH --> INT DATA --- INT ORCH -.governed by.-> CTRL DATA -.governed by.-> CTRL INT -.governed by.-> CTRL WX -.governed by.-> CTRL INT --- SOR classDef layer fill:#fff,stroke:#111,stroke-width:1px,color:#111; classDef ctrl fill:#f4f4f2,stroke:#111,stroke-dasharray:3 3,color:#111; classDef edgesys fill:#fafafa,stroke:#111,stroke-width:1px,color:#111; class EXP,WX,ORCH,DATA,INT layer; class CTRL ctrl; class SOR edgesys; ``` *Fig. 3.0a — Reference platform stack. Six horizontal layers: experience, workflow execution, agent runtime, data abstraction, multimodal ingestion / integration, compliance & control. Layerup is everything *between* the user experience and the carrier's systems of record.* Three properties of this stack matter to a CTO: 1. **Layered, not monolithic.** Each layer has a contract; layers are swappable along their contract boundaries. A carrier can replace any one layer without re-platforming the others. 2. **Compliance is a layer, not a feature.** The Compliance & Control Layer (§15) sits across every other layer; nothing reaches a system of record without traversing it. 3. **The carrier's systems of record are the floor, not the inside.** Layerup orchestrates them; Layerup does not replace them (§2.7). ## 3.1 Layered planes — reference diagram For platform engineers, the same stack is more usefully drawn as eight cooperating planes plus three cross-cutting services. This is the canonical decomposition used throughout the rest of this documentation. ```mermaid theme={null} flowchart TB subgraph EX [Experience Plane] EX1[Operator console] EX2[Reviewer queues] EX3[Embedded surfaces] end subgraph RZ [Reasoning Plane] RZ1[Agent runtime] RZ2[Planner / Executor / Verifier] RZ3[Memory] end subgraph LG [Logic Plane] LG1[Tool registry] LG2[Tool contracts] LG3[Policy / rule packs] end subgraph ON [Ontology Plane] ON1[Object model] ON2[Property contracts] ON3[Versioning / branching] end subgraph DA [Data Plane] DA1[Ingest gateway] DA2[Mapping] DA3[Lineage / Replay] end subgraph MG [Model Gateway] MG1[Approved model registry] MG2[Routing / capability lanes] MG3[Eval & drift] end subgraph AC [Action Plane] AC1[Staging] AC2[Approval] AC3[Commit / Compensate] end subgraph SOR [External Systems of Record] SOR1[Policy admin] SOR2[Claims] SOR3[Billing / GL] SOR4[Document mgmt] SOR5[Registries / Partners] end subgraph X [Cross-cutting] X1[Identity] X2[Audit / Lineage] X3[Telemetry] end EX --> RZ RZ --> LG RZ --> MG LG --> ON LG --> AC DA --> ON ON --> RZ AC --> SOR DA --- SOR X1 -.-> EX X1 -.-> RZ X1 -.-> LG X1 -.-> AC X2 -.-> ON X2 -.-> AC X3 -.-> RZ X3 -.-> MG X3 -.-> AC classDef plane fill:#fff,stroke:#111,stroke-width:1px,color:#111; classDef cross fill:#f4f4f2,stroke:#111,stroke-dasharray:3 3,color:#111; class EX,RZ,LG,ON,DA,MG,AC,SOR plane; class X cross; ``` *Fig. 3.1 — The eight planes of Layerup plus three cross-cutting services. Solid edges are functional dependencies; dashed edges are cross-cutting services that observe or gate every plane.* ## 3.2 Per-plane responsibilities ### Experience plane Operator-facing surfaces and embedded components. Renders queues (review, approval, exception), object detail views with lineage, decision graphs, action stages, and model output diagnostics. Performs no side-effects directly; every effect is dispatched through the Action Plane. ### Reasoning plane The agent runtime: planner, executor, verifier, memory, scheduler, sandbox. Runs are queued, scoped, executed under permission and budget bounds, and produce a typed Decision plus zero or more proposed Actions. Detailed in §10–11. ### Logic plane The tool registry and tool contracts. Every capability the platform exposes — extraction, validation, lookup, classification, composition, action-staging, approval-request, aggregation, conversion, search — is a versioned tool with a typed signature. Detailed in §9. ### Ontology plane The canonical object model, its property contracts, its relationships, its markings, and its versioning. Every typed value in the platform — every Property, every Decision, every Action, every AuditEvent — is typed against this plane. Detailed in §5–6. ### Data plane Ingestion of structured, semi-structured and unstructured signal. Source mapping. Field-level provenance. Lineage graph construction. Content-addressable replay. Detailed in §7–8. ### Model gateway Vendor-neutral routing across reasoning, embedding, OCR and VLM lanes. Approved model registry. Capability-lane definitions. Region pinning. Eval and drift instrumentation. Detailed in §12–13. ### Action plane Effect lifecycle: *proposed → staged → approved → committed → reverted/rejected/failed*. Idempotency keys, compensation algebra, transactional vs flat-file paths, batch commit semantics. Detailed in §14. ### External systems of record Authoritative business systems the platform reads from and writes to: policy administration, claims, billing, GL, document management, partner registries, ledger. Layerup is system-of-record-agnostic; tenants pick which integrations to enable. ### Cross-cutting: Identity · Audit · Telemetry Identity (§15) controls every authenticated request; the audit chain (§17) records every decision, action and policy ruling; telemetry (§18) emits OTel-style spans for every plane. These three services are not optional and not pluggable — they are part of the substrate. ## 3.3 Contracts between planes | Source plane | Target plane | Contract type | | ------------------------- | ------------- | --------------------------------------------- | | Data → Ontology | Ontology | Typed object writes with provenance + lineage | | Ontology → Reasoning | Reasoning | Typed object reads + version pin | | Reasoning → Logic | Logic | Tool invocation under permission + audit | | Reasoning → Model Gateway | Model Gateway | Capability-lane request + budget + region pin | | Logic → Action | Action | Typed effect intent + idempotency key | | Action → SoR | External | Adapter-specific (transactional or flat-file) | | Any → Audit | Audit | Hash-chained AuditEvent emission | | Any → Telemetry | Telemetry | OTel span / metric / log emission | ## 3.4 Where principles are enforced | Principle (§2) | Enforced primarily in | | ------------------------------------- | --------------------------------- | | 2.1 Decision-centricity | Ontology, Reasoning, Audit | | 2.2 Det. effects / non-det. reasoning | Logic, Action | | 2.3 Governed agency | Identity, Logic (PDP), Reasoning | | 2.4 Pre-commit reality arbitration | Action | | 2.5 Immutability / replay | Data, Ontology, Audit | | 2.6 Ontology as contract | Ontology, every plane | | 2.7 No rip and replace | Data (mapping), Action (adapters) | | 2.8 Asset separation | Model Gateway | | 2.9 Tenant isolation | Identity, Data, Model Gateway | | 2.10 Failure as first-class | Telemetry, Action, Reasoning | ## 3.5 Layerup as the orchestration substrate A global CTO does not buy a platform unless they understand *where* in the stack it sits and *what it touches*. Layerup is the orchestration substrate that sits between the carrier's user experience surface and the carrier's systems of record. Every request that crosses from one to the other passes through Layerup, with typed contracts on both sides. ```mermaid theme={null} flowchart TB subgraph LEFT [Carrier surfaces] L1[Customer mobile / web] L2[Operator consoles] L3[Broker / agent portals] L4[Email / phone / chat / SMS] L5[Partner APIs] end subgraph CENTER [Layerup — Agentic AI OS] C1[Multimodal ingestion] C2[Insurance ontology] C3[Agent runtime] C4[Model fabric] C5[Compliance and control] C6[Action plane] C7[Audit and lineage] end subgraph RIGHT [Carrier systems of record] R1[Policy admin] R2[Claims platform] R3[Billing & GL] R4[Document mgmt] R5[Partner registries] R6[Reinsurance / treaty] R7[BI & analytics] R8[Identity / SSO] end L1 --> C1 L2 --> C3 L3 --> C1 L4 --> C1 L5 --> C1 C1 --> C2 C2 --> C3 C3 --> C4 C3 --> C6 C5 -.governs.-> C3 C5 -.governs.-> C6 C6 --> R1 C6 --> R2 C6 --> R3 C6 --> R4 C6 --> R5 C6 --> R6 C2 --> R7 R8 -.identity.-> C5 classDef sys fill:#fff,stroke:#111,stroke-width:1px,color:#111; classDef hub fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111; class LEFT,RIGHT sys; class CENTER hub; ``` *Fig. 3.5 — Layerup is the orchestration substrate between carrier-facing surfaces and the carrier's systems of record. Every business event funnels through ingestion, ontology, runtime, control, and action. Nothing reaches a system of record except through Layerup's typed effect contracts.* What this means in practice for the carrier: * **Carrier UX stays the carrier's.** Mobile apps, broker portals, operator consoles, IVR, email pipelines — all keep their existing surface area. They call Layerup over typed contracts; their UI is untouched. * **Carrier systems of record stay authoritative.** Policy admin, claims, billing, doc mgmt, registries, reinsurance — nothing is replaced. Layerup reads from them through typed Data Plane mappings (§7–8) and writes to them through typed Action Plane adapters (§14). * **One substrate, many workflows.** The same ingestion / ontology / runtime / control / action stack serves underwriting submissions, loss notices, endorsements, billing exceptions, fraud investigations, distribution audits, treaty ceding — every workflow is a configuration on the same plane. * **Identity is delegated, not duplicated.** SSO / IdP remains the carrier's. Layerup federates against it (§15.2) and never operates outside the carrier's identity perimeter. ## 3.7 Integration & extensibility plane The plane through which Layerup federates with everything the carrier already runs. Integration here means more than "connectors": it covers identity federation, system-of-record adapters, partner registries, observability bridges, model providers, and the carrier's own internal systems (BI, ML, data lake). The substrate is open along every edge it has. ```mermaid theme={null} flowchart TB subgraph CORE [Layerup core] K1[Ontology] K2[Agent runtime] K3[Model gateway] K4[Action plane] K5[Audit / Telemetry] end subgraph IDF [Identity federation] IDF1[SAML / OIDC IdP] IDF2[SCIM provisioning] IDF3[Service identity / mTLS] end subgraph SOR [System-of-record adapters] SOR1[Policy admin] SOR2[Claims platform] SOR3[Billing / GL] SOR4[Document mgmt] SOR5[Reinsurance / treaty] SOR6[Partner / registry APIs] end subgraph OBS [Observability bridges] OBS1[OTel collector] OBS2[SIEM / audit sink] OBS3[Cost / FinOps export] end subgraph MOD [Model providers] MOD1[Closed-source frontier] MOD2[Approved OSS] MOD3[Customer-owned models] MOD4[Custom embeddings / OCR / VLM] end subgraph DAT [Data & ML extension] DAT1[Data lake / warehouse] DAT2[Carrier ML platform] DAT3[Feature store] DAT4[BI tools] end IDF -.identity.-> CORE CORE -. egress allowlist .-> SOR SOR -. typed effects .-> CORE CORE -. spans / metrics .-> OBS CORE -. cap-lane requests .-> MOD CORE -. lineage exports .-> DAT DAT -. read-only feeds .-> CORE classDef edge fill:#fff,stroke:#111,stroke-width:1px,color:#111; classDef core fill:#fafafa,stroke:#111,stroke-width:1.5px,color:#111; class IDF,SOR,OBS,MOD,DAT edge; class CORE core; ``` *Fig. 3.7a — Integration & extensibility plane. Five edge categories: identity federation, system-of-record adapters, observability bridges, model providers, and data / ML extension. Layerup is open along every edge.* ### Edge categories | Edge | What it federates | Direction | Cross-ref | | --------------------- | ----------------------------------------------------------------------------------- | -------------- | ----------- | | Identity federation | SAML / OIDC IdP, SCIM provisioning, service identity (mTLS), break-glass | In | §15.2 | | SoR adapters | Policy admin, claims, billing/GL, doc mgmt, reinsurance, partners, registries | Bi-directional | §14.4 | | Observability bridges | OTel collector, SIEM, audit sink, FinOps / cost export | Out | §18.5 | | Model providers | Closed-source frontier, approved OSS, customer-owned, custom embeddings / OCR / VLM | Out | §12.2 | | Data & ML extension | Data lake, warehouse, feature store, carrier ML platform, BI tools | Bi-directional | §8.x, §17.6 | The substrate's principle along every edge: **typed contracts in, typed contracts out, governed by the Compliance & Control Layer in the middle.** No raw point-to-point coupling between agents and carrier systems is permitted; agents speak only to the platform's planes, and the planes speak to the carrier through these adapters.