Engineering Blog · Post #97

Sticky Owners and Roll-Up Reminders: How InsightUW Hands Subjectivities to the AC Without Losing Them on Reassign

From "Sarah bound the policy on Friday, the AC was Mike, the broker emailed loss runs Tuesday, but the bind request had been reassigned to Jen by then, the subjectivity was assigned to Mike, the loss runs sat in Mike's inbox for nine days while Jen wondered what was waiting on the broker" to "the AC pin on Subjectivity is sticky — it survives bind-request-level reassignment, the +2d reminder fires regardless of who currently owns the bind, the +5d still fires after AC ack because reviewing isn't the same as driving to clearance" — through one column on Subjectivity, a roll-up notification at confirm time, and the deliberate refusal to fan-out one notification per subjectivity.

The Problem

A binding subjectivity says "loss runs needed by effective date." The AC's job is to drive it to clearance — chase the broker, log evidence, make sure a UW reviews. The work spans days, sometimes weeks.

What goes wrong:

Reassignment churn. ACs go on PTO. Bind requests get reassigned. The new AC inherits a queue with no context — and if the subjectivity owner was tied to the bind request, the previous AC stops getting reminders even though they have all the context.
Notification fatigue. A bind has 8 open subjectivities. The naive system pings the AC 8 times at the moment of authorization-confirm. The AC opens the inbox to a wall of identical "subjectivity assigned" rows and triages them as one.
Acknowledge-as-clearance confusion. The AC clicks "I see this" — but seeing isn't driving to clearance. The system that auto-cancels the rest of the cadence on first-touch hides genuinely overdue work.
Manual escalation back to UW. When the broker won't engage, the AC needs a clean way to bump back to the UW with a reason. Today: write an email, hope the UW notices.

The usual fixes don't fix:

Notify per-subjectivity at confirm. Notification fatigue. AC inbox becomes unusable.
Tie the subjectivity owner to the bind request's assigned_ac. Then reassigning the bind request also reassigns every subjectivity — workload accountability gets churned, prior context stops getting reminders.
Single follow-up timer per bind. Doesn't work — different subjectivities have different due dates and different evidence channels.
A separate task system parallel to Follow Up. Forks the worker, doubles the surface, introduces new dispatcher logic that's almost-but-not-quite the same as the existing one.

The root cause: subjectivity-to-AC ownership has different lifetime semantics than bind-request-to-AC assignment. They overlap initially but evolve independently.

The InsightUW Approach

A sticky AC pin per subjectivity, a roll-up notification at confirm time, per-subjectivity reminders that respect "ack ≠ clearance," and a clean escalate-to-UW path.

graph TD subgraph Confirm["Cap #9 confirm fires"] Authconfirm["Broker Authorization.confirm cap #3 auto create from quote + cap #9 resolve ac"] Bind["Bind Request.ac assigned to=mike"] end subgraph Assign Call["assign to ac on confirm — cap #10"] Scan["Find Subjectivity rows Where quote guid=... AND required by IN (binding,policy issuance,effective date) AND lifecycle status IN (agreed,pending evidence,received)"] Sticky["For each row: if ac assigned to IS Null: ac assigned to=mike ← sticky"] Sched["Schedule Follow Up at +2d (sequence 0) +5d (sequence 1) tagged 'subjectivity:<guid>'"] Rollup["ONE roll-up notification '8 open subjectivities to action'"] end subgraph Later Reassign["Two days later: bind request reassigned"] Reassign["Bind Request.ac assigned to=jen (reassign endpoint)"] Unchanged["Subjectivity.ac assigned to Still =mike ← sticky pin survives"] Remind M["+2d reminder fires for mike (he has the context)"] end subgraph ACWork["AC workflow"] ACK["acknowledge: last ac action kind='reviewed' cancels +2d Only"] Req Info["request info: last ac action kind='requested info' cancels existing reminders schedules +3d post-request"] ESC["escalate to uw: assigned role='underwriter' cancels reminders notifies UW severity=warning"] end subgraph Sweep["Daily overdue sweep"] Sweepcall["overdue sweep Where due date < today AND lifecycle in (agreed,pending,received) AND ac assigned to IS NOT Null"] Dedup["Idempotency: properties.last overdue notify date == today.isoformat → skip"] Fire["Notification subjectivity overdue severity=warning"] end Authconfirm --> Bind Bind --> Scan Scan --> Sticky Scan --> Sched Scan --> Rollup Reassign --> Unchanged Unchanged --> Remind M Sched --> ACK Sched --> Req Info Sched --> ESC Sweepcall --> Dedup Dedup --> Fire

