Why Mapping Matters
A rating model is built using defined variables: for example, the age of a building at the start of a policy term, expressed in completed years. A policy system, however, stores operational fields such as a construction date, an inspection date, or a manually entered age. Those fields may use different units, dates, category labels, and missing-value conventions. Mapping a modeled rating variable to production data means specifying how system fields are selected and transformed so that the value used in production has the same meaning as the value used by the model.
A field with a similar name is not necessarily the same variable. A model variable called “vehicle age” might mean completed years since first registration as of the coverage effective date. A policy system’s “vehicle age” field might instead be calculated as of the quote date or stored as an integer rounded from months. A mismatch can send the same risk to a different model category, even when the rating logic itself is implemented correctly.
Specify the Variable Before Selecting the Field
Start with the modeled definition, not the system field name. For each rating variable, state what is measured, the applicable unit, the date at which it is measured, and how values are grouped. Also identify the population to which the variable applies. These details make it possible to distinguish a genuine data gap from a legitimate value, and to test the production transformation against the intended definition.
- Meaning and unit: What does the variable measure, and in what units? For instance, “annual distance driven” is not interchangeable with “distance recorded at the last inspection.”
- Reference date: Is the value determined at the quote date, the policy effective date, or another specified date?
- Transformation: Does the model use a continuous value, a derived measure, or a category created from the source value?
- Boundary rules: Are categories inclusive or exclusive at each endpoint? The rule must place every valid boundary value in exactly one category.
- Missing and invalid values: What happens if the source is blank, impossible, or outside the defined range? Is a default explicitly authorized, or must the record be referred or rejected?
A production specification should preserve these definitions in language that can be tested. “Use building age” is too vague. “Calculate completed years from the recorded completion date to the policy effective date; assign ages 0–9, 10–24, and 25 or more to the specified categories; do not substitute zero for an unavailable date” is more operational, though the exact rules must match the model definition and approved specification.
Category Transformations and Boundary Rules
A category transformation maps a valid input value to one defined model category. Category names alone are not enough: production and model development could use labels such as “standard” and “older” while assigning different values at a boundary. Write the rule in terms of ranges, including the treatment of each endpoint.
Here, \(x=10\) belongs to category B, while \(x=25\) belongs to category C. The intervals do not overlap and cover all nonnegative values, so every valid value has exactly one assignment. This is an important specification check: overlaps can make assignments order-dependent, while gaps can leave some valid records unclassified.
The unit and reference date must be settled before applying the category rule. A raw value of 10 months is not 10 years, and a value calculated at renewal may not equal the value at the policy effective date. If the source stores a date, the age calculation must also specify whether it counts completed anniversaries or uses a fractional-year convention. Production should implement the convention defined for the model rather than choosing a convenient approximation.
Worked Example: Mapping a Building-Age Category
A hypothetical property model uses completed building age on the policy effective date, in years. Its categories are A for ages 0–9, B for ages 10–24, and C for ages 25 or more. A policy is effective October 1, 2026. The system records the building completion date as September 30, 2001. Determine the modeled age and category, and identify a plausible one-year mapping error.
Method. Calculate completed years at the specified effective date, then apply the stated category boundaries. Do not substitute the current calendar year minus the completion year, since that shortcut can ignore whether the anniversary has occurred.
From September 30, 2001 to September 30, 2026, 25 anniversaries have been completed. The policy effective date is October 1, 2026, one day later, so the completed age remains 25 years. Applying the categories: 25 is at least 25, so the production category must be C.
A system that calculates age as the effective year minus the completion year also returns \(2026-2001=25\) in this case, but this agreement is incidental. If the completion date were October 2, 2001, the 25th anniversary would not yet have occurred on October 1, 2026. The correct completed age would then be 24 and the category would be B, while year subtraction would incorrectly return 25 and category C.
Check. For the stated September 30, 2001 completion date, both the anniversary calculation and the stated rule give age 25 and category C. The common mistake—using calendar-year subtraction without checking the anniversary—would produce a wrong category for the October 2 variant.
Missing, Invalid, and Default Values
A blank value, a genuine zero, and an invalid value are different data states. A recorded annual mileage of zero may be a valid report for a vehicle not driven during the period, while a blank mileage field means no value was supplied. A negative mileage may be invalid under the variable definition. Treating all three as zero hides the difference and can systematically assign records to an unintended category.
A useful data contract distinguishes at least these cases: a valid value, a missing value, an invalid value, and a value that is not applicable. For each, define whether production uses a permitted default, requests correction, refers the record, or prevents rating. “Unknown” may be a valid model category if the model was developed and specified to include it; it is not automatically interchangeable with a numeric default.
This distinction also matters for data review. If a field is missing for 8% of production records but the mapping silently substitutes the most common category, the resulting rating distribution can appear complete while concealing a data-quality problem. Record both the treatment and the frequency of each condition so that a permitted operational rule does not obscure changes in data completeness.
Worked Example: Applying an Authorized Missing-Value Rule
A hypothetical commercial-auto model uses annual mileage in thousands of miles, with categories Low for less than 8, Medium for 8 to less than 15, and High for 15 or more. The approved specification says that a blank mileage value must be referred for completion; it does not authorize a numeric default. Four application records contain 6.5, 8.0, a blank, and -2.0 thousand miles. Classify or disposition each record.
Method. First check whether the source value is present and valid. Only valid values are assigned to mileage categories. Then apply the exact category boundaries.
Record 1 has 6.5 thousand miles. Since \(6.5<8\), assign Low.
Record 2 has 8.0 thousand miles. The Medium interval includes 8, so assign Medium. It is not Low, whose condition is strictly less than 8.
Record 3 is blank. The approved rule requires referral for completion, so it receives no mileage category at this stage. In particular, it is not treated as zero or assigned Low.
Record 4 has -2.0 thousand miles. This is an invalid value for annual mileage under the stated definition. The specification gives no default or referral rule for this particular invalid-value case, so it must be flagged for resolution under the applicable data-quality process, not silently assigned Low.
Check. The valid values produce one Low and one Medium assignment; the blank is referred, and the negative value is flagged as invalid. A common mistake is to turn both blank and negative values into zero, which would create two unsupported Low assignments.
Why Consistent Definitions Produce Consistent Categories
A simple equality check explains the central requirement. Let \(x\) be the source information for a record, \(g(x)\) the transformation specified by the model definition, and \(h(x)\) the transformation implemented in production. For valid records, production reproduces the modeled variable only when \(h(x)=g(x)\). If the model applies category function \(C\), then consistent category assignment follows directly:
The implication holds because the same category function is applied to the same value. Conversely, a transformation mismatch can change the category whenever the two transformed values fall on different sides of a boundary. For example, rounding 9.6 years to 10 before categorization can change an age category defined using unrounded completed years. This is why unit, precision, and transformation order belong in the specification, not just the field name.
This justification assumes that the source information is adequate, both transformations use the same definition and reference date, and the category function has explicit boundaries. It does not establish that the model definition is appropriate, that the source data are accurate, or that a permitted default is fair or suitable. Those are separate review questions.
Record its meaning, unit, timing, valid range, and category boundaries.
Specify which policy-system field or fields provide the necessary information and how conflicting sources are resolved.
State calculations, precision, category assignment, and explicit handling for missing, invalid, and inapplicable values.
Compare test records with independently calculated expected values, especially at boundaries and exception conditions.
Review category frequencies and exception rates for unexpected changes that could indicate a source or transformation issue.
Testing and Reconciling Production Values
A mapping should be tested at both the individual-record and aggregate levels. Record-level tests verify that a given set of source values produces the expected modeled value and disposition. Aggregate checks can reveal broad shifts—for example, a sudden increase in “unknown” values or an implausible change in a category’s share—but do not prove that each individual record is mapped correctly.
Construct test cases that include ordinary values, each category boundary, values immediately below and above boundaries, missing values, invalid values, and relevant date transitions. Where two fields could supply the same concept, include cases where they disagree and confirm that the documented precedence rule is followed. Independent calculation is valuable: if the same implementation is used to produce both the expected and actual result, a shared error may go undetected.
A further check is to calculate expected category counts from a fixed set of test records, then reconcile them to production output. Such a test checks the mapping, not the adequacy of the rating model or the calculation of the final premium. The focus here is whether the values passed to the model match the definitions intended for those variables.
Worked Example: Reconciling a Production Category Field
A hypothetical property model groups roof age in completed years into New for 0–14, Midlife for 15–29, and Old for 30 or more. On a test batch of 20 policies, an independent review identifies 6 New, 9 Midlife, and 5 Old roofs. The production extract reports 6 New, 7 Midlife, and 7 Old. Record-level review finds that two roofs, each exactly 30 years old, were assigned Midlife by production. Diagnose the issue and state the corrected counts.
Method. Compare the observed values with the inclusive boundary definitions, then correct the affected records and reconcile category totals. The Midlife condition is \(15 \le x < 30\); Old is \(x \ge 30\).
Each of the two roofs has age 30. Therefore, each belongs in Old, not Midlife. Move two policies from the production Midlife count to the production Old count:
The corrected production counts are 6 New, 5 Midlife, and 9 Old. They total \(6+5+9=20\), matching the batch size. They still do not match the independent review counts of 6, 9, and 5. That remaining discrepancy means the stated two boundary errors do not fully explain the mismatch: the record-level comparison must be continued to find the other differences or an error in the independent classification.
Check. The corrected totals sum to 20, but the reconciliation is not complete because the expected Midlife and Old counts still differ by four each. A common mistake is to treat matching grand totals as proof that categories match; the category-level counts and record-level assignments must also be checked.
Common Mapping Traps
- Assuming similar names mean identical definitions. Confirm the source, unit, timing, and transformation rather than relying on labels.
- Leaving endpoints implicit. State whether an endpoint belongs to the lower or upper category, and test the exact boundary.
- Substituting zero for missing data. Zero is a value; missing means the value is unavailable. Use a default only when it is explicitly authorized.
- Applying a default to invalid data without authority. A rule for blanks does not automatically govern negative, malformed, or out-of-range values.
- Checking only aggregate totals. Category totals can conceal offsetting record-level errors. Reconcile individual records as well.
Check Your Understanding
For each problem, identify the correct mapping or disposition before comparing it with the stated answer.
- A hypothetical model defines equipment age as completed years on the policy effective date. Equipment completed on June 15, 2014 is covered effective June 14, 2026. What is the completed age? (Answer: 11 years.)
- A territory variable has categories North for codes 1–4 and South for codes 5–8. Code 5 is recorded for a policy. Which category applies, and why? (Answer: South; code 5 is in the 5–8 interval.)
- A model groups annual water usage as Low below 12,000 gallons and High at or above 12,000 gallons. The source contains 12,000 gallons. What category applies, and what boundary condition controls? (Answer: High; the High interval includes 12,000.)
- A model specification says missing occupancy type must be referred for completion. A policy record has a blank occupancy field, and the system’s default is “owner occupied.” What should the mapping do? (Answer: Refer the record for completion; the system default is not authorized by the stated specification.)
- For a 30-record test batch, independent expected counts are 10, 12, and 8 across three categories. Production reports 10, 14, and 6. The record-level review finds two records assigned to the second category in production that belong in the third under the boundary rule. What are the corrected production counts, and is the batch reconciled? (Answer: 10, 12, and 8; yes, the category totals now match the expected counts, though individual records should still be checked.)