Adaptive FNOL Agent
Validation Prototype

A governed path from a claimant's story to the next safe action

SECOND BREAKFAST FELLOWSHIP
Iris Zhou | Jim Xu | Leif Wei | Xiang You | Yang Li

AWS CHALLENGE 2026 / VALIDATION PRESENTATION

One incident quickly becomes a coordination problem

Claimant

“I was rear-ended. The bumper is damaged, but the car still drives.”

Is everyone safe, and is the scene secure?

What damage can you see, and is the vehicle roadworthy?

Was Police involved, and is any report still pending?

Assess

Vehicle assessorDamage evidence, scope and outcome

Repair

RepairerEstimate, availability and next appointment

Evidence

PoliceReport status and reference when available

Decide

Claims staffAuthority, exceptions and professional judgement

One Claim

Shared contextFacts, evidence, consent, service state and next responsibility

External work must return to the Claim, not fragment the journey.

Our Sprint goal was a repeatable VP baseline

01Adaptive intakeNatural, focused and correctable

02Dynamic Form & EvidenceStructured facts with source and state

03Shared Claim ContextOne revisioned source of truth

04Handoff & WorkbenchContext continues into staff work

05Governed Agent RuntimeProposal, authority and result separated

06Business & integration readinessKnown inputs, limits and failure paths

Sprint 3

One repeatable
validation journeyClaimant + Agent + staff

A VP baseline is useful only when the same behaviour and boundaries can be observed again.

Research turned external coordination into implementable boundaries

Stakeholder & service

WHO / HOW / RESULT

Service identityPolice, assessor, repairer and other relevant participants

Service formAPI, form, link, phone or staff-assisted request

Inputs & outputsRequired fields, evidence, documents and returned status

Operational limitsAccess, unavailable providers, timeout and unknown outcome

Privacy & consent

WHY / WHAT / AUTHORITY

PurposeWhy the disclosure is necessary for this service

Minimum dataOnly the fields and Evidence needed for the request

PermissionRecord versus send, claimant consent and staff authority

ControlRefusal, withdrawal, visibility, retention and audit

These are development inputs, not claims that every live provider is already connected. Verified facts remain distinct from simulation-only service paths.

The Agent proposes; the governed Runtime decides

AGENT INPUT

PromptScenario rules and task instructions

Tool-call request

Governed Runtimedecides what may happen

AUTHORITYJUDGEMENTNEXT STEPCONSENTREVISIONVISIBILITY

01 / BOUNDED READ

Context & memoryCurrent Claim, Dynamic Form, history and open work

02 / INTERNAL DATA

Database & policy RAGOwn data queries and sourced policy details

03 / EXTERNAL SERVICE

Third-party interfacesPolice contact lookup or a governed repair request

Tool result → persisted Claim State → role-safe projection

Privacy-aware model option: locally deployed Qwen3.8-27BThe model may change; the same Gateway, schema, tool and authority contract remains.

The claimant journey stays continuous as the work expands

Support

Evidence & policy

Coordinate

Third-party service

Continue

Create or hand off

One journey, one recoverable Claim, one visible next step.

The Workbench continues the same Claim, not a second workflow

Own

Claim or collaborate

Act

Authorised action

Progress

Lifecycle queue

Workbench is a live projection of Claim work, not a manually maintained parallel board.

Next, strengthen the boundaries that make the journey trustworthy

01Security, privacy & risk management

Strengthen authority, disclosure, recovery and operational-risk controls.

02Refine boundary test scenarios

Add detailed cases for ambiguity, failure, recovery and unusual claimant needs.

03Research and validate fraud judgement

Deepen the decision model, then test whether signals are useful without creating false conclusions.

Trust must be demonstrated at the boundaries, not assumed from a happy path.