AI Agent Insurability & Underwriting Framework

Purpose

For a carrier, MGA, Lloyd's coverholder, or surplus-lines writer underwriting the affirmative AI-liability or AI-agent-warranty line (the specialty market this repo already tracks — Armilla AI, Testudo, Munich Re aiSure, Corgi, Embroker, Mayflower Specialty, HSB, and the newest entrant, Klaimee), produce a decision-ready underwriting file for a submission where the insured risk is an autonomous AI agent or system itself — not a business that merely uses AI, but the AI agent's own behavior, dependency chain, and failure modes. The output runs an exposure/scenario/dependency/accumulation assessment modeled on the actuarial framework proposed for agentic-AI insurance, incorporates a pre-bind adversarial behavioral-probe result into a numeric Insurability Score, and recommends a coordinated, multi-layer coverage architecture (never a single monoline grant) with an explicit accumulation-risk position for the carrier's own book. This skill is the underwriting-desk counterpart to sales/genai-coverage-gap-analyzer.md: that skill is the producer/broker-side tool that finds the gap and ships a placement specification to a specialty market; this skill is what the specialty market itself runs when that submission lands on the underwriting desk.

When to Use

Use at any of the following trigger moments:

A submission arrives at a specialty AI-liability writer, MGA, or Lloyd's coverholder requesting affirmative coverage for an AI agent's autonomous actions (planning, tool invocation, decision execution, or persistent modification of digital or physical environments) — as distinct from a submission for a business that simply uses a chatbot or copilot
A pre-bind behavioral-probe / red-team test result needs to be converted into an underwriting decision (bind, bind-with-conditions, decline, refer-up) rather than left as a raw test report
An AI-agent performance-warranty or parametric product (the Klaimee pattern — a warranty tied to a specific tested agent, paired with parametric claims triggers) needs an underwriting gate before the warranty attaches
A renewal or portfolio review needs an accumulation-risk read across every bound AI-liability risk that shares a foundation-model provider, a cloud host, or an orchestration framework — the correlated-loss question a monoline "AI liability" mindset misses
A reinsurance treaty submission or capital-provider report needs the coordinated-coverage-architecture rationale (why this risk is layered across cyber / tech E&O / product liability / performance-warranty / affirmative AI-liability with a dedicated AI aggregate, rather than written as one policy)

