AI Adoption GuideHRReward
Continuous pay-equity monitoring
Model recalculates adjusted pay gap across protected groups on every pay change and flags outliers for remediation.
HR processPlanSourceSelectHireOnboardDevelopRewardExit
By Don, DoneThat’s AI coach · updated
What a defensible flag contains
The output of continuous pay-equity monitoring is a flag a compensation or DEI analytics lead can defend, not a salary change and not a published gap number. When base pay, a bonus, an equity grant, or an allowance hits the pay file, the model recalculates the adjusted pay gap across the protected groups the employer is allowed to use. If a row looks like an outlier inside that grouping, the system writes a flag. The flag must cite three artifacts: the pay file it read, the grouping rule counsel allows, and the model vintage that produced the estimate. If any of those three is missing, the flag is not ready for a human to act on.
What stays out of the flag: a recommended new salary, a company-wide pay-gap percent presented as a measured outcome, and any demographic label that did not come from an HRIS-held, consented field. Names, photos, email patterns, and inferred gender or ethnicity are not inputs. If the HRIS cell is empty for a given cut, that person is out of that protected-group analysis for this run. Empty stays empty.
A usable flag is evidence for a remediating partner. It is not permission to post payroll.
Load the pay file and the grouping counsel allows
Start with two files, not a dashboard screenshot.
Load the current pay file from the system of record. That is usually the compensation extract from an HRIS or total-rewards platform in the same class as Workday, with survey or market cuts available from vendors in the class of Radford when you need job and level context. The extract should include employee ID, job, level, location, each pay component, the effective date, and the reason code for the change (hire, promotion, adjustment, cycle). Do not score a warehouse snapshot if the live pay file has already moved.
Load the grouping file counsel will defend. That file maps each in-scope employee to the analysis cells you are allowed to compute: job family or grade, location or geo band, and the protected-group fields that exist in the HRIS because the employee consented to them. People-analytics and pay-equity platforms in the class of Visier or Syndio may already store those cuts. Treat them as a class of places the grouping can live, not as a reason to skip counsel review. The grouping rule itself (who is comparable to whom, which controls the model uses, the minimum cell size) is a legal and statistical choice. Freeze it as a named rule with a version, the same way you freeze a model vintage.
Join on employee ID. Drop anyone whose protected-group fields are blank for the cut you are running. Do not backfill from a prior year, from a manager guess, or from a classifier that reads a resume photo.
Run the current model vintage against that joined table. The model estimates an adjusted gap inside each allowed cell. You are not publishing that estimate as the company's pay-gap percent. You are using it only to decide which rows look like outliers relative to the same vintage and the same grouping.
Flag outliers with cites, then stop
For every pay change in the extract, persist a flag when the person sits outside the outlier rule that model vintage defines for their cell. The payload should be boring and complete:
- Pay file: extract ID, as-of timestamp, and the row's effective date.
- Grouping rule: counsel-approved rule ID and version, plus the cell keys (grade, geo band, and which protected-group field was used).
- Model vintage: a specification ID, not the word "latest."
- Subject: employee ID and the pay component that moved.
Leave out a new target salary, an auto-applied adjustment, and a headline gap percent for the company.
The system stops there. Compensation still remediates. A human in rewards opens the flag, checks that the three cites resolve to artifacts they can produce, and decides whether the person needs a market check, a promo-equity review, or no action because the change is already explained (for example, a documented skill premium the grouping already allows). Nothing in the monitor writes back to the payroll file.
Illustrative path, not a measured result: a senior engineer in a geo band receives a mid-year promotion. The new salary lands in the pay file that night. The monitor joins that row to the current grouping rule, sees that the person's HRIS gender field is populated and that the grade-by-geo cell is large enough to score, and emits a flag because the new salary sits below the model's outlier threshold for that cell. The flag names extract pay_2026_08_31, grouping rule grade-geo-gender-v4, and model vintage adj-gap-2026.07. A compensation partner pulls those three artifacts, reviews the promo worksheet, and either schedules a remediation conversation or closes the flag with a written reason. The salary does not move unless that partner, or their approver, changes it.
If the same promotion had landed in a cell with too few peers, the outlier field would stay blank. The promotion would still exist. The partner could still review it. The monitor would not invent a gap so the dashboard looks complete.
Thin cells stay blank; remediation still happens
Minimum cell size is a grouping-rule parameter, not a display preference. When a cell is too thin, the adjusted-gap estimate is not stable enough to support an outlier call. Empty stays empty. Do not coerce a blank to zero, borrow peers from a neighboring grade, or average across locations counsel excluded.
Thin does not mean ignored. Compensation still remediates on other evidence: the live market benchmarking range for the job, the promotion letter, or flags in thicker cells in the same family. Document the blank with a cell-level cite that the cell sat below the minimum n in grouping rule v4.
Failure modes that look like monitoring
A flag with no vintage. If the payload says "current model" or omits the specification ID, you cannot reproduce the outlier call after the next retraining. Refuse to queue remediation until vintage, pay file, and grouping rule all resolve.
Treating the flag as a pay change. Wiring the alert into the off-cycle increase workflow trains the organization to treat the monitor as an approval to pay. Auto-applying a midpoint, a survey P50, or a close-the-gap delta turns a quality control into unauthorized compensation action. Keep the flag in a review queue. A merit cycle agent may propose cycle math. It does not get to close a pay-equity flag by posting a number.
Inventing a pay-gap percent. Leadership will ask for "the gap" after a cluster of flags. This monitor does not produce that number. If you need a published statistic, run a separate, counsel-scoped study. Do not average outlier scores, convert flag counts into a gap, or back-solve a percent from a vendor tile. Platforms in the Workday, Visier, Syndio, and Radford class can show pay or representation views. None of those views is a license to mint a gap percent from this flag stream.
Inferring protected class from names or photos. If the HRIS field is blank, skip the cut. Do not parse first names, run a photo through a classifier, or let a manager confirm a box the employee never consented to store.
How this sits next to market, merit, and calibration
Continuous monitoring is the after-change control, not the market survey and not the cycle. Market ranges help a remediating partner see whether a flagged salary is off the job. They do not overwrite the grouping rule. A compensation flight-risk model may explain why a manager is pushing an off-cycle increase. It does not prove or disprove a pay-equity outlier. Cycle design belongs with merit tooling. Whether ratings themselves are skewed belongs with a calibration bias detector, which is a different grouping and a different vintage.
Keep the artifacts aligned. The same employee ID, the same pay file date, and the same counsel-approved grouping should be what you hand a remediating partner. If market, merit, and equity flags disagree, that is a human decision, not a reason for the monitor to pick a salary.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first