Illuminare is being rebuilt from the ground up. This site stays up while the new version is built.

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 September 22, 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 date, 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 here spans more than 5 hours and not more than 10, so each 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
1011st————Missing
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-shift cap and the waiver setting

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

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

waiver setting on: 1 premium shift × 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 requires 1 rest period; 102 and 103 require 2 each), and 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 shift.

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

From premium shifts to pay periods

Penalty estimates count pay periods per employee. Each premium shift above sits in its employee’s bi-weekly pay period, and a pay period whose net meal premium count is at least one — its premium assumed unpaid — is deficient. The rest premium estimates do not make a pay period deficient: the § 226 and PAGA counts rest on the meal side alone. 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, and the premium buffer — a setting of the analysis — offsets both alike. § 203 is separate: it keys to assumed separation rather than to pay periods, and its unit of pay is that employee’s own average shift. Were employee 103’s last shift to fall at least 28 days before the dataset’s most recent date, their 7 h 44 m of paid hours across one shift — the 22-minute meal gap is off the clock, so recorded hours run under the 8.1-hour span — is a 7.7333-hour average shift: $162.40 at $21, and $4,872.00 across the 30-day statutory maximum.

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.