How to run Wrongful Death Damages in DocketMath for North Dakota

Step-by-step

Follow these steps to run Wrongful Death Damages in DocketMath for North Dakota (US-ND) using jurisdiction-aware rules. This walkthrough focuses on what to enter, what you’ll see in results, and how to sanity-check outputs.

1) Open the correct calculator

1. Go to the primary CTA: **/tools/wrongful-death-damages
2. Confirm the jurisdiction selector is set to North Dakota (US-ND).

   • If DocketMath asks for jurisdiction during setup, choose US-ND explicitly so the calculator applies ND-specific assumptions and rulesets.

2) Identify the damages model you’re running

In DocketMath’s wrongful-death-damages calculator, you’re generally modeling damages that fall into a structured set of categories (for example, economic losses and non-economic elements, depending on the calculator’s ND rule logic).

Use the “category” sections as a checklist:

• Economic loss inputs (earnings, household services, etc., depending on what DocketMath requests)
• Non-economic input(s), if the calculator prompts for them
• Beneficiary-related information, if the calculator supports allocation logic

3) Enter the decedent’s work-life information (economic inputs)

Most wrongful-death calculators need income and timing assumptions. Enter the facts as precisely as you have them:

• Decedent’s income (annual or monthly—match the unit DocketMath requests)
• Work participation / employment status (if prompted)
• Expected working years or life expectancy window (if the calculator asks you to provide or confirm it)
• Fringe benefits / additional income (only if DocketMath asks for it)

How output changes:

• Higher annual income increases projected economic loss (usually compounded through the assumed timeframe).
• Changing the working-life window materially changes the total because it affects the number of periods being projected.

4) Enter decedent’s household and services value (if prompted)

For wrongful-death damage modeling, some calculators include the value of household services.

If DocketMath prompts for it, provide:

• Estimated value of household services (monthly/annual, per the calculator)
• Whether services continue through the assumed timeframe (if DocketMath provides a toggle)
• Any reduction factors (only if the tool asks)

How output changes:

• Adding a household-services component typically increases the economic total line item.
• If you leave it blank and the tool defaults to zero, your results will be lower—use that intentionally, not accidentally.

5) Configure the beneficiary side (allocation inputs, if available)

Some versions of wrongful-death damage tools incorporate beneficiary allocations.

If the calculator requests beneficiary-related inputs:

• Number of beneficiaries (or a beneficiary list, depending on UI)
• Relationship category (if requested)
• Allocation percentages (if DocketMath supports split amounts)

How output changes:

• When allocations are enabled, the total may remain the same but each beneficiary line item changes.
• If allocations are not enabled, DocketMath may display a single aggregate number.

6) Enter non-economic components (if the calculator includes them)

If DocketMath requests non-economic inputs (for example, loss-of-consortium/similar non-economic categories), use the tool’s prompts and units exactly.

Common inputs include:

• Select a non-economic category (if multiple)
• Frequency or intensity (if the tool uses qualitative sliders)
• Duration / post-death period assumptions (if prompted)

How output changes:

• Non-economic components usually scale more steeply with selected intensity/duration than economic components.
• A small change in a slider-like input may produce a noticeable change in the non-economic total.

7) Apply North Dakota-specific jurisdiction awareness

DocketMath’s “jurisdiction-aware rules” mean your selections should map to North Dakota’s wrongful-death damages workflow.

Before running the calculation:

• Re-check that US-ND is active.
• Review any ND-specific toggles or rule labels in the interface (for example, whether the tool uses ND-specific treatment of certain components).

Pitfall:

8) Run the calculation and review outputs line-by-line

Click Calculate (or the calculator’s equivalent). Then review:

• Totals (overall damages)
• Category subtotals (economic vs non-economic components)
• Time-based calculations (if DocketMath shows duration or period count)
• Beneficiary breakdown (if allocations are enabled)

Sanity-check checklist (quick):

9) Adjust inputs to test sensitivity (what drives the number?)

You’ll get the most value by varying one key assumption at a time.

Recommended sensitivity tests:

• Increase/decrease annual income by a small amount (e.g., 10%) and re-run.
• Expand/reduce the work-life window by 2–5 years and re-run.
• If non-economic sliders exist, adjust them slightly and compare category movement.

How output changes:

• Economic totals typically move proportionally with income and timeframe.
• Non-economic line items often show higher sensitivity to intensity/duration inputs.

Common pitfalls

Use this section as a preflight list before you rely on results in any workflow.

• Mismatched time units

  • Example pattern: entering monthly income into an annual field.
  • Result: damages that are off by a factor of 12.

• Leaving jurisdiction unset

  • If US-ND isn’t active, DocketMath may apply rules from another state’s damages logic.
  • Result: internally consistent numbers, but wrong legal framework for your jurisdiction.

• Using beneficiary allocation when you shouldn’t

  • Some workflows want only an aggregate number, while others want a split.
  • Result: totals may be redistributed in a way that looks “broken” even if the sum stays consistent.

• Forgetting to intentionally handle household services

  • If you don’t provide household services but you intended to, your economic total will be too low.
  • Conversely, if you provide it without factual basis, the economic total will be too high.

• Over-editing multiple inputs at once

  • Changing income, timeframe, and non-economic sliders simultaneously makes it hard to understand which assumption drove the output.
  • Result: confusion when numbers don’t match expectations.

• Assuming defaults reflect your facts

  • DocketMath may use default timeframe or category values when fields are left blank.
  • Confirm defaults by scanning the input summary before calculating.

Try it

1. Open **/tools/wrongful-death-damages
2. Ensure North Dakota (US-ND) is selected.
3. Enter the minimum viable set of inputs:

   • Decedent’s income (with correct unit)
   • Time window (if prompted)
   • Any household services (only if you have a basis)
4. Run the calculation.
5. Perform one sensitivity test:

   • Adjust income by ±10% and re-run to see how the economic category changes.
6. Finally, review the output breakdown:

   • Confirm category subtotals add up to the total.
   • If beneficiaries are enabled, confirm allocations sum correctly.

When you’re ready, use the output structure for your internal case notes or spreadsheets—category subtotals are often more actionable than the grand total because they show which inputs matter most.

For jurisdiction-aware workflows, also verify you’re using the right tool configuration before exporting or documenting results.

Related reading

• Wrongful Death Damages Estimator Guide for Alabama
• Wrongful Death Damages Estimator Guide for Arizona
• Wrongful Death Damages Estimator Guide for Colorado