Why Damages Allocation results differ in Connecticut
5 min read
Published April 15, 2026 • By DocketMath Team
The top 5 reasons results differ
If you run DocketMath → damages allocation for similar fact patterns in Connecticut (US-CT) and see different allocations, the difference is almost always traceable to how the tool applies jurisdiction-aware time limits and allocation logic to the same underlying numbers.
Below are the top 5 reasons DocketMath results can diverge in Connecticut, even when inputs look “close enough” to be the same.
The applicable limitations period is the general 3-year default Connecticut’s general limitations period for certain claims is 3 years under Conn. Gen. Stat. § 52-577a. In DocketMath, this matters because the calculator uses jurisdiction-aware defaults when a claim-type-specific rule isn’t identified in your inputs.
- This content uses the statute’s general/default period because no claim-type-specific sub-rule was found for the scenarios covered here.
- Practically, that means changing dates (incident date, accrual date, filing date) can shift what damages fall inside vs. outside the window.
**Accrual vs. event date mismatch (date selection drives the window) Even a 1–2 day difference can change whether certain costs fall inside vs. outside the 3-year limitations window. DocketMath typically needs a consistent “start” date for its jurisdiction-time-window filter.
Watch for:
- entering an event date where the scenario actually treats a different accrual date as controlling
- entering “last occurrence” or “last payment” dates differently between runs
Partial-period calculations and start/end truncation When the limitations period cuts through a schedule (for example, recurring damages), allocation may be computed by trimming the schedule to the allowed window. That can create “jumps,” especially when:
- damages are monthly or weekly
- the filing date lands mid-period
- damages are front-loaded (early months are included more often)
Different assumptions about what counts as “damages” DocketMath allocation depends on the categories you choose and the amounts you enter (e.g., economic vs. non-economic buckets, or different components).
Two runs may use the same total dollar figure but still allocate differently if you:
- enter one lump sum in a category in one run, but split it across categories in another
- leave a category blank in one run (the tool may redistribute remaining amounts differently)
Inconsistent allocation weights or distribution rules If you use allocation weights (for example, distributing totals across time slices or categories), small differences in weights can produce different outputs—even if raw totals match.
Common triggers:
- rounding differences (e.g., $12,345.67 vs. $12,345.00)
- using different normalization bases (number of months vs. number of occurrences)
Pitfall: If you only compare the final allocation numbers and ignore the inputs that define the 3-year window, you can miss the root cause. In Connecticut, § 52-577a’s 3-year default can cause sudden inclusion/exclusion of schedule slices that materially change results.
(General informational note: this is not legal advice; it’s guidance for using DocketMath consistently.)
How to isolate the variable
To pinpoint what’s changing, run a controlled “single-variable” test in DocketMath.
Use this checklist:
Keep all category amounts, schedules, and weights identical between runs. For example:
- Run A: accrual/start = Date 1
- Run B: accrual/start = Date 2
Everything else stays fixed. DocketMath should reflect the 3-year default period tied to Conn. Gen. Stat. § 52-577a (general/default period; no claim-type-specific sub-rule identified here). Identify where the calculator starts/stops counting. If the filing date lands mid-month, compare the slice-by-slice effect (or month-by-month effect). Re-enter amounts using the same precision and confirm the same arithmetic basis.
Quick diagnostic sequence (repeat until the culprit emerges):
- Start with your “best” Run 1.
- Create Run 2 by changing only the accrual/start date by +/− 1–7 days.
- Create Run 3 by changing only the filing date by +/− 1–7 days.
- If allocations stay identical across date variations, the issue is likely category mapping or allocation weights, not the limitations window.
If you want to reproduce these steps directly, open DocketMath’s calculator here: /tools/damages-allocation.
Next steps
After you isolate the variable, do the following:
- Document the date assumptions you used Save the three key dates you entered (start/accrual date, event date if different, filing date) and connect them to the 3-year default under Conn. Gen. Stat. § 52-577a.
- Normalize your inputs before re-running
- Use consistent units (months/quarters)
- Split or lump categories consistently across runs
- Run a “stability check”
- If changing a date by 1–3 days flips large amounts of allocation, your result is highly sensitive to the limitations window.
- If changing dates barely moves the output, focus on category mapping or weighting.
If you’re comparing two competing allocation theories, treat DocketMath like an experiment: keep everything constant except the hypothesis you’re testing.
