How to run Wrongful Death Damages in DocketMath for Indiana

How to run Wrongful Death Damages in DocketMath for Indiana

7 min read

Published May 2, 2026 • Updated April 23, 2026 • By DocketMath Team

Article claim inventory in progress

Trust release 4

This page has legal or numeric text that still needs claim-level inventory before we can treat it as verified.

Step-by-step

Run this scenario in DocketMath using the Wrongful Death Damages calculator.

This guide walks you through running Wrongful Death damages in DocketMath for Indiana (US-IN) using the wrongful-death-damages calculator. You’ll also see how jurisdiction-aware rules (including Indiana’s general statute of limitations) can affect what the tool flags in its output.

Note: DocketMath helps you model and organize numbers. This article is for informational purposes and does not provide legal advice.

1) Open the correct tool

Start at the primary CTA:

  • /tools/wrongful-death-damages
    (Make sure you’re in the Wrongful Death Damages calculator, not a general damages tool.)

2) Confirm the jurisdiction is set to Indiana (US-IN)

Locate the jurisdiction selector (or jurisdiction setting) and set it to:

  • **Indiana (US-IN)

If DocketMath asks you to choose jurisdiction rules, selecting US-IN is what activates the Indiana-specific logic for this workflow.

3) Enter the key timing inputs (the “when”)

Wrongful death calculations in DocketMath typically depend on the timing of the death/event and when damages are being evaluated. Enter dates carefully:

  • Date of incident / death (the event date)
  • Date of filing / evaluation date (the date you’re measuring from)

Then DocketMath can compute whether your scenario falls within the relevant window and may display a statute-of-limitations indicator.

Indiana timing rule you’ll see in the output

Indiana’s general statute of limitations is 5 years for the category being modeled in this walkthrough. Indiana’s general SOL provision is Indiana Code § 35-41-4-2.

Important: No claim-type-specific sub-rule was found for this walkthrough, so DocketMath uses the general/default period (5 years) rather than a specialized timeline.

4) Enter economic loss inputs (the “what”)

Depending on the calculator’s fields, you’ll typically provide inputs such as:

  • Past economic loss (if your workflow models this separately)
  • Future economic loss (if included in the model)
  • Other quantifiable components supported by the jurisdiction-aware template you’re using

If the calculator provides toggles for which components to include, select the ones that match your modeling plan—for example:

  • include future loss only if you have a basis for future projection
  • keep past loss aligned with the same accounting approach (time span, wage assumptions, etc.)

5) Enter demographic/life expectancy or duration inputs (the “how long”)

Many workflows use either duration or age/life-expectancy style inputs. Enter what the calculator requires, such as:

  • Age-related inputs (if required)
  • Duration (if your version uses years remaining or a derived time span)

How outputs change when you adjust these values:

  • Longer time windows usually increase future components (and can increase totals if future loss is enabled).
  • Shorter time windows reduce future totals and may shift the emphasis toward past-only components.

6) Enter adjustment factors (the “multiplier” logic)

If DocketMath includes parameters like:

  • discounting / present value settings
  • inflation or wage growth assumptions
  • allocation/percentage settings (if applicable)

set them to match your modeling approach.

Because these factors compound, even small changes can move totals noticeably. If the tool offers multiple versions or assumptions, document which one you used so your worksheet is reproducible.

7) Review output categories (the “what you get”)

After you run the calculator, DocketMath should display items like:

  • A damages total (often broken into pieces such as past/future or economic/non-economic depending on the template)
  • Any limitation/timing flags tied to the Indiana SOL rule
  • A summary you can export or use as a draft calculation worksheet

Even when the output appears to be a single number, scan the component breakdown. That’s where you’ll usually see which inputs actually drove the results.

8) Check the statute of limitations indicator before finalizing

Because you’re in Indiana (US-IN), DocketMath’s jurisdiction-aware logic will apply the 5-year general SOL guidance from Indiana Code § 35-41-4-2.

If your evaluation date is more than 5 years from the incident/death date, DocketMath may flag a timing concern. Treat this as a modeling indicator for workflow purposes, not a final legal conclusion.

Quick sanity-check using the timing relationship:

ScenarioIncident/Death → EvaluationWhat you should expect in the tool
Within 5 years≤ 5 yearsSOL indicator should reflect “within” behavior for the general period
Outside 5 years> 5 yearsSOL indicator may reflect “outside” behavior for the general period
Dates entered inconsistentlywrong year or swapped datestiming flag may trigger unexpectedly

Warning: Date order matters. If you accidentally swap the incident/death date and the evaluation date, you can push the calculation beyond 5 years and distort the SOL indicator.

9) Run “what-if” scenarios to see sensitivity

Before locking in a worksheet, test at least two variations to confirm your results are stable and your inputs are correct:

  • Change future duration by ±1–3 years (if supported)
  • Change wage growth / discount factor by a small amount (if supported)

This helps you distinguish:

  • true modeling sensitivity (expected changes when assumptions change) from
  • input errors (unexpected swings or flags caused by date mistakes)

10) Save, export, or capture your calculation notes

DocketMath outputs are easiest to validate later when your notes are clear. Record at least:

  • the exact dates entered
  • your duration/life expectancy basis (if any)
  • the economic assumptions you used (even if documented informally)

Common pitfalls

Use this checklist to avoid the most common issues when running Indiana wrongful death damages in DocketMath:

If jurisdiction isn’t set to US-IN, the tool may not apply the Indiana SOL logic tied to Indiana Code § 35-41-4-2. This walkthrough uses the general/default 5-year SOL because no claim-type-specific sub-rule was found for the purposes of this run. Even a one-year error can shift the scenario across the 5-year window and change the SOL indicator. Example: projecting future loss with wage growth while using past figures that weren’t built with the same conventions can make totals hard to justify. If you adjust duration and discounting together, it becomes difficult to tell what actually caused output changes. Totals may appear similar while major components shift underneath—review the breakdown. Without input context, it’s difficult to reproduce or defend the numbers later.

Pitfall reminder: If the calculator shows an SOL-related timing flag, don’t treat it as the final legal answer. First, confirm jurisdiction = Indiana (US-IN) and verify your date entries.

Try it

To run your Indiana wrongful death damages calculation now:

  1. Go to /tools/wrongful-death-damages
  2. Set jurisdiction to **Indiana (US-IN)
  3. Enter:
    • incident/death date
    • evaluation/filing date
    • your economic loss inputs used by your workflow
    • any duration/life-expectancy inputs required by the calculator
  4. Review:
    • the damages total and component breakdown
    • the SOL indicator, using **Indiana Code § 35-41-4-2 (general 5-year period)

Quick test plan (recommended):

  • Run Version A with your best-guess dates and assumptions.
  • Run Version B with the evaluation date moved by ±30 days to check whether the SOL indicator behavior stays consistent.
  • Run Version C with duration changed by ±1 year to see how the future component responds.

If you’re checking whether the tool’s limitations logic behaves as expected, compare Version A vs. Version B first—this isolates timing effects from economic modeling effects.

Related reading