Sticky AC pin survives bind-request reassignment

Subjectivity.ac_assigned_to is set once, at confirm time, by assign to ac on confirm. The function only writes when the field is currently NULL — re-running on the same subjectivity is a no-op for already-pinned rows.

This is deliberate. Bind-request-level AC reassignment (the bind workflow gets a new owner because of PTO, workload balancing, escalation) is a different decision than subjectivity-level workload accountability. The person who already started chasing the broker for the loss runs is the right reminder recipient — even if a different AC now owns the bind.

When workload genuinely needs to move, an admin can manually update ac assigned to on the subjectivity (per-row, audited).

Roll-up at confirm, per-subjectivity at reminder

At authorization-confirm, the AC gets one notification:

Severity = warning if any are already overdue (broker-confirmation dates in the past), else info. The deep-link goes to /uw/bind/ac-subjectivities filtered to this bind.

But the per-subjectivity reminder cadence fans out individually. Two days later, a subjectivity-specific reminder fires for each subjectivity that hasn't progressed:

Eight reminders if eight aren't progressing — but they fire one-per-subjectivity-per-cadence-step rather than eight-at-once. The AC sees individualized, actionable nudges.

Reminders respect "ack ≠ clearance"

The +2d / +5d cadence is two reminders (sequence 0 and 1). Per-subjectivity action acknowledge:

Sets ac acknowledged at / ac acknowledged by / last ac action at / last_ac_action_kind='reviewed'
Cancels only the +2d reminder (sequence 0) for this subjectivity

The +5d still fires because reviewing isn't the same as driving to clearance. If the broker has gone quiet between +2d and +5d, the AC needs the second nudge.

request info, by contrast, cancels all scheduled reminders and reschedules a single +3d post-request reminder — the AC actively went to the broker; if no response in 3 days, fire again.

Escalation flips assignment + notifies UW

When the broker won't engage:

Effects:
- Subjectivity.assigned_role = 'underwriter'
- Subjectivity.assigned_to = 'sarah' (or fallback to original quote.created_by_user)
- All scheduled reminders cancelled
- last_ac_action_kind = 'escalated_to_uw'
- UW receives subjectivity escalated to uw notification with severity='warning'

The subjectivity is now off the AC's plate (it no longer shows up in list for ac); it's on the UW's. The UW can call the broker directly, mark cleared, or push back to the AC.

Daily overdue sweep with calendar-day dedup

The hourly sweeper finds every open subjectivity with due_date < today and an ac assigned to. To avoid pinging the AC twice in one day per subjectivity:

Calendar-day dedup is good enough for human-pace work. The sweep runs hourly so newly-overdue subjectivities (one whose due date crossed midnight) get caught within an hour rather than waiting 24h.

Worked Example: Acme Construction $35M GL Bind, Eight Open Subjectivities

QT-2026-GL-5527. Broker authorization landed Wednesday at 2pm; cap #9 confirmed → cap #3 created the bind request → AC routing resolved Mike (lob='general_liability', priority 100). 8 open subjectivities, 2 already showing past due dates from earlier broker conversations.

Step 1 — Wednesday 2:01pm: roll-up to Mike

Mike opens his inbox:

He clicks; lands on /uw/bind/ac-subjectivities filtered to QT-2026-GL-5527. Eight rows, statuses agreed/pending evidence/received. The 2 overdue (red Overdue chip): "OSHA recordable summary, prior 5 years" (due 2026-04-20) and "EMR rate certification" (due 2026-04-22).

For each, Mike clicks Acknowledge — this sets ac_acknowledged_at=now, last_ac_action_kind='reviewed', and cancels each subjectivity's +2d reminder. The +5d for each still sits scheduled.

Behind the scenes: 8 Follow Up rows tagged subjectivity:<guid> were inserted at confirm time:
After Mike's bulk acknowledge: 8 of the seq-0 rows go to cancelled with reason auto: ac_action by mike. The 8 seq-1 rows remain scheduled for May 1.

Step 2 — Thursday: Mike emails the broker for the OSHA summary

