> For the complete documentation index, see [llms.txt](https://kb.theloops.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.theloops.io/digitalworkers/ifs-loops-digital-workers/digital-worker-guides/warranty-claims-manager/core-concepts/fundamentals.md).

# Fundamentals

## Overview

The Warranty Claims Manager is an AI-powered Digital Worker that validates a warranty claim before it becomes a record. It collects claim submissions from any permitted source, decomposes a bulk document into discrete claims, and extracts structured fields from unstructured text. Each claim is validated against the system of record: entitlement checked against purchase date and warranty term, part and product references verified, and duplicates matched against open and recently settled claims.

Only eligible and complete claims are created as warranty claim incidents. Everything else is routed to a human queue with the reason attached. The Warranty Claims Manager validates; it does not adjudicate. It never decides what a claim is worth, approves settlement, or issues credit, replacement, or goodwill. Every monetary outcome remains a human decision or a downstream system decision.

## Key Benefits

**Ineligible claims stopped at intake:** Expired cover, wrong part references, and duplicate submissions are caught before a record is ever created.

**Defensible claim decisions:** Every acceptance and rejection carries a recorded reason, available for audit and supplier recovery.

**Not tied to one claims system:** Intake source and write target are configured adapters, so the same worker can serve a different claims system or ERP.

**Adjudication capacity released:** Agent effort moves from splitting and checking batches to settling the claims that are real.

## The Challenge It Solves

Warranty claims arrive from multiple uncontrolled sources, in bulk, and in unstructured form. A single submission can carry twenty-five to one hundred individual claims in one document. Before any of them can be worked, a person splits the batch, extracts each claim, looks up the part or product reference in a separate system, checks whether cover was still active on the failure date, and identifies claims missing customer or product detail. Duplicate submissions of the same failure are caught by memory rather than by rule.

The cost is paid twice: once in the manual pre-check, and again in what gets through it, because an ineligible claim still becomes a record that has to be created, investigated, and withdrawn. Claim volume drives administrative headcount rather than settlement throughput, and the reason a claim was rejected is rarely recorded in a form anyone can audit.

## Before and After

#### Before

Before the Warranty Claims Manager, working a bulk claim submission requires manual effort at every stage:

{% stepper %}
{% step %}
Split a bulk claim document apart by hand, claim by claim, before any assessment can begin
{% endstep %}

{% step %}
Look up each part or product reference in a separate system, one at a time
{% endstep %}

{% step %}
Check manually whether cover was still active on the failure date
{% endstep %}

{% step %}
Catch duplicate submissions from memory alone
{% endstep %}

{% step %}
Investigate and withdraw claims that should never have qualified but slipped through the pre-check
{% endstep %}
{% endstepper %}

#### After

With the Warranty Claims Manager, the same process runs automatically:

{% stepper %}
{% step %}
Claim submissions are collected from each configured source, whether a monitored mailbox, a client or dealer portal, or a partner platform
{% endstep %}

{% step %}
Bulk documents are decomposed into discrete individual claims
{% endstep %}

{% step %}
Structured fields are extracted from unstructured text, including part reference, product reference, failure date, and customer identity
{% endstep %}

{% step %}
Entitlement is checked against the purchase date and warranty term, and part and product references are verified
{% endstep %}

{% step %}
Each claim is matched against open and recently settled claims to catch duplicates before they get paid twice
{% endstep %}

{% step %}
Only eligible, complete claims move forward, created as warranty claim incidents with a recorded reason behind every outcome
{% endstep %}
{% endstepper %}

## How It Works

The Warranty Claims Manager follows a consistent sequence for every claim submission it processes.

**Collect and decompose:** The worker collects claim submissions from each configured intake source and decomposes a bulk submission carrying many claims into discrete claim records.

**Extract structured fields:** Structured claim fields are extracted from unstructured text, including part reference, product reference, failure date, and customer identity, with a confidence value and an evidence pointer on every extracted field.

**Validate entitlement:** Entitlement is checked against the purchase date and warranty term held in the system of record. The worker holds no independent warranty term master and never infers cover from the claim narrative alone.

**Verify part and product references:** Part and product references are verified against the system of record.

**Detect duplicates:** Each claim is matched against open and recently settled claims to suppress duplicate and previously rejected resubmissions.

**Hold or escalate:** Claims missing required information are held with the specific missing fields named, rather than rejected outright. Low-confidence extractions and ambiguous entitlement cases are escalated to a human queue, with the reasoning attached.

**Disposition:** Users can approve all valid claims, reject the batch, or approve selected claims individually before any incident is created. Only eligible, complete claims move forward, created as warranty claim incidents with a recorded reason behind every outcome.

## What Triggers the Warranty Claims Manager

**A claim submission arriving at a configured source:** Whether that’s a monitored mailbox, a client or dealer portal, or a partner platform, on a configured interval.

**A bulk document carrying multiple claims:** A single submission carrying many individual claims triggers decomposition into discrete claim records before any of them are assessed.

**A claim with incomplete information:** Missing required fields trigger a held state with the specific gap named, rather than a rejection.

**A low-confidence extraction or ambiguous entitlement case:** These are escalated to a human queue with the reasoning attached, rather than resolved on a guess.

**A potential duplicate:** A claim matching an open or recently settled claim triggers duplicate suppression before it can be paid twice.