Why Damages Allocation results differ in North Dakota

The top 5 reasons results differ

Run this scenario in DocketMath using the Damages Allocation calculator.

When you run DocketMath’s Damages Allocation calculator for North Dakota (US-ND) and notice different results across scenarios or iterations, it’s usually because the calculator’s jurisdiction-aware rules respond differently to your inputs. Even if you believe the “damages number” is the same, small structural or assumption changes can cause the model to allocate into different buckets.

Here are the most common drivers of divergence in US-ND outputs.

1. Which damages categories are eligible for allocation

   • If you input a single combined amount versus splitting it into components (for example, economic vs. non-economic, or compensatory vs. other categories), the allocation may route dollars at the category level rather than treating everything as one undifferentiated total.
   • Result: totals may look similar, but bucket-level distributions can move because the eligible items differ.

2. **Apportionment inputs (or missing apportionment-related inputs)

   • Allocation can change when contributory factors are represented explicitly (or omitted).
   • If one run includes an apportionment-related field (even unintentionally) and another run leaves it blank or defaults it differently, the distribution across claim components can shift.
   • Result: the same overall damages can be redistributed because the model is applying a different apportionment structure.

3. Timeline assumptions that affect “time-weighting”

   • Many damages models allocate based on date ranges (e.g., start/end dates) to weight dollars across periods.
   • A small date change (even a one-day shift) can move amounts from one time bucket to another if the period boundaries or weighting windows change.
   • Result: bucket totals can diverge even if the headline total stays close.

4. Method selection: proportional vs. category-based allocation

   • If you switch the allocation method—or if North Dakota-specific defaults activate differently based on your inputs—results may diverge sharply.
   • Typical behavior:

     • Category-based allocation emphasizes how you break down totals into categories.
     • Proportional allocation emphasizes the weighting basis (for example, duration or occurrence counts).
   • Result: the “same input numbers” can yield different bucket outputs because the governing allocation logic changed.

5. Rounding and unit normalization

   • Allocation often involves intermediate calculations (multiplying weights, dividing by totals, and then rounding).
   • Two runs can look close at each step but still end with meaningfully different bucket sums due to when and how rounding occurs.
   • Result: you may see differences that are not “about facts,” but about computational sequencing.

How to isolate the variable

Use a controlled “diagnostic loop” to identify what changed between outputs. The goal is to reduce the difference to one variable at a time, so you can explain the output shift rather than chase it randomly.

• Freeze the jurisdiction and tool settings so both runs use the same rule set.
• Compare one input at a time (dates, rates, amounts) and re-run after each change.
• Review the breakdown to see which segment or assumption drives the difference.

Quick isolation checklist

• the exact input value that changed

  • the total allocated output
  • which bucket(s) moved (not just whether the total moved)

Minimal-change test (recommended)

1. Run DocketMath with your full North Dakota scenario using the same setup each time: /tools/damages-allocation
2. Duplicate the run.
3. Modify only one of the following in the duplicate:

   • start date
   • end date
   • damages category split (combine vs. separate)
   • allocation method
   • any apportionment-related toggle/field
4. Compare results (bucket-level first).

Use output deltas, not totals

When debugging allocation, focus on which buckets changed rather than only the grand total. For example, if totals remain stable but buckets shift, that often indicates:

• category routing differences,
• apportionment/weighting basis changes, or
• rounding differences after intermediate steps.

Next steps

To converge on a consistent allocation pattern for your North Dakota (US-ND) scenario—without treating any output as legal advice—follow these practical steps:

1. Standardize your input structure

   • Keep one “source-of-truth” damages breakdown format for category inputs.
   • Reuse the same date windows across runs unless the facts truly differ.

2. Lock the allocation method

   • During testing, keep the allocation method constant so you can attribute differences to other inputs rather than method changes.

3. Create a short change log

   • Write down every input you altered between the runs (even if it feels minor).
   • When you rerun, confirm the only difference is the field you intended to change.

4. If differences persist, debug from the first bucket that moves

   • Treat it like a debugging session: identify the first field that causes a bucket to shift, then expand only from there.
   • If a date shift moved bucket totals, re-check period boundaries and any time-weighting basis tied to those dates.

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