How to run Settlement Allocator in DocketMath for Vermont
7 min read
Published March 15, 2026 • Updated April 23, 2026 • By DocketMath Team
Trust release 4
This page has legal or numeric text that still needs claim-level inventory before we can treat it as verified.
Step-by-step
This guide walks you through running Settlement Allocator in DocketMath for Vermont (US-VT) using jurisdiction-aware rules. The goal is to allocate settlement amounts across potential categories based on the rules DocketMath applies for the selected jurisdiction and calculator.
Before you start, two quick grounding points for Vermont:
- Vermont’s general statute of limitations (SOL) period is 1 year.
- No claim-type-specific sub-rule was found for this calculator in the Vermont dataset provided, so DocketMath will rely on the general/default period for SOL-related assumptions.
Source note: The 1-year general SOL reference is drawn from Vermont’s materials here: https://legislature.vermont.gov/Documents/2020/Docs/CALENDAR/hc200226.pdf
Note: This post explains how to run the tool and interpret its output—not how to make legal decisions.
1) Open the Settlement Allocator calculator
- Go to the tool here: /tools/settlement-allocator.
- If the tool prompts for jurisdiction, select Vermont (US-VT).
If you already have a workflow open, you can jump directly to the calculator:
2) Enter the required inputs for your run
Settlement Allocator typically needs a few core inputs that determine how the allocation is computed. Use values you have in your case materials (for example, settlement amount and relevant dates).
Common input types you’ll see (labels may vary by UI):
- Settlement amount (numeric)
- Key date(s) used to test timing assumptions (for example, the date used for SOL evaluation)
- Any category toggles exposed by the calculator interface
To keep your run consistent and avoid accidental changes to results:
3) Confirm the Vermont SOL rule behavior
After you enter inputs and review the rule summary (if shown), you should see behavior consistent with:
- General/default SOL period: 1 year
- No claim-type-specific sub-rule found, meaning DocketMath should not apply a separate timing rule by claim category for this calculator/run.
In practical terms, the 1-year baseline changes how timing-dependent logic affects allocation. Depending on what Settlement Allocator is designed to compute, the tool may:
- Compute timing-based eligibility/risk: events older than 1 year from the relevant date may be treated differently than events within the last year.
- Apply weighting/timing adjustments: even if it isn’t deciding “eligibility,” timing can influence the allocation math.
If the UI provides a rule summary panel, verify it explicitly references 1-year and indicates it is the general/default period.
4) Run the allocator and review output structure
Click Run (or the equivalent action) and review the output panels. Settlement Allocator outputs are usually structured into some combination of:
- A total settlement allocation by category (buckets)
- Amounts per bucket
- Any rule-driven adjustments (for example, timing/SOL impacts)
Use this quick interpretation checklist:
- If your key date falls within 1 year of the comparator date DocketMath uses, timing-dependent portions of the allocation are more likely to reflect “in-range” treatment.
- If your key date is more than 1 year away, timing-dependent portions are more likely to shift based on the 1-year general SOL baseline.
5) Adjust inputs and compare runs (recommended workflow)
To make the tool actionable, you’ll usually want to compare runs rather than rely on a single output.
A fast, controlled workflow:
- Record the original totals and bucket amounts.
- Change only one variable at a time—most often the date field that affects SOL evaluation.
- Re-run and compare.
For example, try two runs:
- Run A: your original key date
- Run B: move the key date forward/backward by a month or two
If you notice allocation changes around the 1-year threshold, that indicates the calculator’s timing/SOL logic is influencing the math.
Warning: Changes caused by date/timing inputs are not a legal determination. Use comparisons to understand how DocketMath applies jurisdiction-aware rule logic to settlement allocation math.
6) Save or export results (if available)
If DocketMath offers export or share options, save your results. Even without export, screenshots and notes are useful for reproducibility.
At minimum, keep track of:
- The jurisdiction selection (US-VT)
- The exact date(s) entered
- The settlement amount entered
- The resulting total and bucket breakdown
This helps you reproduce the same allocation later or explain differences to others on your team.
Common pitfalls
These issues commonly lead to confusing or inconsistent Settlement Allocator outputs for Vermont.
- missing a required input
- using a stale rate or rule
- ignoring calendar or holiday adjustments
- skipping documentation of assumptions
Capture the source for each input so another team member can verify the same result quickly.
Input and configuration mistakes
- Selecting the wrong jurisdiction
- Make sure US-VT is selected. Switching jurisdictions can change SOL assumptions and therefore the allocation logic.
- Assuming claim-type-specific SOL rules are being applied
- In the provided Vermont dataset for this calculator, no claim-type-specific sub-rule was found.
- DocketMath should therefore use the general/default 1-year SOL as the baseline.
- Entering dates in an inconsistent format
- A formatting mismatch or minor date-entry difference can move your scenario across the 1-year threshold.
Misreading output
- Over-interpreting bucket changes as legal conclusions
- Bucket shifts often reflect internal rule math (especially timing/SOL logic), not a final legal determination.
- Changing multiple variables at once
- If you modify settlement amount and dates together, you won’t know what caused the output change. Prefer one-variable-at-a-time comparisons.
Timing boundary misunderstandings
- Forgetting the baseline is 1 year
- Vermont’s general SOL period is 1 year (general/default).
- Since no claim-type-specific sub-rule was found, the 1-year baseline is the anchor for timing-related assumptions.
- Pitfall: Key date near the threshold
- If your key timing date is close to 1 year, small changes (weeks/months) can flip timing treatment in the tool and therefore change allocation outputs.
Try it
Use this quick “test run” approach to validate your setup in DocketMath before using real case numbers.
Open the Settlement Allocator calculator and follow the steps above: Run the calculator.
If an assumption is uncertain, document it alongside the calculation so the result can be re-run later.
Mini exercise (2 runs)
- Open /tools/settlement-allocator and choose Vermont (US-VT).
- Enter:
- A sample settlement amount (use a realistic number from your materials)
- Your best estimate of the key date the tool uses for SOL-related assumptions
- Run the allocator and note:
- Total allocation
- Amounts per bucket
- Run again after changing only the key date slightly (for example, shift it by a few weeks).
- Compare:
- Do any bucket amounts move?
- Do totals change?
- If there is a rule summary/message, does it align with the 1-year general/default SOL baseline?
What you should see
Because Vermont’s baseline SOL period is 1 year and the rule set is general/default (with no claim-type-specific sub-rule found), you should generally see consistent behavior relative to that threshold—either in:
- eligibility/risk weighting logic, or
- allocation adjustments driven by SOL timing assumptions.
If you don’t see any SOL-driven changes after you move the date, check:
- Whether you entered the date into the correct key date field
- Whether the tool’s rule summary confirms it is applying the 1-year general/default SOL assumption
