Inferal Insurance Market Ontology

The Inferal Insurance Market Ontology is a sourced, jurisdiction-aware RDF model for buyers, intermediaries, carriers, placements, policies, representation, delegated actions, risk participation, risk transfer, and participant forms. It keeps contextual market roles separate from organizational classifications and keeps written capacity separate from the direction and amount of transferred risk. It enables data engineers, market analysts, and knowledge-graph teams to integrate buyer, broker, carrier, delegated-authority, and reinsurance records without erasing their context or evidence.

The key words MUST, MUST NOT, SHOULD, and MAY are to be interpreted as described in [[RFC2119]]. Normative statements apply to the following actors.

Publisher: Creates RDF assertions using this vocabulary. A publisher MUST preserve the identity and contextual boundaries described by each qualified resource and MUST attach the evidence required by the intrinsic shapes.
Conforming data graph: Contains instances that satisfy the base ontology's meaning and the intrinsic SHACL constraints when the base ontology and its imports are available for RDFS entailment.
Validator: Applies the intrinsic shapes to explicit and RDFS-entailed target classes. A validator MUST report SHACL violations; it does not determine whether a source assertion is factually true.
Consumer: Queries or combines conforming data. A consumer MUST preserve unknown and partial information and MUST NOT infer representation, authority, transferred share, or organizational form from a role label alone.

The RDFS vocabulary states open-world meaning. The optional OWL addendum types classes, properties, and named scheme resources but adds no equivalence, disjointness, functional properties, keys, or closure axioms. SHACL expresses intrinsic graph well-formedness under a closed-world validation operation. The query recipes in this specification are informative inspection behavior; they do not materialize new market facts. No inverse triples need to be materialized because this module defines no inverse properties.

A stricter application profile MAY require complete market rosters, shares that sum to one, source-specific identifiers, or closed action lists. Such a profile MUST identify its completeness boundary and MUST NOT present its local closure assumptions as base ontology entailments.

Introduction

Insurance records often turn a contextual label into a permanent party type. That fails when the same carrier leads one policy, follows another, fronts a third, and transfers only part of what it wrote. This ontology makes assignments, participations, transfers, authorities, and classifications explicit resources so that context, provenance, jurisdiction, dates, and confidence travel with each assertion.

The specification is intended for knowledge-graph publishers who merge broker, carrier, authority, and market records; ontology engineers who map operational standards; validators who enforce a portable graph contract; and analysts who need to distinguish incomplete evidence from a negative fact. It is deliberately role-first: a party remains the same resource while its assignments and capacity relationships change.

Design goals

Preserve the distinction between party identity and contextual market role.
Keep representation and delegated action explicit instead of deriving either from occupational labels.
Represent capacity written and retained independently from directional risk transfer.
Support multi-offering, multi-policy, and multi-jurisdiction records without arbitrary single-value limits.
Carry source, validity, and confidence on qualified assertions so conflicting records can coexist.
Remain extensible through open SKOS schemes without weakening scheme separation.

Scope and non-goals

The module covers contextual roles and representation, program placements with multiple offerings and policies, written and retained capacity, directional risk transfer, delegated insurance actions, and evidence-backed participant forms. Its identity boundary is an assertion-sized relationship: publishers mint separate assignments, participations, transfers, authorities, and classifications whenever context, represented party, parties, evidence, or validity differ.

This module does not:

model coverage clauses, limits, exclusions, deductibles, pricing, premium accounting, claim events, payments, reserves, solvency, or regulatory filings;
identify a canonical legal person or resolve mergers, aliases, branches, or corporate ownership;
assert that every policyholder is insured, that every broker represents the buyer, or that every managing general agent has authority;
infer a risk transfer from a difference between written and retained shares;
prove that an authority instrument is legally effective, that a classification is correct, or that the listed market is complete; or
provide a universal identifier scheme for policies, jurisdictions, organizations, or agreements.

Those concerns belong to imported identity vocabularies, line-of-business modules, explicit profiles, or mappings. Their absence is unknown or out of scope—not a negative assertion.

Competency questions

Which party plays which role, in what context, and whom does it represent?
Which parties are policyholder, insured, beneficiary, payer, or claimant?
Which offerings and policies form a placement program?
Who writes and retains capacity, and in which role?
Who transferred risk to whom, in what context, and with what known share?
Which actions may a grantee perform under the asserted authority?
Which participant form is asserted, and what evidence qualifies it?