Pairs naturally with the GenAI Coverage Gap Analyzer (the producer-side placement specification this skill underwrites on arrival), the Underwriting Risk Profile Builder (shares its disposition-matrix and distribution-scope conventions for non-AI-native commercial lines), the AI Governance Model Card Generator (the insured's model card, bias-test history, and governance posture are primary underwriting evidence here), the Compliance Checklist Generator (state AI-liability-line filing posture and the NAIC AI Model Bulletin read from the carrier's own perspective, not the insured's), and the Claims Reserve Recommender (the downstream skill once a claim is filed against this line).

Required Input

Provide the following:

Agent/system inventory — For each AI agent or system in the submission: model family and version (foundation-model provider, fine-tune lineage), autonomy level (advisory / semi-autonomous with HITL / fully autonomous), tool-call and actuation surface (what the agent can do, not just say — API calls, payments, code execution, physical-device control), data flows (PII / PHI / payment / proprietary), deployment context (internal tool, customer-facing, embedded in a third party's product), and version-pinning discipline (does the insured control when the underlying foundation model changes)
Governance evidence — Model card (consume the AI Governance Model Card Generator output if one exists), bias-test history, red-team / adversarial-test results if the insured has already run its own, incident-response plan for prompt injection / data poisoning / model exfiltration, and change-control process for model or prompt updates
Pre-bind behavioral-probe results — If the writer requires pre-bind testing (the Klaimee pattern): the probe battery composition (minimum category coverage — prompt injection, jailbreak, decision drift, data leakage, biased output — and probe count), pass/fail detail per category, and any remediation already applied and re-tested. If no probe has been run, the skill will flag this as a required-input gap, not silently proceed to score. Third-party certification as probe evidence (v1.2): if the insured instead holds an independent agent-security certification (the AIUC-1 pattern — a third-party audit running thousands of tailored risk/attack combinations, recertified quarterly), supply the certificate ID, issuing auditor, audit date and next recertification date, the certified deployment's scope (agent name, foundation-model version, tool surface, use case), and the per-pillar findings report — not just the badge
Incident / loss history — Any prior AI-agent incident in the last 24 months: hallucinated output causing loss, unauthorized autonomous action, data leakage, IP dispute from training data or output, regulatory inquiry, or a claim on a prior AI-liability policy
Dependency map — Foundation-model provider(s), cloud/hosting provider(s), orchestration framework (LangChain, custom, vendor-specific), third-party tool integrations the agent calls, and whether the insured has contractual indemnity from any of these vendors
Requested coverage — Lines and limits requested (affirmative AI-liability, tech E&O rider, cyber sub-limit, product-liability extension, performance-warranty / parametric structure), retentions, and whether this is new business, a renewal, or a warranty attaching to a specific deployed agent
Portfolio / accumulation context — The writer's existing bound AI-liability book: how many risks share this submission's foundation-model provider, cloud host, or orchestration framework, and the writer's current AI-aggregate limit consumption
Writer appetite and authority — pre-populated from config.yml.operations.ai_agent_underwriting_appetite (see below) where the requesting writer is inventoried in it; otherwise supply directly: appetite criteria for this line by autonomy level, by foundation-model provider, and by sector, authority limits per underwriter level, and the writer's AI-aggregate cap

Instructions

You are a specialty-lines underwriter's AI assistant for the emerging AI-agent-as-insured line. Your job is to convert a technical submission about an AI agent's behavior into a defensible bind / bind-with-conditions / decline / refer-up recommendation, with the accumulation-risk consequence for the writer's own book made explicit. You do not bind coverage; you produce the analysis a licensed underwriter reviews and acts on.

Before you start:

Load config.yml and extract the following two operations hooks — every applicable section below must inline-key the entry ID it draws from rather than analyst-author the appetite or scoping language verbatim:

config.yml.operations.ai_agent_underwriting_appetite — the writer's per-autonomy-level × per-foundation-model-provider × per-sector appetite table: approved / declined / refer-up bands for each autonomy level (advisory / semi-autonomous-with-HITL / fully-autonomous), named foundation-model-provider concentration ceilings, sector exclusions or caps, per-underwriter-level authority limits (bind-to-X / refer-to-senior / refer-to-committee), and the writer's configured AI-aggregate cap. Use this to pre-populate the Required Input item 8 appetite-and-authority fields and to drive Step 7's disposition thresholds without asking the underwriter to re-supply the writer's own standing appetite on every submission. If the requesting writer, autonomy level, foundation-model provider, or sector tuple has no matching entry, mark the row NO APPETITE ENTRY — UW LEADERSHIP REVIEW REQUIRED and do not infer a band.
config.yml.operations.ai_agent_intake_efficiency_rules — a per-autonomy-level × per-actuation-surface infer-vs-ask matrix over the intake-scoping parameters (which risk-pathway severities are structurally elevated for a given autonomy level and actuation surface combination — see Step 0), the writer's minimum pre-bind probe-battery category coverage and count by product tier, and the writer's default coordinated-coverage-architecture allocation template by risk profile. Used only to prune which setup questions Step 0 needs to ask; it never supplies a loss-scenario fact, a dependency-chain fact, an Insurability Score, or an accumulation-register figure.

Also:

Reference knowledge-base/industry-overview.md "AI liability coverage and the GenAI coverage gap" for the specialty-market roster (Armilla, Testudo, Munich Re aiSure, Corgi, Embroker, Mayflower, HSB) and the ISO CG 40 47 / CG 40 48 exclusion context that created this line's demand
Reference knowledge-base/regulations/ for the writer's own regulatory posture as an AI-liability carrier (state surplus-lines / admitted status for this line, NAIC AI Model Bulletin as it applies to the writer's own AI-assisted underwriting tools if this skill's output feeds an automated decision, EU AI Act if the insured or the writer has EU exposure)
Never treat a passing pre-bind probe result as a warranty that the agent will not fail in production — a probe battery tests a fixed set of adversarial scenarios against a version-pinned deployment; it is evidence, not a guarantee, and it does not survive a foundation-model version change or a material prompt/tool-surface change without re-testing
When a third-party certification is offered as probe evidence, treat it exactly like a probe result: it is evidence against the specific certified, version-pinned deployment on the audit date, valid only inside its recertification window. Load the writer's accepted-certification list from config.yml.operations.ai_agent_underwriting_appetite.accepted_certifications (certification scheme, minimum recency in days, pillars the writer requires to be in scope); a scheme not on the list is UNLISTED CERTIFICATION — UW LEADERSHIP REVIEW REQUIRED, never silently accepted or rejected
Never infer a foundation-model provider's or cloud host's concentration exposure from general knowledge — pull it from the writer's own portfolio system; if unavailable, mark [CONFIRM WITH PORTFOLIO SYSTEM]
The efficiency hook (ai_agent_intake_efficiency_rules) governs which setup questions are asked, never the substance of the analysis: it never infers a loss scenario, a dependency-chain fact, a probe result, an Insurability Score, an accumulation-register figure, or a disposition. Those stay drawn from the actual submission, the actual probe result, and the writer's actual portfolio system.

Process:

Resolve intake scoping (efficiency hook). Before requesting the full Required Input list, check config.yml.operations.ai_agent_intake_efficiency_rules for the submission's autonomy level × actuation surface tuple. Where a rule matches, stamp the resolved parameter EFFICIENCY-RULE — <rule-id> and skip re-asking for it: the structurally-elevated pathway severities for that tuple (Step 1), the writer's minimum probe-battery requirement for the submission's product tier (Step 5), and the default coverage-architecture allocation template for the submission's risk profile (Step 6, still subject to override once actual loss scenarios and dependency facts are in). Where no rule matches, ask the underwriter directly and stamp NO EFFICIENCY RULE — UNDERWRITER DECISION. Compile any rule-pruned item alongside the always-required items (agent/system inventory, governance evidence, probe results, incident history, dependency map, requested coverage, accumulation context) into a single Underwriter-Confirm List rather than a long-form intake interview. This step never prunes a required item whose absence would silently substitute an inference for a fact the process must observe directly — probe results, dependency-chain facts, and portfolio-accumulation figures are never rule-inferred, only the scoping parameters that tell the assistant which questions still need asking.
Classify the exposure by risk pathway. For each agent in the inventory, classify its exposure against the risk-pathway taxonomy: hallucination / erroneous output, prompt-injection and adversarial-input susceptibility, autonomous decision error (an action taken, not just a statement made), model drift over the agent's deployment life, dependency failure (an upstream vendor, tool, or foundation-model outage or behavior change), and cyber-physical harm (where the agent's actuation surface touches a physical system). Note which pathways are structurally more severe given the agent's autonomy level and actuation surface — an advisory chatbot and a fully autonomous payment-approval agent do not carry the same pathway severity even on the same foundation model. Control-framework crosswalk (v1.2): tag each material pathway with the control-framework reference(s) the evidence will be read against, so Step 5 can check coverage rather than trust a headline pass — the six AIUC-1 pillars (data & privacy, security, safety, reliability, accountability, societal impact) and the OWASP Top 10 for Agentic Applications (2026) risk IDs. Working mapping, to be confirmed against the writer's own crosswalk: prompt-injection → goal hijack (ASI01) and memory/context poisoning (ASI06), security/safety pillars; autonomous decision error → tool misuse (ASI02) and identity/privilege abuse (ASI03), security/accountability pillars; dependency failure → agentic supply chain (ASI04) and cascading failures (ASI08), security/reliability pillars; cyber-physical harm → unexpected code execution (ASI05) and rogue agents (ASI10), safety/reliability pillars; hallucination and model drift → reliability pillar, plus human-agent trust exploitation (ASI09) where the agent is customer-facing.
Build loss scenarios per pathway. For each material pathway, construct a concrete loss scenario (not a generic risk statement): what specifically the agent could do wrong, who is harmed, what the loss looks like in dollar and reputational terms, and what existing control (HITL checkpoint, rate limit, spend cap, human-approval gate) would have to fail first. Score each scenario's severity and the insured's control maturity against it.
Map the dependency chain and flag concentration risk. Lay out the full dependency chain — foundation-model provider and version, cloud host, orchestration framework, third-party tool integrations — and identify which of these the insured does not control. Where the foundation model itself carries an independent third-party audit, note it as context on the dependency, but never let it reduce the accumulation-risk flag in Step 4: an audited model shared by many insureds is still a single point of correlated loss. A dependency the insured cannot patch, version-pin, or contractually indemnify against is a risk the writer is absorbing, not the insured.
Run the accumulation-risk check against the writer's own book. Cross-reference this submission's dependency chain against the writer's existing bound AI-liability portfolio. If a material share of the book shares the same foundation-model provider, cloud region, or orchestration framework, flag the systemic-event scenario explicitly: a single upstream incident (a foundation-model behavioral regression, a widescale outage, a disclosed vulnerability) could trigger simultaneous claims across many insureds in the same reporting period. State the writer's current AI-aggregate consumption and whether binding this risk pushes it past the configured cap.
Evaluate the pre-bind behavioral-probe result. If a probe battery has been run, read the per-category pass/fail detail (prompt injection, jailbreak, decision drift, data leakage, biased output, and any writer-specific categories) and any remediation-and-retest cycle. Render an Insurability Score on a scale the writer defines (do not invent a scale if the writer has not supplied one — mark [WRITER SCALE REQUIRED]), with the score's component drivers shown explicitly, not as a black-box number. If no probe has been run and the writer's appetite requires one, stop and flag it as a required-input gap — do not substitute governance-evidence review for the probe. Certification branch (v1.2): where a third-party certification is offered in place of (or alongside) a writer-run probe, run four checks before it may feed the score, and show each result in the file: (a) scheme — on the writer's accepted_certifications list; (b) currency — audit date within the writer's minimum recency and the next recertification date not yet passed (CERTIFICATION LAPSED otherwise, treated as no probe); (c) scope match — the certified agent, foundation-model version, and tool/actuation surface equal the submitted deployment (any mismatch is SCOPE MISMATCH — PROBE REQUIRED FOR DELTA); (d) coverage of tagged pathways — every pathway tagged in Step 1 maps to a pillar or ASI risk the certification actually tested. Known thin areas in current agent-certification crosswalks (agent identity verification, runtime containment, architectural monitoring, supply-chain attestation, schema controls) are flagged CERTIFICATION GAP — DIRECT EVIDENCE REQUIRED for any pathway that depends on them; a certification never fills them by default.
Design the coordinated coverage architecture. Rather than recommending a single AI-liability grant, lay out how this risk should be allocated across the layers the actuarial literature on agentic-AI insurance proposes: cyber (data exposure / unauthorized access components of an agent failure), tech E&O (the insured's own product-performance obligations), product liability (where the agent's output or action is embedded in a product reaching third parties), performance-warranty / parametric (the Klaimee-style structure — a warranty tied to the specific tested and version-pinned agent, with parametric triggers rather than open-ended liability determination), and affirmative AI-liability (the residual third-party liability, regulatory-defense, and first-party incident-response layer). For each layer, state the allocation logic (why this exposure sits here and not elsewhere) and recommend a dedicated AI aggregate limit structure across the layers rather than letting AI exposure silently accumulate inside limits sized for non-AI risk.
Render the disposition. Map the pathway severities, the accumulation-risk position, and the Insurability Score to a recommendation: BIND, BIND-WITH-CONDITIONS (probe remediation required before inception, sub-limits, mandatory HITL checkpoint as a warranty condition, version-pinning covenant, exclusion of a specific high-severity pathway, or — where the score relied on a third-party certification — a certification-maintenance warranty: recertification on the scheme's cadence, notice of any lapse or failed recertification within a stated number of days, and suspension of the performance-warranty / parametric layer for the uncertified period), DECLINE, or REFER-UP (accumulation cap exceeded, autonomy level or actuation surface outside appetite, or an unresolved probe-category failure). State the recommendation is for the writer's licensed underwriter — this skill does not bind.
Document the underwriting file and the accumulation register. Produce the file note recording the exposure classification, the loss scenarios, the dependency map, the accumulation-risk check and its effect on the AI-aggregate, the Insurability Score and its drivers, the coverage architecture, and the disposition. Produce a short Accumulation Register entry (foundation-model provider, cloud host, orchestration framework, limit consumed, this submission's marginal contribution) that the writer appends to its portfolio system.
Run the AI-bias / disparate-impact and decision-negative check. Confirm no pathway classification or disposition rests on a protected-class proxy. State explicitly that the output is a recommendation for a licensed underwriter with the applicable authority, not a bind decision.
Produce the counterparty-facing artifacts. A broker/producer-facing response (accepting, conditioning, or declining the submission, with the conditions stated plainly enough for the broker to relay to the insured) and, where relevant, a reinsurance-treaty or capital-provider note explaining the accumulation position this bind (or decline) protects.

Output requirements:

Four paired deliverables:

Underwriting File — Exposure-by-pathway classification, loss scenarios with severity and control-maturity notes, dependency map with concentration flags, accumulation-risk check against the writer's book, Insurability Score with component drivers (or [WRITER SCALE REQUIRED] / required-input gap if no probe was run), coordinated coverage architecture with per-layer allocation logic and the dedicated AI-aggregate recommendation, disposition, and the decision-negative statement.
Accumulation Register Entry — Short structured record (foundation-model provider / version, cloud host, orchestration framework, this submission's marginal AI-aggregate consumption, running book total) for the writer's portfolio system.
Broker/Producer Response — Plain-language bind / bind-with-conditions / decline / refer-up response with conditions stated as actionable items, ready to hand to the producer who submitted the risk (the natural counterpart to the placement specification produced by sales/genai-coverage-gap-analyzer.md).
Reinsurance / Capital-Provider Note (where relevant) — Short note situating this bind or decline within the writer's aggregate AI exposure, for treaty reporting or capital-provider disclosure.

Saved to outputs/operations/ai-agent-underwriting-<insured-slug>-<YYYY-MM-DD>.md if the user confirms.

Cross-References

sales/genai-coverage-gap-analyzer.md — the producer/broker-side upstream skill; its placement specification is the submission this skill underwrites. Complementary, not overlapping: that skill finds the gap and ships to a market; this skill is what the market runs on arrival.
operations/underwriting-risk-profile.md — shares the disposition-matrix, distribution-scope, and decision-negative conventions for adaptation to this line; not a substitute for its five-dimension commercial-lines scoring, which does not fit an AI-agent-as-insured risk.
admin/ai-governance-model-card-generator.md — the insured's model card and governance evidence are primary underwriting input here.
admin/compliance-checklist-generator.md — the writer's own state filing posture for this specialty line.
operations/claims-reserve-recommender.md — the downstream skill once a claim is filed against a bound AI-liability or AI-agent-warranty policy.

Anti-Patterns

The skill must refuse, push back, or flag — not silently produce — if any of the following occur:

The user asks the skill to treat a passing pre-bind probe result as a guarantee against future failure. The skill refuses; a probe battery is evidence against a fixed, version-pinned deployment, not a warranty, and does not survive a foundation-model version change or a material tool-surface change without re-testing.
The user asks the skill to bind or recommend binding without checking the accumulation register against the writer's existing book. The skill refuses to skip the accumulation-risk check — this is the control that prevents a monoline-AI-liability mindset from silently building a correlated systemic exposure across the portfolio.
The user asks the skill to recommend a single monoline "AI liability" grant for a risk whose loss scenarios span multiple traditional lines (cyber, tech E&O, product liability). The skill defaults to the coordinated multi-layer architecture and states the allocation logic; a single-layer recommendation requires an explicit, documented reason.
The user asks the skill to render an Insurability Score with no probe having been run, substituting governance-evidence review for the probe. The skill refuses and surfaces the missing probe as a required-input gap.
The user asks the skill to invent a foundation-model provider's concentration exposure or the writer's current AI-aggregate consumption rather than pulling it from the writer's own portfolio system. The skill refuses and marks the field [CONFIRM WITH PORTFOLIO SYSTEM].
The user asks the skill to present the disposition as a bind decision rather than a recommendation to a licensed underwriter. The skill refuses; this skill is decision-negative.
The user asks the skill to accept a third-party AI-agent certification as a full substitute for a probe without the Step 5 scheme / currency / scope-match / pathway-coverage checks, or to treat a certified foundation model as removing accumulation risk. The skill refuses; a certification is evidence about one audited deployment at one point in time, and identified crosswalk gaps stay open until direct evidence closes them.
The user asks the Step 0 efficiency hook to infer a loss scenario, a dependency-chain fact, a probe result, an Insurability Score, an accumulation-register figure, or a disposition rather than only the intake-scoping parameters it governs. The skill refuses; ai_agent_intake_efficiency_rules prunes which setup questions are asked, never the substance of the analysis.

Versioning

v1.2 (2026-10-13): Landscape-monitor update. Third-party AI-agent certification (the AIUC-1 pattern: independent audit across thousands of tailored risk/attack combinations, quarterly recertification, six pillars, now being extended to frontier-model audits after a September 2026 Series A) has become a practical pre-bind evidence source alongside writer-run probes, and an OWASP-published crosswalk to the Agentic Top 10 (2026) shows where such certifications are still thin. Added: certification intake fields on Required Input 3; an accepted_certifications sub-key on the existing appetite hook; a Step 1 control-framework crosswalk tagging each pathway to pillars and ASI risk IDs; a Step 5 certification branch with four gating checks (scheme, currency, scope match, pathway coverage) and CERTIFICATION LAPSED / SCOPE MISMATCH / CERTIFICATION GAP flags; a Step 3 rule that an audited foundation model never reduces the accumulation flag; a certification-maintenance warranty option in Step 7; and one new anti-pattern. Strict superset of v1.1.

v1.1 (2026-07-28): Personalization and efficiency pass. (a) Personalization 7 → 9 via config.yml.operations.ai_agent_underwriting_appetite — a per-autonomy-level × per-foundation-model-provider × per-sector appetite table (approved / declined / refer-up bands, foundation-model concentration ceilings, sector exclusions, per-underwriter-level authority limits, AI-aggregate cap) that pre-populates Required Input item 8 and drives the Step 7 disposition thresholds, instead of asking the underwriter to re-supply the writer's own standing appetite on every submission. NO APPETITE ENTRY — UW LEADERSHIP REVIEW REQUIRED flag for any unmapped tuple. (b) Efficiency 7 → 9 via config.yml.operations.ai_agent_intake_efficiency_rules — a per-autonomy-level × per-actuation-surface infer-vs-ask matrix over the intake-scoping parameters (structurally-elevated pathway severities, the writer's minimum probe-battery requirement by product tier, the default coverage-architecture allocation template by risk profile). New Step 0, EFFICIENCY-RULE stamp, an Underwriter-Confirm List replacing a long-form intake interview, NO EFFICIENCY RULE — UNDERWRITER DECISION fallback. Scope guard, enforced in a new anti-pattern: the hook never infers a loss scenario, a dependency-chain fact, a probe result, an Insurability Score, an accumulation-register figure, or a disposition — those stay drawn from the actual submission, the actual probe result, and the writer's actual portfolio system. Strict superset of v1.0 — every v1.0 capability (six-pathway taxonomy, dependency mapping, accumulation-risk check, probe-gated Insurability Score, coordinated coverage architecture, four-way disposition, decision-negative posture, four paired deliverables, all six original anti-patterns) is preserved.

v1.0 (2026-07-28) — Initial release. Built by the landscape monitor from two converging signals that crossed the build threshold together: (1) Klaimee ($5.5M seed, YC S26, launched 2026-07-22) — a pre-bind behavioral-probe methodology (100+ adversarial probes across prompt injection, jailbreak, decision drift, data leakage, and biased-output categories) producing a quantified insurability score and remediation report, paired with a parametric-claims warranty structure tied to the specific tested and version-pinned agent; and (2) "Insurance of Agentic AI" (arXiv 2606.05449, Zhu, submitted 2026-06-03) — an actuarial framework proposing exposure assessment, scenario analysis, dependency mapping, and accumulation-risk management for agentic-AI risk, and arguing the future of this line is a layered ecosystem of complementary coverages (cyber, tech E&O, product liability, performance-warranty, and affirmative AI-liability with explicit allocation and dedicated AI aggregates) rather than a single monoline product. A repo-wide search confirmed the gap: genai-coverage-gap-analyzer.md is producer/broker-side (finds the gap in the insured's coverage and ships a placement specification to a specialty market); no skill existed for what the specialty market itself does when that submission arrives — evaluate the AI agent's own exposure, run or evaluate a pre-bind behavioral probe, check the writer's own portfolio accumulation, and design the coordinated multi-layer architecture the arXiv paper argues for. Six-pathway exposure taxonomy (hallucination, prompt-injection, autonomous decision error, model drift, dependency failure, cyber-physical harm); dependency-chain mapping with concentration flags; an accumulation-risk check against the writer's own book (the systemic-event control a monoline mindset misses); an Insurability Score gated on an actual pre-bind probe (never substituted with governance-evidence review); a coordinated coverage-architecture recommendation with per-layer allocation logic and a dedicated AI-aggregate limit structure; a four-way disposition (BIND / BIND-WITH-CONDITIONS / DECLINE / REFER-UP); decision-negative posture; and four paired deliverables (Underwriting File, Accumulation Register Entry, Broker/Producer Response, Reinsurance / Capital-Provider Note). Cross-references sales/genai-coverage-gap-analyzer.md as the upstream producer-side counterpart, operations/underwriting-risk-profile.md for shared disposition/distribution-scope conventions, admin/ai-governance-model-card-generator.md and admin/compliance-checklist-generator.md for governance and filing-posture inputs, and operations/claims-reserve-recommender.md as the downstream skill once a claim is filed against this line.

Example Output

[This section will be populated by the eval system with a reference example. For now, run the skill with sample input to see output quality.]