How to interpret Damages Allocation results in United States Federal

What each output means

Run this scenario in DocketMath using the Damages Allocation calculator.

If you ran the Damages Allocation calculator in DocketMath for United States Federal (US-FED), the results are typically shown as a breakdown of your estimated damages into allocable portions—most commonly by damage category and sometimes by party/responsibility depending on how your run is configured.

The exact labels can vary based on the calculator inputs you chose (and what components the US-FED ruleset enables). But the goal is consistent: convert a single damages estimate into a distribution that’s easier to interrogate and compare against your assumptions.

Below are the common output types you’ll see and how to interpret them in a practical, jurisdiction-aware way.

1) Total estimated damages

This is the calculator’s combined estimate before allocation into categories/parties.

• How to use it: Treat it as the baseline for later breakdowns.
• How to sanity-check: If you expected a different magnitude, the issue is usually in the inputs (e.g., your damages basis, included periods, or any rate-like assumptions), not in the allocation logic itself.
• How to interpret carefully: A “total” shown here is not a court finding—it’s your model’s starting point transformed by your entered assumptions.

2) Allocated amounts by category (or claim type)

Many runs show a table that breaks the total into buckets such as:

• Economic damages (quantifiable monetary loss)
• Non-economic damages (if your configuration includes them)
• Time-based components (e.g., interest or other period-driven components, if enabled)
• Other specified components (depending on what you entered and how the tool maps your inputs)

What this means: These allocated amounts are the calculator’s way of distributing the baseline total across the categories your model includes.

Practical tip: If one category’s dollar amount looks unusually high or low, it usually points to an input classification mismatch (for example, mapping a loss to the wrong category bucket), not a mathematical error.

3) Percentage allocation (share of total)

Some outputs add a percent-of-total view for each bucket. Percentages are especially useful when you want to compare scenarios because they reveal relative weight, even when the total changes.

• How to use it: Identify which bucket dominates (for example, “economic” being 70–90%).
• How to interpret shifts: If totals stay close but percentages move a lot, it usually means your changes caused the allocation to redistribute across categories.

4) Party allocation (if applicable to your run)

If your US-FED scenario includes more than one party (or responsibility/apportionment inputs), you may see outputs showing:

• Share of damages per party
• Potential net effects after offsets/credits (only if your run supports those inputs)

What this means: These figures reflect the calculator’s application of your entered party/responsibility structure to the allocated damages.

Important framing: Party allocation outputs are a model representation of your assumptions. They are not an automated prediction of who is legally entitled to recover what.

What changes the result most

The fastest way to understand your output is to identify which “layer” you changed. In US-FED interpretations, the largest swings typically come from inputs that affect the allocation basis and any time/valuation window.

These inputs have the biggest impact on the final number. Adjust them one at a time if you need a sensitivity check.

• date range
• rate changes
• assumption changes

Highest-impact inputs (often)

Check whether your run depends on any of the following (the UI labels may differ):

• Damages basis / category mapping

  • Choosing the wrong category (or an overly broad bucket) can misallocate dollars even if your overall total seems plausible.
• Time period selection

  • Start/end dates (and duration assumptions) can significantly affect time-based components like interest or other period-driven pieces (if included).
• Apportionment or responsibility inputs (if included)

  • Any entered percentages, weights, or allocation rules often directly determine party splits.
• Growth/discounting or rate-like assumptions

  • Even small rate changes can create large dollar differences when applied over long durations.
• Offsets / credits

  • Offsets can reduce totals and change the shape of the allocation—sometimes making smaller categories appear to “disappear” from the breakdown.

Quick sensitivity checklist (before you rely on outputs)

Use this as a practical pre-flight check:

An “interpretation pattern” to apply when results change

When the output changes, ask which part changed:

1. Total changed substantially

   • Likely driven by valuation inputs, time windows, or rate-like assumptions.
2. Total stayed similar, but category percentages shifted

   • Likely driven by reallocation among categories based on your mapping or allocation rules.
3. Party shares changed

   • Likely driven by apportionment/responsibility inputs, not by the underlying damages category amounts.

Next steps

To move from “reading results” to using them responsibly in your workflow, focus on auditability and scenario testing—not certainty.

Run the Damages Allocation calculator now and save the inputs alongside the result so the workflow is repeatable. You can start directly in DocketMath: Open the calculator.

1) Create an input-to-output mapping you can explain

Make a simple internal checklist that ties each output line back to the relevant inputs you entered:

• Which input maps to each category in the results?
• Which dates drive any time-based or interest-like components?
• Which inputs drive any party allocation outputs?

If the output includes categories you didn’t intend, revisit category selection and ensure each bucket maps cleanly to your factual narrative.

2) Run stress tests (2–3 variants)

Use small, purposeful changes to understand robustness:

• Date window stress test: adjust start/end dates by ~30 days
• Rate/assumption stress test: if a rate is present, change it modestly (e.g., ±1–2 percentage points if the UI uses annual rates)
• Category mapping stress test: toggle the most uncertain category classification

Then compare:

• Total damages
• Dominant category percentage
• Any party allocation percentages

3) Prioritize the outputs that drive decisions

In practice, not every line matters equally. Focus review on:

• the largest dollar bucket
• the largest percentage swing across variants
• the most model-dependent categories (often those tied to time windows or rate-like assumptions)

If these look unstable, treat the allocation table as a prompt to refine inputs or tighten your factual support before using results downstream.

4) Document the run for consistency across a team

If your DocketMath workflow supports saving runs, capture:

• the key input fields (dates, rates/assumptions, offsets, mappings)
• the resulting allocation table
• one or two stress-test variants

This helps prevent confusion when team members compare outputs.

If you’re ready to generate or revisit allocations, start here: /tools/damages-allocation

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules