How to run Wrongful Death Damages in DocketMath for Massachusetts

How to run Wrongful Death Damages in DocketMath for Massachusetts

6 min read

Published August 8, 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

This guide walks you through running Wrongful Death Damages in DocketMath for Massachusetts (US-MA) using jurisdiction-aware setup. It focuses on a practical calculator workflow—what to enter, what to expect, and how Massachusetts time limits can affect whether you should treat the results as actionable.

Note: This is a walkthrough of the DocketMath workflow, not legal advice. For case-specific guidance, verify the facts and any applicable limitations period with qualified counsel.

1) Open the calculator for the right claim type

  1. Go to DocketMath → Wrongful Death Damages using this primary CTA:
    **/tools/wrongful-death-damages
  2. Confirm the calculator is set to the Massachusetts jurisdiction code: US-MA (if DocketMath prompts you for jurisdiction, select US-MA).

2) Identify the Massachusetts limitations period you’ll apply in your model

Before you enter damages numbers, decide what limitations period DocketMath should screen against in your Massachusetts run.

For Massachusetts, use the general/default period:

  • General SOL Period: 6 years
  • General Statute citation: Mass. Gen. Laws ch. 277, § 63

Important: The brief’s jurisdiction notes say that no claim-type-specific sub-rule was found. That means you should use the general/default 6-year period for this workflow, rather than swapping in a different duration unless you have a clearly supported basis from a more specific authority.

3) Enter the core damages inputs (and watch how outputs change)

Inside the wrongful-death damages calculator, the exact field names can vary, but the workflow typically includes date inputs and economic/non-economic loss components.

Use this structure to guide your entries:

A. Date-related inputs

  • Date of death (or the event date the calculator uses as the “trigger”)
  • Filing date or an “as of” date (depending on how DocketMath asks for SOL screening)

B. Economic loss inputs

  • Expected earnings / income
  • Work-life duration assumptions (if the calculator includes a horizon or duration)
  • Discount rate / inflation assumptions (if provided)

C. Non-economic or other components

  • Any additional categories the calculator includes (if present, enter the amounts you are modeling)

As you enter values, review intermediate totals or line items to understand what drives changes:

  • Increasing annual earnings usually increases the economic loss portion, and then increases the discounted present value total if discounting is enabled.
  • Changing the modeling horizon (for example, more years vs. fewer years) expands the time window for loss calculation and typically raises the damages total.
  • Discount rate changes typically shift totals by reducing (or less reducing) the present value of future losses.

Checklist while you enter:

4) Apply the SOL screen using Mass. Gen. Laws ch. 277, § 63

If DocketMath includes an “eligibility,” “SOL impact,” or screening step, use it to align the model with the Massachusetts baseline:

  • SOL: 6 years
  • Citation: Mass. Gen. Laws ch. 277, § 63

Practical modeling approach:

  1. Identify which date DocketMath uses as the trigger (often the death/event date).
  2. Compute the time gap between that trigger date and the filing date (or the calculator’s specified “as of” date).
  3. If the gap exceeds 6 years, the calculator may still compute a damages estimate, but the usability/viability signal may shift toward “estimate only” rather than a “likely actionable” screen.

To keep your model aligned with the jurisdiction:

Warning: If you use a shortened or extended SOL without matching the specific Massachusetts rule applicable to your fact pattern, the “viability” or eligibility output in the calculator can become misleading—even when the internal damages math is consistent.

5) Generate and review the output

After you run the calculator:

  • Review the total damages figure.
  • Review the component breakdown to validate your assumptions.

If the calculator provides present value (PV) or discounting:

  • Changing the discount rate typically has a larger effect for longer horizons.
  • Shorter horizons often reduce the difference between discount scenarios.

If DocketMath outputs multiple scenarios (for example, conservative/standard/aggressive inputs):

  • Use them to bound expectations
  • Identify which input drives the largest spread—often earnings, timeline/horizon, or discount assumptions.

Quick consistency habit:

  • If the output changes dramatically, confirm whether it’s due to dates, units, or the discounting toggle—not just your selected numbers.

6) Capture the result in your DocketMath workflow

To keep your work traceable:

  • Save the run so you can compare versions.
  • If you adjust dates for SOL modeling, rerun the calculator and note how both:
    • the damages totals, and
    • any SOL/eligibility indicators
      change.

A useful workflow:

  1. Run with your best estimate.
  2. Run at least one sensitivity check (example: earnings ±10% or timeline ±2 years) to see what actually matters most to the result.

Common pitfalls

Massachusetts modeling in a wrongful-death damages calculator can go wrong even when the underlying math is correct. Watch for these issues:

  • Using the wrong SOL assumption

    • For this Massachusetts workflow, use the general/default 6-year SOL under Mass. Gen. Laws ch. 277, § 63.
    • The jurisdiction notes state no claim-type-specific sub-rule was found, so avoid swapping to a different period unless you have a clearly supported basis.
  • Inconsistent trigger and filing/as-of dates

    • Make sure the “death/event date” and the “filing/as-of date” match what DocketMath expects.
    • A common mismatch is using one date in one field that doesn’t correspond to the calculator’s trigger definition in another.
  • Unit mismatch

    • Annual vs. monthly earnings confusion can inflate/deflate results dramatically.
    • Pre-tax vs. net income mismatches also distort totals.
  • Horizon drift

    • If the calculator has a time-horizon input (or derives horizon from another setting), verify that all related fields use the same horizon concept.

Pitfall: A model can look “precise” while being based on inconsistent assumptions—for example, a “years of expected earnings” entry that doesn’t align with the income timing (monthly vs. annual) selected elsewhere. Treat the component breakdown as a consistency check, not just a display.

Try it

Follow this quick “sanity run” sequence in DocketMath for US-MA:

  1. Confirm US-MA jurisdiction selection.
  2. Enter:
    • Death/event date
    • Filing date (or the date the calculator uses for SOL screening)
    • Earnings/income assumptions used for the economic loss portion
  3. Run the calculator.
  4. Review two outputs:
    • Damages total (and any PV/discount effects)
    • SOL impact / eligibility screen tied to 6 years under Mass. Gen. Laws ch. 277, § 63

Then do one adjustment to confirm the model responds as expected:

  • Confirm the total damages changes in the expected direction (typically up if earnings increase).
  • If it doesn’t, stop and verify units, toggles, and jurisdiction selection.

Related reading