Engineering × Insurance

Teach an agent to read the fine print.

Build an agent that reads a motor policy, finds the applicable percentage an insurer pays the broker, and explains its answer with exact source evidence.

Learn the problem Inspect the supplied files

Start here

One document describes the policy. Another defines the commission.

A customer pays an insurer for motor cover. The insurer may then pay a broker for placing and servicing that policy. The percentage it pays is called a commission or brokerage rate.

Insurers publish those rules as spreadsheets, PDFs, circulars and images. A commission grid, also called a brokerage grid or rate card, is simply a conditional lookup table: if a policy has these facts, this rate applies. It is not a discount shown to the customer.

What the grid reads

Below are the typical fields an insurer uses to decide the commission on a policy. Each is a proxy for risk and cost. A new city hatchback and an ageing commercial vehicle are not equally profitable to cover, so insurers tune the rate fact by fact, paying more for the business they want and less for the business they don't.

registration area vehicle model fuel / engine size vehicle age policy type business type claim-free discount premium amount

Motor insurance, in five minutes

OD protects the car. TP protects other people.

A motor premium is not a single number. It is assembled from coverage components, each one a separately priced piece of protection that the policy schedule lists on its own line.

Every motor policy is built on two of them, Own Damage and Third Party, and those are the only components this challenge asks you to rate. Real schedules usually carry more: roadside assistance, paid driver cover, a CNG kit endorsement. Commission grids often pay a different percentage on each component, so an agent that applies one rate to the whole premium will get the money wrong.

Own Damage

Covers damage to the insured vehicle.

Think accident damage, theft, fire or similar loss to the policyholder’s car. The OD rate is applied to the relevant OD premium component.

Third Party

Covers legal liability to somebody else.

This is the mandatory liability cover for injury or property damage caused to others. The TP rate is applied to the relevant TP premium component.

Note Comprehensive / package policy = OD + TP

Stand-alone TP policy = TP only; OD is not applicable, never zero

Follow one lookup

A fictional policy becomes one complete trace.

These values are deliberately invented, not answers to the supplied cases. Each transformation remains inspectable.

01
Read the policy facts. A fictional policy says comprehensive cover, petrol hatchback, registration code HR-26, 1,197 cubic centimetres (cc), 20% No Claim Bonus (NCB), and a ₹14,000 OD premium. Cite fictional-policy.pdf · page 1.
02
Translate them into grid vocabulary. The fictional mapping table places HR-26 in Zone A and the hatchback in Segment H1, an insurer-defined vehicle bucket. Cite Geography!B14:C14 and Vehicles!D8:F8.
03
Select every applicable dimension. This grid requires Zone A, Segment H1, petrol, the 1,001–1,500 cc band and the ₹10,001–₹20,000 premium slab (a range bucket). The fictional matched row returns OD 12% and TP 2%. Cite Rates!G22:H22.
04
Apply exceptions before answering. The cited footnote excludes diesel vehicles only, so this petrol example remains resolved. A declined segment or missing registration area would instead override the apparent table cell. Cite Rates!A27:H27.
05
Return the result and its trail. OD 12% and TP 2%, with the policy page, both mapping ranges, rate cells and footnote attached to the decisions they support.

Terms you will meet in the source files 7 terms Hide Read them

RTO: Regional Transport Office. The vehicle-registration code acts as a geographic key; an insurer may group several RTOs into one zone or cluster.
CC: Cubic centimetres: the engine’s capacity. Grids often use bands such as “up to 1,000 cc” or “1,001–1,500 cc”.
NCB: No Claim Bonus. A claim-free discount on the OD premium; some grids use its percentage as another lookup condition.
Business type: When a policy names the same insurer as both the current and previous insurer, classify it as a renewal, not as new business or rollover/ported business.
Premium slab: A range bucket for the premium amount. For example, one rate applies below a threshold and another above it.
Segment: An insurer-defined vehicle bucket based on model, fuel, engine size, age or a combination of those facts.
Rate card / rater / grid: Different names for the source document containing the commission rules. In this challenge, treat that source as authoritative.

Problem statement

Build the brokerage agent.

Given a motor policy PDF and a directory of insurer rate cards, return the expected commission rates with an evidence trail another engineer, or a broker, can audit.

Input

Policy PDF + commission grids

Accept motor policy PDFs through the deployed browser frontend and resolve them against the supplied raters/ directory. During review, Vaatun will upload additional policy PDFs that are not included in the supplied samples. A CLI or a preloaded sample selector alone does not meet this requirement. Uploading new commission grids is optional.

Output

OD / TP rates + exact source evidence

Return extracted facts, separate Own Damage (OD) and Third Party (TP) rates where applicable, granular source citations, confidence, and a plain-language explanation of every lookup step. Keep previous runs, uploaded PDFs and completed analyses available after refreshing or reopening the app, signing out and back in when authentication is used, and application restarts or redeployments. Percentage rates are required; calculating rupee amounts is optional.

Put that fictional trace into a structured result View the same example as JSON

Your schema may differ. What matters is that applicability, evidence and uncertainty are explicit rather than buried in prose.