Evidence map

Question	Answer pattern
Which party plays which role, in what context, and whom does it represent?	Role assignment roster, including optional represented party, jurisdiction, validity, source, and confidence.
Which parties are policyholder, insured, beneficiary, payer, or claimant?	Independent role assignments sharing a policy context; no identity collapse is required.
Which offerings and policies form a placement program?	All placement-offering and resulting-policy edges for the placement.
Who writes and retains capacity, and in which role?	Risk participations with optional written and retained shares.
Who transferred risk to whom, in what context, and with what known share?	Directional risk transfers; missing share remains unknown.
Which actions may a grantee perform?	Delegated authority with actions, instruments, jurisdictions, scope, dates, evidence, and confidence.
Which participant form is asserted?	Participant classification with source, jurisdiction, validity, and confidence.

The examples demonstrate each pattern. The operational query recipes return the role, participation, transfer, authority, and classification answers without treating absent optional values as false.

Namespace and dependencies

The preferred prefix is insm for https://ontology.inferal.com/modules/insurance-market/.

Dependency	Reused semantics	Boundary
Inferal Company Intelligence (`ci`)	Qualified relationships, sources, jurisdictions, validity dates, and confidence links.	This module does not redefine party identity, corporate structure, or source truth.
Inferal Commercial Intelligence (`cmi`)	Product and service offering foundation.	An insurance offering does not become a policy, placement, or coverage contract.
[[PROV-O]]	Activity and entity foundations for placements and policies.	PROV entity identity does not supply insurance-specific lifecycle rules.
[[SKOS-REFERENCE]]	Open concept schemes, grouping, and extension.	SKOS broader links organize values; they do not create class subsumption or party typing.

FIBO, ACORD, and openIDS are referenced rather than imported. Their nearby terms are useful mapping targets or sources, but none is adopted here as a complete replacement for the qualified role, authority, participation, and transfer contract. Mapping boundaries are discussed in the interoperability section.

Conceptual model

An insurance role assignment binds one party, one role from the role scheme, and one context. A risk participation separately records written and retained capacity. A risk transfer records direction from transferor to transferee, so fronting and reinsurance are not inferred from a generic participation percentage. A delegated authority requires an explicit action rather than relying on an occupational role label.

Policyholder, insured, beneficiary, payer, claimant, and applicant are independent roles. Organizational and regulatory forms use a different SKOS scheme. No equivalence or disjointness is inferred among parties from those labels.

Construct	Qualifies	Primary question	Does not imply
Role assignment	One party in one context	What role is played, and whom is represented?	Permanent party type, authority, organizational form, or risk share.
Risk participation	One party's capacity in one context	What was written and retained?	A counterparty or a transfer direction.
Risk transfer	Two distinct parties in one context	Who transferred risk to whom?	That either party wrote the policy or that the transferred share is complete.
Delegated authority	Grantor, grantee, and permitted actions	What may the grantee do?	That the action occurred or that the instrument is legally effective.
Participant classification	One party and one form concept	How is the participant organized or regulated?	A contextual role, license, solvency, or authority.

Identity and lifecycle

Qualified resources are not deduplicated merely because their principal parties and types match. Two brokers can represent the same buyer in different placements, and one broker can hold two assignments with different evidence or validity. A publisher SHOULD reuse a qualified resource IRI only when it intends one assertion identity and SHOULD mint a new resource when its context, parties, represented party, source interpretation, or validity boundary changes.

Policies are minimal anchors and may have several source-local identifiers. Matching identifier strings do not prove policy identity; different strings do not prove distinct policies. Placements are activities and may connect to many offerings and outcomes. Neither edge asserts that every offering was accepted or that every policy has the same coverage period.

Controlled dimensions and extension

Roles, participant forms, and insurance actions are three independent SKOS dimensions. Core role grouping concepts organize discovery but are still concepts, not OWL classes. Extensions MAY add concepts to the appropriate scheme and SHOULD relate refinements with SKOS broader or mapping relations. A concept from one dimension MUST NOT be substituted into another simply because its label is plausible.

Evidence, time, confidence, and jurisdiction

