Collect equal-opportunity data without letting it touch the decision

The demographic questions on an application 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. The application record and the demographic record are linked by an identifier used only for aggregate reporting. There is no view anywhere in the product that puts a candidate's name beside their demographic answers, and there is no export that produces one.

Categories 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 that nobody asked you to collect.

Surhires scores candidates against requisitions, drafts outreach and parses resumes using models. The rule that governs those features is absolute: demographic data is never included in a prompt, a feature vector, an embedding, a training set or a fine-tune. The payload assembled for any model call is built from an allow-list of fields, and the demographic table is not on the list and cannot be added to it 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. We reduce the obvious surface by excluding images from the parsing payload and by keeping match explanations at field level, so you see which requirement drove each point rather than being handed a number. We cannot promise that a model infers nothing.

That is precisely 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 no scoring system at all, 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 it, 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. Immutable stage history, plus a coded reason, plus the scorecard behind it, reconstructs what happened at the time it happened, rather than requiring somebody to reconstruct it from memory two years later in front of an audience who was not there.

Adverse impact is a calculation rather than an opinion: the selection rate of one group set against the selection rate of the group with the highest rate. The calculation needs applicant counts and selection counts by stage, by requisition and by group. Most systems cannot produce them, because the disposition data was free text and the demographic data was never cleanly separated in the first place.

The reporting surface exports exactly those counts, in aggregate, from the separated table. 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 product computes and exports. It does not interpret. What a given ratio means for your organisation, what threshold you treat as a signal worth acting on, and what you do when you see one are decisions for you and your counsel, and a vendor that offers to make them for you is selling something it cannot deliver.

Where an automated employment decision tool is in scope, the product records which candidates were scored and exports the data an independent bias audit needs. Commissioning the audit and issuing candidate notice remain yours. That division is not us being cautious; it is what the obligation actually looks like, and a vendor cannot hold it for you.

In practice the export carries the score, the requisition, the date, the version of the tool that produced it, and the separated demographic categories joined only in aggregate. Your auditor receives a dataset they can work with rather than a set of screenshots and an assurance.

The notice a candidate may be entitled to before a tool is used, the timing of that notice, and the publication of an audit summary are actions you take. The product can store the text and send it on the schedule you set. It cannot decide that the requirement applies to your process.

Reporting obligations usually come with a record-keeping period, and it is a different clock from the retention window on the candidate relationship. An application, its coded disposition, its scorecards and its stage history are retained for the period configured on the tenant, independently of whether the candidate record itself is still active or has been erased at the candidate's request.

The two clocks are kept apart deliberately, because a candidate exercising a data right and an employer holding an application record for a statutory period are different questions with different answers. Collapsing them into one setting is how organisations end up either deleting records they were required to keep or keeping records they had no reason to hold.

When both apply to the same person, the product says which one governed which part of the record, and the erasure summary shows it. Silence at that moment is the thing that turns a routine request into a complaint.