Four checks, one file

Eric Gil Coll works on iudexnc's coverage-check pipeline. He came to the domain as a software engineer, moved from Spain to Zürich for the role, and now describes the coverage check in a way most engineers will recognise immediately. We asked him about that, and about what surprised him along the way.

You've said a coverage check works like an authorisation system. What do you mean?

It took me a while to see it that way. I'd assumed the check was one question with a yes or no at the end. It's actually several independent ones. Is this person insured. Is this kind of dispute insured. Did it happen inside the covered time window, in the covered territory. Then the exclusions on top. A case can look obviously covered and still fail on one single dimension, and the reasoning for each has to stand on its own.

For an engineer: who, what, when, where. The file needs a pass on every scope check, and a deny on any single one denies the whole thing. Once I had that picture, a lot of the architecture made sense to me.

What surprised you most in the first weeks?

How much of the job is language rather than code. Almost all source material lives in long legal PDFs written for lawyers, in German, and German legal compound words are a boss level of their own. Everyone around me said "AVB" fifty times a day, and I spent my first days nodding along to three letters before I looked them up. Allgemeine Versicherungsbedingungen, the general conditions of the policy.

The other surprise: "it depends" is often the correct output. I expected the goal to be a clean yes or no. In practice, an honest "unclear, we need this document first" is worth far more than a wrong "yes, covered".

Was there a moment when it clicked?

In a live demo. We took an example case, removed one key piece of information, and instead of guessing a verdict the system said it couldn't decide yet and named the specific missing documents. The reaction in the room was more positive than to any "covered" answer we'd shown.

That was the click: in this world, "not yet, send me X" is a good outcome.

It's what a careful case handler would say. The product isn't an answer machine, it's a colleague who checks before speaking. After that, the insistence on citing the exact clause behind every statement had an obvious why.

You learned this domain as a newcomer to Switzerland. What would you tell an engineer starting somewhere similar?

Treat the domain like a codebase. I think and take notes in Spanish, the team works in English, the product speaks German through proper localisation, and keeping those layers separate made the vocabulary manageable. Build your own glossary from day one and don't nod along to a term you don't understand; the dumb question is much cheaper in week one than in month three.

Read the primary sources. The actual policy terms, the actual cases. It's slower and it pays off. And live inside the evaluations: if the company measures its product against real cases, every failure is a domain lesson with a concrete example attached. Honestly, it's one of the few things in this job that feels like being a student again.