Cost of Delay Modeler Guide for Tennessee

7 min read

Published March 22, 2026 • By DocketMath Team

What this calculator does

Run this scenario in DocketMath using the Cost Of Delay calculator.

DocketMath’s Cost of Delay Modeler helps you translate a Tennessee criminal case timeline into a practical “cost of delay” estimate you can use for planning and internal analysis. The model converts time (days or months between key dates you choose) and a cost rate (such as staffing costs, operational overhead, or other quantifiable impacts) into a single output: an estimated total cost attributable to delay.

This guide focuses on the Tennessee timing context you’ll most often see in pretrial and post-indictment planning, including the statute-based period you may use to anchor your assumptions:

  • General SOL period anchor used by this guide: 1 year
  • Statutory citation: Tennessee Code Annotated § 40-35-111(e)(2) (commonly cited for a 1-year limitation period in the listed exception context)
  • Related Tennessee provision often referenced in the same planning conversation:
    • Tenn. Code Ann. § 40-2-102(a) — also shown here with a 1-year limitation anchor (exception V3 as provided in your jurisdiction data)

Note: This guide is for modeling and planning, not for making legal determinations. Timing rules in criminal matters can be affected by case-specific events (for example, continuances, tolling-like circumstances, or procedural posture). Use the calculator to structure analysis, then apply the results to your own decision-making workflow.

When to use it

Use DocketMath’s Cost of Delay Modeler when you need to answer questions like:

  • “If the case resolution slips by 90 days, what’s the estimated operational impact?”
  • “How does changing the assumed delay from 6 months to 12 months affect total cost?”
  • “Which stage—early pretrial vs. later proceedings—creates the biggest modeled cost of delay?”

This is especially helpful in Tennessee when your planning is anchored to a 1-year period commonly associated with Tenn. Code Ann. § 40-35-111(e)(2) and Tenn. Code Ann. § 40-2-102(a), both reflected in your jurisdiction data as 1-year limitation anchors.

A quick checklist for when the tool fits well:

Step-by-step example

Below is a concrete walkthrough using the calculator mindset. (You can plug these same numbers into DocketMath via the inline link to help you visualize how outputs change.)

Primary CTA: Open DocketMath Cost of Delay

Step 1: Define the “clock” you’re modeling

Pick the date you’re treating as the start of delay and the date you’re treating as the end (or resolution estimate).

For example:

  • Start date (modeled delay begins): 2026-01-01
  • End date (modeled delay ends): 2026-10-01
  • Modeled delay length: 273 days (about 9 months)

Step 2: Choose a cost rate (your dollar-per-time assumption)

Let’s say you model an internal cost rate of:

  • $350 per day (staffing + admin time allocated to the case)

Step 3: Enter delay length into the model

The model will compute an estimated total cost:

  • Estimated total cost = 273 days × $350/day = $95,550

Step 4: Compare against a “faster path” scenario

Now model a scenario where the case resolves sooner.

  • Alternative end date: 2026-07-15
  • Alternative delay length: 196 days
  • Alternative total cost = 196 × $350 = $68,600

Step 5: Compute the cost of delay attributable to slipping

Difference between scenarios:

  • $95,550 − $68,600 = $26,950

That difference is your modeled “cost of delay” for the extra ~77 days.

Where the Tennessee 1-year anchor fits

If you are using statute-based planning horizons as a backstop in your assumptions, you can align your scenarios so they don’t drift beyond a 1-year (365-day) anchor used in your jurisdiction data:

In practice, that means you might run:

  • a “within 1-year horizon” scenario (e.g., 300–360 days)
  • a “beyond 1-year horizon” scenario (e.g., 410–520 days)

Then observe how the modeled cost scales with time.

Pitfall: Don’t mix timeline definitions. If you measure “delay” from different start dates across scenarios (for example, one scenario uses a filing date and the other uses an indictment date), your comparison will be misleading even if the math is correct.

Common scenarios

DocketMath is most useful when you turn broad uncertainty into a handful of explicit scenarios. Here are practical Tennessee-focused examples you can model (without treating the output as a legal conclusion).

1) Sliding resolution dates (most common)

You’ll vary only the end date while holding the daily cost constant.

ScenarioStart dateEnd dateDaysCost rateModeled cost
Expected2026-01-012026-09-01244$350/day$85,400
Delayed2026-01-012026-11-01305$350/day$106,750
Substantial delay2026-01-012027-01-01366$350/day$128,100

2) Staged costs (different cost rates by phase)

Sometimes cost isn’t constant. For example:

  • early phase: $250/day
  • later phase: $500/day

If your tool supports multi-input phase modeling (or if you run multiple passes), you can model the total as:

  • Phase A days × rate A + Phase B days × rate B

This approach is useful when the operational burden changes after certain procedural milestones.

3) Anchoring around a 1-year limitation period

Because your jurisdiction data highlights a 1-year anchor tied to:

  • Tenn. Code Ann. § 40-35-111(e)(2) (1 year; exception V2)
  • Tenn. Code Ann. § 40-2-102(a) (1 year; exception V3)

…you can create a scenario set around that horizon:

  • 0–365 days: “Within anchor”
  • 366–450 days: “Slightly beyond”
  • 451+ days: “Well beyond”

Then compare incremental costs. The calculator helps you see how quickly the dollars accumulate after the anchor point.

4) Comparing cost rates (sensitivity analysis)

If you aren’t sure whether the daily cost should be $250/day or $450/day, run both:

  • $250/day × 300 days = $75,000
  • $450/day × 300 days = $135,000

This reveals how sensitive your estimate is to the cost rate input—often more important than the difference of a few weeks.

Tips for accuracy

To get outputs you can trust for planning, focus on data hygiene and consistent assumptions.

Use a consistent “days” methodology

Decide whether you’re counting:

  • calendar days (most straightforward), or
  • business days (if your cost rate is tied to working time)

Then keep that choice constant across scenarios.

Keep the cost rate grounded in actual operations

Choose a cost rate you can justify internally. For example:

  • staffing cost per day
  • contracted services cost per day
  • overhead per active case per day

If you’re using attorney time, consider converting hourly rates into a daily equivalent so your time units match the model’s input units.

Separate “timeline uncertainty” from “cost uncertainty”

It’s easy to accidentally double-count uncertainty. A clean structure is:

  • Scenario set A: same cost rate, vary timeline
  • Scenario set B: same timeline, vary cost rate
  • Optional: combine only after you understand each driver separately

Sanity-check the magnitude

A quick reality check can prevent bad assumptions from producing extreme outputs.

  • If your delay is 30 days, cost rate $350/day implies ~$10k.
  • If your tool shows $1M for a 30-day delay, something is likely off (unit mismatch, wrong date, or wrong rate entry).

Warning: The calculator output depends entirely on your inputs. If you input “months” but the model expects “days” (or vice versa), the computed cost will be off by a factor of ~30–31.

Tie the 1-year anchor to a modeling horizon (not a conclusion)

When using Tennessee 1-year anchors such as Tenn. Code Ann. § 40-35-111(e)(2) and Tenn. Code Ann. § 40-2-102(a) (both shown as 1-year anchors in your jurisdiction data), treat them as:

  • planning horizons,
  • scenario boundaries,
  • or comparison benchmarks.

They are not automatic determinations of rights or outcomes in any specific case.

Related reading