{
  "status": "resolved",
  "facts": {
    "policyType": "comprehensive",
    "rto": "HR-26",
    "fuel": "petrol"
  },
  "rates": {
    "od": { "applicable": true, "ratePercent": 12 },
    "tp": { "applicable": true, "ratePercent": 2 }
  },
  "trace": [
    {
      "decision": "HR-26 maps to Zone A",
      "policyCitation": "fictional-policy.pdf · page 1",
      "gridCitation": "fictional-grid.xlsx · Geography!B14:C14"
    },
    {
      "decision": "Vehicle maps to Segment H1",
      "gridCitation": "fictional-grid.xlsx · Vehicles!D8:F8"
    },
    {
      "decision": "OD 12%; TP 2%; diesel exclusion does not apply",
      "gridCitation": "fictional-grid.xlsx · Rates!G22:H22; A27:H27"
    }
  ],
  "confidence": {
    "level": "high",
    "reason": "Every required fact and mapping was found"
  }
}

R / 01

Required policy facts

Return insurer, previous insurer and business type where relevant, make/model, fuel, Regional Transport Office (RTO) code, engine capacity (CC), manufacture year, policy type, No Claim Bonus (NCB) and premium breakup, with uncertainty preserved.

R / 02

Explicit result states

Every run ends as resolved, unsupported or ambiguous, with separate OD and TP applicability.

R / 03

Cite the precise source

Cite the policy page for each extracted fact, the source for every mapping, and the exact grid sheet, row, cell or PDF page that produced the rate. “Found in the grid” is not enough.

R / 04

Deterministic boundary

LLMs are welcome for extraction. Grid resolution must remain reproducible and testable. Never infer through a missing, declined, contradictory or out-of-scope rule.

R / 05

Process policies beyond the samples

During review, Vaatun will upload additional motor policy PDFs that are not included in the supplied samples. The hosted frontend must process these files and display their results; a solution that works only with the sample policies is incomplete.

R / 06

Keep previous runs available

Uploaded PDFs and completed analyses must remain accessible after refreshing or reopening the app, signing out and back in when authentication is used, and application restarts or redeployments. Ephemeral local storage alone does not meet this requirement.

Now apply the vocabulary

Your test bench

01

HDFC ERGO · Comprehensive

Map geography, then select the OD rate.
Zone × OD premium slab × fuel × NCB
PDF · included
02

Go Digit · Stand-alone TP

Find the TP-only vehicle bucket.
RTO cluster × fuel / engine-size segment
PDF · included
03

Reliance · Comprehensive

Identify the model, then obey the footnote.
RTO zone × model segment × exception
PDF · included
04

Tata AIG · Stand-alone TP

Prove why no supported rate exists.
TP-only coverage gap detection
PDF · included

Every supplied policy is a metadata-clean synthetic fixture. Names, contacts and customer-specific identifiers have been replaced; city/RTO context, vehicle rating facts and premium figures remain intact. The bundle includes a public verification summary and checksums.

The supplied files

Messy by design. Realistic by default.

Use the original source formats. Normalising them is part of the challenge; hard-coding the four answers is not.

4 × PDFDe-identified test policiesFor example: HDFC ERGO comprehensive and Go Digit SATP

3 × XLSXOriginal-format commission gridsFor example: Go Digit multi-sheet and Tata AIG 70+ columns

1 × PDFOriginal-format commission gridHDFC ERGO · two pages with zone and slab tables

DocsBrief, verification and manifestTask contract, privacy summary and SHA-256 checksums

Download starter bundle

What good looks like

Correct is the start. Defensible is the bar.

Scoring matrix

Before scoring, we verify the baseline: the hosted frontend accepts a policy PDF that was not included in the supplied samples, returns its result, and keeps previous runs available after refreshes, reopening the app, signing out and back in when authentication is used, and application restarts or redeployments. Submissions missing any part of this baseline are incomplete. For qualifying submissions, the percentage on each card is the weight it carries, and the four weights add up to 100.

40%

Accuracy

Extract the right facts and reach the right rate, or the right refusal.

25%

Traceability

Make every transformation and source lookup inspectable.

20%

Resilience

Handle missing fields, exclusions, footnotes and unsupported segments.

15%

Engineering

Readable code, meaningful tests, sensible boundaries and a useful README.

“The most impressive submission may be the one that confidently says I cannot determine this rate from the supplied evidence, and proves why.”

No deadline. No permission slip.

Build it because the problem bothers you.

Your submission must include a working browser frontend deployed to a hosted URL. During review, we will upload additional motor policy PDFs that are not included in the supplied samples. The application must process these files, display their results, and keep the uploaded policies and completed analyses accessible after browser refreshes, closing and reopening the app, signing out and back in when authentication is used, and application restarts or redeployments. A CLI, a sample-only implementation or container-local ephemeral storage alone does not meet the baseline. Email both the hosted application link and the source-code repository to careers@vaatun.com. The repository must explain where uploaded PDFs and completed analyses are stored and how previous runs remain available across those events. It must also include setup and deployment instructions; automated tests; structured outputs and decision traces for all four policies; and a short note on architecture, assumptions, failure modes and trade-offs. If the hosted application requires credentials, share them with the team by email or another agreed communication channel.

Submit your challenge Review the corpus ↓ Re-read the brief ↑

□ working frontend □ hosted application URL □ additional policy uploads □ saved run history □ history after refresh / re-login □ source code □ access credentials, if required □ setup + deploy docs □ rating + storage tests □ outputs + traces for all 4 policies □ architecture + assumptions + failure modes + trade-offs