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):

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:

  1. Past damages: $40,000
  2. Future damages (projected): $55,000
  3. Economic damages (overlapping subset) already captured above: $30,000
  4. 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 categoryInput amountSOL-eligible?Allocation logicAllocated amount
Past damages$40,000Yes (time-trimmed)$40,000 × 0.987$39,480
Future damages (projected)$55,000Kept separatenot retroactively trimmed in this model$55,000
Non-economic damages$25,000kept as documentedno 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

ChangeWhat it affectsExpected direction on allocated past damages
Filing earlierSOL window expands to include more past timeUp
Filing laterSOL window shrinks relative to event startDown
Event extends further into eligible yearsMore time falls inside eligibility bandUp
Event entirely before lookback startPast fully outside default SOLDown 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.

Related reading