Qualified market assertions require one or more ci:source values. Source identifies the evidentiary basis, not an endorsement of truth. Optional validity dates bound when the assertion is intended to apply; they do not describe document publication time. Optional confidence assessments qualify evidence quality using the Confidence ontology and MUST NOT be interpreted as authorization or probability unless their declared scale supports that interpretation.

Jurisdiction is repeatable because a program, policy, role, transfer, or authority may span territories. Its presence identifies relevance, not licensing, domicile, governing law, or regulatory approval unless a separate vocabulary states that stronger relation.

Normative model

Roles and representation

Every role assignment MUST identify exactly one role player, one role concept, and one context. The role concept MUST be asserted as a SKOS concept in the insurance role scheme. A source is mandatory; jurisdictions, validity, confidence, and represented party are optional.

At most one represented party is permitted on one assignment because representation participates in that assignment's identity. If the same intermediary represents two parties, the publisher MUST create two assignments or use a more specific profile that defines a different relationship. Consumers MUST NOT infer represented party from Broker, Agent, Managing General Agent, or Coverholder labels.

Customer-side roles are independent. A single party may hold several, or each may be held by a different party. Their omission does not show that nobody holds the omitted role.

Placements, offerings, and policies

A placement represents the activity that seeks, negotiates, arranges, renews, or binds capacity. It MUST have a human-readable label and a source. It MAY point to multiple offerings and resulting policies. An offering is the marketed product or service; a policy is the resulting or contextual entity. These resources are not interchangeable.

A policy MUST have a label and source. Policy identifiers are repeatable source-local strings. Publishers SHOULD preserve the source that gives each string meaning and MUST NOT use an unqualified string alone as proof of global identity.

Risk participation and risk transfer

A risk participation MUST identify one participating party, one context, one role-scheme concept, and at least one source. Written and retained shares are optional decimals from zero through one. When both are present, retained share MUST NOT exceed written share.

Share absence means unknown, unreported, or inapplicable—not zero. The base contract does not require all participations for a context to sum to one because market views are often partial and roles such as cedent and reinsurer can describe different layers. A completeness profile may impose totals only after defining which participations belong in the same aggregation.

A risk transfer MUST identify exactly one transferor, one distinct transferee, one context, and at least one source. Transferred share is optional and bounded from zero through one when known. A consumer MUST NOT construct a transfer solely from writtenShare - retainedShare: that difference may reflect several transfers, commissions, limits, accounting treatments, or incomplete data.

Delegated authority

A delegated authority MUST identify exactly one grantor and one distinct grantee. It MUST name at least one action from the insurance action scheme, at least one evidence instrument, at least one jurisdiction, and at least one source. Multiple instruments and jurisdictions are allowed because a grant can be evidenced or effective across more than one resource or territory.

Authorized roles are optional supplemental context; actions are the operative controlled dimension. Free-text scope can record product, line, limit, function, or business boundaries not represented by this core vocabulary. A conforming authority graph establishes only that a source asserts the grant. It does not prove legal validity, licensing, occurrence of an action, or compliance with limits.

Participant classification

A classification MUST identify exactly one participant and one concept in the participant form scheme, with at least one source. Jurisdiction, validity, and confidence MAY qualify the claim. Form is evidence-bearing and time-sensitive; a role assignment MUST NOT be used as a shortcut for form, and a form MUST NOT be used as a role value.

The supplied forms are broad integration concepts. Their use does not assert a license, regulator determination, legal personality, ownership percentage, or eligibility to transact business. Publishers SHOULD use jurisdiction-specific classifications or mappings when those stronger conclusions are required.

Term reference

Classes

Insurance role assignment: A sourced contextual relationship assigning one role to one party.
Insurance placement: An activity seeking, negotiating, arranging, renewing, or binding insurance or reinsurance capacity.
Insurance policy: A minimal policy anchor for market relationships, not a coverage-clause model.
Insurance offering: An offering of insurance, reinsurance, placement, administration, or related capability.
Delegated authority: An evidence-bearing relationship granting specified insurance actions.
Risk participation: A party's contextual risk-capacity role with optional written and retained shares.
Risk transfer: A directional transfer of risk between distinct parties in an explicit context.
Participant classification: An evidence-bearing classification of a participant's organizational, regulatory, ownership, or market form.

