Skip to main content

05 — The insurance ontology.

The Ontology is the canonical, version-controlled object model that every plane projects onto. It defines 28 objects across seven groups: Parties, Master data, Underwriting, Claims, Workflow, Evidence, and Governance. Every Property, Decision, Action and AuditEvent the platform produces is typed against the Ontology.

5.1 Object index

5.2 Object cards

Each object card defines: a one-line description, the field set (a subset; full schema in the Accordion), key links, default permissions, and the JSON Schema. Every field is implicitly accompanied by a provenance record.

Group A · Parties

Insured

ontology · party | marking: pii.medium | scope: tenantThe named insured / policyholder party on a Policy. May be an individual or organisation. Always content-addressed against an external party-master identifier where one exists.Links: policiesOf → Policy[], claimantOf → Claimant[].Permissions: read — insured.read; mutate — insured.write; PII fields require purpose underwriting.review or claims.adjustment.

Broker

ontology · party | marking: tenantThe distribution intermediary that placed a Submission or that is bound to a Policy. Typically also has BindingAuthority records on certain LOBs.Links: submissionsOf → Submission[], policiesOf → Policy[], bindingAuthorityOf → BindingAuthority[].

Claimant

ontology · party | marking: pii.mediumA party making a claim against a Policy. Distinct from the Insured: a third-party claimant on a liability coverage is not the policyholder.Links: claimsOf → Claim[].

Underwriter

ontology · party · internalA carrier-side decision principal authorised to bind, decline or refer Submissions within their scope. Has typed authority limits (line, jurisdiction, premium ceiling).Links: quotesAuthored → Quote[], decisionsAuthored → Decision[].

Adjuster

ontology · party · internalA carrier-side claims handler authorised to assess, reserve, settle or refer Claims within their scope. Authority is typed by line, severity band, and jurisdiction.Links: claimsAssigned → Claim[], decisionsAuthored → Decision[].

Group B · Master data

Policy

ontology · master | soR: policy adminAn insurance contract. The canonical record lives in the carrier’s policy administration system; Layerup’s Policy is a projection augmented with derived properties.Links: coverages → Coverage[], endorsements → Endorsement[], claims → Claim[].

Coverage

ontology · masterA typed risk-transfer scope on a Policy. Each Coverage has its own limits, deductibles, perils, and exclusions.Links: policy → Policy, exposures → Exposure[].

Endorsement

ontology · masterA mid-term contract amendment to a Policy or Coverage. Has its own effective date, change set, and approval lineage.Links: policy → Policy, approvedBy → Decision.

Group C · Underwriting

Submission

ontology · uwInbound risk presented by a Broker (or directly by a prospective Insured) for the carrier’s consideration. Drives the underwriting workflow until quoted, declined, or referred.Links: quotes → Quote[], riskAssessment → RiskAssessment, documents → Document[].

Quote

ontology · uwA carrier-side priced response to a Submission. Bound by the issuing underwriter’s authority. Either binds (becoming a Policy) or expires.Links: submission → Submission, boundPolicy → Policy?, pricing → Pricing.

RiskAssessment

ontology · uwA structured evaluation of an exposure: hazards, prior loss history, geography, regulatory class, model-derived scores, agent-derived recommendations, and underwriter sign-off where required.Links: subject → Submission|Endorsement, decision → Decision, evidence → EvidenceSpan[].

Pricing

ontology · uwThe premium calculation result for a Quote. Captures rating factors, base rates, modifiers, surcharges, taxes, and the model lineage of any non-deterministic rating step.

BindingAuthority

ontology · uwA delegated authority record granting a Broker (or carrier office) the right to bind risks within a defined scope on the carrier’s behalf. Has limits by line, jurisdiction, premium, and aggregate.

Group D · Claims

Claim

ontology · claims | soR: claimsA reported loss case against a Policy. Aggregates one or more LossEvents and one or more Exposures (per coverage). Long-horizon entity with its own state machine.Links: policy → Policy, lossEvent → LossEvent, exposures → Exposure[], reserves → Reserve[], payments → Payment[].

LossEvent

ontology · claimsThe real-world loss occurrence — the underlying fact a Claim is reporting. Distinct from the Claim because one event may produce multiple Claims (third-party, multi-policy, multi-jurisdiction).Links: claims → Claim[].

Exposure

ontology · claimsThe per-Coverage manifestation of a Claim. A single Claim against a Policy with three Coverages produces up to three Exposures, each reserved and settled independently.

Reserve

ontology · claims | soR: claims · ledgerA held estimate of expected payout against an Exposure. Reserves are typed (indemnity, expense, recovery), have an estimator (model, adjuster, agent), and are versioned over the life of the Claim.

Payment

ontology · claims | soR: billing · glA typed outflow against a Claim Exposure. Always settled through the carrier’s billing/GL system; Layerup records the intent, the approval, and the SoR confirmation.

Group E · Workflow

Task

ontology · workflowA unit of operator work. Tasks are routed to roles or named principals via queues and have SLAs. Tasks may be created by agents, by humans, or by policy.

Exception

ontology · workflowA typed deviation from the expected path that requires human or policy resolution. Examples: low-confidence extraction, integration unavailable, conflicting evidence, authority breach, schema mismatch.

Group F · Evidence

Document

ontology · evidenceA content-addressed file (PDF, image, spreadsheet, structured form). Always hashed; original bytes retained per retention policy. Ingest produces a Document; OCR / VLM / extraction produce derived properties that link back via EvidenceSpan.

EmailThread

ontology · evidenceAn inbound or outbound conversation thread. Holds participants, message order, and a set of bound Attachments. Drives many ingest paths (submissions, loss notices, endorsement requests).

