Why Table Design Matters
A table can make a model result easy to use—or make a correct result difficult to interpret. Readers should be able to identify what is being compared, what each number measures, and which direction represents better performance without having to reconstruct the analysis. A table designed for a decision is therefore more than a container for output: its labels, units, comparison columns, and notes carry part of the evidence.
The aim is not to include every available statistic. It is to select and organize the results that help answer a specific question. For example, a decision-maker considering a model for review prioritization may need to compare missed cases and unnecessary reviews at candidate thresholds. A table containing many unlabeled model metrics may be technically correct but still fail to support that decision.
Design the Table Around the Comparison
Begin by stating the question the table must answer. The question determines what belongs in the rows and columns. Rows commonly represent models, segments, thresholds, or time periods. Columns commonly represent metrics, counts, units, or differences from a reference. A useful layout makes the intended comparison visible rather than leaving the reader to scan disconnected numbers.
Specify what the reader is comparing or deciding, such as whether a candidate model improves validation error relative to a baseline.
Use rows for the objects being compared and columns for the measures needed to compare them. Keep the same measure in the same column.
State the metric, unit, relevant population or denominator, and—where needed—the period or validation setting.
Use a clear baseline, a defined change column, and a brief note stating how to interpret the metric and any important limitation.
A column heading such as “Error” is usually insufficient. It does not say whether the value is mean absolute error (MAE), root mean squared error (RMSE), or something else; it also omits the unit. A heading such as “MAE per policy (dollars)” is more informative. If results come from a validation sample, say so in the table title or note. If a rate is calculated from a denominator, make that denominator clear in a label or note.
For model comparisons, a compact structure often places each model on one row and each metric in a separate column. A change column can then make the comparison explicit. Define its sign convention: “reduction in RMSE” is positive when the candidate has lower RMSE, while “candidate minus baseline” is negative in that same situation. Either convention can work; an unstated convention cannot.
Worked Example: Combining Segment Results Correctly
A hypothetical insurer evaluates a claim-cost model on 100 validation policies. Segment North contains 80 policies with an MAE of $120 per policy. Segment South contains 20 policies with an MAE of $300 per policy. The decision-maker asks for the overall validation MAE and a compact segment comparison table. Use the supplied segment counts and MAEs as exact values.
Method. An overall MAE is the average absolute error across all individual policies. A segment MAE is already an average within that segment, so combine the segment averages using their numbers of policies as weights.
North contribution to total absolute error. There are 80 policies, each contributing an average absolute error of $120: \(80 \times \$120 = \$9{,}600\).
South contribution to total absolute error. There are 20 policies, with an average absolute error of $300: \(20 \times \$300 = \$6{,}000\).
Combine and divide by the total number of policies. Total absolute error represented by the segment summaries is $9,600 + $6,000 = $15,600. There are 80 + 20 = 100 policies, so the overall MAE is $15,600 ÷ 100 = $156 per policy.
| Validation segment | Policies (count) | MAE per policy (dollars) | Contribution to total absolute error (dollars) |
|---|---|---|---|
| North | 80 | $120 | $9,600 |
| South | 20 | $300 | $6,000 |
| Overall | 100 | $156 | $15,600 |
Check. The overall MAE of $156 lies between the segment MAEs of $120 and $300, and it is closer to $120 because North has more policies. The common mistake is to take the unweighted average, \((\$120+\$300) ÷ 2 = \$210\). That treats the two segments as equally large, which they are not, and is not the overall policy-level MAE.
Comparison Columns and a Short Justification
A comparison table should show both the values being compared and the meaning of any reported change. For a metric where lower is better, one possible convention is to report the reduction from baseline:
This percentage is defined when the baseline value is nonzero. It describes the change relative to the baseline, not the candidate. A table must still state which metric is used and whether a lower value is preferred; the sign of a number alone does not explain its meaning.
The reason for the weighted average used in the previous example follows directly from the definition of a mean. If segment \(j\) contains \(n_j\) observations and has mean absolute error \(m_j\), then its total absolute error is \(n_jm_j\). Across \(J\) disjoint segments, the total absolute error is \(\sum_{j=1}^{J} n_jm_j\), and the total number of observations is \(\sum_{j=1}^{J} n_j\). Dividing the total error by the total count gives:
This identity applies when the segment results use the same definition of MAE and cover the observations being combined without overlap or omission. It does not justify averaging segment MAEs equally unless the segment counts are equal. It also does not allow an MAE to be combined with a different metric such as RMSE.
Worked Example: Showing Model Improvement Without Hiding the Baseline
A hypothetical pricing team compares two models on the same 400-policy validation set. The baseline has MAE of $780 per policy and RMSE of $1,200 per policy. The candidate has MAE of $720 and RMSE of $1,050. The team wants a table showing the values and the candidate’s percentage reduction from baseline for each metric. Both metrics are measured in dollars per policy, and lower values indicate smaller prediction errors.
Method. Keep MAE and RMSE in separate columns because they summarize error differently. Calculate each reduction from its own baseline value, then divide by that baseline to obtain its percentage reduction.
MAE reduction. The absolute reduction is $780 − $720 = $60 per policy. The percentage reduction is \((\$60 ÷ \$780) \times 100\% = 7.6923\ldots\%\), or 7.7% to one decimal place.
RMSE reduction. The absolute reduction is $1,200 − $1,050 = $150 per policy. The percentage reduction is \((\$150 ÷ \$1,200) \times 100\% = 12.5\%\).
| Model | MAE per policy (dollars) | RMSE per policy (dollars) | MAE reduction from baseline | RMSE reduction from baseline |
|---|---|---|---|---|
| Baseline | $780 | $1,200 | — | — |
| Candidate | $720 | $1,050 | $60 (7.7%) | $150 (12.5%) |
Check. In both metric columns the candidate value is below the baseline, so both reductions are positive under the stated convention. The common mistake is to report “12.5% better overall” as if that one percentage described both metrics. It describes only the RMSE reduction here; the MAE reduction is 7.7%. The table also avoids implying that RMSE and MAE are interchangeable by giving them distinct columns. The comparison is interpretable because the two models use the same validation set and the units and direction are stated.
Make Denominators and Decision Consequences Visible
Rates and percentages are easier to interpret when the reader can see what they are rates of. For example, “recall = 0.80” is less useful than “recall: 32 of 40 actual events (80.0%).” Counts help readers understand how much data supports a rate and allow them to check its denominator. When the decision involves consequences such as review workload or missed events, include the relevant counts or a clearly defined cost measure rather than relying on a performance rate alone.
The following example uses a hypothetical validation sample. The cost amounts are assumed decision inputs, not observed market results. Costs are assigned to false positives and false negatives only; true positives and true negatives have zero cost in this simplified calculation. In practice, the table note should make such assumptions visible.
Worked Example: Comparing Thresholds With Counts and Costs
A hypothetical claims team evaluates two score thresholds on the same 200-claim validation set. There are 40 claims with the target event and 160 without it. At threshold 0.30, the model identifies 32 actual events, flags 28 non-events, misses 8 events, and correctly leaves 132 non-events unflagged. At threshold 0.50, it identifies 26 events, flags 14 non-events, misses 14 events, and correctly leaves 146 non-events unflagged. Assume each false positive costs $40 in unnecessary review and each false negative costs $250 in missed-event impact.
Method. For each threshold, calculate sensitivity as true positives divided by all actual events, and precision as true positives divided by all flagged cases. Calculate the stated simplified cost by multiplying false positives by $40 and false negatives by $250, then adding the results.
Threshold 0.30. Sensitivity is \(32 ÷ 40 = 0.8000\), or 80.00%. There are \(32+28=60\) flagged claims, so precision is \(32 ÷ 60 = 0.5333\), or 53.33% to two decimal places. Cost is \((28 \times \$40)+(8 \times \$250)=\$1{,}120+\$2{,}000=\$3{,}120\).
Threshold 0.50. Sensitivity is \(26 ÷ 40 = 0.6500\), or 65.00%. There are \(26+14=40\) flagged claims, so precision is \(26 ÷ 40 = 0.6500\), or 65.00%. Cost is \((14 \times \$40)+(14 \times \$250)=\$560+\$3{,}500=\$4{,}060\).
| Score threshold | True positives (claims) | False positives (claims) | False negatives (claims) | Sensitivity (of 40 events) | Precision (of flagged claims) | Simplified cost (dollars) |
|---|---|---|---|---|---|---|
| 0.30 | 32 | 28 | 8 | 80.00% | 53.33% | $3,120 |
| 0.50 | 26 | 14 | 14 | 65.00% | 65.00% | $4,060 |
Check. At either threshold, true positives plus false negatives equal 40 actual events. At 0.30, 32 + 28 = 60 claims are flagged; at 0.50, 26 + 14 = 40 are flagged. Under the stated cost assumptions, threshold 0.30 has the lower simplified cost by $4,060 − $3,120 = $940. The common mistake is to compare precision alone and select 0.50 without considering that it misses 6 more events. The result supports a cost comparison under the assumptions given; it does not establish that either threshold is operationally feasible if review capacity or other constraints matter.
Notes, Layout, and Common Traps
A compact table can be clear without being crowded. Put the most decision-relevant columns first, use consistent units and decimal places, and avoid repeating long explanations in every cell. A concise note can state shared context once—for example, the validation population, period, metric direction, or cost assumptions. If a table uses abbreviations, define them in a note. If one value is unavailable or not applicable, use a clear label rather than leaving a blank that could be mistaken for a missing result.
- Unclear labels: Replace “Score” or “Error” with a metric name, unit, and relevant denominator or population.
- Hidden comparison basis: State which model is the baseline and calculate every change relative to that same reference.
- Unweighted group averages: Do not combine segment averages by taking their simple mean when segment sizes differ; use the correct observation counts.
- Ambiguous signs: Define whether a positive change means improvement, an increase, or candidate minus baseline.
- Rates without counts: Include the numerator and denominator where they help the reader judge what the rate represents.
- Too many metrics: Keep measures that answer the decision question; more columns do not automatically provide more useful evidence.
The table should not overstate what the displayed numbers establish. A good note can clarify that results come from a particular validation sample or depend on stated cost assumptions. That context helps readers interpret the comparison without turning the table into a substitute for a fuller account of the analysis.
Check Your Understanding
For each problem, identify the relevant comparison and check that the displayed denominator or weighting is appropriate.
- A hypothetical model has segment A with 60 validation cases and MAE of $90, and segment B with 40 cases and MAE of $210. What is the overall MAE? (Answer: $138 per case.)
- On the same validation set, a baseline RMSE is $2,400 and a candidate RMSE is $2,100. What is the candidate’s percentage reduction from baseline, rounded to one decimal place? (Answer: 12.5%.)
- In a validation set with 20 actual events, a threshold produces 15 true positives, 20 false positives, 5 false negatives, and 60 true negatives. What are sensitivity and precision, each to four decimal places? (Answer: sensitivity = 0.7500; precision = 0.4286.)
- A table reports MAE of 0.18 but gives no unit, population, or validation context. Name three additions that would make the result more interpretable. (Answer: State the MAE unit, identify the population or observation unit, and state that the result is from the specified validation data or period.)
- Two segments have counts of 30 and 70 and MAEs of $80 and $140, respectively. Calculate the overall MAE and explain why the simple average of the two segment MAEs is not correct. (Answer: Overall MAE = \((30 \times \$80 + 70 \times \$140) ÷ 100 = \$122\) per case; the simple average of $110 gives equal weight to unequal segment sizes.)