Abstract background illustration for How to run Wrongful Death Damages in DocketMath for New Mexico

How to run Wrongful Death Damages in DocketMath for New Mexico

6 min read

Published June 4, 2026 • By DocketMath Team

Under review

missing_or_unverified_packet

Step-by-step

This guide walks you through running Wrongful Death Damages in DocketMath for New Mexico (US-NM) using the wrongful-death-damages calculator and jurisdiction-aware rules.

Note: This is a practical walkthrough of how to use DocketMath. It’s not legal advice. For legal strategy and case-specific requirements, consult a qualified attorney.

1) Open the correct DocketMath tool

Start here:

Once you’re in the calculator, confirm the tool is set to New Mexico (US-NM). If DocketMath includes a jurisdiction selector, choose US-NM before entering numbers.

2) Understand the New Mexico wrongful-death legal basis (so inputs line up)

New Mexico’s wrongful-death cause of action is grounded in the general wrongful-death statute:

  • N.M. Stat. Ann. § 41-2-1:
    “Whenever the death of a person shall be caused by the wrongful act, neglect or default of another... the person who, or the corporation which, would have been liable, if death had not ensued, shall be liable to an action for damages, notwithstanding the death of the person injured.”
    Source: https://nmonesource.com/nmos/nmsa/en/item/4408/index.do

How this affects DocketMath input logic: DocketMath applies jurisdiction-aware rules to determine how wrongful-death damages are organized and how the calculation period is selected. For New Mexico, the jurisdiction note provided indicates:

  • No claim-type-specific sub-rule period was found in the dataset you supplied.
  • Therefore, the calculator should use the general/default wrongful-death period as the baseline rule set.

Warning: Don’t assume there’s a special “wrongful-death-only” override for a unique timeframe/period. Based on your jurisdiction note, DocketMath should follow the general/default period rather than a claim-type-specific override.

3) Enter core economic inputs (what changes the output most)

Wrongful death calculators typically depend on a limited set of economic drivers. In DocketMath, you’ll usually see fields such as:

  • Income / earnings (often annual, but confirm the unit)
  • Work-life period or a projection horizon (how long losses are modeled)
  • Time horizon / measurement period (if separately requested)
  • Economic adjustments (if the UI offers them)
  • Discounting / present value settings (if available)

Practical “cause and effect” for your outputs

  • Higher annual income → higher projected economic loss → higher total damages.
  • Longer projection horizon → more years of loss accumulate → higher totals.
  • Discount rate / present value toggle → can materially change the present value even if the future stream looks the same.

If the tool offers options like conservative vs. projection mode, choose the one that matches the reliability of your underlying data—not the one that happens to yield the highest number.

4) Add non-economic components only if DocketMath includes them

Depending on how the wrongful-death-damages calculator is configured for US-NM, there may or may not be fields for non-economic categories (examples might include grief-type or companionship-type placeholders, depending on the UI).

  • Only enter values for non-economic components if the calculator actually provides those categories and you have a defensible basis for the amounts.
  • If the UI doesn’t compute certain categories in this jurisdiction mode, leave those fields alone—forcing data into irrelevant inputs can make the output harder to interpret.

5) Use scenario runner (or manual re-runs) to compare “what if”

A best-practice workflow is to run multiple scenarios to understand sensitivity—especially because wrongful death results often change dramatically with horizon and income.

Try scenarios like:

  • Scenario A (baseline): best available income and the default/general period behavior
  • Scenario B (income lower): reduce annual income by a chosen percentage or dollar amount
  • Scenario C (horizon shorter): shorten projection horizon by a few years
  • Scenario D (discount sensitivity): compare two present-value settings if available in the UI

DocketMath is helpful here because you can quickly see which assumptions move the total the most.

6) Verify the jurisdiction tag and period logic in the results panel

After you compute, review the results summary for anything that explains the methodology.

You’re looking for two confirmations:

  • Jurisdiction applied: US-NM
  • Period rule used: general/default period (not a claim-type-specific override)

If DocketMath shows an assumptions, rules applied, or calculation method panel, review it closely for the selected period logic. If you maintain case notes, record that panel’s key statements.

7) Export or record outputs with your inputs

Before you leave the tool:

  • Save the final totals
  • Record the dominant drivers (for example, income, projection horizon, discounting)
  • Keep the input set corresponding to the most accurate representation of your facts

This makes it easier to re-run the model later or explain why one scenario differs from another.

Common pitfalls

Avoid these issues—each can materially change outputs in DocketMath:

  • Wrong jurisdiction selected (US-NM not active)
    • Even with correct data entry, rules might not align if the jurisdiction tag is wrong.
  • Assuming a claim-type-specific period override exists
    • Your jurisdiction note states no claim-type-specific sub-rule period was found, so DocketMath should use the general/default period.
  • Entering yearly vs. monthly income into the wrong field
    • Example: entering $6,000/month into a $/year box can inflate results by ~12x.
  • Mixing inconsistent time horizons
    • For instance, if one input represents “up to retirement” and another represents “X years from death,” you can accidentally double-count time.
  • Changing multiple variables at once during sensitivity testing
    • When comparing scenarios, change one input at a time unless you intentionally want a compound effect.
  • Overlooking discounting / present value settings
    • Identical future assumptions can yield different totals if present-value options differ.
  • Entering non-economic categories without basis in the tool/UI
    • If the calculator doesn’t compute certain components under US-NM, leaving or forcing values can confuse interpretation.

Pitfall: The projection horizon is often one of the biggest drivers. If DocketMath shows the period used, always confirm it reflects the general/default period consistent with your New Mexico setup.

Try it

Follow this hands-on checklist using DocketMath’s /tools/wrongful-death-damages tool:

  • Select New Mexico (US-NM)
  • Enter a baseline annual income value (verify whether the field expects yearly or monthly)
  • Enter the time horizon / measurement period DocketMath requests
    • Use the tool’s general/default period behavior (since the provided jurisdiction data indicates no claim-type-specific override)
  • Run the calculation
  • Review output assumptions to confirm:
    • The rule set is US-NM
    • The period logic reflects the general/default period tied to N.M. Stat. Ann. § 41-2-1
  • Run at least 1 sensitivity scenario (for example: reduce income by 10% or shorten horizon by 2 years)
  • Compare baseline vs. scenario results to identify the dominant driver

If you want a streamlined order, try:

  1. Baseline compute
  2. Horizon sensitivity
  3. Income sensitivity
  4. Discount/present-value sensitivity (if available)

Related reading