How to read this spec

Every question is tagged by what it forces you to model

This document is the third in the set: the competency-questions brief explains why to work this way, the insurance-workflows atlas catalogues what the workflows are, and this one lists the questions each must answer. Every CQ carries a pattern tag — the shape of model it demands. Read the tag and you already know which axioms you’ll need.

STATE “What stage is X in?” → a status vocabulary + time-indexed assignment.

ACTIVITY “Who did what, when?” → an activity with agent, time, in/outputs.

DERIVATION “What came from what?” → artifact lineage between records.

ANALYTICS “How many / how long / average?” → aggregation over the trace.

PLAN “Does this conform / what’s next?” → a process definition vs. its execution.

green — answerable from concepts already in the model (plus a status link) amber — needs new concepts; the dashed chips are what to build

New business & underwriting

The submission-to-issuance funnel.

STATE

What stage of the underwriting funnel is submission S in right now?

uw:Submissionuw:SubmissionStatusproc:hasStatus

DERIVATION

Which quotes were generated from submission S, and which one was bound?

uw:Quoteuw:quoteForSubmissionuw:Binder

ACTIVITY

Who underwrote submission S, and who approved the bind?

policy:Underwriteruw:BindingActivityproc:performedBy

STATE

Which submissions have been sitting at “quoted” for more than 30 days?

uw:SubmissionStatustime:DateTimeIntervalproc:StatusAssignment

ANALYTICS

What is the average elapsed time from submission to policy issuance, by line of business?

uw:IssuanceActivitypolicy:policyTypetime:

STATE

Which submissions were declined, and for what reason?

uw:Submissionuw:declineReason

Status: needs a new ins/underwriting module — the entities in the funnel (Submission, Quote, Binder) aren’t modelled yet. Reuses existing policy:Underwriter, policy:policyType, agreement:.

Policy servicing

Mid-term change: endorsement, cancellation, renewal, audit.

STATE

What is the status of policy P right now — in-force, cancelled, or non-renewed?

policy:Policypolicy:PolicyStatuspolicy:hasStatus

ACTIVITY

What endorsements have been applied to policy P, and on what effective dates?

policy:PolicyEndorsementpolicy:hasEndorsementagreement:hasTerm

STATE

Which policies are up for renewal in the next 30 days?

policy:PolicyTermagreement:hasTermtime:hasEnd

STATE

Was policy P cancelled flat, pro-rata, or short-rate, and what premium was returned?

claim:CancellationEventpolicy:cancellationBasiscoverage:Premium

ANALYTICS

What premium adjustment resulted from the audit of policy P?

uw:PremiumAuditcoverage:Premium

ACTIVITY

Who requested, and who approved, endorsement E?

policy:PolicyEndorsementproc:requestedByproc:approvedBy

Status: mostly answerable — the endorsement/cancellation/term structure already exists. Needs a policy:hasStatus link (the PolicyStatus orphan) + a cancellation basis.

Billing, collections & commission

Premium to cash, and producer pay-out.

STATE

What is the outstanding balance on policy P’s account?

biz:Accountbiz:balancecore:MoneyAmount

STATE

Which policies are in dunning or at risk of cancellation for non-payment?

biz:Invoicebiz:InvoiceStatustime:

ANALYTICS

What premium has been earned vs. written on policy P as of date D?

coverage:WrittenPremiumcoverage:EarnedPremiumtime:

ANALYTICS

What commission is owed to producer X for period Y?

policy:Producerbiz:Commissioncore:MoneyAmount

ACTIVITY

What payments have been received against invoice I, and when?

biz:Paymentbiz:Invoicetime:

Status: needs billing entities (Account, Invoice, Payment, Commission) in ins/business. Premium states (Written/EarnedPremium) already exist to build on.

Claims

FNOL to closure — the richest lifecycle, and the one with real seeds already in the model.

STATE

What is the current status of claim C?

