Two Notes, One Audit Trail: How UW Summaries and Manager Approval Notes Close the Referral Loop

From "the manager approved with one line of notes and the UW reads it as a wall of confusion" to "the UW gets the rich approval rationale, the conditions are itemised, the next-step section says exactly what to do, and the file has the PDF" — through two separately-authored, separately-finalised notes that share an audit trail.

The Problem

When a referral lands on a manager's desk, two pieces of context get conflated by every system that ships with one:

1. What the UW is asking for — terms, quote, rationale for the request. The UW needs to articulate this clearly so the manager doesn't have to reverse-engineer the file.
2. What the manager is granting (or denying) — the decision, conditions, terms required, follow-up actions. The UW reading the answer needs to know exactly what changed and what to do next.

Most platforms shove both into one free-text box. The UW types two sentences in decision notes, the manager types two more on top. The audit trail is "approved by Jennifer: 'Approved with conditions'" — a string with no structure, no PDF, no follow-up section, no reference back to the request.

Half-fixes:

• Notes templates that shoehorn both POVs into one document. The UW's section gets edited by the manager. The artefact reads schizophrenic.
• Email threads. Audit lives in Outlook. Compliance can't reconstruct.
• Free-text everywhere. Works until two months later when nobody can answer "what conditions did we approve?"

Result: the request and the answer both exist as scattered string fragments. The UW reading the back-notification has to read between the lines.

The InsightUW Approach

Two artefacts on every referral. Both built on the same manuscript template engine. Different POV, different sections, different lifecycle, separate audit trail — connected by a cross-reference, not a merge.

The UW's Note (Capability #7)

The UW authors a referral summary — what they're asking for. Sections come pre-populated from the live submission/quote:

UW edits any section, hides what's irrelevant, adds custom sections (custom_*) that survive regenerates. Finalize renders to PDF/DOCX, attaches as Submission Document(category='referral_summary', entity_type='referral'). The submission file gets it automatically.

The Manager's Note (Capability #10)

The manager authors an approval note — what they're granting (or denying). Sections branch by decision type:

Each section seeds with cheap markdown: "Decline reasons:\n- list specific reasons" — the manager isn't staring at empty boxes. Custom sections supported.

Why Two Notes, Not One

Three reasons:

1. Different POV. The UW is requesting; the manager is responding. Merging the two muddles the audit story (who said what, when?).
2. Different lifecycle. The UW finalizes when the request is locked. The manager finalizes when the decision is made. Linking them in one row would mean either can't finalize until the other does.
3. Different output cadence. A referral can be escalated then approved — that's two manager-side approval notes (history of decisions) tied to one UW request summary.

Cross-reference, not merge: Referral Approval Note.linked_referral_summary_guid points at the UW's finalized note. The rendered approval-note PDF includes a "see attached referral summary v3" line. Both PDFs land on the submission file.

The Finalize-and-Apply Button

Capability #10's headline workflow. The manager doesn't finalize then approve in two steps — they click Finalize & APPROVE once. The button:

1. Finalizes the approval note (locks content, renders PDF, attaches as Submission Document).
2. Calls the lifecycle endpoint (/referrals/{guid}/approve) with approval note guid set.
3. The lifecycle service:
   - Updates Referral Queue.referral_status = 'approved'.
   - Writes a Audit Entry for the lifecycle event, returns its guid.
   - Calls the helper that stamps Referral Approval Note.decision_event_audit_guid with that guid.
   - Calls notify referral with the persisted approval note.
4. The dispatcher embeds the note's full body text in the back-notification body and adds a download link.

Two notes, one click, full audit chain. The originating UW gets the bell ping with the rich content already in the message.

Worked Example: Stronghold Capital — Approval With Conditions

Picking up Stronghold's two referrals from blogs #87 and #89.

Sarah authors the UW summary

She opens /uw/submissions/{stronghold_guid}, scrolls to the referral panel, clicks the pencil icon on the policy_limit referral. The drawer opens. She sees six sections pre-populated:

• Rule rationale — "Quote QT-2026-DO-0319 for Stronghold Capital requests a $14,000,000 limit, which exceeds the US private D&O underwriting threshold of $10,000,000. Breach: observed 14,000,000 vs threshold 10,000,000."
• Quote terms — table with premium $385k, total limit $14M, effective Jul 1 2026 → Jul 1 2027.
• Coverage layers — JSON dump (she leaves it).
• Terms & conditions — the quote's T&C text.
• Risk signals — Stronghold's industry (Private Equity Fund Management), revenue, loss ratio, risk score 72.
• Audit history — created at 2026-04-25 09:14:02 by Sarah Chen.

She adds a custom section "Why this risk is worth the reach" with two paragraphs about Stronghold's asset growth and the broker relationship. Hides "Audit history" (irrelevant for the manager — they have their own queue). Clicks Finalize, picks DOCX. The drawer renders, attaches referral_summary_xyz.docx as a Submission Document, closes.

Total time: 4 minutes. Most of it spent typing the custom section.

Jennifer authors the approval note

