Cost of Delay Modeler Guide for Washington
8 min read
Published March 22, 2026 • By DocketMath Team
What this calculator does
DocketMath’s Cost of Delay Modeler helps you estimate the economic impact of time in a Washington (US-WA) timeline—using a structured model tied to Washington’s statute of limitations (SOL) framework.
Instead of treating “delay” as a vague concept, the tool lets you translate timing into a cost signal you can apply to project planning, settlement evaluation, budgeting, and operational decision-making. The model is built around the Washington SOL rules reflected in:
- RCW 9A.04.080 (general rule: 5 years)
- Exceptions that reduce the SOL period to 3 years for certain cases
- RCW 9A.04.080(1)(j) — 3 years (exception “V1” in the tool’s model)
- Additional 3-year exception (“V2” in the tool’s model), represented in the tool’s jurisdiction configuration as 3 years
Warning: This guide is for modeling and planning. It’s not legal advice, and it can’t determine whether a specific case is actually time-barred. SOL application depends on case-specific facts and timing details.
If you want to jump straight into the workflow, open the tool here: /tools/cost-of-delay.
When to use it
Use the DocketMath Cost of Delay Modeler when you need to compare “what happens if we act now vs. later” under Washington SOL constraints—especially when timing drives cost, risk, or leverage.
Common triggers include:
- Project scheduling and intake triage
- You’re deciding whether to prioritize cases that are “older” within the Washington SOL window.
- Litigation readiness and staffing
- You want a consistent way to quantify how delays change expected value (for planning purposes).
- Settlement and negotiation strategy
- You’re comparing alternatives across time horizons (e.g., 6 months vs. 18 months).
- Operational risk management
- You’re trying to avoid “silent” timeline creep that can increase costs and reduce options.
Here are specific Washington-focused reasons the modeler matters:
- Washington’s general SOL is 5 years under RCW 9A.04.080
- Some scenarios fall into 3-year exceptions under RCW 9A.04.080(1)(j) or the model’s configured **3-year exception (“V2”)
- Modeling delay against the correct SOL period changes the outcome of your timing window calculations—your “cost of delay” curve will shift accordingly.
Step-by-step example
Below is a concrete walkthrough that uses Washington SOL timing configuration (5 years generally; 3 years for exception scenarios) to produce a delay-cost estimate.
Step 1: Choose the SOL period in the tool
In DocketMath, you typically select the relevant SOL rule variant for Washington based on your case category inputs (the tool’s jurisdiction mapping reflects):
- 5 years — RCW 9A.04.080
- 3 years — RCW 9A.04.080(1)(j) (V1) and 3 years — V2 configuration
For this example, assume you’re evaluating a scenario that fits the 5-year general SOL under RCW 9A.04.080.
Step 2: Enter the key dates
You’ll provide timing inputs such as:
- Event date (the start of the timeline for modeling purposes)
- Target decision date (when you expect resolution/filing/next milestone)
- Optionally: today’s date and/or “currently pending” date depending on the tool’s flow
Example inputs for modeling:
- Event date: January 15, 2021
- Target decision date: July 15, 2026
- Modeling SOL period: 5 years
That’s 5.5 years between event and target decision date.
Step 3: Model the delay relative to the SOL window
If the general SOL is 5 years under RCW 9A.04.080, then:
- The SOL “ceiling” in this example occurs around January 15, 2026
- Your target decision date is 6 months after that ceiling
In a cost-of-delay model, crossing time thresholds usually increases cost/risk signals. Even where you’re not “deciding” legal outcomes, the tool’s purpose is to quantify the operational and economic effect of late timing.
Step 4: Set economic parameters
This is where you translate delay into dollars.
The cost-of-delay model typically uses inputs such as:
- Daily/weekly/monthly cost rate (internal costs, carry costs, opportunity costs)
- Value at resolution or expected benefit if handled within the preferred timeline
- Discount rate / time preference (often a standard assumption in tool models, if the interface includes it)
Example (for illustration of modeling mechanics):
- Cost rate: $250 per day equivalent (or the tool’s unit)
- Expected benefit: $50,000 if resolved within the optimal window
- Delay penalty: modeled as increased cost and/or reduced expected value with time
You then compare the modeled outcome if the target decision date were:
- Within 5 years (baseline)
vs. - After 5 years (delayed scenario)
Step 5: Review output and interpret change drivers
The modeler will output a cost figure and often a break-down such as:
- Total modeled cost from delay duration
- Impact of being inside vs. outside the relevant SOL window (5-year or 3-year)
- Sensitivity to key assumptions (cost rate, time horizon, and selected SOL period)
What you should notice in this example
- Switching from the 5-year rule (RCW 9A.04.080) to a 3-year exception scenario (RCW 9A.04.080(1)(j) for V1 or V2) would tighten the timeline and generally increase the cost signal earlier.
- Adjusting the target decision date by even 3–12 months can materially change the modeled output because the tool scales cost with delay duration and window crossing.
Pitfall: If you select the wrong SOL variant (e.g., using 5 years when the scenario should be modeled under a 3-year exception like RCW 9A.04.080(1)(j)), you’ll systematically understate the impact of delay. The fix is to align the tool’s SOL period with the correct category used in your inputs.
Common scenarios
Different Washington SOL configurations show up in practice as recurring planning patterns. Use these scenarios to sanity-check your model inputs before relying on output.
Scenario A: General 5-year horizon (RCW 9A.04.080)
Best for modeling when:
- Your case category aligns with the general Washington SOL rule.
Tool expectation:
- Delay cost grows steadily with time.
- Costs spike primarily when the target date approaches or passes the 5-year mark.
Washington anchor:
- RCW 9A.04.080 — 5 years
Scenario B: 3-year exception (RCW 9A.04.080(1)(j) — V1)
Best for modeling when:
- Your facts align to the 3-year exception reflected in the tool configuration.
Tool expectation:
- The window is shorter, so your modeled “time outside the SOL horizon” may occur sooner.
- Your cost-of-delay curve shifts left (earlier threshold crossing).
Washington anchor:
- RCW 9A.04.080(1)(j) — 3 years (V1)
Scenario C: Additional 3-year exception (V2)
Best for modeling when:
- Your case type falls into the tool’s configured 3-year bucket labeled “V2”.
Tool expectation:
- Behavior mirrors the 3-year horizon: earlier threshold crossing compared to the general 5-year rule.
Washington anchor:
- Model configuration: 3 years — exception V2 (mapped to RCW 9A.04.080 in the tool’s jurisdiction profile)
Scenario D: Decision timing comparisons (planning rather than prediction)
Even if you aren’t using the model to predict legal outcomes, you can use it to compare operational alternatives:
- “If we bring the case to the milestone in 90 days vs. 180 days, what’s the cost delta?”
- “If we allocate extra staffing next month, how much can we reduce delay cost?”
To run comparisons, keep every variable constant except:
- target decision date
- (if needed) the SOL variant selection
This makes the output interpretable and avoids accidental confounding.
Tips for accuracy
Accuracy in a cost-of-delay model comes from disciplined input hygiene. These practices reduce mistakes that commonly distort outputs—especially when the Washington SOL window changes from 5 years to 3 years.
1) Lock the SOL variant to the modeled category
Because Washington’s SOL differs between the 5-year general rule and certain 3-year exceptions, your results can swing dramatically.
- Use 5 years when modeling under RCW 9A.04.080
- Switch to 3 years when the tool inputs reflect an exception such as:
- RCW 9A.04.080(1)(j) (V1)
- V2 (3-year exception in the tool’s Washington configuration)
2) Verify date meaning before modeling
Inputs that look similar often mean different things:
- event date vs. filing date vs. “current date”
- “target resolution” vs. “target milestone”
A reliable pattern:
- Keep one start date (your event/timeline anchor)
- Keep one comparison date (your target milestone)
- Use “today” only if the tool requires it for cost accumulation
3) Test sensitivity for your highest-impact assumptions
If your tool lets you adjust cost rates or discount rates, run at least two sensitivity passes:
- Lower cost rate vs. higher cost rate
- Conservative vs. aggressive time preference (if available)
If the conclusion flips based on a tiny parameter change, your model is too fragile for decision-making and you should tighten inputs.
4)
Sources and references
Start with the primary authority for Washington and confirm the effective date before relying on any output. If the rule has been amended, update the inputs and rerun the calculation.