Properties

Term	Definition and intrinsic constraint
role player	The party playing a role; exactly one per assignment.
role type	A concept in the insurance role scheme; exactly one per assignment.
role context	The resource bounding the assignment; exactly one.
represented party	The optional party represented by this assignment; at most one.
has jurisdiction	A reusable Company Intelligence jurisdiction; multiple values are permitted.
placement offering	An offering sought or arranged by a placement; multiple values are permitted.
resulting policy	A policy produced or renewed through a placement; multiple values are permitted.
policy identifier	A source-local identifier. Multiple values are permitted and global uniqueness is not implied.
authority grantor	The granting party; exactly one and different from the grantee.
authority grantee	The receiving party; exactly one.
authority instrument	A source that records authority; at least one.
authorized action	An action from the insurance action scheme; at least one.
authorized role	An optional supplemental role from the insurance role scheme.
authority scope	A human-readable product, line, territory, function, limit, or business boundary.
participating party	The party in a risk participation; exactly one.
participation context	The placement or policy bounding a risk participation; exactly one.
risk role	The role-scheme concept describing participation capacity; exactly one.
written share	An optional decimal in [0, 1] for the share written by the party.
retained share	An optional decimal in [0, 1], no greater than written share when both are known.
transferor	The party transferring risk; exactly one.
transferee	The distinct party accepting transferred risk; exactly one.
transfer context	The resource bounding a transfer; exactly one.
transferred share	An optional known decimal in [0, 1] transferred between the parties.
classified participant	The party being classified; exactly one.
participant form	A concept in the participant form scheme; exactly one.

Role vocabulary

Insurance role scheme is the open SKOS scheme accepted by role-valued properties.

customer-side role: Grouping concept for buyer- and benefit-side roles.
applicant role: Party requesting or applying for coverage.
policyholder role: Party holding a policy.
insured role: Party or interest treated as insured in context.
beneficiary role: Party designated to receive a policy benefit.
payer role: Party responsible for premium or another policy-related amount.
claimant role: Party making or pursuing a claim.
intermediary role: Grouping concept for intermediary and administrative roles.
broker role: Broking role whose represented party is explicit.
agent role: Agency role whose representation and authority are explicit.
managing general agent role: Contextual MGA role that does not itself grant authority.
coverholder role: Contextual coverholder role whose permission requires an authority assertion.
administrator role: Administrative role without implied risk capacity.
reinsurance intermediary role: Role arranging or advising on reinsurance placement or transfer.
risk participation role: Grouping concept for risk-capacity roles; transfers are modeled separately.
insurer role: Party accepting primary insurance risk.
reinsurer role: Party accepting transferred insurance risk.
cedent role: Party ceding risk in context.
fronting carrier role: Carrier supplying policy paper while transferring economic risk.
capacity provider role: General role supplying underwriting or risk capacity.
lead insurer role: Risk participant leading shared capacity.
following insurer role: Risk participant following the lead.

Participant forms

Insurance participant form scheme classifies form independently from contextual role.

stock insurer form: Shareholder-owned insurer form.
mutual insurer form: Mutual or policyholder-owned insurer form.
captive insurer form: Insurer formed primarily for related-party risks.
risk retention group form: Liability risk retention group under the applicable regime.
reciprocal exchange form: Reciprocal or inter-insurance exchange form.
Lloyd's syndicate form: Market form that does not assert legal personality.

Authorized actions

Insurance action scheme is the open SKOS scheme used by delegated authority.

quote action: Prepare or communicate a quotation.
underwrite action: Evaluate and select risk.
bind action: Commit coverage.
issue policy action: Issue policy documentation.
collect premium action: Collect premium or related amounts.
administer policy action: Administer a policy.
adjust claim action: Investigate, evaluate, or adjust a claim.
settle claim action: Agree or pay a claim settlement.

Validation regime

Target selection and ontology graph

Intrinsic node shapes target resources typed as each of the eight public classes. Validators SHOULD load the base ontology and its declared imports and apply RDFS entailment before target selection, so instances typed through a subclass remain reachable. The shapes are not closed: additional properties are allowed unless a stricter profile says otherwise.

Structural constraints

