How to run Wrongful Death Damages in DocketMath for South Dakota

How to run Wrongful Death Damages in DocketMath for South Dakota

7 min read

Published December 27, 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 guide walks you through running a Wrongful Death Damages calculation in DocketMath for South Dakota (US-SD) using jurisdiction-aware rules. It focuses on what to enter, how the output responds, and which South Dakota timing rule governs the case window.

1) Open the Wrongful Death Damages calculator

Start at the primary call to action:

  • /tools/wrongful-death-damages

Once the calculator loads, confirm the jurisdiction is set to South Dakota (US-SD). DocketMath uses the jurisdiction context to apply South Dakota-specific assumptions and timing logic—especially around limitations.

2) Enter the key damages inputs

Wrongful death damages are often broken into categories. In DocketMath, use the input fields that match the structure shown in the calculator UI (for example, economic loss, non-economic loss, and any other components displayed).

As you add numbers, watch for these behaviors:

  • Totals update instantly as you change an input amount.
  • Category selections toggle which totals and subtotals contribute to the final range (if the calculator provides ranges or structured outputs).

Input checklist

  • Use the same currency basis (typically USD).
  • Enter amounts using the format the interface expects (whole numbers vs. decimals).
  • Use dates that match the incident timeline you’re modeling.
  • Leave a field blank only if the calculator allows it; otherwise use 0 for items you’re not including.

3) Run the South Dakota limitations check (SOL)

DocketMath’s jurisdiction-aware rules include a general statute of limitations timing constraint for South Dakota. For this jurisdiction:

  • General SOL Period: 3 years
  • General Statute: SDCL 22-14-1

DocketMath applies this as the controlling default because no claim-type-specific sub-rule was found. In other words, treat the calculator’s SOL logic as using the general/default 3-year period under SDCL 22-14-1 for wrongful death damages modeling.

How to interpret the SOL step

  • If your modeled claim timeline (based on the triggering/event date you input) falls within 3 years, the calculator should proceed without a “time barred” result tied to limitations.
  • If it falls outside 3 years, the output should reflect that timing constraint—commonly by flagging the claim window, limiting recovery, or presenting a reduced/denied scenario depending on the calculator design.

Warning (not legal advice): Limitations can turn on event dates, discovery concepts, tolling, and other fact-specific details. DocketMath uses the general 3-year default under SDCL 22-14-1 here, but real outcomes may require legal analysis.

4) Review the output structure

After you complete the inputs, DocketMath should show outputs in at least two useful layers:

  • Category totals (what each input component contributes)
  • Overall damages totals (the combined result based on what you entered and what categories are enabled)

In addition, you should see a limitations/timing indicator tied to South Dakota’s 3-year general SOL under SDCL 22-14-1. Use both parts together:

  • The damages math tells you what the numbers imply.
  • The SOL/timing indicator tells you whether limitations affect recoverability in the model.

Sensitivity check If you’re iterating:

  1. Change one input category by a known amount (e.g., adjust economic loss by $5,000).
  2. Re-run the calculation.
  3. Confirm the overall total changes in a predictable way (unless the calculator uses multipliers, caps, or eligibility rules).

5) Iterate with scenario planning

Wrongful death damages are rarely a single-number exercise. DocketMath supports an iterative workflow by letting you adjust inputs and compare runs quickly.

Try three scenarios:

  • Conservative: lower economic loss and/or services inputs
  • Balanced: mid-range assumptions
  • Aggressive: higher economic/non-economic assumptions

Then use the SOL step as a gate in your comparisons:

  • A scenario within 3 years may show a more favorable recoverability outcome.
  • A scenario outside 3 years may change the result even if your damages inputs are similar.

6) Save, export, or document your run

When you finish a run, document the details that matter most for replicability:

  • The jurisdiction shown (US-SD)
  • The triggering date you used for the 3-year SOL analysis
  • The category totals and overall damages total
  • Any limitations indicator referencing SDCL 22-14-1

Keeping screenshots or exports from multiple scenarios makes it much easier to compare how changing the timeline (not just the dollar amounts) impacts the model output.

Common pitfalls

Avoid these issues when running Wrongful Death Damages in DocketMath for South Dakota (US-SD).

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

If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.

1) Using the wrong SOL assumption

South Dakota’s general/default timing rule used here is:

  • 3 years
  • SDCL 22-14-1

DocketMath uses that default because no claim-type-specific sub-rule was found.

Pitfall: Assuming a different limitations period just because the claim is “wrongful death” can lead to inconsistent modeling. In DocketMath for US-SD, the default SOL is the general 3-year period under SDCL 22-14-1.

2) Entering inconsistent dates

Even strong damages inputs won’t fix a timeline problem. Common date errors include:

  • Accidentally swapping incident/event date and filing/claim date (or whatever the calculator labels those fields as)
  • Using a precise date in one scenario and an estimated date in another without tracking the change
  • Choosing dates that don’t actually match the scenario you intend to represent

3) Mixing units (or letting defaults obscure assumptions)

A frequent error is mixing:

  • monthly vs. annual figures
  • totals vs. component amounts
  • “net” vs. “gross” assumptions (if your case uses one approach)

In DocketMath, double-check that the values you enter align with the calculator’s expected format.

4) Updating the wrong category (or ignoring a toggle)

If you change an input and the total doesn’t move the way you expect, it may be because:

  • You edited a field that isn’t mapped to the enabled category
  • A category toggle is off, so the value isn’t contributing
  • The calculator conditions a component based on other selections

5) Treating SOL as purely “informational”

Some dashboards present limitations as a note; others make it meaningfully affect outcomes. In DocketMath’s US-SD run, the SOL check tied to SDCL 22-14-1 (3 years) can significantly affect the final presentation of recoverability/timing-related results.

Try it

If you want to run a US-SD wrongful death damages calculation now, open:

  • /tools/wrongful-death-damages

Use this quick test plan:

  1. Set jurisdiction to US-SD (South Dakota).
  2. Enter a simple damages set:
    • Use 1–2 categories to keep the comparison clean.
  3. Use dates that create two SOL outcomes:
    • Scenario A: within 3 years
    • Scenario B: just outside 3 years
  4. Run twice and compare:
    • Damages totals (should change only based on your category inputs)
    • Limitations indicator (should change based on the 3-year SOL under SDCL 22-14-1)

To keep the comparison meaningful, write down:

  • the exact dates used
  • the limitations outcome shown
  • the overall damages figure

Note: DocketMath applies the general 3-year default based on SDCL 22-14-1 because no wrongful-death-specific sub-rule was identified. Use the output as a modeling framework, not a substitute for legal judgment.

Related reading