> 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/architecture-and-capabilities.md).

# Architecture & capabilities

## Overview

The Warranty Claims Manager is built on three agentic skills that together take a claim submission from intake through to a created incident or a routed exception: Multi Source Claim Ingestion, Extraction and Entitlement Validation, and Disposition and Exception Handling. This article covers those skills, the claim workflow they share, integration points, and how the system tiers and routes human review so a claims team isn’t flooded with individual notifications.

## Agentic Skills

#### Multi Source Claim Ingestion

Collects claim submissions from a monitored mailbox, client or dealer portal, and partner platform, configured per source, polling each source on a configured interval if no system event is available. This skill decomposes a bulk document carrying many claims into discrete claim records before any of them are assessed individually.

#### Extraction and Entitlement Validation

Interprets unstructured claim text into structured fields, including part reference, product reference, failure date, and customer identity. This skill checks entitlement against the purchase date and warranty term held in the system of record, verifies part and product references, and matches each claim against open and recently settled claims to suppress duplicate submissions.

#### Disposition and Exception Handling

Creates only eligible and complete claims in the target workflow, whichever system that is. This skill holds incomplete claims with the missing field named, rather than rejecting them generically, escalates low-confidence extractions and ambiguous entitlement to a human queue with its reasoning attached, and records the disposition reason for every claim as the audit trail for supplier recovery and dispute.

#### Claim Processing Workflow

The following table outlines the process from claim intake through to incident creation.

| **Stage**             | **What the System Does**                                             | **Action / Output**                                                          | **Channel**                       |
| --------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------------- |
| Claim Collected       | Collects submissions from each configured intake source              | Bulk document received                                                       | Email / Portal / Partner Platform |
| Claim Decomposed      | Splits a bulk document into discrete claim records                   | Individual claims identified                                                 | System of Record                  |
| Fields Extracted      | Interprets unstructured text into structured fields                  | Part reference, product reference, failure date, customer identity extracted | System of Record                  |
| Entitlement Validated | Checks purchase date and warranty term against the system of record  | Claim confirmed in or out of cover                                           | System of Record                  |
| References Verified   | Verifies part and product references                                 | References confirmed or flagged                                              | System of Record                  |
| Duplicates Matched    | Matches against open and recently settled claims                     | Duplicate or resubmission suppressed                                         | System of Record                  |
| Held or Escalated     | Names missing fields, or escalates low-confidence or ambiguous cases | Held claim or human queue item created                                       | Collaboration Channel             |
| Incident Created      | Creates eligible, complete claims in the target workflow             | Warranty claim incident created with reference                               | Target Claims System              |

## Integration Points

**System of Record:** Purchase date, warranty term, and part and product master data are read from the system of record, which the worker treats as authoritative. It holds no independent warranty term master.

**Target claims workflow (e.g. IFS Assyst):** Intake source and write target are configured adapters against a fixed internal contract. IFS Assyst is one supported write target, not the platform the worker is built on, so the same worker can serve a different claims system or ERP.

**Email (e.g. Microsoft Outlook):** A monitored mailbox is one of the configurable intake sources for incoming claim submissions.

**Collaboration channel (e.g. Microsoft Teams):** Used for escalations, held-claim digests, and human-in-the-loop disposition actions.

## Human-in-the-Loop Design

At full intake coverage, a notification for every held claim would flood a claims team within a day, so escalation is tiered, grouped, routed, and capped rather than sent one claim at a time.

#### Escalations are handled by severity:

**Immediate:** A write failure that has exhausted retry, or an intake source that has failed authentication, is delivered immediately, targeted for same-working-day response.

**Next working day:** Entitlement that’s indeterminate, a date conflict with the record, or a duplicate match in the review band is batched at a configured cadence within the working day.

**Within the week:** Held claims with named missing fields, unresolved references, and unreadable submissions are delivered as a daily digest with inline disposition actions, grouped by submission and by submitting party.

**Review cadence:** Hold ageing, a sustained rejection rate by submitting party, and unknown-reason accumulation are delivered as a weekly digest to operations and configuration owners.

One hundred claims held from a single bulk file arrive as one queue item with one hundred lines, never as one hundred separate notifications. Where a single cause accounts for a large share of a submission, the cause is stated once at the group level rather than repeated per claim.

Every escalation carries the extracted claim, the evidence pointer into the source text for each field, the entitlement decision with the dates and cover source relied on, and, where relevant, the duplicate candidate set. Disposition options are: confirm, correct a field, override the entitlement outcome, override a duplicate match, or reject, with every override requiring a mandatory reason code. A human disposition is final: the worker does not re-evaluate a claim a person has already decided.

## Feedback and Continuous Improvement

A corrected field is recorded as a correction against the original extraction, with the original value retained, forming the tuning signal for extraction quality. Override rate is reported per field and per validation rule: a field overridden frequently points to an extraction defect, and a rule overridden frequently points to a configuration defect, giving the team a concrete signal for where to tune the system rather than a general sense that something is off. Every claim reaches a terminal state with a reason, so the full disposition history stays available for review, audit, and supplier recovery.