Assignments, participations, transfers, and classifications enforce their exact-one identity components.
Authority enforces exact-one grantor and grantee and minimum-one action, instrument, jurisdiction, and source.
Role, form, and action values are checked both as SKOS concepts and as members of the correct scheme.
Sources and authority instruments are checked as ci:Source; jurisdictions are checked as ci:Jurisdiction.
Shares are xsd:decimal values in the inclusive interval [0, 1].
Dates are xsd:date values, with at most one start and end per qualified resource.

Cross-node and arithmetic constraints

SPARQL constraints reject equal authority parties, equal transfer parties, retained share greater than written share, and a validity start later than its end. These checks compare terms inside one qualified resource. They do not reconcile totals across several records or decide whether two differently named parties are actually the same legal entity.

What conformance does not prove

SHACL conformance proves only that the selected graph satisfies this structural regime under the supplied ontology and entailment settings. It does not prove factual truth, legal effectiveness, source authority, roster completeness, policy identity, or that capacity totals reconcile. A graph with no transferred share can conform because the share may be unknown. A graph with only 60% known written capacity can conform because the remaining market may be absent from the publisher's view.

Entailment and non-entailment

RDFS subclass statements allow a reasoner to infer that assignments, participations, transfers, and authorities are Company Intelligence relationships; placements are PROV activities; policies and classifications are PROV entities; and insurance offerings are Commercial Intelligence offerings. Property domain and range statements also infer the corresponding subject or value type when a property is used.

The ontology intentionally does not entail:

party equality or inequality from labels, identifiers, or role combinations;
role membership from participant form, or form from role membership;
representation or delegated authority from an intermediary role;
a risk transfer, transferee, or transferred share from written and retained shares;
that broader SKOS role concepts are OWL superclasses of parties;
that known participations or transfers are exhaustive; or
that a SHACL-valid authority has been exercised or is legally enforceable.

The OWL addendum declares no functional or inverse-functional properties. Therefore repeated values do not cause identity merging, and maximum counts remain validation behavior rather than OWL equality consequences.

Operational query recipes

These informative queries illustrate how consumers can answer competency questions without fabricating missing values. They assume the graph has already been validated or that the consumer is prepared for duplicate and malformed rows. Optional columns remain unbound when the fact is absent.

Role and representation roster

This query returns one row per assignment, jurisdiction, and source combination. Multiple sources or jurisdictions can therefore produce multiple rows. An unbound represented party means it was not stated; it does not mean the player represents nobody.

# Question: Which parties play which roles, in what contexts, and whom do they represent?
# Assumptions: Assignments are explicit and the graph may be partial.
# Outputs: Assignment, context, player, role, optional qualifiers, and source.
# Missing data: Optional values remain unbound; absence does not mean false.
# Status: Informative inspection query; it does not infer representation.

PREFIX ci: <https://ontology.inferal.com/modules/company-intelligence/>
PREFIX insm: <https://ontology.inferal.com/modules/insurance-market/>

SELECT ?assignment ?context ?player ?role ?representedParty
       ?jurisdiction ?validFrom ?validThrough ?confidence ?source
WHERE {
  ?assignment a insm:InsuranceRoleAssignment ;
      insm:roleContext ?context ; insm:rolePlayer ?player ;
      insm:roleType ?role ; ci:source ?source .
  OPTIONAL { ?assignment insm:representedParty ?representedParty }
  OPTIONAL { ?assignment insm:jurisdiction ?jurisdiction }
  OPTIONAL { ?assignment ci:validFrom ?validFrom }
  OPTIONAL { ?assignment ci:validThrough ?validThrough }
  OPTIONAL { ?assignment ci:confidenceAssessment ?confidence }
}
ORDER BY ?context ?role ?player

Written, retained, and transferred risk

Participation and transfer are queried independently and combined only for presentation. The ?kind column prevents a consumer from mistaking transfer direction for a capacity role. Missing shares remain unbound. No arithmetic derivation is performed.

# Question: What capacity is written or retained, and what risk is transferred between parties?
# Assumptions: Participation and transfer are independent explicit records.
# Outputs: A typed row for each participation or transfer and its known shares.
# Missing data: Shares remain unbound and are never derived or treated as complete.
# Status: Informative inspection query; it performs no arithmetic reconciliation.

