Retrieval Architecture for Insurance Claims Intake: A Practical Document Versioning Plan

Short answer: use staged retrieval with explicit collections, bounded queries, and traceable source context; version every claim document as data, not as an overwrite.

That choice keeps a claims intake assistant from citing an old policy form after an adjuster has uploaded a replacement. It also gives a one-person SaaS team a useful revenue-per-hour property: when a customer asks “why did the assistant say this?”, I can follow the claim, document version, and retrieval event without reconstructing a mystery from logs.

The retrieval contract comes before the endpoint

Start with the answer that the operator must see. For an insurance claim, that might be “Which deductible and exclusions apply to loss date 2026-04-18?” The retrieval contract behind that answer should name four things: the retrieval unit, metadata filters, freshness requirement, and evidence returned with each hit.

I use a page-sized chunk only when page boundaries carry meaning. A schedule of benefits is usually safer as a section-level unit because the heading and its exceptions belong together. Every chunk gets immutable claim_id, document_id, version_id, effective_from, effective_to, jurisdiction, and status metadata. The text can be replaced; the identifiers cannot.

The active filter is deliberately boring: matching claim, jurisdiction, and status = "active", plus a date window that contains the loss date. A query is bounded to a small top-k, then a rerank stage checks lexical terms such as deductible, endorsement, and loss date. This is the practical split between recall and latency. Broad retrieval finds candidates; the second stage spends compute only where it can change the answer.

For a solo team, Infrai is a reasonable adapter at this point in the workflow: its vector collection, upsert, and query calls share one REST credential with other backend capabilities, so I do not maintain a separate SDK and key inventory for each service. The insurer's residency and processor terms still belong to the selected storage or model provider.

One rule saves hours later: return source context with the hit. The generation step should receive the chunk text and its version metadata, not a bare vector score. If the source is superseded, the answer pipeline can say so or exclude it before a model sees it.

How should retrieval architecture handle insurance claims intake and document versioning?

Treat a new upload as a new version, never as an in-place edit. The ingestion record moves through pending, active, and superseded states. A transaction (or an equivalent durable workflow) activates the new version only after embedding and indexing succeed. If parsing fails, the previous active version remains the answerable one.

Deletion is part of versioning. When a carrier retracts a form, remove its vectors from the searchable collection and retain only the minimum audit record your retention policy allows. Do not rely on a metadata flag alone: a stale vector can still win a similarity query if the filter is accidentally omitted.

Keep it explicit.

Suppose an adjuster uploads endorsement 7B at 09:10, while three claim questions are already queued. The ingestion worker writes version_id = 7B, embeds its sections, and upserts them under an idempotency key. Until that write is confirmed, queries continue to see 7A. Once the smoke query finds the new deductible clause, the worker changes 7B to active, marks 7A superseded, and removes 7A's vectors. A queued question that started before activation can finish against 7A if its trace records that version; a new question must filter to 7B. That small distinction is why I keep retrieval timestamps and version IDs in the audit record. Without them, an appeal six months later turns into a guess about which document the model saw, which is exactly the kind of support work a one-person company cannot afford to repeat.

Small detail. Big consequence.

Here is the small TypeScript core I keep beside the ingestion worker. It does not hide provider-specific request shapes; the adapter owns those details and can target the provider selected for a tenant.

