Methodology

How Illuminare turns raw timekeeping data into the figures it reports — every threshold, formula, and default assumption, with worked examples you can reproduce by hand. It applies identically plaintiff-side or defense-side: the system reports what the data shows and leaves interpretation to you.

Authored by

Philip Gundy — economist & data scientist, several years in California wage-and-hour litigation analytics at an Am Law 100 firm.

Written to be cited

Every figure traces to a section here — for expert reports, meet-and-confer briefings, and class-certification work.

Current

Updated August 23, 2026 — the date moves whenever a threshold, formula, or assumption changes.

A worked example — from punches to premium

How these rows were validated, de-duplicated, and grouped into the three shifts below is walked stage by stage on Data processing.

Simulated data: three employees on one workday, 2025-03-03, all clocking in at 08:00 — one shift each, average hourly rate $21. Their punches produce one, two, and two Time Segments, and each stage below shows the columns the analysis computes on those rows.

The Time Segments, row by row

Each clock-in/out pair is one Time Segment. For every segment the analysis computes its length, the total length of the shift it belongs to, and the gap that follows it before the employee’s next segment — a gap below the split-shift threshold keeps the segments in one shift and becomes a meal-break candidate:

employee_idclock_inclock_outSegment lengthShift durationGap (meal break)
10108:0013:305 h 30 m5.5 h
10208:0011:303 h 30 m7.5 h30 m
10212:0015:303 h 30 m7.5 h
10308:0013:105 h 10 m8.1 h22 m
10313:3216:062 h 34 m8.1 h

The shifts — spans set the meal requirement

Segments group into one shift per employee. Every shift duration here is 5 hours or more (and under 10), so each shift requires exactly one meal period:

employee_idShift startShift endShift durationMeal periods required
10108:0013:305.5 h1
10208:0015:307.5 h1
10308:0016:068.1 h1

Meal detection — each required meal, classified

A required meal is compliant when it begins by 5 hours elapsed and runs at least 30 minutes — compared at exact recorded minutes, never rounded (Donohue). A qualifying shift with no recorded meal is “No meal period recorded”:

employee_idMeal periodMeal startMeal endStarted (elapsed)DurationClassification
1011stMissing
1021st11:3012:003 h 30 m30 mCompliant
1031st13:1013:325 h 10 m22 mShort · Late

The classification and meal period read exactly as the app’s own meal table renders them (a short-and-late meal is “Short · Late”, with the meal period in its own column). 102 starts under the 5-hour deadline at a full 30 minutes; 103 starts 10 minutes past it and runs 8 minutes short. 101’s shift — over 5 and up to 6 hours with no meal — is additionally flagged Waiver-eligible; the premium stage shows both treatments.

Premium math — the per-workday cap and the waiver setting

A workday carries at most one meal premium regardless of how many meals violate, valued at one hour of pay. Employee 103’s short & late workday carries one. Employee 101’s no-meal workday counts under the default treatment — waivers are assumed not to exist — and is excluded when the case-level waiver setting is on:

default treatment: 2 premium workdays × 1 hour × $21 = $42

waiver setting on: 1 premium workday × 1 hour × $21 = $21

Rest breaks — estimated from the meal record

Rest breaks are rarely punched, so no rest figure is measured — the analysis estimates instead. All three shifts are rest-qualifying (101 owes 1 rest break; 102 and 103 owe 2 each), and under the default mode each employee’s own meal violation rate becomes their rest premium estimate per qualifying shift:

employee_idMeal violation rateRest-qualifying shiftsRest premium estimate
101100.0%11.0
1020.0%10.0
103100.0%11.0

Rates reflect the default meal treatment (101’s Waiver-eligible shift counted); with the waiver setting on, 101’s rate is 0.0% and the estimate drops to 1.0 workday.

estimated rest exposure = 2 rest premium workdays × 1 hour × $21 = $42

From premium workdays to pay periods

Penalty estimates count pay periods per employee. Each premium workday above sits in its employee’s bi-weekly pay period, and a pay period holding at least one premium workday — its premium assumed unpaid — is deficient. Rest premium workdays drive deficiency the same way (unchanged here, since 101 and 103 already carry meal premiums). Under the default treatment employees 101 and 103 each carry one deficient pay period; with the waiver setting on, only 103 does.

The § 226 schedule, the cap, and the window — an employee with history

Penalty arithmetic needs history, so extend the picture with an employee on the same bi-weekly calendar carrying 52 deficient pay periods across two years of data, of which 26 end inside the 1-year window. The all-time schedule hits the per-employee cap; the windowed figure is re-counted from the 26 in-window pay periods and re-capped — never scaled down from the all-time number:

§ 226, all time — 52 pay periods: $50 + $100 × 51 = $5,150 → capped at $4,000

§ 226, 1-year window — re-counted, 26 pay periods: $50 + $100 × 25 = $2,550

PAGA base, 1-year window — 26 pay periods: $100 × 26 = $2,600

The § 226 and PAGA estimates share the same deficient-pay-period grain but move differently: the assumed-paid share scales the § 226 count and never the PAGA count, while the premium buffer offsets both. § 203 is separate — it keys to assumed separation, not pay periods: an employee whose last shift falls more than 28 days before the dataset’s end would add the full 30-day statutory maximum, $21 × 8 × 30 = $5,040 of waiting-time exposure.

Every case figure is this arithmetic summed across employees — each step reproducible by hand from the counts shown.

Going deeper

Citing this methodology. Reference it as “Illuminare Analysis Methodology” together with the last-updated date above. The date moves whenever a threshold, formula, or default assumption changes, so a cited figure can always be reconciled against the methodology text it was produced under.

Questions about an assumption, an edge case, or a figure you can’t reconcile: hello@illuminare.app.

See the methodology on your own matter.

Illuminare is in closed alpha — access is by invitation.