How to calculate Settlement Allocator in Kentucky

Quick takeaways

• In Kentucky, a Settlement Allocator is typically built on Ky. R. Civ. P. 23 as the governing class-action settlement framework for how distribution is handled.
• For Kentucky in DocketMath, the allocator uses the Ky. R. Civ. P. 23 “general/default” period because no claim-type-specific sub-rule was found in the Ky. R. Civ. P. 23 materials provided.
• To run a defensible allocator in DocketMath, you need:

  1. class membership and eligibility inputs,
  2. a consistent allocation basis (your “driver” values), and
  3. the allocable settlement amount to distribute.
• DocketMath helps you run the math consistently, but your final allocation still needs to align with what the court approves under Ky. R. Civ. P. 23.

Inputs you need

Before you open DocketMath → /tools/settlement-allocator, gather the following inputs. Organizing them up front prevents mismatched numbers later.

Settlement and allocation setup

• Settlement gross amount (example: $1,250,000)
• Total “allocable” amount

  • The portion you will actually distribute to class members.
  • If your settlement is structured with separate deductions (e.g., administration costs or other items handled outside the member allocation), make sure DocketMath receives the allocable figure you intend to distribute.
• Allocation basis (choose one consistent approach)

  • Common options include pro rata by documented/verified loss, claim points, or another measurable proxy used in your settlement framework.
• Ky. R. Civ. P. 23 allocation timing assumptions

  • Use the general/default period under Ky. R. Civ. P. 23.
  • Important: Based on the materials provided, no claim-type-specific sub-rule was found, so you should not apply different “period” rules by claim type.

Class-member level inputs

For each class member (or each claim bucket), collect:

• Identifier (e.g., Member ID / Claim ID)
• Individual allocation driver value (Dᵢ)

  • Examples: verified loss amount, claim points, or another eligibility-weighted measure—whatever your chosen allocation basis uses.
• Eligibility limits / inclusion rules

  • Example: include only claims submitted by the settlement submission deadline, or include only members who satisfy defined eligibility criteria.

Aggregation totals (for sanity checks)

You’ll also want to compute totals that must align with what you load into DocketMath:

• Sum of all driver values (D_total)

  • Example: total verified loss across all eligible class members (or across all buckets).
• Number of participating claimants

  • Useful for cross-checks and for spotting unexpected exclusions/inclusions.

Quick data checklist (copy/paste)

• Settlement gross amount captured
• Allocable amount determined (what you will distribute)
• Allocation basis selected and applied consistently
• Each member has a defined driver value (Dᵢ) if included
• Eligibility filter applied consistently
• D_total computed for the same included population
• Kentucky rule selection set to Ky. R. Civ. P. 23 general/default (no claim-type-specific sub-rule)

How the calculation works

DocketMath’s Settlement Allocator converts your settlement fund and allocation basis into per-member (or per-bucket) allocations. The core math is the same conceptually; what changes in a jurisdiction-aware setup is the configuration used to match the settlement framework expectations under Ky. R. Civ. P. 23.

Below is a practical way to understand what the tool is doing and what inputs affect the output.

Step 1: Decide what you’re allocating

Let:

• S = total allocable settlement amount (the amount you intend to distribute)
• Dᵢ = driver value for member i
• D_total = sum of driver values across all included members
• Aᵢ = allocation for member i

Under a proportional/pro-rata approach, DocketMath uses:

• Aᵢ = S × (Dᵢ / D_total)

What this means in practice:

• If a member’s driver is twice as large, their proportional share should be about twice as large (assuming both are included in the denominator).
• If you change S (allocable amount), all allocations scale up or down proportionally.

Step 2: Apply eligibility and dataset scope

The single most common reason allocator results “don’t match expectations” is denominator drift.

• Your D_total must be computed using exactly the same inclusion rules used for each member’s Dᵢ.
• If you later exclude some members (or claims) but forget to recompute D_total, allocations will not reconcile to S.

Practical example:

• If you filter out disqualified claims, you must also exclude their driver values from D_total—not just from the output list.

Step 3: Use the Kentucky jurisdiction-aware ruleset

For Kentucky, the DocketMath configuration is tied to Ky. R. Civ. P. 23.

Key configuration point for this guide:

• Use the Ky. R. Civ. P. 23 general/default period.
• No claim-type-specific sub-rule was found in the Ky. R. Civ. P. 23 material you provided, so you should not apply different allocation-period logic depending on claim type.

As a result, your allocations should remain consistent across member categories unless your driver values and eligibility filters already encode the distinctions your settlement framework intends.

Step 4: Run checks for internal consistency

After DocketMath calculates allocations, validate with basic reconciliation checks:

Step 5: Interpret the output in Kentucky settlement context

DocketMath outputs proposed per-member allocation amounts. Those numbers are the distribution math you’re ready to present, but they are still subject to Ky. R. Civ. P. 23 procedures, including settlement approval and any court-required handling/notice.

Common pitfalls

Settlement allocation math tends to fail in predictable places. Watch for these issues in your Kentucky DocketMath workflow.

1. Using the wrong Ky. R. Civ. P. 23 “period” configuration

   • If you apply claim-type-specific logic that isn’t supported by the Ky. R. Civ. P. 23 general/default approach you’re using, results can drift.
   • Kentucky guidance here: use Ky. R. Civ. P. 23 general/default, because no claim-type-specific sub-rule was found.

2. Denominator mismatch (D_total drift)

   • You exclude invalid claims from the member list but forget to recompute D_total.
   • Result: allocations may not sum to the allocable amount S.

3. Mixing driver types midstream

   • Example: one member’s Dᵢ is “verified loss $,” while another’s is “points,” without normalization.
   • Proportional math becomes meaningless unless your model treats the driver consistently (same units/basis).

4. Allocating gross instead of allocable

   • DocketMath needs S to represent what you actually intend to distribute.
   • If you input gross settlement while separately deducting costs, ΣAᵢ can exceed the distributable fund.

5. Ignoring rounding and reconciliation

   • Per-member rounding can cause ΣAᵢ to differ slightly from S.
   • Use DocketMath’s reconciliation outputs or export and do a cents-level reconciliation so you can explain small differences.

6. Not documenting the allocation basis

   • Even with correct math, you should be able to explain:

     • how Dᵢ was defined,
     • what eligibility filter was applied,
     • how D_total was computed.
   • Keep a short “model note” next to your exported results.

Sources and references

• Ky. R. Civ. P. 23 — Class actions and settlement framework
  https://govt.westlaw.com/kyrules/Browse/Home/Kentucky/KentuckyCourtRules
• DocketMath tools entry point: /tools/settlement-allocator

Next steps

1. Open DocketMath

   • Go to: /tools/settlement-allocator
2. Enter settlement inputs

   • Input S (allocable amount) and your chosen allocation basis.
3. Load member driver values

   • Provide Dᵢ for each member (or bucket).
   • Apply eligibility filters consistently with how you’ll compute totals.
4. Confirm Kentucky configuration

   • Set jurisdiction to Kentucky (US-KY) and use