IamHetPatel/EchoClaim

VOICE THAT UNDERSTANDS · CLAIMS THAT MOVE; We built a voice agent that already knows the caller.

0

stars

42

commits

Python

primary language

Sep 8, 2026

updated

README

EchoClaim

A phone-based first-notice-of-loss (FNOL) claims-intake assistant for a German motor insurer. The assistant, Jamie, answers an inbound call, works from what the insurer already knows about the caller, gathers the remaining claim details in conversation, and writes everything down as structured data while the call is still going. Coverage answers are grounded in the policy wording and cited. The conversation and the structured extraction run in parallel so the dialogue stays natural.

Architecture

Inbound call -> Gradium STT -> GeminiBrain -> Gradium TTS -> Caller
                                  |  (Gemini 2.5 Flash, known-context injection,
                                  |   function-calling tools, model fallback chain)
                                  v
                       transcript fans out in parallel
                                  v
        GLiNER2 extractor -> 15 claim pillars + 5 fraud signals -> WS bridge -> dashboard

A retrieval subsystem backs the conversation. Policy and regulation documents are chunked on German §/Teil markers, embedded, and indexed. A coverage_lookup tool fetches and cites the exact clause before Jamie states any coverage fact, and reports low confidence (so Jamie declines to answer) when nothing matches well.

Stack

LayerComponent
SpeechGradium STT / TTS
ConversationGemini 2.5 Flash, with automatic fallback to 2.0 / 1.5 Flash
Context & toolsKnown-context CRM injection; Tavily real-time lookup; coverage_lookup retrieval
Extractionfastino/gliner2-base-v1 (fine-tuned), benchmarked against LLM structured output
RetrievalBGE-M3 embeddings, bge-reranker-v2-m3, Qdrant, plus a dependency-free BM25 fallback for offline use
TelephonyLiveKit rooms, Twilio SIP
ServicesFastAPI WebSocket bridge, React dashboard
PrivacyPII redaction on transcripts and logs

Repository layout

agent/         System prompt, claim-state tracker, Gemini client
voice/         LiveKit + Gradium production voice loop (and a mic-only quickstart)
telephony/     Twilio SIP / LiveKit room glue
extraction/    GLiNER2 microservice + benchmark vs. LLM structured output
tools/         Real-time lookups exposed as function calls (Tavily, coverage_lookup)
retrieval/     RAG over the policy corpus: chunking, embedding, index, retriever, eval
bridge/        FastAPI WebSocket bridge to the dashboard
dashboard/     React dashboard
data/          Mock CRM profiles, the policy corpus, and the retrieval golden set
tests/         Unit + adversarial conversation tests
scripts/       run_demo_text.py and other operator commands

Quick start (text mode, no telephony, no API keys)

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
python scripts/run_demo_text.py --crm max_mueller

This runs Jamie against typed input with the GLiNER2 extractor live and the dashboard updating over WebSocket. Coverage questions trigger coverage_lookup, which cites the matching policy clause. No paid infrastructure is needed.

For the voice loop and Twilio SIP setup, see telephony/README.md.

Retrieval

The retrieval subsystem (retrieval/) runs locally with no paid services. See retrieval/README.md. Quick checks:

python -m retrieval.ingest --dry-run     # chunk + embed the corpus, write a manifest
python -m retrieval.eval                 # precision@k / recall@k / MRR / nDCG

Retrieval quality is measured against a golden set of coverage questions, each mapped to the clause it should return (data/eval/golden_set.jsonl). The lexical backend and the hash embedder are deterministic, so the metrics are reproducible.

Status

Built so far: the voice loop, known-context injection, GLiNER2 extraction with a benchmark, the tool layer, the dashboard, and the retrieval subsystem (structure-aware ingest, a Qdrant named-vector index, query plus rerank, the cited coverage_lookup tool, and the ranking-metric evaluation).

Next: an LLMOps layer (versioned prompt registry, LLM-judge groundedness scoring, PII-redacted trace logging, a CI eval gate, drift monitoring) and zero-downtime embedding-model migration. The retrieval index already stores vectors under named versions so two embedding models can coexist, which is what the migration builds on.

License

See LICENSE.

Contributors

IamHetPatel

23 commits

Viraj5503

17 commits

IamHetPatel/EchoClaim

