Controls that support your equal-opportunity obligations

Equal-opportunity reporting fails for a boring reason. The demographic answers end up in the same table as the hiring data, on the same screen, in front of the same people. The moment a recruiter can see a candidate's race, sex, veteran status or disability status next to their pipeline stage, data collected to measure the decision has become part of the decision, and no policy written afterwards undoes that.

The fix is architectural. Demographic fields live in their own store with their own access control, keyed to the application through a reporting identifier rather than joined into the candidate view. A recruiter working a shortlist never renders them, because the query that builds the shortlist has no permission to read them. Access is a separate grant held by a reporting role, and every grant is logged.

There is no view anywhere in the product that puts a candidate's name beside their demographic answers, and no export that produces one. That is a stronger statement than a policy asking people to be careful, and it is the one worth testing during a demo rather than taking on trust.

The demographic questions exist because reporting obligations exist. Where they apply to you the categories are prescribed rather than invented, the answers are voluntary, a decline-to-answer option is always present, and the form states plainly that the answers play no part in the hiring decision and are not shown to the people making it.

Because the fields are stored separately, that statement is structurally true rather than aspirational. Category sets are configurable per market, because different jurisdictions prescribe different sets and asking the wrong questions is its own problem. You configure which set applies to which posting.

The product does not decide that an obligation applies to you and it will not invent a category nobody asked you to collect. Firms that are not federal contractors and not covered by a reporting threshold often collect demographic data anyway, out of habit, and that is a decision worth revisiting rather than automating.

Surhires scores candidates against requisitions, drafts outreach and parses resumes using models. The rule governing those features is absolute: demographic data is never included in a prompt, a feature vector, an embedding, a training set or a fine-tune. Payloads are built from an allow-list of fields, and the demographic store is not on the list and cannot be added by configuration.

Proxies are the harder problem and an honest answer beats a confident one. A model handed a resume can infer things from a name, a graduation year, a photograph, a school or a postcode. The obvious surface is reduced by excluding images from the parsing payload and by keeping match explanations at field level, so a recruiter sees which requirement drove each point rather than being handed a number. Nobody can promise a model infers nothing.

That is exactly why the score is shown with its reasons and why a person makes the decision. A score nobody can inspect cannot be defended, and a scoring system that cannot be explained is worse than none, because it launders a judgement into something that looks like a measurement.

When a candidate does not go forward, the reason is recorded from a fixed list rather than typed: failed technical screen, salary above budget, better-qualified candidate selected, candidate withdrew, candidate declined the offer, requisition withdrawn, or a stated licence or right-to-work requirement not met. A free-text note can sit alongside, but the code is mandatory and the drop-out cannot be saved without one.

Free-text reasons cannot be counted, and a reason that cannot be counted cannot be reviewed. Coded dispositions turn a pile of individual decisions into a distribution somebody can look at: this client rejects on salary six times in ten, this requisition rejected everybody from one source, this recruiter's screen rejects at twice the rate of the rest of the desk.

The same codes answer a question about one specific decision two years later. Immutable stage history, plus a coded reason, plus the scorecard behind it, reconstructs what happened at the time rather than requiring somebody to reconstruct it from memory in front of an audience who was not there.

Adverse impact is a calculation rather than an opinion. The four-fifths guideline compares the selection rate of one group against the rate of the group with the highest rate, and treats a ratio below four-fifths as a signal worth investigating. It needs applicant counts and selection counts by stage, by requisition and by group. Most systems cannot produce them, because dispositions were free text and demographic data was never cleanly separated.

The reporting surface exports exactly those counts, in aggregate, from the separated store. Where a cell is too small to be meaningful it is suppressed rather than published, because a group of three tells you nothing statistically and identifies somebody personally. Exports run as CSV and JSON on a schedule you set, to a destination you control.

The analysis is yours to run and yours to interpret. A ratio below the guideline is a signal to investigate, not a finding of discrimination, and the reverse is also true: a passing ratio does not validate a process. Both readings need somebody who understands the roles, the applicant pools and the criteria, which is not a report and not a vendor.

Record-keeping obligations run to defined periods after the application or the personnel action, and for federal contractors they run further, covering the requisition, the applicant pool, the criteria and the reasons for selection. The practical requirement is that the record survives, unaltered, for longer than the memory of the people involved.

Retention windows for application records are configured separately from candidate-relationship retention, because the two clocks answer different obligations. Deleting an application record on a marketing-driven data-minimisation schedule can destroy exactly what a later inquiry needs, and that mistake is easier to make than it sounds.

The audit trail is append-only: stage changes, disposition codes, scorecards, who did what and when, retained with the application rather than with the candidate profile. Where an erasure request touches a candidate whose application record sits under a retention obligation, the workflow separates what can go from what must stay and produces a summary of the exception rather than silently keeping everything.

Some jurisdictions add rules specifically about automated employment decision tools. New York City's regime is the most cited: where a tool is in scope it requires an independent bias audit and notice to candidates. The product records which candidates were scored and exports the data such an audit needs. Commissioning the audit and issuing the notice remain yours.

That split is not a technicality. An audit is independent precisely because the vendor does not run it, and notice is given by the employer or agency because that is who the candidate is dealing with. A vendor claiming to have handled either has misunderstood what the obligation is for.

Whether a given configuration is in scope depends on how your firm uses scoring, and that determination belongs to counsel. The product's contribution is to make the underlying data available so the determination and, if needed, the audit can happen at all.