Modernizing a Claims Monolith While Adding a Cited Document Assistant
Calder Insurance runs a 12-year-old Java EE claims monolith on 14 on-premises VMs backed by a 350 GB Oracle database. Releases happen about 40 times a year and consume a full weekend; two teams routinely block each other on the shared database. Leadership approved a two-year modernization with three goals: ship weekly, cut claims-handling time, and let 900 adjusters search 2.5 million claim PDFs a year and receive answers that cite the source page. Staff have solid Java and Spring skills, and one team has run Kubernetes on-premises for 18 months. Regulated claim data cannot leave the IBM Cloud account except through an approved egress proxy, and model outputs used in decisions must be explainable and auditable. The CIO is wary of a multi-year big-bang rewrite and wants measurable value within two quarters.
1. Sequence the modernization. What do you extract first, what runs it, and what is the concrete two-quarter milestone?
Read the worked answer
Use a strangler pattern: put an API gateway in front of the monolith, then move one capability at a time behind it, leaving the monolith to serve everything not yet extracted.
First extraction. Pick a bounded context with real user value and low coupling to the shared schema. Claim document intake and search is the natural candidate because it is read-mostly, aligns with the AI goal, and does not require rewriting claims adjudication logic. Second candidate is notification and correspondence. Avoid starting with the rating engine; it is the most entangled with the database.
Runtime. The team already runs Kubernetes, so managed OpenShift is the lower-friction target: consistent security context, built-in CI/CD and image management, and portability if the insurer later splits workloads. A managed Kubernetes service is defensible if cost dominates and the team accepts more assembly, but the existing operational experience argues for the platform with more guardrails.
Data. Assess the Oracle schema for stored procedures before picking a target. If PL/SQL is heavy, run Oracle self-managed initially for the monolith and give the extracted service its own managed PostgreSQL schema, so the shared-database coupling disappears service by service.
Two-quarter milestones. Quarter one: pipeline, containerized extracted service in production, weekly deploys for that service, measured by deployment frequency and claim-search latency. Quarter two: document intake live and a 50-adjuster pilot of the assistant, measured by handle time and answer acceptance rate. Commit to those two numbers, not to a rewrite percentage.
2. Design the retrieval-augmented assistant so answers cite source pages and the data never leaves the account. Name the trade-offs.
Read the worked answer
Retrieval-augmented generation, not fine-tuning, is the right default: 2.5 million PDFs change constantly, and citation requires pointing at retrieved text rather than memorized weights.
Pipeline. Ingest to object storage, then parse - OCR for scanned pages - into text with page anchors preserved. Chunk with overlap and store each chunk with document ID, page number, and claim metadata. Generate embeddings with an embedding model and index them in a vector store inside the account, whether that is an integrated discovery service or a vector-capable database the team operates.
Answering. On query, apply metadata filters (claim type, date, jurisdiction) before vector search, retrieve top-k chunks, and prompt a foundation model in the account's own deployment with instructions to answer only from the supplied passages and to emit document and page references. If grounding is weak, the assistant must say so and hand the adjuster the source documents.
Trade-offs. A managed discovery-style service gets parsing, enrichment, and passage retrieval faster with less engineering but less control over chunking and ranking. A custom pipeline on a foundation-model platform gives control over model choice and evaluation but shifts ingestion, reindexing, and evaluation cost onto the team. Model size trades answer quality against latency and token cost - 900 adjusters asking several questions a day is a real run-rate, so cache frequent queries and route simple lookups to a smaller model.
3. What governance, auditability, and human-oversight controls must exist before an adjuster can rely on the assistant, and how do you keep the pilot honest?
Read the worked answer
Because outputs influence claim decisions, the control set must cover the model, the data, and the decision.
Model governance. Maintain a model inventory with factsheets covering intended use, training data provenance, evaluation results, and known limitations. Track prompt templates and model versions in source control, so any answer can be reproduced from the logged prompt, model version, and retrieved chunk IDs. Monitor for drift and for quality regressions after any model or index change.
Data controls. Redact or tokenize direct identifiers before they reach the model where the use case permits; keep the index and model access behind least-privilege access groups; and confirm regional processing so regulated claim data stays within the approved boundary. Log retrieval and generation events for audit, and retain them per the claims retention rule.
Human oversight. The assistant proposes with citations; the adjuster decides. Prohibit automatic adverse decisions, and require the adjuster to acknowledge the cited source for anything that changes a payout.
Honest pilot. Build a labelled evaluation set of representative claims before launch, measure groundedness and citation correctness, and set an acceptance threshold in advance. Publish weekly handle-time and acceptance metrics to the CIO, and define the rollback: disable the assistant and leave search working. A pilot that cannot be measured or switched off is not a pilot.