PREFIX ci: <https://ontology.inferal.com/modules/company-intelligence/>
PREFIX insm: <https://ontology.inferal.com/modules/insurance-market/>

SELECT ?kind ?record ?context ?party ?counterparty ?role
       ?writtenShare ?retainedShare ?transferredShare ?confidence ?source
WHERE {
  {
    BIND("participation" AS ?kind)
    ?record a insm:RiskParticipation ;
        insm:participationContext ?context ;
        insm:participatingParty ?party ; insm:riskRole ?role ;
        ci:source ?source .
    OPTIONAL { ?record insm:writtenShare ?writtenShare }
    OPTIONAL { ?record insm:retainedShare ?retainedShare }
  }
  UNION
  {
    BIND("transfer" AS ?kind)
    ?record a insm:RiskTransfer ; insm:transferContext ?context ;
        insm:transferor ?party ; insm:transferee ?counterparty ;
        ci:source ?source .
    OPTIONAL { ?record insm:transferredShare ?transferredShare }
  }
  OPTIONAL { ?record ci:confidenceAssessment ?confidence }
}
ORDER BY ?context ?kind ?party ?counterparty

Delegated action inspection

This query returns a row for each action, instrument, and jurisdiction combination. Authorized role is optional because actions carry the operative permission. The result is evidence for an asserted grant, not a legal authorization decision engine.

# Question: Which actions may a grantee perform, and what evidence qualifies the grant?
# Assumptions: The graph records an assertion, not a legal-effectiveness decision.
# Outputs: Grant parties, action, instrument, jurisdiction, optional qualifiers, and source.
# Missing data: Optional role, scope, dates, and confidence remain unbound.
# Status: Informative inspection query; it is not an access-control decision engine.

PREFIX ci: <https://ontology.inferal.com/modules/company-intelligence/>
PREFIX insm: <https://ontology.inferal.com/modules/insurance-market/>

SELECT ?authority ?grantor ?grantee ?action ?role ?instrument
       ?scope ?jurisdiction ?validFrom ?validThrough ?confidence ?source
WHERE {
  ?authority a insm:DelegatedAuthority ;
      insm:authorityGrantor ?grantor ; insm:authorityGrantee ?grantee ;
      insm:authorizedAction ?action ; insm:authorityInstrument ?instrument ;
      insm:jurisdiction ?jurisdiction ; ci:source ?source .
  OPTIONAL { ?authority insm:authorizedRole ?role }
  OPTIONAL { ?authority insm:authorityScope ?scope }
  OPTIONAL { ?authority ci:validFrom ?validFrom }
  OPTIONAL { ?authority ci:validThrough ?validThrough }
  OPTIONAL { ?authority ci:confidenceAssessment ?confidence }
}
ORDER BY ?authority ?action ?role

Examples

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:source a ci:Source .
ex:property a insm:InsuranceOffering ; rdfs:label "Property offering" ; ci:source ex:source .
ex:liability a insm:InsuranceOffering ; rdfs:label "Liability offering" ; ci:source ex:source .
ex:property-policy a insm:InsurancePolicy ; rdfs:label "Property policy" ; ci:source ex:source .
ex:liability-policy a insm:InsurancePolicy ; rdfs:label "Liability policy" ; ci:source ex:source .
ex:program a insm:InsurancePlacement ; rdfs:label "Program placement" ;
  insm:placementOffering ex:property, ex:liability ;
  insm:resultingPolicy ex:property-policy, ex:liability-policy ; ci:source ex:source .

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .

ex:source a ci:Source .
ex:assignment a insm:InsuranceRoleAssignment ;
  insm:rolePlayer ex:broker ; insm:roleType insm:BrokerRole ;
  insm:roleContext ex:placement ; insm:representedParty ex:buyer ;
  ci:source ex:source .

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .

ex:source a ci:Source . ex:instrument a ci:Source .
ex:wa a ci:Jurisdiction . ex:or a ci:Jurisdiction .
ex:authority a insm:DelegatedAuthority ;
  insm:authorityGrantor ex:carrier ; insm:authorityGrantee ex:mga ;
  insm:authorityInstrument ex:instrument ;
  insm:authorizedAction insm:QuoteAction, insm:BindAction ;
  insm:authorizedRole insm:ManagingGeneralAgentRole ;
  insm:jurisdiction ex:wa, ex:or ; ci:source ex:source .

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .

