Real-Time Decisioning Demo | Insurance Claims Triage
Pipeline<10ms
1 / 9
1
Architecture
2
Claim Reported
3
Ingest
4
Context
5
Feature Serving
6
Ranking
7
Business Impact
8
Outcome
9
Architecture Recap
Stage 1: The Architecture
Harbor Mutual's Real-Time Decisioning Stack
Five tiers form a continuous loop: ingest, context, decide, act, learn. Redis assembles policy, prior claims, fraud, and repair context before the first triage screen renders. Systems of record stay where they are. Redis becomes the operational context layer that makes the moment actionable.
Data Sources

Policy Admin System

Operational source

Claims Management Platform

Operational source

Photo / Document Repository

Operational source

Fraud Platform

Operational source

Repair Network APIs

Operational source

Kafka / FNOL Events

Operational source

Ingest Layer

Redis Data Integration (RDI)

CDC from repositories and operational databases with sub-second activation

Redis Feature Form + Streams

Feature serving and live event hydration from Kafka, Redis Streams, and industry APIs

Unified Context Layer

Redis RAM

Hot claim state, active fraud signals, live adjuster capacity, and document verification status

Redis Flex

Warm claims history, fraud pattern embeddings, policy context, and repair network state

Feature Store

Fraud likelihood, straight-through eligibility, SIU routing, and settlement risk features

Redis Context Retriever

Assembles the Claimant 360 — policy state, claim history, and risk context — and exposes it as structured MCP tools for the decision engine

Decision Engine

Eligibility Rules

Policy, compliance, and inventory constraints

NBA Ranker

Contextual ranking weighted by value, risk, and fit

Policy Arbitration

One action selected for the current moment

Output Channels (Act)

Claims Portal

Customer-facing activation surface

Adjuster Desktop

Customer-facing activation surface

Mobile App

Customer-facing activation surface

SMS / Email

Customer-facing activation surface

