Worked example: Damages Allocation in Connecticut
7 min read
Published April 15, 2026 • By DocketMath Team
Example inputs
Run this scenario in DocketMath using the Damages Allocation calculator.
Below is a worked example of damages allocation in Connecticut using DocketMath with jurisdiction-aware rules. This example uses the general/default statute of limitations (SOL) because the provided jurisdiction data did not identify any claim-type-specific sub-rule.
Jurisdiction basis (Connecticut default):
- General SOL period: 3 years
- Statute: Conn. Gen. Stat. § 52-577a (general SOL framework referenced in the provided jurisdiction data)
Source: https://law.justia.com/codes/connecticut/title-52/chapter-926/section-52-577a/
Gentle disclaimer: This is an educational walkthrough of how the DocketMath (damages-allocation) calculator can apply a general SOL “lookback” to a time-trimmed damages bucket. It is not legal advice, and real cases may involve additional accrual rules, tolling, or claim-specific timing doctrines not captured here.
Scenario (what we’re allocating)
Assume a plaintiff claims multiple categories of damages tied to the same overall event timeframe:
- Past damages: $40,000
- Future damages (projected): $55,000
- Economic damages (overlapping subset) already captured above: $30,000
- Non-economic damages: $25,000
To keep the example concrete, we’ll assume your underlying evidence supports (a) a “past” pool that should be SOL-trimmed using a filing-date lookback, and (b) a “future” pool treated as projected (not retroactively trimmed by the same “past” window). Your actual inputs may be structured differently.
Key dates and numbers (inputs)
Use these as the calculator inputs in DocketMath → damages-allocation (primary tool page): /tools/damages-allocation
- Event start date: 2022-01-15
- Event end date: 2022-12-20
- Filing date (complaint): 2025-01-20
Damage totals (gross):
- Past damages total: $40,000
- Future damages total (projected): $55,000
- Non-economic damages total: $25,000
Overlapping economic subset (optional cross-check input):
- Economic overlap subset: $30,000
Assumptions used for allocation logic (practical and calculator-friendly)
- The SOL “cutoff” is measured relative to the filing date.
- The portion of past damages attributable to conduct outside the general 3-year lookback is excluded from the SOL-eligible allocation.
- Future damages (projected) are kept separate and not trimmed by the same retroactive time window in this simplified example.
- Because the jurisdiction data did not provide a claim-type-specific sub-rule, the example applies only the general/default 3-year period from Conn. Gen. Stat. § 52-577a.
Pitfall: If your “past” damages actually reflect discrete incidents with different accrual dates, using only an overall start/end window can over- or under-include amounts. The allocation is only as accurate as the date mapping you enter.
Example run
Run the Damages Allocation calculator using the example inputs above. Review the breakdown for intermediate steps (segments, adjustments, or rate changes) so you can see how each input moves the output. Save the result for reference and compare it to your actual scenario.
Step 1: Apply Connecticut’s default 3-year SOL window
Using the general SOL period of 3 years under Conn. Gen. Stat. § 52-577a, the SOL-eligible “lookback” window for past conduct runs backward 3 years from the filing date.
- Filing date: 2025-01-20
- SOL lookback start boundary: 2022-01-20 (three years before)
Interpretation for this example:
- Conduct on/after 2022-01-20 is generally within the default SOL window.
- Conduct before 2022-01-20 is outside the default SOL window.
Since no claim-type-specific sub-rule was provided, no special sub-period is layered in this example—only the general/default period is used.
Step 2: Determine the SOL-eligible portion of “past” damages
Your event window is:
- Event start: 2022-01-15
- Event end: 2022-12-20
The SOL lookback begins at 2022-01-20, which is about 5 days after the event start date. In this worked example, we model a time-proportional eligibility fraction for the past damages pool:
- SOL-eligible fraction for “past” damages: 0.987
(Because only a small slice of the early period falls before the lookback boundary.)
In DocketMath, if you provide more granular date mappings (e.g., multiple incident dates or a timeline split), the “eligible fraction” logic can be more precise than a single start/end proportion.
Step 3: Allocate damages by category
Apply allocation rules to each damages bucket:
| Damage category | Input amount | SOL-eligible? | Allocation logic | Allocated amount |
|---|---|---|---|---|
| Past damages | $40,000 | Yes (time-trimmed) | $40,000 × 0.987 | $39,480 |
| Future damages (projected) | $55,000 | Kept separate | not retroactively trimmed in this model | $55,000 |
| Non-economic damages | $25,000 | kept as documented | no time-trim applied in this simplified allocation | $25,000 |
Step 4: Handle overlap checks (economic subset)
The optional economic overlap subset ($30,000) is treated as a consistency check to help you ensure you are not double-counting overlapping categories.
- Economic overlap subset: $30,000
- Goal: verify whether that subset is already represented within other buckets (e.g., “past” or “future”) rather than summing it again as a new pool.
In this example run, DocketMath treats it as a check rather than automatically adding it as an additional category total (unless your input structure indicates it’s a distinct, additive bucket).
Output (what In DocketMath, this appears as)
SOL-allocated totals:
- Allocated past damages: $39,480
- Allocated future damages (projected): $55,000
- Allocated non-economic damages: $25,000
Gross allocated total (three categories):
$39,480 + $55,000 + $25,000 = $119,480
Note: This is a simplified mechanics walkthrough using the general/default 3-year SOL from Conn. Gen. Stat. § 52-577a. It does not model tolling, special accrual timing, or claim-specific doctrines because none were provided in the jurisdiction data.
Sensitivity check
Small date changes can materially change the SOL-trimmed portion of “past damages.” Rerun DocketMath → damages-allocation and compare the “Allocated past damages” result.
To test sensitivity, change one high-impact input (like the rate, start date, or cap) and rerun the calculation. Compare the outputs side by side so you can see how small input shifts affect the result.
Sensitivity A: Filing date pushed back by 30 days
- Change filing date: 2025-01-20 → 2025-02-19
- New SOL lookback start: 2022-02-19
Effect direction:
- Less of the early event period falls inside the 3-year window.
- Allocated past damages may decrease.
Sensitivity B: Filing date delayed by 1 year
- Change filing date: 2025-01-20 → 2026-01-20
- New SOL lookback start: 2023-01-20
Effect direction:
- The entire event window (2022-01-15 to 2022-12-20) is now outside the default 3-year lookback.
- Allocated past damages drop toward $0 in this proportional model.
- Future damages may remain unchanged in the model if treated as projected and not retro-trimmed.
Sensitivity C: Event end date moved later (while keeping filing date fixed)
- Keep filing date: 2025-01-20
- Extend event end date: 2022-12-20 → 2023-03-01
Effect direction:
- Depending on how you label/define “past” vs “future” in your inputs, more of the timeline may land inside the eligible period.
- Allocated past damages could increase if your “past damages” pool includes that later portion.
Sensitivity summary table
| Change | What it affects | Expected direction on allocated past damages |
|---|---|---|
| Filing earlier | SOL window expands to include more past time | Up |
| Filing later | SOL window shrinks relative to event start | Down |
| Event extends further into eligible years | More time falls inside eligibility band | Up |
| Event entirely before lookback start | Past fully outside default SOL | Down toward 0 |
Warning: If your real-world evidence includes activity after the “event end date,” but you’ve labeled it under the same “past” pool, a single start/end window can mask SOL eligibility. For best results, align your date mapping to how your evidence breaks down.