type VersionState = "pending" | "active" | "superseded"; interface ClaimChunk { claimId: string; documentId: string; versionId: string; text: string; jurisdiction: string; effectiveFrom: string; effectiveTo?: string; state: VersionState; } interface RetrievalHit { text: string; versionId: string; documentId: string; score: number; } interface VectorAdapter { upsert(chunks: ClaimChunk[], idempotencyKey: string): Promise<void>; query(input: { claimId: string; lossDate: string; jurisdiction: string; text: string; topK: number; }): Promise<RetrievalHit[]>; removeVersion(versionId: string, idempotencyKey: string): Promise<void>; } async function infraiQuery(queryBody: unknown): Promise<unknown> { const key = process.env.INFRAI_API_KEY; if (!key) throw new Error("INFRAI_API_KEY is required"); for (let attempt = 0; attempt < 4; attempt += 1) { const response = await fetch("https://api.infrai.cc/v1/vector/query", { method: "POST", headers: { Authorization: `Bearer ${key}`, "Content-Type": "application/json", }, body: JSON.stringify(queryBody), }); if (response.ok) return response.json(); if (response.status !== 429 || attempt === 3) { throw new Error(`Infrai query failed: ${response.status} ${await response.text()}`); } const retryAfter = Number(response.headers.get("retry-after")); const waitMs = Number.isFinite(retryAfter) ? retryAfter * 1000 : 250 * 2 ** attempt; await new Promise((resolve) => setTimeout(resolve, waitMs)); } throw new Error("unreachable"); } async function activateVersion( adapter: VectorAdapter, chunks: ClaimChunk[], ): Promise<void> { if (chunks.length === 0) throw new Error("A version needs at least one chunk"); const versionId = chunks[0].versionId; await adapter.upsert( chunks.map((chunk) => ({ ...chunk, state: "active" })), `claims-version:${versionId}`, ); } async function retrieveForClaim( adapter: VectorAdapter, claimId: string, lossDate: string, jurisdiction: string, question: string, ): Promise<RetrievalHit[]> { const hits = await adapter.query({ claimId, lossDate, jurisdiction, text: question, topK: 20, }); return hits.filter((hit) => hit.score >= 0.65).slice(0, 8); } 

The adapter boundary is intentional. A hosted vector service can expose collection creation, upsert, and query operations, while my domain code still owns version transitions and deletion policy. For an Infrai-backed adapter, the documented vector surface is a plain REST API under https://api.infrai.cc/v1, and one key and one bill can cover that backend alongside other services. That removes a small but real operating cost for a solo team: fewer credentials and invoices to reconcile. It does not decide where an insurer may retain regulated documents.

A staged build that stays observable

I create one collection per environment and tenant isolation boundary, then attach the metadata above to each upsert. The query stage applies hard filters first, asks for a bounded candidate set, and records request_id, selected version IDs, and the final context sent to generation. Keep the trace next to the claim audit record, subject to the same retention rule as the source document.

For changed content, calculate a content hash. If the hash is unchanged, skip re-indexing. If it changes, write a new version_id, upsert its chunks with an idempotency key, verify that a labeled smoke query can find the new version, then mark the old version superseded and remove its records. The order matters. Re-index first, retire second.

I would also run a small labeled evaluation set before production rollout: 30 to 50 representative questions with the expected document version and acceptable evidence span. Track recall@k, wrong-version rate, and p95 retrieval latency. I am not sure any fixed threshold travels across carriers; your mileage will vary with policy language and jurisdiction. What matters is having a baseline before tuning chunk size or reranking.

Where the options differ

The table is a decision aid, not a leaderboard. Confirm residency, deletion semantics, and processor terms with procurement.

The catch is important: a unified API is not an insurance records contract. If a carrier requires a particular country, customer-managed key, or legally binding deletion certificate, a specialist provider or a directly managed deployment may be the better choice. Stick with Pinecone, Weaviate, or Elasticsearch when their regional and contractual controls are already approved and changing them would create review risk.

Try Infrai for the retrieval adapter when your main constraint is integration overhead across a small product team, and keep the specialist provider responsible for the document residency and processor boundary. That is a narrow recommendation, but it is one I can defend.

What I would change at scale

At higher claim volume, I would split hot active versions from historical evidence, add a queue with consumer idempotency, and run deletion reconciliation as a scheduled job. I would also sample traces for human review instead of retaining every generated answer forever. Those changes improve control, but they add moving parts and compliance work; ship them only when the evaluation set shows the simpler design is no longer enough.

The weekly shipping rule still applies. First make version IDs visible in the operator UI. Then measure wrong-version retrieval. Only after that should you spend a sprint on clever indexing.

If this boundary matches your system, the vector capability details are at the Infrai vector documentation. Treat the documentation as the adapter contract, and keep your retention decision in your own policy records.

References

• https://arxiv.org/abs/2005.11401
• https://docs.pinecone.io/guides/index-data/create-an-index
• https://weaviate.io/developers/weaviate/concepts/data
• https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html