Why Damages Allocation results differ in Maryland

The top 5 reasons results differ

Run this scenario in DocketMath using the Damages Allocation calculator.

If you run DocketMath’s Damages Allocation calculator for Maryland (US-MD) and see different allocation outputs across attempts, the cause is usually not “randomness.” Differences typically come from a mismatch between (1) the inputs you provide and (2) the jurisdiction-aware rules DocketMath applies.

Below are the top 5 reasons Maryland results commonly differ, with a focus on what to check before rerunning.

1. **Wrong time window (Maryland SOL gate) Maryland’s general statute of limitations (SOL) for civil claims is 3 years under Md. Code, Cts. & Jud. Proc. § 5-106. Per the brief guidance, this 3-year general SOL is the default period because no claim-type-specific sub-rule was found for this diagnostic.

   DocketMath can effectively “gate” damages by including or excluding portions that fall inside (or outside) the SOL window you model. If you enter different dates—such as incident date, accrual date, or filing/notice-related dates—you can change which damages periods count, leading to different allocation outputs.

2. Accrual date mismatch Even if the incident date is the same, the accrual date (when the right to sue begins) can shift the SOL window. If one run uses incident date as the accrual proxy, while another run uses a later discovery/impact date, the SOL boundary moves. In Maryland, that movement near the 3-year mark (under § 5-106) can change inclusion/exclusion and therefore the allocation.

3. Inconsistent categorization of damages types Allocation changes when the same dollars are classified differently—for example:

   • economic vs. non-economic,
   • past vs. future,
   • single lump sum vs. segmented/time-based components.

   If two runs treat the same number as belonging to different categories (even if the grand total stays similar), DocketMath may allocate to different buckets.

4. Different “policy” selections inside the calculator DocketMath may apply jurisdiction-aware logic keyed to Maryland. If you change any assumptions that affect how time-based amounts are prorated or assigned (even subtly), the output can shift. This can happen when two attempts use different option selections rather than different case facts.

5. Arithmetic side-effects from rounding and segmentation When damages are split into multiple periods (monthly, quarterly, etc.), small input differences—like whole-month vs. exact-date boundaries—can change rounding and proration. Over multiple segments, those tiny arithmetic deltas can become visible as different allocated totals.

Quick checklist (Maryland-focused inputs)

How to isolate the variable

Use a controlled one-change-at-a-time workflow. The goal is to identify which input or rule selection drives the allocation gap.

1. Run a baseline Use your best, internally consistent set of dates and damages.

   • Record: total damages and the displayed allocated components
   • Also note any SOL-adjusted inclusion/exclusion figures DocketMath shows

2. Lock everything except one variable Test in the order most likely to matter in US-MD:

   • Dates first: change only the accrual date by a fixed amount (e.g., +30 days), then rerun.
   • Segmentation next: keep overall totals identical, but switch the breakdown format (e.g., lump sum vs. monthly/periodic).
   • Category mapping last: keep totals the same, but verify the damages are classified the same way (only do this if you truly intend different categorizations).
   • Calculator selections: only after the above, change any DocketMath options that affect prorating or allocation logic.

3. Compute the “delta” For each rerun, track:

   • change in total allocated damages
   • change in each allocation bucket
   • change in the SOL-adjusted inclusion/exclusion amount (if shown)

4. Tie the delta to Maryland’s SOL gate If the biggest changes track to date movement near the 3-year boundary, the difference is likely driven by SOL-window inclusion/exclusion under Md. Code, Cts. & Jud. Proc. § 5-106.

Diagnostic note (not legal advice): This is a process walkthrough. If a specific claim has a non-default SOL or distinct accrual rules, the 3-year general period in § 5-106 may not control the real timeline.

Next steps

• Confirm your date definitions before trusting outputs

  • Incident date ≠ accrual date ≠ filing/notice date.
  • DocketMath results will follow the dates you enter.
• Normalize damages formatting

  • If you input monthly amounts, ensure you’re not unintentionally shifting which month each amount belongs to.
• Write down the scenario in one sentence

  • Example: “We’re modeling damages accruing from [accrual date] to [end date], classified as [categories].”
• Rerun after each change

  • Don’t batch multiple edits. Isolate the trigger so the variance is explainable.

If you want to rerun the same scenario consistently, start from the calculator at /tools/damages-allocation and make changes one at a time.

Related reading

• Damages Allocation Guide for Alabama — Comparative Fault Rules
• Damages Allocation Guide for Alaska — Comparative Fault Rules
• Damages Allocation Guide for American Samoa — Comparative Fault Rules