How to interpret Damages Allocation results in Brazil

What each output means

Run this scenario in DocketMath using the Damages Allocation calculator.

DocketMath’s Damages Allocation output for Brazil (BR) helps you translate a total damages figure into an allocation that fits the way damages are commonly handled in litigation records—particularly when your inputs include multiple claims, categories, or time segments.

Because the exact fields you see can change based on the Damages Allocation inputs you selected, use the checklist below to interpret the most common output components consistently.

1) Allocated amounts (by claim / bucket)

You’ll typically see one or more allocated sub-totals that add up to your overall damages total (sometimes called Total allocated damages).

These sub-totals usually represent how the tool assigns portions of damages to one or more of the following, based on the data you provided:

• different causes of action (e.g., contract vs. non-contract theories as captured in the docket data),
• different time windows (e.g., segmented periods if you entered date boundaries),
• different damage categories (e.g., compensatory components vs. other recoverable components—depending on the dataset and mapping selected).

How to read it

• Add the sub-totals to confirm they reconcile to the overall total (allowing for rounding).
• Treat these allocations as modeling results tied to your inputs, not as a statement of what a court will ultimately decide.

2) Allocation percentages

If the interface displays percentages, they’re generally computed from the allocated amounts, conceptually like:

• % for bucket = allocated amount for that bucket ÷ total allocated damages

Use percentages to triage quickly:

• which claim theory / category dominates your allocation,
• which bucket is most sensitive to changes (because a small input shift can disproportionately affect a bucket’s share).

3) Implicit drivers (rate/period indicators)

When your inputs include dates or recurring components, DocketMath may show period-sensitive elements—often in the form of time segments, day counts, or other period-dependent breakdowns.

Even if the tool doesn’t label them explicitly as “interest” or “indexing,” the practical rule is:

• If an output changes when you change the timeline, it’s probably a primary sensitivity driver.

Pitfall to avoid: Don’t assume labels like “pre” vs. “post” automatically match every judge’s terminology. Instead, verify that your input date boundaries align with the events your docket data describes (e.g., when the measure of damages starts and ends).

4) Totals and reconciliation checks

Many results include:

• a Total figure, and
• one or more reconciliation indicators (for example, sum-of-parts checks).

Because of rounding, you may see small differences between:

• the sum of displayed bucket amounts, and
• the displayed total.

A small mismatch is often normal—track it rather than treating it as a data error.

What changes the result most

If you want the biggest insight fast, focus on the three levers below first. In BR damages allocation modeling, these typically create the largest swings.

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

1) Claim / bucket mapping (how amounts get assigned)

The allocation outcome depends on how your numbers are mapped into DocketMath’s categories.

Changing any of the following can reshape the allocation profile—even if your overall total stays similar:

• reclassifying a component into a different bucket,
• regrouping docket components (e.g., splitting or combining categories),
• adding or removing buckets from the inputs.

**Quick test (about 1 minute)

• Take one monetary figure and temporarily move it to a different bucket in your inputs.
• Re-run and compare:

  • bucket totals,
  • top bucket percentages.

2) Timeline boundaries (event dates and cutoffs)

Brazil damages calculations in practice can be sensitive to how events are dated and segmented. In DocketMath, outputs often respond strongly to:

• the start date of a damage period,
• the end date of that period,
• any cutoff dates that create multiple segments.

What to look for

• buckets that swing in amount or share more than others,
• changes in any time-day counts or period-based components,
• re-segmentation that changes how formulas apply across the timeline.

3) Discounting / adjustment parameters you provided (or that were implied)

If your inputs include assumptions about adjustments—such as a rate, an index choice, a method selector, or compounding/step mechanics—allocations can shift because different buckets may be subject to different modeled components.

Practical method

• Identify any input that looks like a rate, index, or method selector.
• Change it slightly (for example, 1–2%) and compare:

  • total allocated damages, and
  • the bucket with the largest share.

Summary table: most sensitive levers

Important caution: A high allocation percentage for one bucket doesn’t automatically mean that bucket is “stronger” legally. In DocketMath, dominance usually reflects how your inputs partition damages, not a merits conclusion.

Next steps

To use Damages Allocation results effectively (and avoid treating unverified output as a definitive answer), follow a simple workflow.

After you run the Damages Allocation calculation, capture the inputs and output in the matter record. You can start directly in DocketMath: Open the calculator.

1) Reconcile first, then interpret

• Confirm the bucket totals sum to the overall total (allowing for rounding).
• Check that bucket labels correspond to how your docket breaks down claims or components.
• Make sure timeline dates match the events described in your record set.

2) Run a sensitivity pass (fast iteration)

Use the “three levers” approach:

• move one component between buckets (mapping),
• adjust one date boundary (timeline),
• modify one adjustment parameter by a small step (rate/adjustment).

Track which change causes the biggest movement in:

• the total allocated damages, and
• the top 1–2 allocation buckets.

3) Create a short internal summary (non-legal)

For your work file, note:

• the top bucket by share (%),
• the second bucket by share (%),
• the key timeline boundaries used,
• which inputs most affected outputs (your sensitivity notes).

This keeps your interpretation grounded in what DocketMath actually modeled from your inputs.

4) Add a “data provenance” note

Because interpretation depends on what the tool ingested, document:

• where each amount came from (line item vs. docket extract),
• why the date boundaries were chosen,
• what mapping rules you used to assign components to buckets.

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