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.

​

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

​

3.4 Where principles are enforced

​

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

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.