VOICE THAT UNDERSTANDS · CLAIMS THAT MOVE; We built a voice agent that already knows the caller.

0

stars

42

commits

Python

primary language

Sep 8, 2026

updated

README

EchoClaim

A phone-based first-notice-of-loss (FNOL) claims-intake assistant for a German motor insurer. The assistant, Jamie, answers an inbound call, works from what the insurer already knows about the caller, gathers the remaining claim details in conversation, and writes everything down as structured data while the call is still going. Coverage answers are grounded in the policy wording and cited. The conversation and the structured extraction run in parallel so the dialogue stays natural.

Architecture

Inbound call -> Gradium STT -> GeminiBrain -> Gradium TTS -> Caller
                                  |  (Gemini 2.5 Flash, known-context injection,
                                  |   function-calling tools, model fallback chain)
                                  v
                       transcript fans out in parallel
                                  v
        GLiNER2 extractor -> 15 claim pillars + 5 fraud signals -> WS bridge -> dashboard

A retrieval subsystem backs the conversation. Policy and regulation documents are chunked on German §/Teil markers, embedded, and indexed. A coverage_lookup tool fetches and cites the exact clause before Jamie states any coverage fact, and reports low confidence (so Jamie declines to answer) when nothing matches well.

Stack

LayerComponent
SpeechGradium STT / TTS
ConversationGemini 2.5 Flash, with automatic fallback to 2.0 / 1.5 Flash
Context & toolsKnown-context CRM injection; Tavily real-time lookup; coverage_lookup retrieval
Extractionfastino/gliner2-base-v1 (fine-tuned), benchmarked against LLM structured output
RetrievalBGE-M3 embeddings, bge-reranker-v2-m3, Qdrant, plus a dependency-free BM25 fallback for offline use
TelephonyLiveKit rooms, Twilio SIP
ServicesFastAPI WebSocket bridge, React dashboard
PrivacyPII redaction on transcripts and logs

Repository layout

agent/         System prompt, claim-state tracker, Gemini client
voice/         LiveKit + Gradium production voice loop (and a mic-only quickstart)
telephony/     Twilio SIP / LiveKit room glue
extraction/    GLiNER2 microservice + benchmark vs. LLM structured output
tools/         Real-time lookups exposed as function calls (Tavily, coverage_lookup)
retrieval/     RAG over the policy corpus: chunking, embedding, index, retriever, eval
bridge/        FastAPI WebSocket bridge to the dashboard
dashboard/     React dashboard
data/          Mock CRM profiles, the policy corpus, and the retrieval golden set
tests/         Unit + adversarial conversation tests
scripts/       run_demo_text.py and other operator commands

Quick start (text mode, no telephony, no API keys)

python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
python scripts/run_demo_text.py --crm max_mueller

This runs Jamie against typed input with the GLiNER2 extractor live and the dashboard updating over WebSocket. Coverage questions trigger coverage_lookup, which cites the matching policy clause. No paid infrastructure is needed.

For the voice loop and Twilio SIP setup, see telephony/README.md.

Retrieval

The retrieval subsystem (retrieval/) runs locally with no paid services. See retrieval/README.md. Quick checks:

python -m retrieval.ingest --dry-run     # chunk + embed the corpus, write a manifest
python -m retrieval.eval                 # precision@k / recall@k / MRR / nDCG

Retrieval quality is measured against a golden set of coverage questions, each mapped to the clause it should return (data/eval/golden_set.jsonl). The lexical backend and the hash embedder are deterministic, so the metrics are reproducible.

Status

Built so far: the voice loop, known-context injection, GLiNER2 extraction with a benchmark, the tool layer, the dashboard, and the retrieval subsystem (structure-aware ingest, a Qdrant named-vector index, query plus rerank, the cited coverage_lookup tool, and the ranking-metric evaluation).

Next: an LLMOps layer (versioned prompt registry, LLM-judge groundedness scoring, PII-redacted trace logging, a CI eval gate, drift monitoring) and zero-downtime embedding-model migration. The retrieval index already stores vectors under named versions so two embedding models can coexist, which is what the migration builds on.

License

See LICENSE.

Contributors

IamHetPatel

23 commits

Viraj5503

17 commits

Languages

Python

80.2%

JavaScript

8.5%

CSS

7.1%

HTML

3.4%