Encoding policy terms as rules: what happens when the wording is ambiguous
Turning a 69-clause policy into rules surfaces the clauses your handlers have quietly been reading two different ways.
Short answer. Encoding a policy means converting each clause into a condition a system can evaluate against facts. Most clauses convert cleanly. The ones that resist are not a technical obstacle: they are clauses your handlers are already interpreting inconsistently, and that inconsistency is already priced into your settlements.
What encoding actually involves
Each clause becomes a condition evaluated against facts already gathered: the vehicle record, the claim description, the component, the mileage, the policy start date.
On the document we worked through — 69 clauses — most converted without argument. “Not covered if the vehicle has exceeded X miles” is a comparison. “Wear and tear excluded” is not, and that is where the work is.
The output is a rule set that produces the same answer every time, with the clause it relied on attached. That last part matters as much as the decision: an outcome you cannot trace to a clause is an outcome you cannot defend.
The three ways a clause resists
It depends on a judgement nobody has defined. Wear and tear, reasonable use, adequate maintenance. Handlers apply an internal standard that has never been written down, and different handlers hold different standards.
It depends on a fact you do not hold. A clause requiring proof of servicing is perfectly clear and unusable if service history is not available in a form a system can read.
It contradicts another clause. Rare, and always worth finding. Two clauses that cannot both be satisfied means the outcome currently depends on which one the handler reads first.
Ambiguity is the finding, not the blocker
The instinct is to treat these as reasons automation will not work. They are better read as an audit of your own consistency.
If a clause can be read two ways by a system, it is being read two ways by people, and it has been for as long as the policy has existed. That shows up as similar claims settling differently depending on who picked them up — which is a fairness problem, a complaints problem, and a cost you are already carrying without a line item for it.
The same pattern appears in shadow mode, where the disagreements between system and team are consistently more informative than the agreements.
Who resolves it
Not the supplier. We can surface an ambiguous clause and show what each reading costs across a year of real claims, and that second part usually makes the decision obvious. But the decision is the client's, because it is a commercial and regulatory judgement about their own product.
Written down, it becomes a rule everyone applies. Left alone, it stays a lottery.
Why the rules must be deterministic
It is tempting to hand ambiguity to a language model and let it decide. That is precisely the wrong instinct.
A model will produce a fluent, confident answer to an ambiguous clause and produce a different one next week. You would have converted a known inconsistency into an untraceable one. Rules are the answer specifically because they force the ambiguity into the open where a person has to settle it.
The architectural argument is set out in can claim assessment be automated, and the full design in the claims engine write-up — which, to be explicit, describes a system that was designed and validated but never built.
Related questions.
Converting each clause into a condition a system can evaluate against facts it has already gathered — the vehicle record, the claim description, the component, the mileage, the policy dates. The output produces the same answer every time with the clause it relied on attached.
It resists encoding, which is a finding rather than a blocker. A clause a system can read two ways is a clause people are already reading two ways, so similar claims settle differently depending on who handles them. That inconsistency is already priced into your settlements.
No. A language model will give a fluent, confident answer and a different one next week, converting a known inconsistency into an untraceable one. Deterministic rules are the answer precisely because they force the ambiguity into the open for a person to settle.
The client. A supplier can surface the clause and show what each reading costs across a year of real claims, which usually makes the decision obvious, but it is a commercial and regulatory judgement about their own product.
Describe the process you want to automate.
You will receive a fixed price and a build plan.
There is no charge for the initial call and no obligation. You deal directly with the engineer who builds the system.