claim:Claimclaim:ClaimStatusclaim:hasStatus

ANALYTICS

What is the total incurred amount on claim C, broken down by coverage?

claim:Claimclaim:incurredAmountcoverage:Coverage

STATE

Which open claims exceed their coverage limit?

claim:hasStatusclaim:incurredAmountcoverage:hasLimit

ACTIVITY

Who is the adjuster assigned to claim C?

claim:Claimclaim:Adjusterclaim:assignedTocore:hasRole

STATE

What is the case reserve on claim C, and how has it changed over time?

claim:CaseReservecore:MoneyAmountcore:ValueInTime

ANALYTICS

What is the average time from FNOL to closure, by peril?

claim:OpeningEventclaim:ClosingEventclaim:Loss

STATE

Which claims were reopened after closure, and why?

claim:ReopeningEventclaim:reopenReason

Status: lifecycle events already exist (Opening/Closing/Reopening). Close the flagged gap: claim:hasStatus + claim:incurredAmount.

One CQ, formalized — the STATE pattern in SPARQL

# "Which claims under policy PN-100 are currently open?"
PREFIX claim:  <https://data.chubb.com/ontology/ins/claim/>
PREFIX policy: <https://data.chubb.com/ontology/ins/policy/>

SELECT ?claim
WHERE {
  ?policy policy:policyNumber "PN-100" ;
          policy:hasClaim     ?claim .
  ?claim  claim:hasStatus     claim:Open .   # <-- claim:hasStatus is the piece to add
}

Reinsurance

Ceding risk — treaties, facultative placements, recoveries.

DERIVATION

Which reinsurance treaties cover policy P, or its line of business?

re:Treatyre:cedespolicy:Policy

ANALYTICS

What is the ceded premium on policy P under treaty T?

re:cededPremiumcoverage:Premium

DERIVATION

What reinsurance recoverable applies to claim C, and under which treaty?

re:Recoverableclaim:Claimre:Treaty

ANALYTICS

What is the carrier’s net retention on risk R after all cessions?

re:cededSharere:retentioncore:MoneyAmount

ACTIVITY

Was risk R placed facultatively, and with which reinsurer(s)?

re:FacultativePlacementre:Reinsurer

Status: a whole new ins/reinsurance module — but its agreements slot under agreement:Agreement.

Cross-cutting

Referral/authority, filing, onboarding, compliance — questions that span every workflow.

STATE

Which cases are currently awaiting an authority-referral decision?

proc:Referralproc:hasStatus

PLAN

Who holds the authority to approve a bind above a given amount?

proc:Authorityproc:authorityLimitcore:AgentInRole

STATE

Which product / rate filings are approved and effective in state ST?

uw:Filinguw:FilingStatuscore:Location

STATE

Is producer X appointed and licensed to sell line L in state ST?

policy:Producerbiz:Appointmentbiz:License

PLAN

Which cases went straight-through vs. required a manual referral?

proc:ProcessDefinitionproc:Referral

Status: the generic pieces (proc:Referral, proc:Authority) belong in one shared fnd/process module, reused everywhere.

From this spec to the ontology

What to do with these questions

These are not documentation — they are executable acceptance criteria. Each one becomes a cq:CompetencyQuestion individual in misc/ (with its question and, once written, its sparqlQuery), exactly as policy-cq.ttl already does for its first question.

Read the tags as a build plan

Count the tags in a workflow and you can see its cost. Mostly STATE? A status vocabulary and a time-indexed assignment covers it. Heavy on ACTIVITY and DERIVATION? You need the activity/provenance layer. Any PLAN question is the expensive one — only build the process-definition layer if a real CQ demands conformance.

The recommended path stays the same: start with Claims (D) — its lifecycle events already exist and only two properties (claim:hasStatus, claim:incurredAmount) stand between the current model and half these questions. Formalize those CQs as SPARQL against a little sample data, watch them go green, and the pattern is proven before you scale it to the other five workflows.