ex:source a ci:Source .
ex:fronting a insm:RiskParticipation ;
  insm:participatingParty ex:fronting-carrier ; insm:participationContext ex:policy ;
  insm:riskRole insm:FrontingCarrierRole ; insm:writtenShare 1.00 ;
  insm:retainedShare 0.05 ; ci:source ex:source .
ex:transfer a insm:RiskTransfer ; insm:transferor ex:fronting-carrier ;
  insm:transferee ex:reinsurer ; insm:transferContext ex:policy ;
  insm:transferredShare 0.95 ; ci:source ex:source .

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix conf: <https://ontology.inferal.com/modules/confidence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:register a ci:Source . ex:confidence a conf:ConfidenceAssessment .
ex:classification a insm:ParticipantClassification ;
  insm:classifiedParticipant ex:carrier ; insm:participantForm insm:MutualInsurerForm ;
  ci:validFrom "2026-01-01"^^xsd:date ; ci:confidenceAssessment ex:confidence ;
  ci:source ex:register .

This syntactically valid graph is rejected by the intrinsic role-assignment shape because a participant form is not a role concept.

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .

ex:source a ci:Source .
ex:bad a insm:InsuranceRoleAssignment ; insm:rolePlayer ex:carrier ;
  insm:roleType insm:MutualInsurerForm ; insm:roleContext ex:policy ;
  ci:source ex:source .

This graph conforms. Transfer direction and evidence are known, while the fractional share is absent and therefore remains unknown.

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .

ex:source a ci:Source .
ex:transfer a insm:RiskTransfer ;
  insm:transferor ex:cedent ; insm:transferee ex:reinsurer ;
  insm:transferContext ex:treaty ; ci:source ex:source .

Both resources are syntactically valid RDF but fail the intrinsic shapes. The participation retains more than it wrote, and the transfer names the same resource as transferor and transferee.

@prefix ci: <https://ontology.inferal.com/modules/company-intelligence/> .
@prefix ex: <https://example.com/insurance/> .
@prefix insm: <https://ontology.inferal.com/modules/insurance-market/> .

ex:source a ci:Source .
ex:bad-participation a insm:RiskParticipation ;
  insm:participatingParty ex:carrier ; insm:participationContext ex:policy ;
  insm:riskRole insm:InsurerRole ; insm:writtenShare 0.40 ;
  insm:retainedShare 0.60 ; ci:source ex:source .
ex:bad-transfer a insm:RiskTransfer ;
  insm:transferor ex:carrier ; insm:transferee ex:carrier ;
  insm:transferContext ex:policy ; ci:source ex:source .

Interoperability and mapping boundaries

[[FIBO]] and OMG Commons provide financial and agreement foundations, but mappings MUST NOT equate policyholder and insured without genuine bidirectional semantics. A FIBO or Commons agreement resource may be a useful target for a policy mapping, but this module's policy is only a minimal contextual anchor and does not claim the complete contract semantics needed for OWL equivalence.

[[ACORD-STANDARDS]] is a broad operational standard rather than an open RDF ontology. [[OPENIDS]] is a non-RDF source model and requires a declared transformation. A source-to-RDF mapping SHOULD preserve source identifiers and provenance, MUST state how assignment and transfer IRIs are generated, and MUST disclose fields that cannot be represented without a line-of-business extension.

Logical alignments, RDF projections, and non-RDF transformations are different artifacts and MUST identify their kind. Processor code is not itself a semantic mapping, and ordinary SHACL Core shapes validate data rather than transform it.

Extending controlled vocabularies

A publisher MAY add a narrower role, action, or form concept to the corresponding open scheme. The extension SHOULD have a stable IRI, label, definition, and source, and SHOULD connect to the nearest core concept with skos:broader when the broader relationship is accurate. Adding a concept to a scheme does not make it equivalent to a core concept. Cross-scheme mappings require explicit semantic review.

Loss and review requirements

Operational source models frequently collapse insured and policyholder, combine fronting and reinsurance percentages, or encode authority as an organization type. Transformations from such sources MUST NOT invent the distinctions absent from the source. They SHOULD omit unknown facts or attach a reviewable confidence assessment, and SHOULD document whether the resulting graph is a partial market view.