Findings
Findings to review with severity, kind, citations and Approve, Change, Reject
Findings (illustrative). A missing schedule, a cyber diligence gap and disclosed known issues — each with severity, kind, the page it cites, the agent's reading and Approve, Change or Reject.

An R&W underwriter will ask about the target’s insurance: is the program adequate, are there large open losses, does a claims-made policy need a tail at closing? In most practices that answer sits in a separate insurance due diligence report, written by a different team, that the placement broker reads as a PDF.

InsightDueDiligence and InsightDealDesk share the platform, so the answer travels as data. Reviewed findings from an insurance due diligence engagement arrive on the deal as known issues, each citing the diligence it came from, and the exclusion agent reads them like any other. This post follows one such hand-off. The engagement, deal and figures are illustrative.

Use case card
ActorsDiligence broker (InsightDueDiligence), deal broker (InsightDealDesk), practice leader
TriggerThe report agent in InsightDueDiligence prepares “share with the R&W placement”; a broker accepts
What travelsReviewed findings in R&W-relevant categories: known issue, coverage gap, tail needed, red flag, diligence gap, claims history, litigation
Contractdiligence_findings.v1 — a signed POST to /api/deal_intake/diligence-findings
MatchingBy deal id when the engagement knows it, else by the target’s lookup key
OutcomeThe findings land on the deal’s data room as known issues, cited to InsightDueDiligence; the next Analyze reads them

The flow

flowchart LR subgraph DUE["InsightDueDiligence"] E["Engagement:
insurance program review"] --> R["Findings reviewed
by a broker"] R --> RA["Report agent prepares
share with the placement"] RA --> OK{"Broker
accepts?"} end OK -->|yes| P["Signed POST
diligence_findings.v1"] subgraph DEAL["InsightDealDesk"] P --> V{"Signature valid,
deal matched?"} V -->|yes| L["Known issues on the
deal's data room"] L --> X["Exclusion agent reads them
on the next Analyze"] end style P fill:#fef3c7,stroke:#b45309 style L fill:#e8f8f4,stroke:#22c1a4

Step by step

A hand-off from insurance diligence to the placement Illustrative.
1
Findings reviewedDiligence broker1

Only reviewed findings travel. A pending finding stays in InsightDueDiligence.

2
Share preparedReport agent (InsightDueDiligence)2

The R&W-relevant findings are gathered into the hand-off. Sharing is capped at ask-first.

3
AcceptedDiligence broker3

Accepting signs the body with the shared secret and posts it. With no endpoint configured, it is held in the outbox and nothing leaves.

4
VerifiedInsightDealDesk4

The X-Insight-Signature header is checked (HMAC-SHA256 over timestamp and body, five-minute tolerance). A bad signature is a 401; no matching deal a 404; not configured a 503.

5
LandedInsightDealDesk5

Each finding lands on the deal’s data room as a known issue citing InsightDueDiligence. Idempotent on the finding’s fingerprint: a resend lands nothing twice, and a finding a deal broker has already reviewed is never overwritten.

6
ReadExclusion agent6

On the next Analyze the landed issues are inputs like any schedule disclosure, and appear in the submission’s known issues.

7
ReviewedDeal broker7

Approves, changes or rejects each landed finding in the Findings zone.

Who talks to whom

sequenceDiagram participant DB as Diligence broker participant DUE as InsightDueDiligence participant DD as InsightDealDesk participant XA as Exclusion agent participant B as Deal broker DB->>DUE: Accept share with the placement DUE->>DD: POST diligence-findings, signed DD->>DD: Verify signature, match deal DD-->>DUE: landed, skipped, finding ids B->>DD: Analyze DD->>XA: Known issues incl. landed ones XA-->>B: Likely exclusions, cited B->>DD: Review each finding

What the body looks like

// POST /api/deal_intake/diligence-findings   X-Insight-Signature: t=<unix>,v1=<hmac>
{
  "schema": "diligence_findings.v1",
  "sent_at": "2026-10-28T14:02:11Z",
  "source": { "product": "insightdiligence", "workspace_guid": "…", "pack": "insurance_program" },
  "target": { "deal_guid": null, "target_key": "example-target.example" },
  "findings": [ { "category": "tail_needed", "severity": "high",
                  "title": "D&O run-off needed at closing (illustrative)", "fingerprint": "…" } ]
}

An abridged, illustrative body. The JSON Schema is shared by both products and a test compares the two copies.

Idempotency and review, as a state machine

stateDiagram-v2 [*] --> Received Received --> Rejected401: bad signature Received --> NoDeal404: no matching deal Received --> Landed: new fingerprint Received --> Skipped: fingerprint already landed Landed --> Reviewed: deal broker reviews Reviewed --> Reviewed: resend never overwrites
AgentWhat it preparedWhat it citesWho decides
Report (InsightDueDiligence)Share R&W-relevant findings with the placementReviewed findingsDiligence broker
Exclusion (InsightDealDesk)Landed issues as likely exclusionsFindings citing InsightDueDiligence—
SubmissionKnown issues section includes themFindingsDeal broker

On the deal desk

The insurance diligence is in the placement as findings to review, not a PDF to reread.

For IT and architecture

Signed with insight_integrations.signing; idempotent on fingerprint; contract under docs/contracts in both repos.

For practice leaders

Two teams, one record: the diligence and the placement agree on what was known, and when.

Questions we get asked

Do we need both products?

No. InsightDealDesk works on its own data room. With InsightDueDiligence the insurance program review arrives as data.

What if the deal was not created yet?

The receiver answers 404 and the sender keeps the hand-off; it can be resent once the deal exists.

Keep reading