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.JSON Schema · Insured
JSON Schema · Insured
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[].JSON Schema · Broker
JSON Schema · Broker
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[].JSON Schema · Policy
JSON Schema · Policy
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.
JSON Schema · EvidenceSpan
JSON Schema · EvidenceSpan
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.JSON Schema · Decision
JSON Schema · Decision
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).JSON Schema · AuditEvent
JSON Schema · AuditEvent
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.vinon Personal Auto Claims). - New relations: LOB-specific links (e.g.
Claim → Vesselon Marine). - New Decision / Action types: LOB-specific reasoning outputs and effect intents.
- LOB markings: e.g.
phi.highon Health,treaty.cededon 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.

