Every insurance claim involves several letters in its lifetime. It might be a payment letter breaking down what’s covered, or a denial letter explaining what isn’t. Whatever form these letters take, what’s most important is the precision – verbatim language from the customer’s policy, exact formatting, and even the right hierarchy. Incorrect citations could be the defining factor in litigation to argue that a claim was mishandled.
Given stringent requirements, Kin’s claims engineering team set out to meet a high bar for accuracy for every policy. The challenge lay in the complexity required to correctly read every uniquely configured policy at scale.
The team that owns the end-to-end claim
Kin is a rapidly growing American direct-to-consumer home insurance company. Its claims engineering team owns the end-to-end claims experience, from the customer-facing funnel where homeowners file online, to the internal tooling used by adjusters to resolve claims. That includes the integrations with outside vendors and the custom systems Kin built to support the people doing the work.
Recently, Kin built Scribe: an internal platform for adjusters to assemble claim letters without rebuilding boilerplate every time. Inside of Scribe sits the citation builder, which is powered by Datalab.
Why “close enough” falls short
A denial letter must cite every reason a claim is being denied. A coverage letter does the same for why it’s covered. The citations need to match the policy exactly, including language, formatting, and hierarchy of numbers and letters.
Policies are also unique. While a policy form may be standard, a customer’s policy is a unique combination of their state, endorsements, and coverages stacked on top. Every letter needs to demonstrate an understanding of that specific customer’s policy. If anything is misinterpreted, an attorney could argue that the policy was never correctly cited.
Before Scribe, Kin built a tool that assembled letters so adjusters didn’t have to hunt for the language themselves. While the tool saved time looking for language in policy documents, the backend was hard-coded and difficult for the engineering team to manage. The combination of letters and provisions resulted in complex logic that was difficult to scale.
“We had hundreds of letters and hundreds of provisions, which created thousands of lines of interwoven rules and logic. Every subsequent addition made it more complicated.” — Matt Zollner, Product Director - Claims Technology
Citation Builder: a dynamic tool built with Datalab
Kin’s claims engineering team set out to build a newer, more flexible and scalable tool that was more efficient for both adjusters and the engineering team alike. Scribe launched in 2025 to pilot groups of adjusters. Within Scribe, the citation builder tool is powered by Datalab.
The citation builder uses Chandra to parse a customer’s policy packet. Adjusters receive the policy broken down into citable blocks - every sentence, list, and paragraph is preserved with its structure intact. From these blocks, the adjuster simply selects the language a letter needs, and it drops into the letter already formatted. Because Chandra preserves formatting, adjusters save time reformatting letters by hand.
Chandra also contributes to a conceptual shift in the way the tool functions. Their previous system operated in a subtractive way: letters were pre-built, and adjusters would go in and delete what didn’t apply. With Datalab, Kin was able to flip to an additive system. Adjusters start from the parsed policy and add exactly the right language, getting to a correct citation faster when they know what they’re looking for.
“What Datalab has allowed us to do is be additive – you can get it right faster.” — Jake McHargue, Engineering Manager
On the engineering front, the citation builder understands the policy itself and enables the team to add new provisions quickly rather than adding logic onto an already complex system. Most importantly, when states change or there are policy reforms, the tool adapts around the changes rather than requiring manual adjustments to the logic.
A Kin homeowners policy page parsed by Chandra into citable blocks
Where custom processors fit
Out of the box, Kin found that general parsing models didn’t capture all of Kin’s complexities and idiosyncrasies, especially the unique formatting buried in insurance policy documents. They are typically built in a specific legal writing style with many bullets and hierarchies, and a two-column format that is tricky to parse. Despite the complexity, they could not risk errors when a single misread line could compromise a claim in court.
Rather than forcing every policy document into a clean standard, Kin worked with Datalab to adapt custom processors to the documents as they actually are, quirks and all. Accuracy reached a bar where manual QA of parsing was minimal.
Kin evaluated Marker along the way, too. On its own, Marker was more accurate than Chandra, but Chandra, paired with custom processors, beat Marker.
The collaboration was almost entirely asynchronous; by Kin’s estimate, 95% of it happened in Slack. The method was methodical: scan and screenshot failures, export PDF examples, classify the errors, and lift up the commonalities. What looked like random bugs got grouped into shared root causes, prioritized, fed back as fresh iteration examples, then reprocessed until accuracy hit an acceptable bar.
Impact: Citations pulled in minutes, with half the launch work required
For the letters that were previously assembled by hand, copying and pasting the right policy language could take up to 45 minutes apiece. The citation builder now pulls those citations in minutes. The time savings compound especially quickly for high-volume claims work.
The bigger structural win is in launching new products. Kin used to stand up all the templates and policy logic by hand for every new form, state, and product. With parsing handling the policy itself, that setup work disappears, eliminating roughly half the process of launching a new product, and cutting time-to-launch by about 50%. There’s also an added bonus - by parsing their policy documents cleanly, Kin indirectly made those documents more AI-ready overall, laying the groundwork for future builds.
Inside Scribe’s citation builder: from a parsed policy packet to letter-ready citations
Advice to other teams
Kin’s rule of thumb on custom processors is refreshingly practical. If the customization needed is predictable, write a static transformation script. If they’re stochastic or your input set is unpredictable, that’s where custom processors shine. It depends on how much transformation you require.
“Our use case is so compliance and legal driven that even a small inaccuracy can put a claim at risk in court. But if you’re just scanning pages and pulling numbers, where a stray line break doesn’t matter, you probably don’t need it.” — Pratik Amin, Senior Product Manager
What’s next: the adjuster experience
The citation builder made it dramatically easier to assemble a letter once an adjuster knows which provisions to cite. Kin’s ambition is a system where an adjuster can describe a claim in plain terms — “the roof is damaged, here are the documents, here’s what’s missing” — and have the right policy language surface automatically.
Parsing the policy into clean, structured chunks is what opens that door. With Chandra and custom processors in place, Kin has the foundation to organize policies into consistent, searchable, navigable taxonomies, and to layer AI on top when the use case is right.