↺
Learn:  Decision logs and outcomes stream back into model training, policy updates, and the Redis context layer.
Decision latency
8.0 ms
Cycle time reduction
-41%
Customer satisfaction lift
+26 pts
Stage 2: Trigger Event
Carlos Ramirez creates a decision moment
A policyholder submits an auto claim with photos and location data from the mobile app. Route the claim to the fastest safe path using coverage, severity, fraud, and partner availability.
Live Trigger
CR
Carlos Ramirez
Auto policy | low prior severity | mobile FNOL with photos
CLAIMS
Eventclaim_reported
Customer surfaceClaims portal
Decision objectiveCycle time + cost
Decision windowBefore the surface finishes rendering
Context requiredHistory + live signals + policy
Business stakes-41%
Why This Moment Matters
Redis assembles policy, prior claims, fraud, and repair context before the first triage screen renders.
Without Redis: the application waits on siloed repositories and defaults to a generic next step.
With Redis: the decision surface opens with ranked, contextual action already staged for the moment.
Stage 3: Ingest
Industry repositories and streams flow into Redis
These are common repositories and streaming APIs for insurance decisioning. They remain the systems of record. Redis activates the working set needed to decide now.
Redis Data Integration (RDI)Redis Feature Form
Source Systems → Redis
GUID
Guidewire / Duck Creek
Common repository or streaming source for guidewire context
→
DOCU
Document cloud
Common repository or streaming source for document context
→
FRAU
Fraud API
Common repository or streaming source for fraud context
→
TELE
Telematics / location stream
Common repository or streaming source for telematics context
→
KAFK
Kafka / Redis Streams
Event streaming via Kafka or Redis Streams — no separate broker required with Redis Streams built-in
→
REPA
Repair partner APIs
Common repository or streaming source for repair context
→
Ingest Pipeline Status
CDC modeReal-time
Streaming lag<100 ms
Feature parityTrain = serve
Custom sync code0 lines
Serving roleOperational context layer
Stage 4: Context Assembly
History and live state converge into one working view
Redis assembles profile history, claimant or policy state, live intent, and policy constraints in one low-latency lookup path. What looked like a simple event in Stage 2 becomes a much richer decision moment here.
Redis RAMRedis FlexRedis Context Retriever
Historical Context
Customer value bandavailable
Tenure / relationship depthEstablished
Prior interaction patternKnown baseline available
Eligibility stateResolved in memory
Policy constraintsCurrent and active
Action historyFrequency caps enforced
Live Context
Current intentCycle time + cost
Streaming signal stateFresh for this session
Capacity / inventoryAvailable
Risk / complianceWithin active rules
Surface readinessClaims portal
Decision scopeStraight-through repair scheduling
Key insight: Redis Context Retriever assembles the Claimant 360 — policy state, claim history, and risk context — so the decision engine has exactly what it needs. The winning action becomes obvious only when historical context and live signals appear in the same response path.
Stage 5: Feature Serving
Online features hydrate the ranker in milliseconds
Redis Feature Form serves model-ready signals from Redis with train-serve parity. No fan-out calls to downstream systems during decisioning. No stale fallbacks.
Redis Feature FormRedis Feature Store
severity_score
Model or ranking signal pulled online at decision time.
low0.3 ms
coverage_fit
Real-time feature served from Redis with train-serve parity.
full0.4 ms
fraud_risk
Risk and policy factor used to gate the action.
low0.5 ms
repair_capacity
Real-time feature served from Redis with train-serve parity.
available0.6 ms
claimant_sentiment
Real-time feature served from Redis with train-serve parity.
neutral0.7 ms
straight_through_probability
Real-time feature served from Redis with train-serve parity.
0.910.8 ms
Feature Serving Performance
Features Hydrated
186
P99 Lookup Latency
<10ms
Train / Serve Parity
100%
Stage 6: Ranking
Candidate actions are ranked for this moment
Rules, policies, vector similarity, and business weighting combine to rank the best action now. The winner is selected because it fits the moment, not because it is the easiest generic fallback.
Redis SearchNBA RankerRules Engine
#1 Winner
PRIMARY ACTION
Straight-through repair scheduling
Low severity and strong coverage fit
NBA score0.94
#2 Candidate
ALTERNATIVE
Virtual adjuster review
Reasonable fallback, but slower than needed
NBA score0.79
Suppressed
POLICY
SIU escalation
Suppressed because fraud indicators are below threshold
Suppressed0.24
Stage 7: Business Impact
The value of choosing the right action now
Fast decisions matter, but the real value is choosing the right action while the moment is still open. Redis improves both latency and outcome quality.
Decision Economics
Decision latency8.0 ms
Cycle time reduction-41%
Customer satisfaction lift+26 pts
The key insight: value compounds when the decision surface uses live operational context instead of generic fallback logic.
Moment Outcome
Generic
Siloed systems
lower relevance
→
Redis
Context-aware
higher impact
Stage 8: Outcome
Same surface. Different decision layer.
On the left is a generic or delayed path. On the right is the Redis-powered experience with ranked action already staged. Same customer moment. Different outcome.
Generic Experience
HARBOR MUTUAL
GENERIC PATH
CR
Carlos Ramirez
Insurance workflow
What the system knows
Partial profile, delayed retrieval, and limited live context.
Action shown
Virtual adjuster review
Outcome risk
The action fits broadly, but not the full moment.
Lower
relevance
Higher
fallback use
Siloed
context
Redis-Powered Experience
HARBOR MUTUAL
BRIEF READY · 8.0 ms
CR
Carlos Ramirez
Decision-ready profile
#1 Next Best Action
Straight-through repair scheduling
Low severity and strong coverage fit
Why it wins
Combines history, live signals, business value, and active policy constraints in the same low-latency response.
Visible impact
Cycle time reduction: -41%.
High
relevance
Low
fallback use
Ready
before render
Stage 9: The Architecture, Proven
Architecture first. Architecture last. Outcome in the middle.
The same five tiers you saw at the start now tie directly to a measurable decision outcome. Common repositories and streaming APIs stay in place. Redis remains the operational decisioning layer that makes the customer moment work.
Data Sources

Policy Admin System

Operational source

Claims Management Platform

Operational source

Photo / Document Repository

Operational source

Fraud Platform

Operational source

Repair Network APIs

Operational source

Kafka / FNOL Events

Operational source

Ingest Layer

RDI

CDC and activation from systems of record

Streams + Features

Live event hydration and model parity

Unified Context Layer

Redis RAM

Hot claim state, active fraud signals, live adjuster capacity, and document verification status

Redis Flex

Warm claims history, fraud pattern embeddings, policy context, and repair network state

Feature Store

Fraud likelihood, straight-through eligibility, SIU routing, and settlement risk features

Redis Context Retriever

Assembles the Claimant 360 — policy state, claim history, and risk context — and exposes it as structured MCP tools for the decision engine

Decision Engine

Rules

Eligibility, compliance, and policy

Ranker

Propensity, value, and fit

Arbitration

One action selected now

Output Channels

Claims Portal

Customer-facing activation surface

Adjuster Desktop

Customer-facing activation surface

Mobile App

Customer-facing activation surface

SMS / Email

Customer-facing activation surface

↺
Learn:  Outcomes feed retraining, policy updates, and future decisions without changing the systems of record.
Decision latency
8.0 ms
Cycle time reduction
-41%
Customer satisfaction lift
+26 pts
Press ← → or click to navigate