Worked example: Damages Allocation in Oregon
6 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 how DocketMath can allocate damages components for an Oregon case using jurisdiction-aware rules (Oregon code US-OR). This walkthrough is designed to show how the tool thinks, what inputs typically drive outputs, and where the numbers can move.
Note: This is an educational example, not legal advice. Oregon damages questions can turn on specific pleading, proof, and evidence details.
Scenario (single plaintiff; two damages categories)
Assume the plaintiff brings a civil claim in Oregon and seeks damages broken into two common buckets for a damages-allocation workflow:
- Category A — Compensatory damages (economic loss): $80,000 (e.g., documented wages, invoices, and repair bills)
- Category B — Statutory / penalty damages: $20,000 (assumed fixed statutory measure for this example; the walkthrough focuses on allocation mechanics)
We also assume:
- A Category B cap applies to the statutory/penalty category (modeled as a cap for demonstration): $15,000
- A known overall recovery ceiling across categories (e.g., negotiated or rule-based maximum): $95,000
Inputs you’d enter in DocketMath (example)
Use the DocketMath calculator damages-allocation with jurisdiction = US-OR via the primary CTA:
/tools/damages-allocation
Check these input items (labels may vary slightly in the UI, but the concepts map directly to typical damages-allocation fields):
Expected allocation logic (high level)
In this example, allocation is governed by two constraints:
- Category cap (Category B): Category B cannot exceed $15,000 even if asserted at $20,000.
- Overall cap (A + capped B): The sum of Category A and the capped Category B cannot exceed $95,000.
Example run
Now run the example in DocketMath using the damages-allocation calculator (jurisdiction: US-OR) via /tools/damages-allocation.
For clarity, here’s the logic shown step-by-step in the same order a calculator often applies constraints.
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 the Category B cap
- Category B asserted: $20,000
- Category B cap: $15,000
- Allocated Category B = min(20,000, 15,000) = $15,000
Step 2: Apply the overall recovery cap
- Category A = $80,000
- Allocated Category B (after category cap) = $15,000
- Subtotal = $80,000 + $15,000 = $95,000
- Overall cap = $95,000
- Allocated total = min(95,000, 95,000) = $95,000
Step 3: Produce component allocations
| Damage component | Amount before caps | Cap applied? | Allocated amount |
|---|---|---|---|
| Category A (compensatory) | $80,000 | No (in this model) | $80,000 |
| Category B (statutory/penalty) | $20,000 | Yes (category cap) | $15,000 |
| Total | $100,000 | Yes (overall cap) | $95,000 |
Step 4: Practical consequences of this specific run
Because the overall cap is exactly hit, the allocation is stable in this base run:
- Modeled total recovery: $95,000
- Of that, $80,000 is Category A, and $15,000 is Category B.
Quick caution: if you later change Category A while keeping Category B and caps fixed, the overall cap may stop being binding. When that happens, Category B can “fully apply” its category cap without the overall ceiling limiting it (demonstrated next).
Pitfall: If you set the overall cap lower than Category A alone (e.g., overall cap = $60,000 while Category A = $80,000), many allocation models use a prioritize/scale rule. The exact behavior depends on the jurisdiction-aware settings (and on the inputs you provide).
Sensitivity check
To see what drives Oregon allocations in this workflow, vary one input at a time using the same base assumptions (jurisdiction US-OR, Category B cap $15,000 unless stated otherwise).
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 1: Lower Category A by $10,000
Change:
- Category A: $80,000 → $70,000
- Category B asserted stays $20,000
- Category B cap stays $15,000
- Overall cap stays $95,000
Results:
- Category B allocated = min(20,000, 15,000) = $15,000
- Subtotal = $70,000 + $15,000 = $85,000
- Overall cap = $95,000 (not binding)
New outputs
- Category A: $70,000
- Category B: $15,000
- Total: $85,000
Interpretation: When the overall cap is not binding, Category B can fully use its category cap.
Sensitivity 2: Raise the overall cap (remove the binding ceiling)
Change:
- Category A returns to $80,000
- Category B cap stays $15,000
- Overall cap: $95,000 → $120,000
Results:
- Category B allocated = $15,000
- Subtotal = $80,000 + $15,000 = $95,000
- Overall cap = $120,000 (not binding)
New outputs
- Category A: $80,000
- Category B: $15,000
- Total: $95,000
Interpretation: Increasing the overall cap does not change anything here because Category B is already capped at $15,000, and the subtotal never reaches the new overall limit.
Sensitivity 3: Reduce Category B cap (tighten the penalty/statutory cap)
Change:
- Category A = $80,000
- Category B asserted = $20,000
- Category B cap: $15,000 → $8,000
- Overall cap stays $95,000
Results:
- Category B allocated = min(20,000, 8,000) = $8,000
- Subtotal = $80,000 + $8,000 = $88,000
- Overall cap = $95,000 (not binding)
New outputs
- Category A: $80,000
- Category B: $8,000
- Total: $88,000
Interpretation: Category B cap directly drives both the Category B allocation and the total once it is low enough that the overall cap no longer constrains the result.
Summary of sensitivity impacts
| Case | Category A | Category B cap | Overall cap | Allocated Category B | Total |
|---|---|---|---|---|---|
| Base run | 80,000 | 15,000 | 95,000 | 15,000 | 95,000 |
| Sensitivity 1 (A down) | 70,000 | 15,000 | 95,000 | 15,000 | 85,000 |
| Sensitivity 2 (cap up) | 80,000 | 15,000 | 120,000 | 15,000 | 95,000 |
| Sensitivity 3 (B cap down) | 80,000 | 8,000 | 95,000 | 8,000 | 88,000 |
How to use this in practice with DocketMath
- If your modeled total seems “stuck,” check whether the overall cap is binding (i.e., whether A + capped B hits the ceiling).
- If your penalty/statutory component seems capped “too early,” check the category cap first.
- Adjust one input at a time (like the checks above) to identify which constraint is actively driving the allocation. DocketMath outputs make it easier to see which limit is controlling.