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.
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.
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.
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.
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.
Field
Type
Req
claimantId
id
req
kind
enum
req
legalName
string
req
relationToInsured
enum: self | third_party | beneficiary
req
contact
ContactRef
opt
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).
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.
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.
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.
Field
Type
Req
submissionId
id
req
brokerRef
Ref<Broker>
opt
insuredRef
Ref<Insured>
opt
productCode
string
req
lineOfBusiness
string
req
requestedEffective
date
req
exposureSummary
ExposureSummary
opt
status
enum: open | quoted | declined | referred | closed
ontology · uwA carrier-side priced response to a Submission. Bound by the issuing underwriter’s authority. Either binds (becoming a Policy) or expires.
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.
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.
Field
Type
Req
pricingId
id
req
quoteRef
Ref<Quote>
req
baseRate
Money
req
factors
map<factor, multiplier>
opt
surcharges
map<label, amount>
opt
taxes
map<jurisdiction, amount>
opt
finalPremium
Money
req
modelLineage
ModelLineage[]
opt
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.
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.
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).
Field
Type
Req
lossEventId
id
req
occurredAt
datetime
req
locationRef
LocationRef
opt
cause
string
opt
description
string
opt
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.
Field
Type
Req
exposureId
id
req
claimRef
Ref<Claim>
req
coverageRef
Ref<Coverage>
req
status
enum
req
reserveRefs
Ref<Reserve>[]
opt
paymentRefs
Ref<Payment>[]
opt
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.
Field
Type
Req
reserveId
id
req
exposureRef
Ref<Exposure>
req
kind
enum: indemnity | expense | recovery
req
amount
Money
req
estimator
EstimatorRef
req
asOf
datetime
req
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.
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.
Field
Type
Req
taskId
id
req
kind
string
req
subjectRef
Ref<any>
req
assigneeRef
PrincipalRef
opt
queue
string
req
dueAt
datetime
opt
status
enum: open | in_progress | blocked | done | cancelled
req
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.
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.
Field
Type
Req
documentId
id
req
contentHash
sha256
req
mediaType
mime
req
byteSize
int
req
pageCount
int
opt
language
bcp47
opt
ingestedAt
datetime
req
storageRef
StorageRef
req
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).
Field
Type
Req
threadId
id
req
subject
string
req
participants
EmailParty[]
req
messages
EmailMessage[]
req
attachmentRefs
Ref<Attachment>[]
opt
direction
enum: inbound | outbound
req
Attachment
ontology · evidenceA Document bound to an EmailThread (or a portal upload). Carries the parent thread reference, the part name, and content disposition.
Field
Type
Req
attachmentId
id
req
threadRef
Ref<EmailThread>
req
documentRef
Ref<Document>
req
partName
string
opt
disposition
string
opt
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.
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.
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.
Field
Type
Req
actionId
id
req
kind
string
req
targetSor
string
req
targetRef
Ref<any>
opt
payload
Json
req
idempotencyKey
string
req
state
enum
req
proposedBy
PrincipalRef
req
approvedBy
PrincipalRef
opt
committedAt
datetime
opt
compensatedBy
Ref<Action>
opt
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.
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).
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.
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).
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.