An insurance company wants an LLM to draft claim decision letters. What is your architecture?

What the interviewer is testing

Whether you place the model where its failure mode is acceptable, rather than trying to make it reliable enough.

The framing

A claim decision letter is a regulated communication with financial and legal consequence. The model's failure mode — confident, fluent, wrong — is the worst possible fit for it.

So the design separates what the model is good at from what must be deterministic.

The architecture

The decision is not made by the model. The claim outcome, the amount, the policy clauses applied and the reasons come from the deterministic decisioning system. The model does not decide anything.

The model drafts prose from a structured input containing the decision, the reasons and the relevant clause references. It is a formatting and language task, which is what it is genuinely good at.

Constrained generation: templates for the regulated sections — appeal rights, complaint procedures, statutory notices — which must be exact and are inserted verbatim, not generated.

Output validation before anything reaches a human: every figure in the draft matches the structured input, required sections are present, prohibited content is absent, and no clause is cited that was not in the input.

Human review before sending, with the reviewer shown the structured decision alongside the draft so they are checking the letter against the decision rather than assessing it in isolation.

Full audit: the input, the model and prompt version, the raw output, the validation result, the reviewer and any edits.

Why the human review must be designed carefully

A reviewer approving a stream of mostly-correct letters at speed becomes a rubber stamp — automation bias does the rest. Make disagreement as easy as agreement, show the specific facts to check, and track the edit rate. A rate near zero means the review is not functioning.

What a strong answer adds

Under an AI risk tiering scheme this is a high tier: it needs decision logging sufficient to explain an individual outcome, a documented fallback when the model is unavailable (the deterministic template path), and monitoring for drift. Those are design requirements, not paperwork.

Common weak answers

Prompting the model with the policy documents and asking it to decide. Relying on review without constraining generation.