How to run Structured Settlement in DocketMath for Connecticut

Step-by-step

This guide explains how to run a Structured Settlement calculation in DocketMath for Connecticut (US-CT) using jurisdiction-aware rules, with a focus on Connecticut’s general statute of limitations (SOL) framework. This is for planning and modeling only—not legal advice.

1) Open the Structured Settlement calculator

Start at the primary call to action:

• DocketMath tool: Structured Settlement

If you’re already inside DocketMath, use the calculator picker and select structured-settlement.

2) Confirm you’re using the Connecticut jurisdiction logic (US-CT)

In the calculator’s jurisdiction controls, set:

• Jurisdiction: US-CT (Connecticut)

DocketMath uses this jurisdiction selection to apply the relevant Connecticut timing assumptions used by the structured settlement model.

3) Enter the core case timing inputs

Structured settlement modeling typically depends on a timeline “anchor” (often treated as day 0) and the payment structure inputs.

Add the following in the calculator fields (names may vary by UI):

• Event date / claim trigger date: the date your model treats as day 0 for timeline calculations (keep it consistent across scenarios)
• Proposed payment timing: for example, how long until the first payment, then the schedule thereafter (annual, quarterly, etc., if supported)
• Amount(s) to structure: often a total lump-sum figure that the tool allocates or uses to generate the payment schedule

Practical tip: if your workflow uses a demand timeline or settlement agreement date, pick the date you want to anchor on and reuse that exact rule consistently across scenario runs.

4) Set the interest/discount assumptions (if the tool requests them)

Some structured settlement calculators require discount rate / growth / interest assumptions.

In DocketMath:

• Enter the rate(s) requested by the tool for your scenario.

Practical scenario testing approach:

• Run two or three rate options (for example, low / mid / high) so you can see how the outputs respond to changes in financial assumptions.

5) Understand how Connecticut SOL affects your timeline modeling

For Connecticut, the general SOL period used here is:

• 3 years under Conn. Gen. Stat. § 52-577a
  Source: https://law.justia.com/codes/connecticut/title-52/chapter-926/section-52-577a/?utm_source=openai

Key modeling clarity (important):

• No claim-type-specific sub-rule was found in the jurisdiction data available for this DocketMath setup.
• That means the calculator will treat the applicable SOL timing constraint as the general/default 3-year period, rather than switching SOL rules based on a specific claim category.

What that means for your run:

• Compute any “latest filing date” / deadline-oriented outputs using 3 years from your selected trigger date, consistent with Conn. Gen. Stat. § 52-577a.
• In other words, your model’s SOL-related deadlines are anchored to your selected day 0 and shift when you change that date.

Gentle reminder: for structured settlement work, the SOL is typically about the timeliness of the underlying claim, while annuity/payment mechanics follow contract and financial terms. In DocketMath, the SOL primarily changes timeline/deadline-style outputs based on the anchor inputs you provide.

6) Run the calculation and review outputs

After inputs are complete and US-CT is selected, run the calculation.

Review outputs at minimum for these categories (the labels may differ slightly depending on the interface):

• Derived timeline / deadline outputs

  • For example, any SOL end date computed from the 3-year rule
• Payment schedule outcomes

  • Whether the schedule matches your proposed timing and structured amount assumptions
• Present value / discounting outputs

  • If the tool provides these metrics, confirm they reflect your chosen rates/assumptions
• Scenario comparisons

  • If you’re comparing multiple runs, verify differences come from the variables you intended to change

7) Iterate: compare structured terms side-by-side

To make the model useful for planning, iterate rather than doing only one calculation.

Change one variable at a time and compare results:

• Payment cadence (if supported): annual vs. monthly/quarterly
• First payment delay: shorter vs. longer gap from the trigger/anchor date
• Rate / discount assumptions: conservative vs. aggressive
• Structured amount: partial vs. full structuring (if supported)

In many models, the biggest output movement typically comes from:

• the trigger/anchor date (drives SOL-related timeline/deadline outputs), and
• the rate/discount assumptions (drives present value and related financial outputs).

8) Save or export your scenario (if available)

If DocketMath lets you save, export, or label scenarios:

• Save each scenario with a clear name, such as:

  • “CT default SOL (3 years), Scenario A (rate = X)”
  • “CT default SOL (3 years), Scenario B (first payment delay = Y)”

This helps you keep the jurisdiction rule constant (general 3-year SOL under Conn. Gen. Stat. § 52-577a) while varying other assumptions for comparison.

Common pitfalls

Structured settlement calculations often go off track for reasons that are easy to avoid. Here are the most common issues when running Connecticut (US-CT) in DocketMath:

• Using the wrong “day 0” date

  • The SOL window is measured from the date you choose as the claim trigger/event anchor.
  • Even small date shifts can move SOL end/deadline outputs.

• Assuming claim-type-specific SOL rules are applied

  • In this setup, the jurisdiction data provides the general/default 3-year SOL only.
  • You should not expect the model to automatically switch SOL timing based on claim category.

• Mixing SOL timing outputs with annuity mechanics

  • The SOL affects timeliness/deadlines for the underlying claim.
  • Payment schedule/annuity structure is driven by contract and financial inputs you enter.
  • Treat DocketMath outputs as modeling results, not a definitive compliance determination.

• Running only one financial assumption

  • One rate can make results look precise while masking sensitivity.
  • Use at least 2–3 rate scenarios to understand how outputs change.

Try it

To quickly validate your workflow, run a short “sanity check” in DocketMath:

• Jurisdiction: US-CT
• Use a trigger date close to today (for easier comparison)
• Keep the payment schedule simple

  • Use one first payment timing and a consistent interval thereafter (if supported)
• Keep rate/discount assumptions fixed for the first pass

Then verify:

• The SOL-related output aligns with a 3-year general period under Conn. Gen. Stat. § 52-577a.
• When you only change one input—like the trigger/anchor date—the model responds predictably:

  • SOL/deadline outputs should shift,
  • and payment schedule outputs should remain consistent unless the tool ties them directly to timeline changes.

After the sanity check works, rerun with exactly one change (e.g., move the trigger date by 30–90 days) to confirm the relationship between inputs and outputs.

For the fastest path, open the calculator now:

• Structured Settlement

Related reading

• Structured Settlement Calculator Guide for Alabama
• Structured Settlement Calculator Guide for Arizona
• Structured Settlement Calculator Guide for Colorado