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.
The Agentic AI Operating System for Insurers.
Layerup is a decision-centric operating substrate that connects an insurer’s data, logic, models, action surfaces and security into a single governed plane on which agents and humans co-execute insurance work end-to-end. Existing policy, claims, billing and document systems remain systems of record. Layerup is the governed work-execution layer above them.| platform | Agentic AI OS |
| domain | Underwriting · Claims · Service |
| deployment | Private Cloud · On-Prem · Sovereign |
| posture | Governed Agency |
| version | v0.9 · technical architecture |
| audience | platform · security · ML · operations |
| last reviewed | May 2026 |
01 — What Layerup is.
Insurance operations are not a single-step automation problem. They are a multi-plane problem: heterogeneous evidence enters from many channels, has to be interpreted against a policy and a ruleset, projected onto a canonical object model, reasoned over by humans and agents, and ultimately turned into an action that mutates a system of record under audit. Layerup is the substrate that operates that loop.1.1 Definition
Layerup is a horizontal platform — not a vertical product — composed of seven integrated planes: an Ontology (canonical insurance object model), a Data Plane (ingest, mapping, lineage, replay), a Logic Plane (typed, versioned, idempotent tools), a Reasoning Plane (planner / executor / verifier / memory agent runtime), a Model Gateway (vendor-neutral routing across reasoning, embedding, OCR and VLM lanes), an Action Plane (proposed → staged → approved → committed effects), and a cross-cutting Identity, Audit and Telemetry plane. Every signal that enters the platform produces a typed object, every interpretation produces a versioned Decision, and every effect that leaves the platform is a typed, idempotent Action with a chain of evidence behind it.1.2 Why insurance ops AI is a multi-plane problem
Insurance work is the canonical example of a domain in which intelligence cannot be separated from data, logic, action and security. A submission, a claim, a renewal, an endorsement — none of these are answerable from a model alone. They require:Many channels, many shapes
Heterogeneous signal — Email, attachments, scanned forms, broker portals, telematics, third-party registries, partner APIs, batch files, internal core systems. Signal arrives unstructured, semi-structured, and structured — at different latencies and confidences.
No interpretation without contract
Policy-bound interpretation — A loss notice, a quote, an endorsement — none can be interpreted without the policy contract, the ruleset, the jurisdiction, and the operator’s tribal knowledge. Semantics are not free-form; they are policy-bound.
Decisions must commit
Effects on systems of record — An interpretation only matters when it produces a typed effect on a system of record — a reserve, a payment, a draft loss notice, a referral, an endorsement, a note, an exception. Without commit, there is no value.
Every step must be replayable
Regulated audit trail — Insurers operate under regulator, reinsurer, broker and customer scrutiny. Every interpretation and every effect must be reconstructable end-to-end with evidence, model lineage, and reviewer attribution.
Neither pure automation nor pure assistance
Human-agent co-execution — Some steps run unattended; some require human approval; some require human decision. The platform must encode where the boundary sits per object, per action, per amount, per risk class — and enforce it.
Decisions outlive runs
Long-horizon state — A claim or submission is not a request/response. It is a long-horizon entity that accumulates evidence, decisions, exceptions and actions over weeks or months — across dozens of agent runs and many human reviewers.
1.3 The signal → outcome loop
Layerup operates a single closed loop on every insurance entity. Signal becomes interpretation; interpretation becomes a versioned decision; decision becomes a staged action; staged action becomes a committed effect; committed effect becomes an outcome that feeds back as new signal. Each transition is typed, governed and replayable. Fig. 1.1 — The signal-to-outcome loop. Every transition is typed, governed and replayable. The Learn back-edge feeds eval, drift detection, prompt & routing updates.1.4 System-of-intelligence, system-of-insight, system-of-action
Layerup unifies three traditionally separate planes of an enterprise stack:| Plane | Question it answers | Layerup expression |
|---|---|---|
| System of intelligence | What does this evidence mean? | Extraction, classification, retrieval, reasoning, verification — all gated through the Reasoning Plane and Model Gateway. |
| System of insight | What is going on across the book? | Lineage- and provenance-aware queries against the Ontology — every property has source, confidence, and version. |
| System of action | What should we do about it? | Typed, idempotent Actions on the Action Plane — proposed by agents, approved by policy or humans, committed to systems of record. |
1.5 The “systems of record stay” guardrail
Layerup is explicitly non-replacing. Existing policy administration, claims, billing, document, broker portal and ledger systems remain the source of truth for their domains. Layerup reads from them, projects them onto a canonical Ontology, reasons over them, and writes back through approved Action Plane paths. The platform is opinionated about the decision and action layer; it is deliberately neutral about the underlying systems of record.Where this documentation refers to a “system of record” it means any external authoritative system the platform is integrated with — policy administration, claims, billing, reinsurance, broker, registry, accounting, document management, analytics. Layerup is system-of-record-agnostic.
1.5b Layerup is a platform, not a workflow
For a global CTO or CIO evaluating where Layerup fits in their stack: this is not another workflow product, not another model API, and not another vendor app. Layerup is the operating substrate on which an insurer deploys AI agents that orchestrate every system the carrier already runs — policy administration, claims, billing, GL, document management, partner registries, distribution portals, reinsurance, analytics, BI, and the carrier’s own internal models. Workflows live on top of the substrate; the substrate does not live inside a workflow. Two things happen at once on the substrate, and both are first-class:- The platform orchestrates the carrier’s existing systems: it reads from and writes to every authoritative system through governed adapters, with field-level lineage, idempotent commits, and tamper-evident audit. Nothing is replaced.
- The platform deploys AI agents that execute insurance work end-to-end against those systems — agents that intake, reason, decide, and commit, all under the same governance plane.
Platform vs. workflow tool vs. model API
| Dimension | Workflow tool | Model API | Layerup (Agentic AI OS) |
|---|---|---|---|
| Unit of value | One process flow | One inference | One typed Decision and one typed Action across the enterprise |
| Data model | Per-process, ad hoc | None (caller’s responsibility) | Versioned Insurance Ontology (28 objects, §5) |
| Reasoning surface | Rules + connectors | One model call | Agent runtime with planner / executor / verifier / memory (§10–11) |
| Model strategy | Caller-owned | Vendor-locked | Vendor-neutral Model Gateway across closed-source, OSS, BYO (§12) |
| Effects | Procedural writes | None | Action Plane with idempotency & compensation (§14) |
| Governance | Per-flow checks | Caller’s problem | Compliance & Control Layer: PDP · markings · QA · kill switch (§15–17) |
| Audit | App logs | Provider logs | Tamper-evident hash-chained audit per tenant (§17) |
| Scale axis | Per-flow rebuild | Per-call | Federation: regions × LOBs × workflows × functions (§19, §23) |
| Replaces SoR? | Sometimes | No | Never (§2.7) |
| Operating cost | O(workflows) | O(calls) | O(configurations); marginal cost per new workflow approaches zero |
What scales without rebuild
On Layerup, six dimensions scale by configuration rather than by re-platforming. The substrate is the same in every cell; what changes are the configuration domains pinned to it.Multi-region federation
Geography — Regional cells with first-byte residency, region-pinned models, sovereign-cloud variants. New region ≈ new cell, not new platform. (§19, §23.2)
Multi-LOB ontology
Line of business — P&C, Specialty, Commercial, Life, Health, Workers’ Comp, Marine, Reinsurance. Same 28 canonical objects, LOB-specific extensions on ontology branches. (§5.x, §6.3)
Multi-workflow runtime
Workflow — Underwriting, Claims, Servicing, Billing, Compliance, Distribution, Risk Engineering, Reinsurance — all on the same agent runtime. (§10.6, §23.3)
Multi-function governance
Function — Operations, Compliance, Finance, Audit, Security, ML — each with their own scopes, markings and dashboards on the same substrate. (§15–18)
Multi-system orchestration
Integration — Policy admin, claims, billing, GL, doc mgmt, partner registries, reinsurance, distribution, analytics. New SoR ≈ new adapter, not new substrate. (§3.5)
Multi-provider model fabric
Models — Closed-source frontier, approved OSS, customer-owned fine-tunes — all routed through one gateway with one eval and one drift signal. (§12.2.2)
1.6 What this documentation covers
Sections 2–4 cover the architectural principles, the layered topology of the platform, and the vocabulary used throughout. Sections 5–6 specify the Insurance Ontology and how it evolves under version control. Sections 7–9 describe the Data and Logic planes. Sections 10–13 cover the Reasoning plane, Model Gateway, evaluation and drift. Section 14 specifies the Action plane lifecycle. Sections 15–17 cover identity, tool invocation governance, and the audit / lineage chain. Sections 18–21 cover operations: observability, deployment, reliability, and release governance. Section 23 specifies how the substrate scales across geography, line of business, workflow, and system. Section 24 is reference material.This is platform architecture documentation. It does not describe a specific workflow, a specific carrier, a specific line of business, or a specific integration. The same substrate is intended to operate across underwriting, claims and service workflows in any tenant.