Why Source-to-Rate Lineage Matters
A rating indication is only as explainable as the path from the data behind it. If a premium changes, a reviewer should be able to identify which source values were used, how they were transformed, which model inputs they produced, and how those inputs affected the indicated rate. A field name in a model file is not enough: the reviewer also needs its meaning, origin, responsible owner, and transformation history.
Source-to-rate data lineage describes that end-to-end path. It applies to both policy fields, such as a coverage limit, and claims fields, such as paid loss. Lineage is not a substitute for checking whether values are accurate or totals are complete. It establishes where data came from and what happened to it, so that those checks and subsequent review have a clear basis.
A useful way to represent lineage is as a directed graph. The nodes are source fields, intermediate tables, transformations, model inputs, and rating outputs. The edges show which fields or calculations depend on which upstream items. For example, a source postal code may feed a territory-mapping table, which supplies a territory classification, which in turn selects a rating factor. A missing edge in that chain makes the result harder to reproduce or explain.
What to Document in a Lineage Record
The right level of detail is the level needed to follow a consequential field from its origin to its use. A lineage record commonly includes:
- Source and field: the originating system, table, and field name, along with the field's business meaning.
- Owner: the person or function responsible for the source data, mapping, transformation, or model input. An owner is accountable for explaining or maintaining that item; ownership need not imply that the owner personally performs every step.
- Transformation: the calculation, recoding, filtering, aggregation, or mapping that changes the field. Record units and relevant rules, not just the resulting column name.
- Dependencies: the upstream fields, reference tables, and conditions required to produce the item.
- Destination and use: the model input, rating factor, or indication that consumes the item, and the purpose for which it is used.
- Known limitations: unclear ownership, undocumented mapping rules, unavailable source values, or other breaks that prevent a reviewer from tracing the path completely.
A data dictionary explains what fields mean and often describes permitted values. Lineage goes further: it shows how a particular field is created and where it flows. Both are useful, but one cannot stand in for the other. For instance, a dictionary may define “territory” while failing to explain which address field determined it or which mapping was applied.
| Lineage stage | Example item | Question to record |
|---|---|---|
| Source | Policy postal code | Which system and field supplied the value? |
| Transformation | Postal-code-to-territory mapping | Which mapping rule and reference table were applied? |
| Model input | Territory category | What value entered the model, and what does it represent? |
| Rating output | Territory relativity | Which factor did the model or rating plan assign? |
A Practical Trace from Field to Indication
Trace one important field at a time, then record relationships among fields where a calculation depends on several inputs. This keeps the documentation specific without obscuring the logic in a long narrative. The sequence below is a practical review structure.
Start with a premium indication, rate factor, or model variable that needs to be explained.
List the actual inputs used and the calculation or rating rule that connects each input to the output.
Record the source field, its owner, its business meaning, and every material mapping or transformation along the path.
Check whether all inputs to each transformation are known and whether responsibilities and rules are clear enough to follow the chain.
Lineage should preserve the distinction between an observed source value and a value created downstream. A territory code assigned by a mapping is not the same thing as a postal code received from a policy system. If the two are labeled similarly, reviewers can mistakenly treat an assigned category as directly reported information.
Worked Example: Tracing Three Policy Fields to Premium
A hypothetical property rating calculation starts with a base premium of $500. The source postal code maps to a territory factor of 1.04; a building code maps to a construction factor of 1.10; and a protection code maps to a factor of 0.95. The rating plan multiplies the base premium by all three factors. Trace the calculation and identify what the lineage record should contain.
Method. Follow each source-to-factor mapping and then calculate the premium using the stated multiplicative rating rule. The factors are assumed to be supplied by the hypothetical rating plan; this example does not assert that they are appropriate for a real product.
Step 1: Postal code to territory factor. Record the policy system's postal-code field, its owner, the mapping table or rule, and the resulting territory category. The resulting factor is 1.04.
Step 2: Building code to construction factor. Record the source building code, its owner, the construction classification rule, and the factor 1.10.
Step 3: Protection code to protection factor. Record the source protection code, its owner, the mapping used, and the factor 0.95.
Step 4: Calculate the indicated premium.
The indicated premium is $543.40. Check: the combined relativity is \(1.04 \times 1.10 \times 0.95 = 1.0868\), and \(500 \times 1.0868 = 543.40\), so the sequential and combined calculations agree.
The lineage must connect each source code to its relevant mapping and resulting factor, and then connect those three factors and the $500 base premium to the final indication. A common mistake is to document only the three factor values, without showing how the source codes produced them. That records model inputs but leaves their origins unexplained.
Why the Calculation Depends on Its Lineage
A rating calculation is often a composition of transformations. If source fields \(x_1, x_2, \ldots, x_k\) are transformed into model inputs \(z_1, z_2, \ldots, z_j\), and a rating rule produces \(R\), then the indicated result can be written as a composition:
The functions \(h_r\) represent transformations such as mapping a source code to a category or aggregating claim amounts. The function \(g\) represents the rating calculation using the resulting inputs. To trace \(R\) back to the source, the record must identify both the inputs to each \(h_r\) and the use of each \(z_r\) in \(g\). If a mapping rule is unknown, the downstream result cannot be fully explained from the source values alone.
For a multiplicative rating plan with base premium \(B\) and factors \(f_1,\ldots,f_k\), the indicated premium is \(R=B\prod_{j=1}^{k} f_j\). This formula follows by applying each rating factor to the premium produced by the preceding step: after the first \(m\) factors, the premium is \(B\prod_{j=1}^{m}f_j\). Applying factor \(f_{m+1}\) gives \(B\prod_{j=1}^{m+1}f_j\). Repeating this argument through all \(k\) factors gives the formula. The formula applies when the rating plan specifies multiplicative factors; it does not describe plans with additive adjustments or other calculation rules unless those rules are separately represented.
This gives a simple lineage test: for every factor, can a reviewer identify the source or approved rating-plan input, the rule that assigned the factor, and the place it enters the calculation? If not, the final arithmetic may be correct while its data path remains inadequately documented.
Worked Example: Claims Fields to a Simplified Indication
For a hypothetical coverage segment, a claims extract contains $1,200 paid loss, $300 case reserves, and $100 of recoveries. The corresponding exposure total is 2.0 exposure units. For illustration, define incurred loss as paid loss plus case reserves less recoveries, and define the loss cost as incurred loss divided by exposure. A simplified premium indication adds a fixed expense provision of $90 and then allows for variable expenses of 20% of premium and a target margin of 5% of premium. Trace the fields and calculate the indication.
Method. First document the claims fields and their signs in the incurred-loss calculation, then trace the resulting loss cost and expense assumptions into the premium equation. Treat all amounts and rules as hypothetical, and assume the stated loss and exposure are the complete inputs for this illustration.
Step 1: Calculate incurred loss. The lineage records paid loss and case reserves as positive components and recoveries as an amount subtracted from loss.
Step 2: Calculate loss cost. The transformed incurred-loss amount is divided by 2.0 exposure units.
The indicated loss cost is $700 per exposure unit. Its lineage should identify each claims field, the recovery sign convention, the aggregation that produced $1,400, and the exposure field and unit used as the denominator.
Step 3: Solve for premium. Let \(P\) be the indicated premium per exposure unit. The $700 loss cost and $90 fixed expense provision are amounts independent of \(P\). Variable expenses and target margin together are \(0.20P+0.05P=0.25P\). Thus:
Subtract \(0.25P\) from both sides to obtain \(0.75P=790\). Therefore \(P=790/0.75=1{,}053.333\ldots\), or $1,053.33 per exposure unit, rounded to the nearest cent. Check: $700 + $90 + 25% of $1,053.333... ($263.333...) equals $1,053.333..., as required.
The common mistake is to add 20% and 5% directly to the $790 and report $987.50. Those percentages are defined as portions of the premium, not portions of the loss-and-fixed-expense amount. The correct denominator is \(1-0.20-0.05=0.75\). The lineage should explicitly record that denominator basis, in addition to the source fields and calculations.
Lineage Gaps and Review Priorities
A lineage gap is not simply a field with an unfamiliar name. It is a missing or ambiguous connection that prevents a reviewer from establishing how an output depends on its inputs. Common examples include an undocumented mapping, an unclear unit conversion, a transformation with no identified owner, or a model input whose source cannot be identified.
Prioritize gaps by the importance of the affected field to the rating result and by how much uncertainty the gap creates. A missing description for an unused administrative field may have little consequence for a rate indication. An undocumented mapping that selects a major rating factor can make the indicated premium difficult to explain and review. Record the gap precisely: say what link is missing, which outputs depend on it, and what evidence or owner is needed to close it.
Worked Example: Finding a Break in the Lineage
A hypothetical personal-lines model uses an annual-mileage band to select a factor. The policy system stores annual mileage in miles. A model-input file contains bands labeled “under 8,” “8 to under 12,” and “12 or more,” but its documentation does not state the unit, the source field, or how a policy's mileage was assigned to a band. A policy has reported annual mileage of 10,500. Identify the gap and state what can and cannot be concluded.
Method. Trace the reported value through the transformation to the model input, checking both unit and rule. Do not infer an undocumented conversion or factor.
The source value is 10,500 miles per year. If the band labels mean thousands of miles per year, the transformed value would be \(10{,}500/1{,}000=10.5\) thousand miles per year, which falls in the “8 to under 12” band. But the documentation does not establish that the labels are in thousands, nor does it identify the conversion rule or the factor assigned to that band. Therefore, the band and premium effect cannot be confirmed from the available lineage.
A complete record would name the mileage source field and owner, specify the miles-per-year unit, document division by 1,000 if that is the approved transformation, state the band boundary convention, and identify the factor selected by the rating plan. The common mistake is to silently assume the unit and report a definite selected factor. The calculation \(10{,}500/1{,}000=10.5\) is valid only under the stated hypothetical conversion; the missing rule remains a lineage gap rather than a fact to fill by guesswork.
Common Lineage Mistakes
- Recording destinations but not origins. A model-input name does not reveal which source field supplied it.
- Describing a transformation without its dependencies. A “territory assignment” is incomplete if the address field and mapping rule are unknown.
- Omitting units or sign conventions. Miles versus thousands of miles, or recoveries added rather than subtracted, can change the meaning of a calculation.
- Treating a derived field as source data. A mapped category should be identified as a transformation output, not as a directly reported policy attribute.
- Leaving ownership implicit. Without a responsible source or transformation owner, questions about meaning and rules may have no clear route to resolution.
Check Your Understanding
For each problem, trace the relevant fields and apply only the stated transformations.
- A hypothetical policy has a $420 base premium, a territory factor of 1.03, and a construction factor of 0.97. What is the indicated premium, rounded to cents? (Answer: $419.62.)
- A hypothetical claims extract shows $2,450 paid loss, $550 case reserves, and $200 recoveries. Exposure is 4.0 units. Using incurred loss equal to paid loss plus reserves less recoveries, what is the loss cost per exposure unit? (Answer: $700.)
- A hypothetical rating plan multiplies a $900 base premium by factors 1.08, 0.92, and 1.05, in that order. Calculate the premium to cents and identify the lineage item needed for each factor. (Answer: $938.95; document the source or approved input, mapping or rule, and resulting factor for each.)
- A hypothetical indication has a loss cost of $520 and a fixed expense provision of $75. Variable expenses are 18% of premium and the target margin is 7% of premium. Calculate the premium to cents. (Answer: $793.33.)
- A source field records annual use as 9,600 miles, while a model input has bands labeled in thousands of miles. Documentation does not specify the conversion or band boundary rule. What can be calculated, and what lineage issue remains? (Answer: Under an assumed miles-to-thousands conversion the value would be 9.6 thousand miles, but the conversion and boundary rule are undocumented, so band assignment and its rating effect cannot be confirmed.)