| Internet-Draft | OMP AI Insurance Profile | April 2026 |
| Adebayo, et al. | Expires 7 October 2026 | [Page] |
This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in contexts covered by AI liability insurance policies, including AI performance warranties, AI errors and omissions coverage, and coordinated AI liability structures. The profile -- designated InsureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate per-decision Proof-Points that function as objective parametric trigger data for AI liability insurance claims, and provide independently verifiable underwriting evidence that reduces claims ambiguity and supports premium differentiation.¶
The InsureMark profile addresses the primary gap in current AI liability insurance underwriting: policies are currently issued based on model-level performance assessments, but claims arise at the level of individual AI decisions. No current AI liability insurance product requires or receives per-decision cryptographic evidence. This profile specifies the technical architecture by which OMP Proof-Points close this gap.¶
The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp).¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 7 October 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
AI liability insurance has emerged as a significant market in response to the growing deployment of AI systems in consequential commercial and regulated contexts. AI performance warranties, AI errors and omissions policies, and coordinated AI liability structures now offer coverage for financial losses arising from AI errors, model failures, and AI-generated harms.¶
Current AI liability insurance products share a structural limitation: they are underwritten at the model level and adjudicated at the claim level, with no per-decision evidence infrastructure connecting the two. When a claim arises, the insured and insurer must reconstruct what the AI system did in the specific interaction that generated the alleged harm -- often weeks after the fact, from logs not designed for forensic use.¶
This gap produces two material consequences: claims uncertainty (the inability to reconstruct the precise decision state is the primary source of disputed claims and extended settlement timelines) and underwriting imprecision (policies cover the AI system as a whole without differentiating between the materially different liability profiles of fully autonomous decisions versus supervised decisions).¶
The Operating Model Protocol (OMP) [I-D.veridom-omp] generates a cryptographically sealed Proof-Point for every AI decision, containing the routing outcome, policy compliance flag, confidence scores, Named Accountable Officer identity (where human oversight was applied), RFC 3161 [RFC3161] TimeStampToken, and SHA-256 hash chain per [RFC8785]. These Proof-Points are independently verifiable by any party without access to the operator's or OMP implementer's infrastructure.¶
This document defines the InsureMark profile: the domain-specific instantiation of OMP for insured AI deployments. The profile specifies how OMP Proof-Points function as parametric trigger data for AI liability insurance claims, and how the Audit Trace schema extensions for this profile enable premium differentiation based on per-decision evidence quality.¶
Related OMP domain profiles include the EU AI Act Article 12 profile [I-D.veridom-omp-euaia] and the Legal AI Supervision profile [I-D.veridom-omp-legal]. The OMP specification is also archived at [ZENODO-OMP].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174].¶
This document uses the terminology defined in [I-D.veridom-omp]. In addition:¶
Leading AI liability insurance products assess the AI system's training data quality, testing methodology, governance documentation, usage scenarios, and compliance with AI management standards such as ISO/IEC 42001 [ISO-42001]. These assessments answer: is this AI system designed and governed to operate correctly? They do not answer: did this AI system operate correctly in the specific interaction under claim?¶
When a claim arises, insurer and insured must reconstruct what the AI system did at decision time: what input data was presented, what policy evaluation applied, what the AI recommended, whether a human reviewed it, and whether the record has remained intact. Where this reconstruction is impossible, settlement depends on negotiation rather than evidence -- producing extended timelines, disputed claims, and coverage limits that price in this uncertainty.¶
By 2022, cyber insurers moved from recommending audit logs to requiring them as conditions of coverage, with premium differentiation for verified control effectiveness [DELINEA-2026]. The actuarial basis is direct: organisations with verified audit trails have lower claims uncertainty and reduced disputed claim rates. AI liability insurance is at an earlier stage of the same trajectory.¶
ISO/IEC 42001 certification has been adopted by at least one leading AI liability MGA as a basis for premium differentiation. ISO/IEC 42001 certifies the AI governance process. It does not certify that any specific decision was made correctly. InsureMark Proof-Points are the execution-time evidence layer that completes what ISO/IEC 42001 process certification started. See Section 7.¶
The three OMP routing states create distinct Coverage Tiers:¶
Underwriters SHOULD offer differentiated premiums by Coverage Tier, with AUTONOMOUS carrying the highest rate per interaction and ESCALATED the lowest.¶
For ASSISTED interactions, the Proof-Point records whether the Named Accountable Officer reviewed and approved an AI recommendation before finalisation. This is material to claims assessment (professional judgment versus AI system failure question) and subrogation (the insurer may have rights against the Named Accountable Officer's professional indemnity policy).¶
Under this profile, operators MUST record Named Accountable Officer identity for all ASSISTED and ESCALATED interactions. The identity MUST be stable throughout the coverage period: the same identifier MUST refer to the same individual.¶
This profile does not mandate specific thresholds; these are negotiated at policy inception. However: (a) the AUTONOMOUS routing threshold MUST be documented in the Underwriting Evidence Record; (b) any change to this threshold MUST generate a WT-AIINS-03 event and be notified to the insurer; (c) C_p = 0.0 MUST force ESCALATED routing, ensuring policy compliance failures generate a mandatory human intervention record.¶
Trigger: Composite Confidence Score falls below the configured AUTONOMOUS threshold.¶
Action: FORCE_ASSISTED.¶
Claims relevance: Documents AI system self-identified uncertainty and Named Accountable Officer review decision, enabling distinction between AI-uncertain-and-human-approved versus AI-autonomous-and-erroneous in claims assessment.¶
Trigger: Evaluated at every interaction.¶
Action: Computes policy_compliance_flag (VALID/INVALID/PARTIAL). INVALID sets C_p to 0.0, forcing ESCALATED routing.¶
Claims relevance: policy_compliance_flag is the primary parametric trigger field. An INVALID flag records that the AI system's behaviour deviated from the operator's declared governance policy -- the insurance-equivalent of a covered loss event.¶
Trigger: Any change to OMP routing configuration (thresholds, Watchtower definitions, profile version) during an active coverage period.¶
Action: FORCE_ESCALATED for the triggering interaction, generating a sealed configuration change record.¶
Claims relevance: Enables insurer to verify that the configuration at the time of an alleged error matches the configuration disclosed at underwriting. Configuration version mismatch may affect coverage.¶
Trigger: Interaction type, domain, or risk category not included in the operator's declared coverage scope.¶
Action: FORCE_ESCALATED. The out-of-scope interaction MUST NOT proceed AUTONOMOUS.¶
Claims relevance: Prevents undisclosed scope expansion from generating covered claims without the insurer's knowledge.¶
Trigger: Rate of INVALID policy_compliance_flag determinations for a given interaction type exceeds the configured anomaly threshold within a rolling window.¶
Action: FORCE_ESCALATED for subsequent interactions of the same type, pending human review.¶
Claims relevance: Creates a sealed record of model degradation, data drift, or adversarial input detection events, supporting post-market monitoring rights under the policy.¶
The following fields are REQUIRED under the InsureMark profile, in addition to core fields in [I-D.veridom-omp] Section 7:¶
insurance_policy_id: string, REQUIRED. Identifier assigned by
the insurer or MGA at policy inception.¶
coverage_tier: string, REQUIRED. One of: "AUTONOMOUS",
"ASSISTED", "ESCALATED". MUST match routing_outcome.¶
policy_compliance_flag: string, REQUIRED. One of: "VALID",
"INVALID", "PARTIAL". INVALID is the primary parametric trigger.¶
parametric_trigger_activated: boolean, REQUIRED. True if
policy_compliance_flag is INVALID or composite Confidence Score falls
below insured_performance_threshold.¶
insured_performance_threshold: number, REQUIRED. Decimal
0.0-1.0. Minimum composite Confidence Score specified in policy terms.¶
coverage_period_id: string, REQUIRED. Identifier for the
active coverage period.¶
interaction_type_declared: string, REQUIRED. Interaction
type as declared in the Underwriting Evidence Record.¶
named_accountable_officer_id: string, REQUIRED for ASSISTED
and ESCALATED; NULL for AUTONOMOUS. Stable identifier consistent with
the Named Accountable Officer registry disclosed at underwriting.¶
configuration_version: string, REQUIRED. Semantic version
of OMP configuration at time of interaction.¶
profile_version: string, REQUIRED. MUST be
"VERIDOM-INSUREMARK-v1.0".¶
Primary trigger: policy_compliance_flag = "INVALID" - Policy Compliance Failure Event.¶
Secondary trigger: composite Confidence Score below insured_performance_threshold - Performance Threshold Breach Event.¶
Coverage tier classifier: coverage_tier differentiates AUTONOMOUS from ASSISTED liability for claims assessment and premium calculation.¶
Configuration integrity: configuration_version mismatch between interaction and underwriting disclosure may affect coverage.¶
When parametric_trigger_activated is true, the InsureMark adapter MUST: (a) extract the sealed Proof-Point; (b) verify chain integrity by recomputing SHA-256(payload_canonical) against interaction_hash; (c) verify the RFC 3161 [RFC3161] TimeStampToken; (d) generate a Claims Event Record containing the interaction_id, parametric trigger details, coverage_tier, routing_outcome, named_accountable_officer_id, insurance_policy_id, and full sealed Proof-Point; and (e) submit to the insurer's claims intake system within the policy notification window.¶
The Claims Event Record is self-contained: an insurer with access only to the record and the Timestamp Authority's public key can verify integrity without access to the operator's infrastructure.¶
The OMP Merkle chain structure enables completeness verification: a gap between Proof-Points N and N+2 indicates at least one interaction was not logged. Insurers discovering a chain gap may treat it as a policy condition breach or require explanation before claims assessment proceeds. Operators MUST maintain an unbroken Proof-Point chain throughout the coverage period. Operational interruptions MUST be documented in a sealed Chain Gap Record.¶
ISO/IEC 42001 certifies the AI governance process. InsureMark Proof-Points prove each specific decision. The two mechanisms are layered and complementary:¶
Insurers that offer premium differentiation for ISO/IEC 42001 certification can extend their framework to include InsureMark as a second, execution-time evidence tier. ISO/IEC 42001 answers: is the AI governance system designed correctly? InsureMark answers: did the AI system operate correctly in this specific interaction?¶
Upon a covered claim event, the operator MUST produce a Claims Evidence Package containing:¶
The Claims Evidence Package MUST be producible within the timeframe specified in the policy terms. Implementations SHOULD be capable of generating it within 30 seconds for any single interaction. The package is self-contained: an insurer, MGA, loss adjuster, reinsurer, or court with no access to the operator's infrastructure or the OMP implementer's systems can verify its integrity using only the OMP Reference Validator [OMP-OPEN-CORE] and the Timestamp Authority's public key material.¶
The security considerations of [I-D.veridom-omp] apply in full.¶
Insurance fraud: Operators MUST NOT circumvent WT-AIINS-03. Operating the AI system outside the disclosed configuration while generating technically valid Proof-Points is a material breach of policy conditions.¶
Privacy: The Proof-Point stream may contain personal data subject to GDPR or equivalent legislation. Operators MUST ensure disclosure to insurers is consistent with applicable data protection obligations.¶
Timestamp Authority compromise: Operators SHOULD use QTSPs listed in an EU Member State trusted list under eIDAS or equivalent national trust framework, as these operate under regulatory supervision with key management requirements that reduce retroactive fabrication risk.¶
Chain gap manipulation: Deliberate creation of chain gaps to obscure non-compliant interactions is a material breach of policy conditions.¶
This document has no IANA actions.¶