Why an Extreme Value Is Not Automatically an Error
A value can be unusual for several different reasons. It may have been entered incorrectly, it may be a rare but valid observation, or it may belong to a real subgroup with a different pattern from the rest of the data. These explanations call for different actions. A statistical outlier rule can identify a record for review, but it cannot establish which explanation is true.
This distinction matters in predictive analytics. Correcting a valid high-cost claim can erase information about severe losses; retaining a misplaced decimal can distort summaries and model fitting. The appropriate response depends on evidence about what the variable represents and how the value was recorded, not merely on how far it lies from the center of a distribution. This evidence-based approach is aligned with the SOA Exam PA (Predictive Analytics) syllabus.
The word relevant is important. A value may be extreme compared with all records but ordinary for its exposure, product, region or other meaningful group. Conversely, a value that falls within a broad range of observed data can still be wrong if the source record confirms a transcription error.
A Defensible Review: Evidence Before Action
Start by restating what one row represents and what the field measures, including units and timing. Then inspect the specific record and compare it with reliable source information where available. Check whether the value is allowed by the field’s definition and any genuine contractual or operational constraints. Finally, consider whether a recorded group or exposure explains the difference.
Establish the unit, time period, population and whether the field is a raw measurement, a transformed quantity, a count or an amount after a limit or adjustment.
Compare the value with the original form, system record or other reliable source. Look for a misplaced decimal, swapped digits, duplicated record or unit mismatch.
Ask whether the value is possible for this observation and whether it is compatible with the stated exposure, coverage, date and measurement process.
Compare the record with observations from relevant, defensible subgroups. A meaningful difference between groups may explain an apparent pooled extreme.
Correct a confirmed error using verified information; retain a supported valid observation; or leave an unresolved record explicitly under review rather than guessing.
A domain rule is useful only when it applies to the variable as recorded. For example, a policy limit may constrain the insurer’s payment, but not necessarily the gross loss amount. Rejecting every gross loss above that limit would confuse two different quantities. Similarly, a physically impossible value is strong evidence of a problem, but it does not by itself identify the correct replacement value.
Worked Examples: Three Different Explanations
Worked Example: A Confirmed Unit and Decimal Error
A hypothetical portfolio file contains annual income in dollars. Most records are between $42,000 and $118,000. One record is $850,000. The original application for that record states annual income of $8,500, and the import specification confirms that this one source field was supplied in cents. Decide what to do with the record.
Method. Verify the variable definition, compare the flagged record with its source, and convert the value using the documented unit. Do not infer a correction from the other records’ range alone.
The file’s unit is dollars, while the source value for this record is in cents. Convert cents to dollars by dividing by 100:
The source application independently records $8,500, so both the unit conversion and the original record agree. The appropriate corrected value in the dollar field is $8,500, not $85,000 or $850,000.
Check. Multiplying the corrected dollars by 100 gives 850,000 cents, matching the imported source value. This is a confirmed data-representation error, not a valid high-income case.
Common mistake avoided. Replacing $850,000 with a typical value such as the portfolio median would be unjustified. The evidence supports a specific unit conversion, not an estimate based on neighboring records.
Worked Example: A Rare but Supported Claim
A hypothetical insurer’s field is the covered payment for an individual property claim, after application of the policy limit. Most payments in the review sample are below $30,000. One payment is $180,000. The policy limit for that record is $250,000, and the claim file and payment ledger both confirm $180,000. Decide whether the value should be treated as an error.
Method. Check the record against its source and a constraint that actually applies to the field, then assess whether the high value remains possible.
The claim file and ledger agree on the payment. The relevant policy limit is $250,000, so the payment does not exceed it. Its proportion of the limit is
Thus the confirmed payment is 72% of the applicable limit. Being much larger than most payments makes it worth understanding, but it does not contradict the field definition, the source documents or the limit. With the evidence given, retain it as a plausible extreme observation. It may represent a rare severe claim.
Check. The amount is positive, below the applicable $250,000 limit, and independently verified. These checks support validity; they do not imply that $180,000 is typical.
Common mistake avoided. Deleting or capping the payment merely because it is far above most claims would discard a verified observation. A statistical flag is a prompt to investigate, not proof of a recording error.
Worked Example: A Real Subgroup Behind Pooled Extremes
A hypothetical repair-cost data set contains five passenger-car records of $1,000, $1,200, $1,400, $1,600 and $1,800, and three bus records of $6,000, $6,500 and $7,000. Vehicle class is recorded for each row, and the source invoices confirm the costs. Explain why bus costs may look extreme in the pooled data and choose a defensible response.
Method. Compare group summaries and use the law of total variance to separate within-group variability from variability between group means. Here use population variances, dividing by each group’s count.
For the five cars, the mean is
The car deviations from $1,400 are $-400, $-200, $0, $200 and $400. Their squared deviations sum to \(160{,}000+40{,}000+0+40{,}000+160{,}000=400{,}000\). The car population variance is therefore \(400{,}000/5=80{,}000\).
For the three buses, the mean is \((6{,}000+6{,}500+7{,}000)/3=19{,}500/3=6{,}500\). Their deviations are \(-500,0,500\), so the squared deviations sum to \(250{,}000+0+250{,}000=500{,}000\). The bus population variance is \(500{,}000/3=166{,}666.67\), rounded to two decimals.
The pooled mean is
Every bus cost is well above that pooled mean, but the bus records are close to their own group mean of $6,500. The difference between the group means is $5,100, and the invoices and vehicle labels support a genuine difference in repair-cost scale. The defensible response is to retain the verified costs and preserve vehicle class as meaningful context for analysis, rather than treating bus records as erroneous because they differ from cars.
Common mistake avoided. Comparing every record only with the pooled center can make a group difference look like a collection of data errors. The subgroup is supported by a real recorded characteristic and source evidence, not created merely to excuse inconvenient values.
Why Subgroups Can Produce Pooled Extremes
The law of total variance explains the issue in the previous example. Let \(X\) be a numeric observation and \(G\) a categorical group. The population variance can be decomposed into the average variance within groups and the variance of group means:
To see why, let \(\mu=E[X]\) and write \(X-\mu=(X-E[X\mid G])+(E[X\mid G]-\mu)\). When the square is expanded and averaged, the cross-product has expectation zero: conditional on \(G\), \(E[X-E[X\mid G]\mid G]=0\). The first squared term averages to \(E[\operatorname{Var}(X\mid G)]\); the second averages to \(\operatorname{Var}(E[X\mid G])\). Adding them gives the stated identity.
For the repair-cost example, the within-group term is \((5/8)(80{,}000)+(3/8)(166{,}666.67)=50{,}000+62{,}500=112{,}500\). The between-group term is \((5/8)(1{,}400-3{,}312.50)^2+(3/8)(6{,}500-3{,}312.50)^2\). The squared differences are \(1{,}912.5^2=3{,}657{,}656.25\) and \(3{,}187.5^2=10{,}160{,}156.25\). Weighting gives \(2{,}286{,}035.15625+3{,}810{,}058.59375=6{,}096{,}093.75\). The total variance is therefore \(112{,}500+6{,}096{,}093.75=6{,}208{,}593.75\).
Most of this pooled variance comes from differences between the car and bus means, not from variation among records within each group. A pooled distribution can therefore make valid members of a high-mean group appear extreme. This result does not prove that a particular record is valid; it shows why subgroup context is important to the investigation.
When Evidence Is Incomplete
Not every flagged record can be conclusively classified. A value might be possible but lack a source document; a field definition might be unclear; or the candidate subgroup may be too small to support a reliable comparison. In those cases, do not convert uncertainty into a confident correction. Record what was checked, what remains unknown and which assumptions are being made before deciding how to proceed.
- Confirmed error: use the verified intended value if it can be recovered. If it cannot, do not invent a replacement simply because the recorded value is unusual.
- Supported valid extreme: retain the observation as recorded, while preserving the context that makes it interpretable.
- Unresolved case: keep the uncertainty visible for subsequent analysis and communicate the limitation. An unsupported “fix” can be more damaging than an acknowledged uncertainty.
- Possible subgroup: check that the grouping variable has a substantive meaning and is reliably recorded. A convenient category invented after seeing an extreme is not sufficient evidence.
Keep a clear distinction between evidence and judgment. For example, “the source ledger confirms the payment and the amount is below the applicable limit” is auditable evidence. “The amount seems too high” is a reason to investigate, not a final classification.
Check Your Understanding
For each situation, identify the strongest available evidence and give a defensible action. Answers are shown at the end of each question.
- A hypothetical data field records height in centimetres. One record is 1.82, while the source form gives 1.82 metres and the import notes confirm that this record was not converted. What value belongs in the centimetre field, and why? (Answer: 182 cm; convert the verified 1.82 m to centimetres by multiplying by 100.)
- A hypothetical claim field records gross loss before policy limits. A verified loss is $84,000, while the policy’s payment limit is $75,000. Should the gross-loss value be rejected as impossible? State the distinction and response. (Answer: No; $84,000 is gross loss before limits, so it can exceed the $75,000 payment limit. Retain it if the source verifies it.)
- A hypothetical equipment dataset has four small-machine repair costs of $900, $1,000, $1,100 and $1,200, and three industrial-machine costs of $4,000, $4,500 and $5,000. All invoices are verified. Calculate each group mean and state whether the industrial values alone establish entry errors. (Answer: Small-machine mean = $4,200/4 = $1,050; industrial-machine mean = $13,500/3 = $4,500. No; the verified costs are consistent with a distinct equipment group, so investigate and retain the subgroup context.)
- A hypothetical monthly-benefit file contains a value of $48,000 where most records are below $5,000. The policy schedule shows a $6,000 monthly maximum, but no claim record or source extract is available. What can be concluded, and what should happen before correcting the value? (Answer: The value conflicts with the stated maximum if the field is monthly benefit after applying that maximum, but its intended replacement is unknown. Verify the field definition and source record; do not guess a corrected value.)
- A hypothetical portfolio has large, verified payments concentrated among one product type. What two checks help distinguish a genuine product subgroup from a data-quality problem, and what is a reasonable response if both checks support the subgroup? (Answer: Confirm that product type is reliably recorded and substantively explains different exposures or payment patterns; verify the extreme records against source documents and applicable field constraints. If supported, retain the values and the subgroup information rather than treating them as errors.)