Attachment

ontology · evidenceA Document bound to an EmailThread (or a portal upload). Carries the parent thread reference, the part name, and content disposition.

EvidenceSpan

ontology · evidenceA typed citation linking a derived property (or a Decision) back to the exact bytes that justify it. The substrate’s primary mechanism for evidentiary trace.

Group G · Governance

Decision

ontology · governance | first-class: coreA typed verdict produced by either an agent or a human reviewer against a typed input. Holds linked evidence, model lineage, rationale, and any consequent Actions. Decisions are immutable; corrections are new Decisions with a supersedes link.

Action

ontology · governance | first-class: coreA typed intent to mutate a system of record. Lives on the Action Plane (§14) with state machine proposed → staged → approved → committed → reverted/rejected/failed. Always carries an idempotency key.

AgentRun

ontology · governanceOne bounded execution of an agent against an input object. Has a unique runId, a scoped permission set, a token / wall-clock / cost budget, and a deterministic seed for replay.

AuditEvent

ontology · governance | hash-chain: tamper-evidentThe hash-chained record of every governance-relevant action in the platform: tool dispatches, decision commits, action commits, policy rulings, identity changes, configuration changes. The chain is anchored periodically (§17).

5.3 Marking inheritance & derivation

Markings (§4.2) propagate along derivations: any property derived from a source carries the union of the source’s markings unless the derivation explicitly de-classifies (and the de-classification is itself audited). EvidenceSpans inherit the marking of the underlying Document. Decisions inherit the union of all evidence markings.

5.4 Default permission set

5.5 Per-LOB ontology specialization

The 28 canonical objects defined above are line-of-business agnostic. Specific LOBs need additional fields, additional relationships, and LOB-specific Decision and Action types. Layerup models this as ontology branches (§6.3): the canonical trunk holds the cross-LOB shape; each LOB branch adds typed extensions that inherit from the trunk. This means a carrier deploying P&C, Specialty, and Life on the same Layerup instance does not negotiate a single super-schema; each branch is governed independently and replay still works against any branch version. Anatomy of a branch
  • Extends: which trunk objects the branch extends (e.g. Claim, Coverage).
  • New properties: LOB-specific typed fields (e.g. vehicle.vin on Personal Auto Claims).
  • New relations: LOB-specific links (e.g. Claim → Vessel on Marine).
  • New Decision / Action types: LOB-specific reasoning outputs and effect intents.
  • LOB markings: e.g. phi.high on Health, treaty.ceded on Reinsurance.
  • Pinned tools: per-LOB tool versions in the registry (§9).

Personal Auto

P&C / Personal — Extends Claim, Coverage, Exposure. Adds Vehicle (VIN, year/make/model, garaging), DriverInvolvement, PoliceReport, RepairFacility. Decision types: FastTrackEligibility, TotalLossDecision, SubrogationCandidate. Markings: pii.medium.

Homeowners

P&C / Personal — Extends Claim, Coverage, Exposure. Adds Property, Peril, Inspection, ContractorEstimate. Decision types: CoverageApplicability, CATAccumulation. Markings: pii.medium.

Commercial Property / Liability

Commercial — Extends Submission, Policy, Claim. Adds InsuredEntity, Location, OccupancyClass, SchedulesOfValues, BusinessInterruption. Decision types: UnderwritingDecision, ReservingTier. Branch governance is heavier (broker-mediated submissions).

Workers' Compensation

Casualty — Adds Employer, JurisdictionalRules, InjuryCode (ICD-10), WageStatement, MedicalProvider, RTWPlan (return-to-work). Decision types: CompensabilityDecision, IndemnityRate, IMETriggers. Markings: phi.medium, pii.medium.

Marine / Cargo / Hull

Specialty — Adds Vessel, Voyage, BillOfLading, SurveyorReport, HullParticulars, CargoManifest. Decision types: GeneralAverageDeclaration, SalvageCoverage, JettisonAdjudication. Often multi-jurisdictional.

Specialty / E&S

Specialty — Extends Submission, Quote, BindingAuthority. Adds BrokerOfRecord, RiskAppetiteRule, FacultativeReinsurance, SLAInsurer. Decision types: AppetiteFit, FacRequired, BindingAuthorityCheck.

Life

Life & Annuities — Adds InsuredLife, Beneficiary, RiderSchedule, UnderwritingClass, MedicalEvidence. Decision types: RiskClassification, BeneficiaryDispute, ContestabilityCheck. Markings: phi.high, pii.high.

Health

Health — Adds Member, ProviderNetwork, Authorization, EOB, ClaimLine (CPT / HCPCS). Decision types: MedicalNecessity, NetworkAdjudication, AppealDisposition. Heavy phi.high; HIPAA / HITECH governance applied at the marking level.

Reinsurance

Treaty — Adds Treaty, CededLayer, CessionStatement, BordereauLine, FacRiskFile. Decision types: CessionDetermination, ReportingTrigger, TreatyExceptionFlag. Often dual-tenant (cedant / reinsurer).
An LOB branch is a typed extension of the trunk, not a fork. Branches inherit trunk versioning, lineage, audit, and governance. Cross-branch operations (e.g. a Commercial Property claim that triggers Reinsurance cession) traverse the trunk via the canonical objects both branches share. There is no “Marine instance” of Layerup separate from the “Auto instance” — there is one substrate, with branches.
From a global CTO standpoint, this is the property that matters: the cost of adding a new LOB is the cost of authoring that LOB’s branch and its tools, not the cost of standing up a new platform. Identity, ingestion, runtime, control, action, telemetry, audit, deployment topology, and SRE all carry over unchanged.