⚠ An AI agent answering "What is our loss ratio?" can return 6 different numbers — all arithmetically correct, all semantically different. The ontology must encode which variant applies when, or the answer is always wrong.
IFRS 17 · Contractual Service Margin
Live Jan 2023 · Global (excl. US)
Three measurement models: BBA/GMM (default) · PAA (short-duration) · VFA (participating)
CSM is the unearned profit liability — released into revenue as Coverage Units are served
Requires assumption versioning: each reporting period the model must record current vs locked-in assumptions
Ontology need: ContractGroup, CSM, CoverageUnit, MeasurementModel entity
Lloyd's CDR · Core Data Record
Mandatory · Full risk lifecycle end-2026
Blueprint Two digital data standard for the London market; ACORD-aligned
Covers bind → endorsement → premium → claims → settlement in a single CDR
MRC (Market Reform Contract) data fields map 1-to-1 to ACORD entities
Ontology need: CDR as subclass of Policy, with UMR (Unique Market Reference) as identifier
Solvency II · XBRL Taxonomy
EIOPA 2.10.0 · Q1 2027
QRT (Quantitative Reporting Templates) map to OWL classes; each data point is a XBRL fact
UK diverged post-Brexit: Bank of England Insurance Taxonomy (BEIT) is the UK standard
SCR (Solvency Capital Requirement) entity relates to Net LR, Technical Provisions, Own Funds
Ontology need: SCR, MCR, TechnicalProvisions, OwnFunds entities with XBRL data point labels
ACORD · Information Model v2.9
Sep 2026 · Jul 2026 Virtual Party update
De facto insurance data standard — covers P&C, Life, Reinsurance, Surety
Jul 2026: Virtual Party entity added for AI agents and IoT devices as first-class parties
Member-gated access; Lloyd's CDR, Solvency II, and most insurtech APIs align to ACORD
Loss Ratio Agent
3 entities · 1 rule
"What was our attritional loss ratio for Property Q3 2026?"
Minimum Entities
Policy
Claim
EarnedPremium
LossRatioVariant
Decision Rules
Long-tail line detected → use Ultimate LR (include IBNR)
Cat flag on Claim → exclude from Attritional LR
EarnedPremium is prorated WrittenPremium; never use GWP directly
Pattern: Semantic layer SQL aggregation — no graph, no ML; variant selection as a Genie Page rule or Cortex YAML condition
Stack: Databricks: metric view with three named measures (
paid_lr,
incurred_lr,
ultimate_lr) + Genie Page sets governed default (long-tail → ultimate); Snowflake: Cortex Analyst YAML semantic model with equivalent measures
Hard part: EarnedPremium proration (WrittenPremium × days-in-force ÷ policy-term) — wrong here breaks every LR agent downstream; also never define a bare
loss_ratio measure — force the agent to choose a named variant
Reference: Viral M Desai · Live Databricks Genie insurance walkthrough (AY 2025 GL: 10.6% → 52.1%) ↗
✓ Sufficient because: no coverage structure or party data needed — just premium aggregation and claim classification. Three entities, one disambiguation rule.
FNOL Triage Agent
5 entities · 2 rules
"Is this claim covered under policy P-7821 and who handles it?"
Minimum Entities
Policy
Coverage
Peril
OccurrenceDate
Insured (Party)
Decision Rules
OccurrenceDate must fall within [InceptionDate, ExpiryDate] of Policy
Peril must exist in Coverage.IncludedPerils and NOT in Coverage.Exclusions
Route: if covered → assign adjuster; if borderline → SIU flag; if not covered → denial letter
Pattern: Structured policy lookup + rule matching; RAG over coverage wording PDF for exclusion detection
Stack: MCP tool wrapping Guidewire PolicyCenter or Duck Creek; vector store for coverage language (exclusions live in unstructured wording)
Hard part: Exclusions are in natural language in the policy wording — "flood damage caused by storm surge" may or may not be covered depending on exact wording; the agent must RAG the document, not just query the structured coverage table
✓ Sufficient because: no payment calculation is needed for triage — only policy/coverage matching and routing logic. No financial entities required.
Fraud Ring Detection Agent
4 entities · 1 rule
"Are claims C-1041, C-1098, C-1112 part of a coordinated pattern?"
Minimum Entities
Claimant (Party)
Claim
RepairShop / Provider
SharedIdentifier
Decision Rules
Shared Party (same TaxID, phone, or address) across ≥3 Claims in ≤90 days → fraud ring flag
Same RepairShop on ≥5 Claims in 30 days → provider fraud flag
ACORD Virtual Party (Jul 2026): AI agent itself is a Party — audit trail required
Pattern: Multi-hop graph traversal — the ONLY agent in this library that genuinely requires a graph database; SQL cannot efficiently traverse 3+ hops
Stack: GraphDB (SPARQL) or Neo4j (Cypher) for ring detection; GraphRAG over adjuster notes to surface soft signals (same narrative across claims)
Hard part: Entity resolution — the same claimant with two phone numbers appears as two nodes; an unresolved graph produces false negatives and the ring is invisible; resolve identities before inserting any node
✓ Sufficient because: ring detection is purely a graph connectivity problem. No premium, no coverage, no actuarial data needed — just shared identifiers and claim frequency.
Underwriting Triage Agent
4 entities · 1 checklist
"Does this submission have all the data to quote?"
Minimum Entities
RiskObject
CoverageRequested
LossHistory (5yr)
Broker
Decision Rules
Compare submission against Minimum Required Data (MRD) checklist for line of business
Missing loss runs → auto-request from Broker before routing to underwriter
Appetite check: if RiskObject.Class in DeclinedClasses → decline immediately
Pattern: LLM extraction from broker submission PDFs → structured checklist validation via SHACL MRD (Minimum Required Data) shape
Stack: Azure Document Intelligence or Databricks document parsing; SHACL shape as the MRD definition; broker portal API or email-to-structured pipeline
Hard part: Vocabulary variance — "Named Insured", "Policyholder", "Assured", "Cedant" all mean the same thing across different broker submission templates; the ontology synonym map (SKOS altLabels) must cover all of them or the gap check misfires
✓ Sufficient because: this is gap detection, not rating. The agent does not need to compute a premium — only verify data completeness and appetite. Four entities cover it.
IFRS 17 CSM Release Agent
4 entities · 2 rules
"What is the CSM release for Contract Group G-12 in Q3 2026?"
Minimum Entities
ContractGroup
CSM (opening balance)
CoverageUnit
ReportingPeriod
Decision Rules
Select MeasurementModel: PAA if contract duration ≤1yr OR claims occur evenly; else BBA
CSM release = (CoverageUnits in period / Total CoverageUnits remaining) × Opening CSM
Assumption change in period → split CSM movement into experience vs assumption variance
Pattern: Versioned actuarial calculation — the ontology must carry both locked-in (inception) and current (reporting date) assumptions as separate triples; IFRS 17 requires the split
Stack: Prophet/AXIS actuarial engine → results written as ontology KPIs; GitOps versioning of assumption sets so each reporting period's CSM can be audited and restated
Hard part: Assumption change attribution — when interest rates move, the CSM movement must split into "experience variance" vs "assumption change"; if the ontology conflates the two, the P&L note is wrong and the audit fails
✓ Sufficient because: CSM release is a pure accounting calculation. No claims data or pricing needed — only the group's balance, coverage unit allocation, and measurement model choice.
Renewal Churn Agent
4 entities · 3 signals
"Which motor policies renewing in Nov 2026 are flight risks?"
Minimum Entities
Policy
PremiumChange%
ClaimCount (3yr)
RenewalDate
Decision Rules
Premium increase >15% YoY → HIGH churn risk (price shock)
ClaimCount ≥2 in 3 years AND prior-year premium increase → MEDIUM risk (adverse risk perception)
Score = weighted sum; output: RETAIN (offer discount), MONITOR, or LET LAPSE
Pattern: ML gradient-boosting score surfaced as an ontology KPI (Tredence Step 5 pattern) — the model runs offline; the agent reads the score, not the model
Stack: Databricks MLflow (model training) + Feature Store (premium change, claim count features) → churn score written to ontology as PremiumRetentionScore; LangGraph for action routing
Hard part: PremiumChange% must compare against market rate, not just prior year — a 10% increase is fine if competitors raised 15%; without an external rate feed the signal fires false positives on every hard market renewal
✓ Sufficient because: churn prediction at renewal needs price sensitivity and claim history — not full claim details. A 4-entity model outperforms complex models on explainability and speed for this use case.
Reserve Adequacy Agent
5 entities · 2 methods
"Is the reserve for Accident Year 2023 Motor sufficient at Q3 2026?"
Minimum Entities
AccidentYear
PaidLoss
ReportedLoss
DevelopmentFactor
ExpectedLossRatio
Decision Rules
AY reported ≥60% developed → Chain Ladder (credible history dominates)
AY reported <60% developed → Bornhuetter-Ferguson (a priori ELR blended in)
IBNR = Ultimate (selected method) − Reported; compare to booked reserve
Pattern: Actuarial triangle time-series computation — development periods are a first-class dimension in the ontology, not just a column; each cell is a triple (AccidentYear, DevelopmentAge, CumulativePaid)
Stack: Python chainladder library or R ChainLadder package → results bound as ontology KPIs (UltimateEstimate, IBNR); actuarial sign-off gate before agent surfaces the number
Hard part: Tail factor selection for long-tail lines (WC, GL, Med Mal) — no deterministic answer exists; agent must flag "tail factor applied = 1.15 from industry benchmark" for actuary review, never decide autonomously; wrong tail = material reserve inadequacy
✓ Sufficient because: reserve triangulation only needs paid/reported losses by development period and an ELR for immature years. No policy, party, or coverage entity is required for the calculation.
Reinsurance Cession Agent
4 entities · 2 rules
"What ceded written premium should I report to Treaty T-42 for July 2026?"
Minimum Entities
Treaty (type, CessionPct, Retention, Limit)
PolicyCession
WrittenPremium
InceptionDate
Decision Rules
Quota Share: CededPremium = CessionPct × GrossPremium for all policies in treaty scope
Excess of Loss: CededPremium = RateOnLine × (Limit − Retention); no per-risk cession on premium
Validate: sum of ceded policies matches cession statement from reinsurer within ±0.1%
Pattern: LLM treaty term extraction + arithmetic validation; treaty wordings are unstructured PDFs; carve-backs and corridor definitions buried in 40-page documents
Stack: Nomad Data / V7 Go for treaty extraction → treaty terms as SHACL constraints on cession arithmetic; TCS BaNCS or SAP FS-RI as premium transaction source via R2RML
Hard part: Carve-backs — "losses arising from a single occurrence exceeding $50M" reduces the cession; one missed carve-back creates material leakage that only surfaces at settlement; every exclusion must be a named ontology rule, not just the headline cession rate
✓ Sufficient because: cession calculation on a quota share is purely arithmetic — treaty terms applied to premium. No claim, coverage, or actuarial data required at the cession statement stage.
Solvency II QRT Mapping Agent
5 entities · 1 mapping
"Map our internal model output to QRT S.05.01 for Q3 2026 reporting."
Minimum Entities
SCR (by module)
TechnicalProvisions
OwnFunds
XBRLDataPoint
ReportingTemplate
Decision Rules
Map each internal model output field → EIOPA XBRL taxonomy data point label (e.g., S.05.01.01.01)
UK firms: use Bank of England Insurance Taxonomy (BEIT), not EIOPA taxonomy
Validation: TechnicalProvisions (best estimate + RM) + OwnFunds ≥ SCR + MCR
Pattern: Ontology-to-XBRL crosswalk — EIOPA publishes the target ontology as an XBRL taxonomy; the agent maps internal model fields to taxonomy data point labels via R2RML
Stack: EIOPA XBRL taxonomy (or BEIT for UK) as the target ontology; Altova MapForce or custom R2RML for field mapping; GitOps to track taxonomy version changes (EIOPA releases annually)
Hard part: UK vs EU taxonomy divergence — same internal SCR field maps to different XBRL labels depending on whether the legal entity is FCA-regulated (BEIT) or EIOPA-regulated; a single-taxonomy agent used for a dual-jurisdiction group produces incorrect filings in one jurisdiction
✓ Sufficient because: QRT mapping is a translation task. The agent needs the internal value, its XBRL label, and the template cell. No pricing, claims, or actuarial model logic required.
Catastrophe Exposure Agent
5 entities · 1 model
"What is our total net insured value for hurricane peril in Florida for Q4 2026, and what is the 1-in-250-year PML?"
Minimum Entities
RiskObject (lat/lon, occupancy, construction)
Policy
Coverage (Peril)
TIV (Total Insured Value)
CatTreatyLoss (net XL)
Decision Rules
Gross TIV = sum of RiskObject.ReplacementValue for all risks where peril zone intersects hurricane zone and policy is in-force
Net TIV = Gross TIV × (1 − cat XL cession rate for layer containing this peril-zone aggregate)
PML at 1-in-250yr = external cat model output (RMS Miu / AIR Touchstone) bound as ontology KPI — not computed in the ontology
ACORD Virtual Party rule: if cat model is an AI agent, log it as a VirtualParty with a timestamped audit trail
Pattern: Geospatial aggregation + external catastrophe model API integration; the ontology anchors the exposure; the cat model is called externally and its output is written back as a KPI triple
Stack: Databricks with H3/Apache Sedona for geospatial polygon intersection; RMS Miu or AIR Touchstone API for PML; Iceberg as the exposure data lake shared across all cat model runs
Hard part: RiskObject geocoding — "123 High Street, Canary Wharf, London" must resolve to lat/lon before any peril zone lookup runs; bad geocode = wrong flood zone = wrong TIV = wrong PML; geocoding accuracy is the single largest driver of cat model error and must be validated as a SHACL constraint before the agent runs
✓ Sufficient because: cat exposure aggregation is purely a geospatial join on risk objects — no claims, no premium proration, no actuarial methods needed. The PML is consumed from the external model as a read-only KPI, not recomputed inside the ontology.