10 minutes later, Jennifer's bell pings (the per-event back-notify from the creation of Sarah's referral, not Sarah's note). She opens /uw/referrals/queue, sees Stronghold at the top of the list (urgency 205 — see blog #88). Clicks Approve in the row's actions. The inline panel appears with two buttons: Quick approve and Approve with note.

She picks Approve with note. The drawer opens with decision_type='approved'. Five sections pre-populated:

• Decision — "Referral APPROVED for Stronghold Capital (D&O · US)." She tweaks it: "Approved with conditions — see below."
• Conditions — seed says _list any conditions here_. She types: "Approval contingent on (1) signed engagement letter from Stronghold's GC by 2026-06-30, (2) confirmation that Stronghold's prior carrier has provided five years of clean loss runs, (3) annual reporting obligation as per attached schedule."
• Terms required — seed says Terms required: limit $14,000,000, premium $385,000, deductible $50,000.\n_describe any deviations or required adjustments_. She adds: "No deviations from the quoted terms."
• Follow-up for UW — seed says _what should the originating UW do next?_. She types: "Sarah: please confirm receipt of the engagement letter to Patricia by EOD 2026-06-30. Update Stronghold's account flag to 'manuscript-approved' once bound."
• Manager rationale — seed includes the breach numbers. She extends: "Within delegated authority. Stronghold has a five-year clean loss record with the prior carrier and Marsh's pricing benchmark supports the $385k premium."

The drawer's footer shows a green Finalize & APPROVE button. She clicks. Confirmation prompt. Confirms.

Three things happen in one transaction:

1. The approval note finalizes → renders to PDF → attaches as Submission Document(category='approval_note', entity_type='referral_approval').
2. The referral is approved → Referral Queue.referral_status='approved', decision notes and decision date set.
3. A Audit Entry row is written; its guid stamps Referral Approval Note.decision_event_audit_guid.

Then the back-notify fires.

What Sarah sees

Sarah's bell pings. She opens it. The notification:

Referral approved: policy_limit · D&O

Quote QT-2026-DO-0319 for Stronghold Capital requests a $14,000,000 limit, which exceeds the US private D&O underwriting threshold of $10,000,000.

By: Jennifer Walsh

DECISION DETAILS

Decision

Approved with conditions — see below.

Conditions

Approval contingent on (1) signed engagement letter from Stronghold's GC by 2026-06-30, (2) confirmation that Stronghold's prior carrier has provided five years of clean loss runs, (3) annual reporting obligation as per attached schedule.

Terms required

Terms required: limit $14,000,000, premium $385,000, deductible $50,000. No deviations from the quoted terms.

Follow-up for UW

Sarah: please confirm receipt of the engagement letter to Patricia by EOD 2026-06-30. Update Stronghold's account flag to 'manuscript-approved' once bound.

Manager rationale

Within delegated authority. Stronghold has a five-year clean loss record with the prior carrier and Marsh's pricing benchmark supports the $385k premium.

Download: /api/uw_referral_rules/approval-notes/{note_guid}/download
Open: /uw/submissions/{stronghold_guid}#referrals

Sarah doesn't have to ask Jennifer what the conditions were. She doesn't have to scroll through audit logs to find the rationale. She has a follow-up checklist. She has a PDF for the file. She has the full text in the inbox row.

What the file shows

Two PDFs attached to the submission, both findable on the standard documents view:

• referral_summary_*.docx — Sarah's request, six sections, finalized 2026-04-25.
• approval_note_approved_*.pdf — Jennifer's decision, five sections, finalized 2026-04-25, references referral_summary_* by GUID.

The audit trail (Audit Entry rows for entity_type='referral') is complete: created → approved, with decision event audit guid cross-referenced to the approval note.

What This Means for Underwriters

1. Two POVs, two artefacts. The UW's request and the manager's answer live as separate documents. Compliance can show "what was asked" and "what was granted" side-by-side without parsing a free-text field.
2. Pre-populated, not empty. Both notes seed with merge data (UW's note from the live quote/submission/audit; manager's note from the same plus the breach numbers). Authors edit; they don't start blank.
3. Quick path preserved. Managers in a hurry still get the Quick approve / Quick decline inline buttons — no forced authoring. The structured path is opt-in via Approve with note.
4. One click closes everything. "Finalize & APPROVE" finalizes the note, renders the PDF, attaches it, applies the lifecycle action, writes the audit, fires the back-notify. No four-step shuffle.
5. The back-notify carries the content. The UW reads the manager's full structured rationale in the notification body — no click-through required to learn the conditions. Click-through gets them the PDF.
6. History per decision. A referral that's escalated, then approved, has two finalized approval notes. The submission file shows the chain. The originator sees both back-notifications.
7. No coupling between drafts. UW finalizing the summary doesn't lock the manager out. Manager finalizing the approval doesn't blow away UW edits. Different lifecycles, shared submission, separate audit chains.

What's Next

This closes the Referrals series — capabilities #1 through #10, from rule trigger through queue, gate, notes, and back-notify. The full design lives in REFERRALS_DESIGN.md at the repo root.

Want to see what a referral approval looks like on the receiving end — five sections, a PDF on the file, and a checklist your UWs actually act on? Request a demo.