How to run Wrongful Death Damages in DocketMath for New York

How to run Wrongful Death Damages in DocketMath for New York

7 min read

Published June 3, 2025 • 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 walkthrough shows how to run Wrongful Death Damages in DocketMath for New York (US-NY) using jurisdiction-aware rules. It focuses on setting the inputs correctly and understanding how the outputs change when you adjust facts.

Note: This is a practical tool guide, not legal advice. Wrongful death calculations can be fact-specific—especially around beneficiaries, income evidence, and timing.

1) Open the calculator

Start from the primary CTA and load the correct tool:

  • /tools/wrongful-death-damages

If you’re already in DocketMath, also confirm the jurisdiction selector is set to New York (US-NY) before you enter numbers. (Changing jurisdiction after entering inputs can make results inconsistent.)

2) Confirm the jurisdiction and the default time rules

For this New York setup, DocketMath uses the general/default Statute of Limitations period rather than a wrongful-death-specific sub-rule.

Important configuration note for this tool run:

  • The jurisdiction dataset indicates no claim-type-specific sub-rule was found.
  • So you should treat the limitation period as the general/default 5-year rule for the tool’s timing checks and exposure modeling.

3) Enter the core wrongful death inputs

Wrongful death damages modeling in DocketMath commonly depends on inputs that represent the economic contribution and the projection horizon. Depending on how the calculator is laid out, you may see fields such as:

  • Annual income (or the tool’s required income format)
  • A time horizon (for example, “expected remaining work years” or an equivalent field)
  • A dependency/share fraction (if the tool supports it)
  • Other assumption fields (like discounting or growth), which may have defaults

Practical input approach (to keep your run internally consistent):

  • Use annual income if the tool expects annual values.
  • Use a time horizon in years if the tool expects years (don’t mix years and months).
  • If there’s a share/dependency field, enter it as the tool’s required format (e.g., fraction/percentage—match the label exactly).
  • Avoid mixing units (for example, don’t enter monthly income into an annual-income box).

4) Set the timing window (the “5-year” constraint check)

In DocketMath, the timing logic typically uses relevant dates you enter (commonly an incident date and/or a filing date). The goal is to see whether the scenario falls within the default limitation window.

With the New York default configuration:

How to run it in the tool:

  1. Enter the date(s) the calculator requests.
  2. Look for the tool’s timing indicator (often something like “within” vs. “outside” the limitation window).
  3. If there’s a toggle (e.g., “timing adjustment” or similar), keep it consistent with your workflow. Model the scenario you’re trying to evaluate—don’t treat the toggle as a guarantee of legal outcomes.

Warning: A timing mismatch can change the modeled results materially. Even if your economic inputs are correct, being outside the default 5-year window can affect whether the tool treats the scenario as timely and how it reports totals.

5) Choose the assumptions that drive the projection

Most damages calculators require at least one economic assumption such as:

  • discount rate / present value
  • wage growth
  • earnings period / survival horizon
  • or a dependency contribution share

How to handle assumptions practically:

  • Start with tool defaults if you don’t have strong basis to change them.
  • Then run a small set of scenarios to see which inputs the output responds to most.

A good sensitivity pattern (3 passes):

  • Baseline: defaults + your best estimate inputs
  • Conservative: lower income and/or shorter horizon (and/or less favorable assumption inputs)
  • Optimistic: higher income and/or longer projected contributions

The purpose isn’t to “pick the right answer”—it’s to understand how sensitive the output is to the facts you input.

6) Review the output breakdown

After you run the calculation, review how the totals are built. While exact labels can vary by version of the calculator, you should generally look for:

  • Total damages (overall figure)
  • Component breakdown (economic loss components vs. any other included categories)
  • Timing-related notes (based on the dates you entered)

Sanity-check the results against your inputs:

  • If you increase dependency/share, the economic contribution component should generally move upward proportionally.
  • If you change dates, the tool’s timing status should update accordingly (e.g., timely vs. outside the window).
  • If you change the horizon, the projection should generally lengthen/shorten and affect the total.

7) Export or document your run for consistency

If you’ll share results or compare scenarios, record:

  • the jurisdiction (US-NY),
  • the dates used,
  • key numeric inputs (income, horizon, share/dependency),
  • and any assumptions you modified.

This makes reruns comparable and prevents accidental inconsistencies (like comparing a baseline run to a run with a different timing status).

Common pitfalls

  • missing a required input
  • using a stale rate or rule
  • ignoring calendar or holiday adjustments
  • skipping documentation of assumptions

Capture the source for each input so another team member can verify the same result quickly.

When rules change, rerun the calculation with updated inputs and store the revision in the matter record.

Misreading the limitation period as a wrongful-death-specific rule

A common error is assuming the tool has a dedicated “wrongful death limitation period” coded separately. In this jurisdiction setup:

Mixing units across income and time horizon

If one field expects annual income and another expects monthly, you can accidentally skew the result.

Checklist:

Updating dates without re-checking timing flags

If you change an incident date or filing date, the tool may switch timing status (within 5 years vs. outside 5 years) and update outputs.

After every date change:

Skipping scenario comparisons

Single-run outputs can hide sensitivity. Many damages models respond strongly to:

  • earnings and horizon inputs,
  • discount/present value assumptions,
  • dependency/share.

Recommended approach:

Try it

Use DocketMath’s Wrongful Death Damages tool and run the steps in this order so you can spot where outputs change:

  1. Open: /tools/wrongful-death-damages
  2. Confirm jurisdiction: **New York (US-NY)
  3. Enter the key economic inputs (income, dependency/share, horizon)
  4. Enter the relevant dates so the tool can apply the default 5-year rule
  5. Keep assumptions consistent, then run:
    • Baseline
    • Conservative (adjust one variable)
    • Optimistic (adjust one variable)

While you test, track these output signals:

  • Does “total damages” change when you alter the dependency/share input?
  • Does the tool’s timing status reflect your updated incident/filing dates?
  • When you change horizon, does the economic component scale in a way that matches intuition?

If you want to cross-check other New York calculation workflows, browse related guidance in the tools area first, then return here to keep your assumptions aligned.

Related reading