Documentation
Analytics Methodology
How PaySymmetry™ measures pay equity, flags potential disparities, and estimates remediation — written for the legal, compliance, and analytics teams who rely on it.
This methodology documentation is provided for informational purposes. Organizations should consult qualified legal counsel before relying on any pay equity analysis for legal filings or litigation defense.
Overview
Pay equity analysis tests whether employees of different demographic groups — primarily by sex, and by race/ethnicity where EEO-1 data is provided — are paid differently after accounting for legitimate, job-related pay factors.
PaySymmetry™ uses two complementary lenses:
- Descriptive comparison: an employee’s pay is compared to the median of their peer group (employees of the same pay grade and job title in the reference gender group). This produces a concrete, employee-specific benchmark.
- OLS regression: a statistical model that isolates the pay difference associated with gender while simultaneously controlling for multiple legitimate pay determinants. PaySymmetry™ uses this for the org-wide adjusted gap.
The unadjusted gap is the raw average pay difference between groups; the adjusted gap is what remains after the regression controls for job grade, title, tenure, and other mapped factors.
Such analyses support employer obligations and defenses under Title VII of the Civil Rights Act, the Equal Pay Act (EPA), and a growing body of state pay-transparency and pay-data-reporting laws — including California SB 1162, Colorado’s Equal Pay for Equal Work Act (EPEWA), and New York S9427A — covered in the Jurisdictional Coverage section.
Data Ingestion & Validation
Users upload a workforce file (CSV or Excel) and map their columns to PaySymmetry™ fields in the upload wizard.
Required fields
- Employee identifier
- Annual salary (or pay rate)
- Gender
- Pay grade
- Job title
Optional fields
- Tenure
- Performance rating
- Work location
- Race/Ethnicity (EEO-1 categories)
Column mapping
The wizard auto-suggests mappings via name hints and lets the user confirm or override each mapping. An unmapped optional column is simply ignored and the corresponding control is dropped from the model.
Validation rules
- Rows with non-positive salary (≤ 0) are dropped before analysis.
- Race/Ethnicity values are validated against the 7 standard EEOC EEO-1 categories; non-standard values generate a warning but are not dropped.
- Employees missing performance data are retained via a
_missing_sentinel rather than dropped, preserving sample size. - Minimum peer-group size (default 3) is enforced downstream — see Peer Group Construction.
Data is processed per-organization in isolation, with row-level org separation enforced at the database layer.
OLS Regression Model
Specification
PaySymmetry™ uses Ordinary Least Squares regression with the natural log of annual salary as the dependent variable:
log(salary) = β₀ + β₁·gender + β₂·pay_grade + β₃·job_title
+ β₄·tenure + β₅·performance + β₆·race_ethnicity + εpay_grade, job_title, and race_ethnicity enter as categorical (dummy-coded) controls. tenure, performance, and race_ethnicity are included only when those columns are mapped.
Why log-linear?
With a log-transformed outcome, the gender coefficient is interpreted proportionally: exp(β₁) − 1 is the approximate percentage pay difference associated with gender, holding the controls constant. This matches how pay gaps are reported (as a percentage) and stabilizes variance across the salary range.
What the gender coefficient means
β₁ (reported as exp(β₁) − 1) is the adjusted pay gap — the average pay difference associated with the non-reference gender group after accounting for all modeled legitimate pay determinants. A negative value means the non-reference group earns less on average.
Optional gender × pay-grade interaction
When enabled, the model appends a gender × pay_grade interaction term so the gap can vary by grade. The per-grade gap is back-calculated as exp(β_gender + β_interaction,grade) − 1. This reveals whether a disparity is concentrated at senior levels (a “glass-ceiling” pattern) versus uniform across grades.
Statistical significance
Assessed at the conventional two-tailed p < 0.05 threshold.
R² interpretation
R² is the share of salary variation explained by the model’s controls. A higher R² means the model accounts for more of the legitimate pay structure. R² is a measure of model fit, not of fairness — a high R² does not by itself imply the absence of a pay gap.
Peer Group Construction
A peer group is the set of reference-gender employees who share the same pay grade and the same job title (the grade × job-title cell). The peer-group median salary is the benchmark used for individual flagging and remediation costing.
Minimum peer-group size
Default is 3 reference-gender employees; configurable from 1 to 5 in the upload wizard. If a peer group contains fewer than the minimum number of reference-gender employees, its median is treated as undefined (set to NaN) because a median from 1–2 people is not a reliable benchmark.
What happens to a too-small group
Affected employees are excluded from the remediation estimate and counted in excluded_no_peer_group; the results surface a note explaining the exclusion. Setting the minimum to 1 reverts to no exclusions.
Note: performance ratings are not used to define peer groups (grade + job title only), even when performance is included as a regression control.
Flagging Methodology
PaySymmetry™ uses a dual-lens approach to identify potential pay disparities:
- Org-wide signal (regression): the OLS adjusted gender coefficient establishes whether a statistically significant disparity exists across the workforce after controlling for legitimate pay factors.
- Individual signal (peer median): an individual employee is flagged when their salary falls below their peer-group median (same grade × job title, reference-gender employees, subject to the minimum peer-group size).
The analysis applies a configurable gap threshold (gap_threshold_pct, default −5.0%): employees whose shortfall relative to the peer median exceeds this threshold are surfaced as flagged.
Employees whose peer group is too small to produce a reliable median are not flagged for remediation — see Peer Group Construction.
Using both lenses together means a flag reflects both a workforce-level statistical pattern and a concrete, employee-specific benchmark gap, making each flag explainable in plain terms.
Remediation Estimation
Adjustment cost per employee
The cost to raise a flagged employee to their peer-group median:
adjustment_needed = max(0, peer_median − salary)
Employees already at or above their peer median require no adjustment.
Total remediation cost
The sum of adjustment_needed across all flagged employees with a valid peer median. Employees excluded for small peer groups are not included in this total.
Budget optimizer (greedy, cheapest-gap-first)
When a fixed budget is supplied, the optimizer sorts flagged employees by adjustment_needed ascending and funds each to their peer median until the budget is exhausted — maximizing the number of employees resolved per dollar. It runs without re-running the regression and persists no state.
What-if simulation
Users can propose new salaries per employee in the What-If Sandbox; the platform recomputes the resulting gap impact without re-running OLS. Simulation results are not persisted.
Remediation figures are planning estimates, not legally binding obligations. Adjustments must be implemented outside the platform.
Jurisdictional Coverage
PaySymmetry™ produces pay-transparency and pay-data reports for the US jurisdictions below; all reports are generated from the same underlying analysis.
| Jurisdiction | Statute | What it requires | How PaySymmetry™ addresses it |
|---|---|---|---|
| California | SB 1162 | Annual employer pay-data reporting, including mean/median pay by job category and, for full compliance, by sex and race/ethnicity (EEO-1) | Generates the CA SB 1162 report with pay data by job category; includes a race/ethnicity breakdown when the EEO-1 column is mapped, and warns when it is not |
| Colorado | Equal Pay for Equal Work Act (EPEWA) | Pay transparency and equal-pay obligations; pay range and equity disclosure | Generates the CO EPEWA report from the same analysis |
| New York | S9427A | Pay-data and transparency reporting | Generates the NY S9427A report from the same analysis |
All three reports are produced from a single analysis run via the Compliance Hub and are rendered to PDF.
Limitations & Assumptions
- OLS assumptions: linearity (in the log of salary), independence of observations, and that the included controls capture the legitimate pay structure.
- Omitted-variable bias: the model can only control for factors present in the uploaded data. It does not control for variables that were not provided — e.g. specific skills, certifications, market premiums, negotiated offers, or team-level effects — and a gap may shrink or grow once such factors are added.
- Independence caveat: standard OLS assumes employee observations are independent; nested structures (employees within managers or teams) can violate this. Hierarchical modeling is on the roadmap but is not part of the current standard model.
- Intersectional analysis (gender × race jointly) is not yet part of the standard output.
- Small groups: estimates for thinly populated grades or peer cells are inherently less stable. Analyses with fewer than 30 employees may produce unreliable estimates.
- Not a legal determination: the model does not determine whether any pay difference is legally discriminatory — that is a legal determination requiring qualified counsel.
A qualified analyst and legal counsel should review results before they are used for any legal filing or litigation defense.
Audit Trail & Data Retention
Analysis storage
Analyses, their configuration, and results are stored per-organization with row-level isolation enforced at the database layer.
Audit log
User and system actions are recorded — including the event type, user, resource, timestamp, and IP address.
SOC 2 evidence export
A downloadable ZIP package contains:
audit_log.csv— all audit log rowsactive_users.csv— current users with role and last logindeletion_receipts.csv— analyses whose underlying files were purged, with reason and timestampmanifest.json— generated-at, org id, export id, row counts, and SHA-256 checksum
Retention & purge
Organizations may enable automated retention. A nightly retention job (runs daily at 02:00 UTC) purges stored files for organizations that have opted in; each purge produces a deletion receipt added to the audit trail.