Mike opens the OSHA subjectivity, clicks Request info. Modal: broker email pre-filled, additional context "Need OSHA 300A summaries for years 2021–2025 by 2026-05-10 to support binding effective 2026-05-15." Submit.

Service:
- Records last_ac_action_at=now, last_ac_action_kind='requested_info'
- Cancels scheduled reminders for this subjectivity (sequence 1 +5d gets cancelled)
- Schedules a fresh Follow Up at now + 3d with sequence_index=99 (post-request kind), tag subjectivity:<guid>

Now this specific subjectivity has 1 active reminder due Sunday. The other 7 subjectivities still have their seq-1 reminders for Tuesday May 1.

Step 3 — Friday: Bind request reassigned to Jen

Mike's going on PTO. The bind request gets reassigned to Jen via Bind Request.ac_assigned_to=jen. The 8 subjectivity rows still have ac_assigned_to=mike — sticky pin.

Why? Mike already chased the broker for OSHA, has context on which subjectivities are real-blockers vs. paperwork. Jen owns the bind now; Mike is finishing the subjectivities he started. When subjectivities clear or escalate, the bind doesn't care who chased them — it cares that they're closed.

Sunday evening: post-request reminder for OSHA fires for mike (not Jen). The notification recipient is assigned_to=mike snapshot from the row. Mike responds from his hotel, escalates if needed.

Step 4 — Tuesday May 1: bulk +5d reminders fire

The remaining 7 subjectivities (everything except OSHA, which is on its own +3d clock) hit their seq-1 reminder. The cadence dispatcher walks the registered _DISPATCHERS for subjectivity ac reminder and emits one notification per row to mike. Inbox shows 7 individual reminders, not a wall of 50.

Mike triages:
- 3 are now received (broker sent evidence between confirm and now). UW handoff for review — Mike marks lifecycle progressed manually.
- 2 are agreed but Mike has confirmed by chat with broker — clicks Request info to reset the cadence.
- 2 are agreed and broker is non-responsive — escalates to UW Sarah with reason "Broker has not responded to two outreach attempts in 14 days."

Sarah gets two subjectivity escalated to uw notifications with severity=warning. She picks up the phone.

Step 5 — Two weeks later: 6 cleared, 2 waived

By bind effective date 2026-05-15:
- 6 subjectivities cleared (evidence reviewed, lifecycle_status=cleared) — cap #11 owns those transitions
- 2 waived by senior_uw with reason (cap #11 role-gated waiver)
- All cadence reminders auto-cancelled when each subjectivity reached cleared/waived (cap #11 hook into cap #10's cancel reminders)
- check all clear fires once the last binding subjectivity flips terminal — Mike + Sarah get the all-clear notification

The bind request stays bound (it never blocks on subjectivities — the bind gate at cap #3 fired weeks ago, with the binding-open counter as one of its blocker sources at that moment). The post-bind subjectivity loop ran independently.

What This Means for Underwriters

Sticky AC pins survive bind-request reassignment. The person who started chasing the loss runs gets the reminder, even if a new AC now owns the bind workflow.
One roll-up notification at confirm, per-subjectivity reminders later. AC inboxes don't drown in 8 identical notifications when a bind has 8 open items.
Acknowledge cancels +2d, not +5d. The system distinguishes "I see this" from "I'm driving this to clearance."
Request info reschedules. When AC actively pushes the broker, the cadence resets to +3d post-request — neither too soon nor too late for a real follow-up.
Escalate-to-UW is auditable + notified. The UW gets a severity=warning notification with the AC's reason. The subjectivity is now in the UW's queue; AC's reminders cancel.
Daily overdue sweep with calendar-day dedup. AC hears about an overdue subjectivity once per day, not on every hourly tick.
Bulk-bound subjectivities aren't a wall. 8 subjectivities each get individualized reminder cadences; AC works each row at its own pace; the work surfaces in list for ac filtered to overdue / due-this-week / status.
Cap #11 takes over progression. Clear / Mark not met / Waive transitions are the next cap's territory; cap #10 hands off the work, cap #11 closes it.

What's Next

Next: Engines and Endorsements: How a Loss Control Survey That Returns 'Unknown Risk' Auto-Drafts a Rescission Endorsement

Want to see how a sticky AC pin, a roll-up notification, and a per-subjectivity cadence respect "ack ≠ clearance" in your underwriting workstation? Request a demo.