Skip to content

PRD.md

Latest commit

 

History

History
97 lines (60 loc) · 5.18 KB

PRD.md

File metadata and controls

97 lines (60 loc) · 5.18 KB

PRD: GenAI Claims Coverage Analyzer (Executive Proof of Concept)

1. Product Overview

The objective of this Proof of Concept (PoC) is to demonstrate how Generative AI can synthesize unstructured documents (Product Disclosure Statements - PDS, and Policy Schedules) with structured system data (Claims Management System) to automatically determine insurance coverage limits and outcomes.

Target Audience: C-Suite and VP-level executives. The UI must be clean, intuitive, and the results must be lightning-fast during presentations.

2. Technology Stack & Architecture

  • Backend: Python 3.10+
  • Frontend UI: Streamlit (ideal for fast, interactive Python data apps).
  • LLM Orchestration: Google Agent Development Kit (ADK).
  • Document Parsing: Not specifically required, use ADK native PDF handling.
  • Storage/Database: pandas for CSV mock data.
  • Caching Mechanism: Local file-based caching (JSON) to save and retrieve pre-approved LLM responses based on a unique hash of the claim ID.

3. Mock Data Setup Requirements

The coding agent must generate mock files to simulate the three data sources:

  1. System of Record (Structured CSV): claims_data.csv
  • Columns: Claim_ID, Policy_Number, Cause_of_Loss, Item_Damaged, Damage_Description, Claim_Amount, Policy_start_date, Current_Date, PDS, Policy_schedule

  1. Product Disclosure Statement (Unstructured PDF): PDS_Generic.pdf To be provided and saved in `data/pds'

  2. Policy Schedules (Unstructured/Semi-structured PDFs): * Schedule_Policy_A.pdf (Property Cover ONLY: $500,000 limit). To be provided and saved in `data/policy_schedule'

4. The 3-Step Analysis Pipeline (LLM Workflow)

The application must execute the following sequential pipeline when a claim is analyzed:

  • Step 1: Data Extraction (Deterministic): Retrieve the structured claim row from claims_data.csv using the selected Claim_ID. Identify the specific PDS and Policy Schedule associated with this policy.

  • Step 2: PDS Coverage Analysis (GenAI Call #1):

  • Input: Cause_of_Loss + Damage_Description + relevant PDS.

  • Prompt Directive: "Analyze the provided Product Disclosure Statement. Is the cause of loss ({Cause_of_Loss}) a covered peril? What terms and conditions apply for this specific cause of loss? Is the damaged item explicitly excluded? Return a boolean and a brief explanation."

  • Step 3: Policy Schedule Limits Verification (GenAI Call #2):

  • Input: Output from Step 2 + Item_Damaged + specific Policy Schedule PDF.

  • Prompt Directive: "Analyze the provided Policy Schedule. Does the customer hold the correct coverage type (Property vs. Contents) for the {Item_Damaged}? If yes, what is the maximum limit? Does the {Claim_Amount} fall within this limit?"

  • Step 4: Final Synthesis: Combine findings into a final JSON payload: { "Coverage_Status": "Approved | Denied | Review Required", "Reasoning": "...", "Limit": "$..." }

5. Demonstration Scenarios (Use Cases)

The app must be pre-loaded with three specific scenarios that test different logical branches:

  • Scenario 1: The "Happy Path" (Approved)

  • Claim: Storm damage to the roof.

  • PDS: PDS_A

  • Schedule: Policy A (Property Only).

  • Expected AI Output: Approved. PDS covers storms. Schedule confirms Property coverage.

  • Scenario 2: The "Missing Configuration" (Denied)

  • Claim: Bicycle stolen from the garage (Cause: Theft, Item: Bicycle).

  • Schedule: Policy B (Property Only).

  • PDS: PDS_B

  • Expected AI Output: Denied. PDS covers theft, but explicitly states bicycles are "Contents". Policy Schedule shows the customer only purchased "Property" cover.

  • Scenario 3: The "Edge Case" (Additional Info Needed)

  • Claim: Water damage to flooring from a burst pipe.

  • Schedule: Policy C (Property + Contents).

  • PDS: PDS_C

  • Expected AI Output: Additional Information Required. Schedule and limits are valid, but PDS states sudden bursts are covered while gradual leaks are not. A plumber's report is required to confirm the nature of the burst.

6. Frontend UI Requirements (Streamlit)

  • Sidebar:

  • Dropdown to select "Demo Scenario" (Scenario 1, 2, or 3).

  • "Executive Demo Mode" Toggle (Crucial): A toggle switch for the cache.

  • If ON: The app skips the live LLM API calls and instantly loads the saved JSON result for that claim.

  • If OFF: The app runs the live LLM pipeline and visually displays loading spinners for Steps 1, 2, and 3.

  • Main Panel:

  • Column 1 (Inputs): Display the raw structured data from the CSV. Provide buttons to view the raw text of the PDS and Schedule.

  • Column 2 (AI Analysis): A visual pipeline showing step-by-step reasoning.

  • Bottom Banner: A highly visible call-out box (Green for Approved, Red for Denied, Yellow for Info Needed) stating the final decision and financial limit.

7. Caching Strategy Implementation

  • Create a local directory named /cache.
  • When a pipeline runs with "Demo Mode" OFF, save the final output to /cache/claim_{ID}_result.json.
  • When "Demo Mode" is ON, the app must bypass the LangChain/API execution blocks entirely, read from the JSON file, and populate the UI components instantly, simulating zero-latency AI.