Skip to main content
Back to journal
— ——June 20, 2026 · 1 min read

Building FairHire in the open

FairHire began as a practical question: can we make compensation signals in Mexican tech more legible without flattening the people behind the data. The first version focuses on the gender pay gap using INEGI and ENOE microdata, then adds job-fit analysis through the Claude API so salary context and role context can be examined together.

What shipped is intentionally narrow. We built the ingestion path for public labor microdata, mapped the variables needed for comparable salary views, and designed an interface that separates descriptive evidence from interpretation. The system is not a fairness oracle. It is an evidence workspace for asking better questions about compensation, hiring signals, and role expectations.

What comes next

The next layer is validation. We are tightening data provenance, documenting assumptions, and testing how the job-fit analysis behaves when resumes, vacancies, and salary bands carry different levels of detail. The goal is not to produce a single score that looks precise. The goal is to show where evidence is strong, where it is thin, and where a human reviewer should slow down.

Building in the open keeps the product honest: every assumption has to survive contact with data, users, and public scrutiny.

We are sharing the process because fairness tools fail when they hide their method. Public labor data has limits. Language models have limits. Hiring teams have incentives that need to be made visible. The build log is where those constraints stay on the table while the product evolves.