Equity Gap Calculator

The Equity Gap Calculator is a live, public web application that answers one question well: which student groups are succeeding at lower rates than their peers — and by how much? It implements the California Community Colleges Chancellor's Office PPG-1 (percentage point gap) methodology, the state's official approach to identifying disproportionate impact, and wraps it in a product that a practitioner can use in minutes with a CSV export or a pasted Excel table.

This is a methodology-translation project as much as a software project. The statistical rules — subgroup versus all-other comparisons, margin-of-error thresholds, minimum-n handling — already existed in policy documents. The work was turning them into a tool that produces defensible answers for people who are not statisticians, without dumbing the method down.

California community colleges are required to identify disproportionate impact in student outcomes — for equity plans, program review, and accreditation. The Chancellor's Office publishes the PPG-1 methodology for doing this, but in practice the calculation lives in scattered spreadsheet templates, one-off scripts, and institutional research offices with long request queues.

The people who most need the answer — faculty leading a program review, a dean preparing an equity plan, a counselor questioning a pattern they noticed — usually can't get it without filing a data request and waiting. And when the calculation is done by hand in a spreadsheet, the subtle parts (the error threshold, small-group handling) are exactly the parts that get skipped.

• Institutional researchers who know the methodology and want a faster, consistent way to run it.
• Faculty and administrators doing program review or equity planning who have data but not statistical training.
• Student-services and equity practitioners who need a shared, credible number to organize action around.

These groups have very different tolerance for statistical language, which drove one of the core product decisions: every result is available in a simple mode (plain-language findings) and a technical mode (rates, gaps, thresholds, and counts) — same calculation, two presentations.

I built this as an independent public project, informed by years of doing this exact analysis inside institutional research offices. It uses only the public PPG-1 methodology and the user's own data — no institutional data ships with the tool. It links back to the Chancellor's Office methodology notes so users can verify the approach against the source.

Everything: product definition, methodology research, interaction design, implementation, validation, and deployment. I used AI coding tools to accelerate implementation — deliberately and with review — while owning the methodology decisions, the validation logic, and every judgment call about how results are computed and communicated. The statistical correctness is mine to defend, and I can.

• Fidelity to the published methodology — a tool like this is only useful if an IR office would sign off on its numbers.
• Privacy: users upload student-level data, so processing had to stay in the browser rather than shipping records to a server.
• Audience range: the same result screen serves statisticians and people who have never heard the phrase 'margin of error'.
• Messy real-world inputs: institutional exports differ in column names, encodings, and category labels, and the tool has to cope.

PPG-1 compares each subgroup's success rate to the rate of all other students combined: PPG-1 = subgroup rate − all-other rate. A negative gap alone is not enough to flag disproportionate impact — the gap must exceed a margin-of-error threshold that accounts for subgroup size, so small groups aren't flagged (or cleared) on statistical noise.

The tool also computes a gap-closing estimate for each flagged group: the number of additional successful outcomes required to close the gap. This turns an abstract percentage into a concrete, discussable target — 'about 14 more students succeeding' is something a program can plan around.

• Simple and technical result modes, not one compromise view. Practitioners get plain language ('Gap detected'); researchers get rates, thresholds, and counts.
• Insufficient data is a first-class result state, not an error. Small groups are reported as unreliable rather than silently dropped or falsely flagged.
• Percentage and count toggles, because equity conversations need both 'how big is the gap' and 'how many students is that'.
• Export, share, and print built in — the destination of this analysis is a meeting, a plan, or a report, not the screen.
• Links to the official Chancellor's Office methodology notes, so the tool's authority is checkable rather than asserted.

Real adoption depends on meeting data where it lives. The tool accepts four input paths that converge on one normalized internal representation before any analysis runs:

• Student-level file upload — CSV, .xlsx, or .xls exports straight from institutional systems.
• Pasted data — a table copied from Excel or a report and pasted directly into the app.
• Pre-aggregated entry — group-by-group counts for users who only have summary tables.
• Automatic column detection — headers are matched to expected fields (demographics, outcomes, optional fields like course/section, retention, discipline, subject, and education goal) with the user confirming the mapping.

Because users bring their own data, validation is the product's immune system. Rules run at import and again at analysis time:

• Structural checks — required columns present, outcome values interpretable, rows with unusable records surfaced rather than silently dropped.
• Category normalization — demographic labels mapped to consistent groups before comparison.
• Minimum-n enforcement — groups at or below the reliability threshold (n ≤ 10) are reported as 'insufficient data' and excluded from flagging.
• Aggregation consistency — pre-aggregated inputs are checked for internally consistent counts (successes cannot exceed attempts).

function classify(group: GroupResult, threshold: number): Status {
  if (group.n <= MIN_RELIABLE_N) return "insufficient-data";
  const ppg1 = group.successRate - group.allOtherRate; // percentage points
  if (ppg1 <= -threshold) return "gap-detected";      // beyond margin of error
  if (ppg1 < 0) return "below-average";               // within margin of error
  return "on-track";
}

The app is organized as a three-step workflow — bring data in, run the calculation, review results — with demographic breakdowns across Race/Ethnicity, Gender, and Age. Results pair a success-rate visualization with per-group status: gap detected, below average, on track or above, or insufficient data. From there, users can export to Excel, print, or share.

The UX principle throughout: the tool should feel like a knowledgeable colleague, not a statistics exam. Plain-language status labels lead; precise figures are one toggle away. Error states explain what to fix, not just what failed. The riskiest misreading — treating a noisy small-group result as a finding — is designed out by making 'insufficient data' its own prominent, explained status.

A client-side web application: parsing, validation, and the PPG-1 engine run in the browser, which is both a privacy stance (student-level records never leave the user's machine) and an operational one (no data-retention surface to secure). File parsing handles CSV and Excel formats; the calculation engine is isolated from the UI so the statistical logic is testable on its own.

I used AI coding tools to move faster on implementation scaffolding, and treated their output the way I'd treat a junior developer's: reviewed, tested, and corrected. The methodology layer — what gets computed, when a group is flagged, how edge cases resolve — was specified and verified by hand against the published methodology.

A live, public tool at di-calculator.com that performs the state's official disproportionate-impact calculation for anyone with a data export — no request queue, no spreadsheet template, no skipped error thresholds. It stands as the clearest public demonstration of what I do: take a method buried in policy documents and manual process, and turn it into a system people can actually use.

• Methodology translation is a design problem. Most of the hard decisions were about presentation and edge cases, not formulas.
• Import flexibility is the adoption feature. Every input path added (paste, pre-aggregated, auto-detection) removes a reason to give up.
• 'Insufficient data' handling is where credibility is won or lost — the honest answer is sometimes 'this group is too small to say'.

• Additional methodologies (e.g. proportionality index, 80% rule) behind the same import and results experience.
• Cohort-over-time comparisons to track whether identified gaps are closing.
• Saved analysis configurations for recurring program-review cycles.
• A documented test suite published alongside the methodology notes, so IR offices can audit the calculations directly.