How to interpret Damages Allocation results in Idaho

What each output means

Run this scenario in DocketMath using the Damages Allocation calculator.

DocketMath’s Damages Allocation results for Idaho (US-ID) are meant to translate a damage estimate into an allocated structure across one or more damages buckets (for example, different compensatory components or subcategories). That allocation can change the bottom-line total you use for evaluation or settlement discussion.

Because DocketMath is a calculator, not a court order, treat the results as structured estimates that support analysis—not legal conclusions.

In Idaho, damages timing matters alongside allocation. For timing, the workflow’s referenced default SOL rule is the general period (and no claim-type-specific sub-rule is provided in this calculator workflow). Use the default below:

• General SOL Period: 2 years
• General Statute: Idaho Code § 19-403
• Source: https://law.justia.com/codes/idaho/title-36/chapter-14/section-36-1406/?utm_source=openai

When you run DocketMath → /tools/damages-allocation, the output typically includes the following elements. Exact labels can vary, but the concepts usually hold:

1. Allocated amounts by bucket

   • Each bucket number represents the portion of your overall damages estimate assigned to a specific category based on your inputs and the calculator’s allocation logic.
   • Use the bucket allocations to understand what the model thinks is driving the total—not just what the total is.

2. Subtotal and overall totals

   • Subtotals (if shown) group related buckets.
   • The overall total is the aggregate of the allocated buckets.
   • If you see a “surprisingly high” total, compare bucket values first; the total is usually the sum of those drivers.

3. **Time-sensitive or “due/allowed window” impacts (when enabled)

   • Some views incorporate SOL timing logic to determine whether certain portions fall within an allowed window.
   • For Idaho, the default timing window referenced in these workflows generally uses 2 years under Idaho Code § 19-403.
   • Practical interpretation: if your inputs include damages that fall outside that 2-year window relative to the calculator’s relevant trigger date, those amounts may be excluded from the counted total shown in results.

4. **Change indicators (if you compare scenarios)

   • If you run multiple scenarios (for example, different assumed dates or alternative inputs), the output may show differences between runs.
   • In practice, deltas (changes) are often more informative than absolute totals because they reveal which assumption is causing the shift.

How to read “period” effects in Idaho results

If your Damages Allocation output includes a damage-period component—such as “counting” only damages within a lookback window—then the default 2-year SOL becomes central to interpretation.

• Under the calculator workflow described here, the timing window generally uses Idaho Code § 19-403 as the 2-year default.
• That means: if parts of your damages period fall beyond the 2-year cutoff from the trigger date used by the calculator, those amounts may be reduced or excluded in the “counted” result.

Gentle reminder: a calculator cannot determine legal applicability to your specific claim. Use the SOL rule above as the workflow default, and confirm whether your case file requires a different timing analysis.

What changes the result most

To interpret Damages Allocation outputs efficiently, focus on the inputs that commonly move totals the most in Idaho runs. Use this checklist while reviewing your output:

• Trigger/key date used for SOL timing

  • If the output uses SOL filtering, the trigger date effectively sets the 2-year lookback under Idaho Code § 19-403.
  • Even modest date changes can push portions of damages just inside or outside the window, causing noticeable swings.

• Start and end dates for the damages period

  • A longer period often increases included damages.
  • Shortening the period—or shifting it—can reduce totals sharply if part of the period crosses the 2-year SOL cutoff.

• Bucket allocation inputs

  • If you provide category amounts or allocation percentages, the bottom-line total typically tracks the most heavily weighted bucket(s).
  • When the largest bucket changes between scenarios, the overall total usually follows.

• **How damages were entered (granular vs. lump sum)

  • Granular entries allow more transparent allocation across buckets, making it easier to spot the driver.
  • Lump-sum entries can reduce transparency—sometimes you’ll see a large total shift without a clear “why” unless you review bucket breakdowns carefully.

• Scenario comparisons

  • When you run “before vs. after” scenarios, prioritize the difference view (deltas).
  • If the delta aligns with changes to dates, the SOL window (2 years under Idaho Code § 19-403) is likely the main driver.
  • If the delta aligns with changes to percentages/bucket assignments, allocation assumptions are likely driving the result.

Idaho “interpretation moment” to watch

Because the default SOL period is 2 years, the biggest interpretation risk (and the biggest sensitivity) usually happens when:

• Your damages period begins just over 2 years before the calculator’s trigger date, or
• Your damages period ends just over 2 years before the trigger date.

In these situations, a small date adjustment can cause a narrow slice of damages to flip from “counted” to “excluded,” producing an outsized change relative to how small the date change seemed.

Next steps

Use the Damages Allocation output to turn calculations into a testable case assessment. A practical Idaho workflow:

1. Confirm the timing anchor used in the run

   • Identify the date the calculator uses as the SOL trigger (even if presented generically in the UI).
   • Confirm your damages period start/end dates map to your factual timeline the way you expect.

2. **Sanity-check the biggest bucket(s)

   • Look at the largest allocated bucket(s).
   • Ask what factual component those buckets correspond to in your case notes. If the mapping doesn’t make sense, adjust inputs and re-run.

3. Run one targeted scenario change

   • Change only one variable at a time to keep interpretation clean:

     • SOL trigger date, or
     • damages period start/end date, or
     • bucket allocation assumption(s)
   • Re-run and compare totals to see whether the result is driven mainly by timeline (Idaho Code § 19-403 default 2-year window) or by allocation.

4. Document your assumptions

   • Record:

     • the run date,
     • key input dates and any allocation assumptions,
     • the bucket breakdown (or at least the top drivers),
     • and the Idaho timing rule used as default: Idaho Code § 19-403 (2 years).
   • This helps you explain your assumptions in settlement discussions or internal review.

5. Use the output as decision support

   • DocketMath structures and estimates; courts decide legal issues and factual disputes.
   • If your case theory depends on a different timing rule than the workflow default, the calculator results should be treated accordingly.

If you want to rerun with changes, start a fresh run in /tools/damages-allocation and keep scenario differences tightly controlled.

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