Defining the role

The problem it solves

Requirements nobody wrote down get weighted differently by everyone. One interviewer treats distributed systems as the whole job, another treats it as nice-to-have, and the disagreement only surfaces in the debrief — as an argument about a candidate rather than about the role. A rubric written before anyone applies turns that argument into a decision made once, in advance, by the people who own the role.

Everything downstream reads this rubric. The résumé scorer scores against it, the AI interviewer probes it, the transcript scorer measures against it, the coverage gate counts it, and the automatic decision applies thresholds to the number it produces. A vague rubric produces vague everything.

How it works

Drafting the prose

A recruiter can type a role, paste a messy job description and ask for it to be tightened, or talk it through with a voice assistant. The drafting assistant is grounded in the company's own website — its product, market and stage — so the brief reads like the company wrote it rather than like generic filler. It returns a proposed title and a role brief in plain text, which fills in the form for a person to edit. It also fills in what it has learned: location, employment type, work mode, the country (read from the location: "Austin" is US, "Remote — US" is US), seniority, years and languages. It asks for those before it offers the rubric, a few related ones at a time. The four yes/no facts (visa sponsorship, travel, shift work, relocation) start as "Not stated", and it asks about one only when the role makes it a real question. A job description pasted straight into the form is read the same way before the rubric is written, and a voice call's details reach the form when the call ends.

The draft is saved as you go: the brief when the assistant writes it, then the rubric, details, thresholds and facts as soon as the rubric exists. Leaving the page with unsaved changes asks first.

Drafting is deliberately separate from the rubric engine. The assistant produces prose a human edits; a second step turns that prose into scored criteria. Keeping them apart means a recruiter can rewrite the brief without fighting a rubric that has already been generated from an earlier draft.

If the role is talked through rather than typed, a preliminary pass works out what the draft already settles and what it still leaves open, and asks the single question that unlocks the most — so the conversation finishes the role instead of making the recruiter repeat the half they already wrote down.

Generating the rubric

The rubric engine produces two sets of criteria:

• Role criteria — what it takes to succeed in this specific role: core skills, depth, experience, judgement.
• Company criteria — fit with how this company hires, drawn from what its site actually says rather than from culture platitudes.

Each criterion carries a name, a description of what "good" looks like, a weight, and two to four concrete signals an interviewer or an AI screen should listen for.

Weights are a distribution over 100 points: "this criterion is worth 15 of the 100 that decide this hire". Role and company criteria share one budget, because they are competing claims on the same decision — weighting them on separate scales would make "15" mean two different things on one page. The largest criterion absorbs the rounding remainder so the displayed numbers add to exactly 100.

Criteria also carry a kind, and the kind changes how they are treated later: deal-breakers, required skills, preferred skills, competencies, behavioural traits, success signals, certifications, education, and red flags.

A role criterion is a deal-breaker only when the recruiter made it a must-have. The drafting chat and the voice Architect ask what on a résumé, and what in the interview, would rule a candidate out, and test each answer before recording it: hard no or preference, where the line is, whether a résumé can show it, and whether it is about the job at all. Each confirmed one becomes the rubric's must-have for it, and the editor's Must-have checkbox changes them later. Nothing becomes a deal-breaker because of its weight.

Versioning

Editing a rubric appends a new version. It never overwrites the old one.

This matters because an assessment records the rubric version it measured against. A score taken in March is read against March's rubric, not against whatever the rubric says today. Each criterion also carries a stable key, so a criterion that survives an edit keeps its identity and its history — and a criterion that is renamed gets a new key, which is correct, because a renamed criterion measures something else and the next interview genuinely does need to cover it.

The rest of a job's configuration

A job also carries:

• Stages — the pipeline plan for this job, configurable per job. Each stage has a name your team can change and a type the product acts on (screening, interview, offer, hired, rejected), so renaming "Hired" to "Signed" changes nothing about how the stage behaves. A job running three interview rounds reports progress out of three where a job running two reports out of two.
• Who runs each round — the AI interviewer, or one of your interviewers. See Interviewing. A round run by a person is held on video or in person. An in-person round is not recorded, its emails don't say it is, and its invite calls it an in-person interview. Each round starts with the person creating the role as its interviewer.
• Thresholds — two numbers, advance and reject, read at the résumé score and after every scored round. A new job starts at 80 and 65. See Deciding.
• A salary range, shown on hosted postings. Set it under Role details when creating the role, on a draft's job page, or on the edit page.
• A careers page version of the description (optional, on the edit page). Without one, candidates read the brief exactly as written.

The compliance lint

Creating a rubric version, and activating a job, both trigger an advisory scan of the job's description, its rubric criteria and its interview must-probes for language that would be unlawful for a person to write — age proxies, native-speaker demands, citizenship requirements beyond work authorisation, salary-history questions, and so on. It runs deterministic patterns first and then one best-effort model pass for phrasings a pattern cannot anticipate.

It never blocks. A job with findings activates as far as this scan is concerned. An admin can acknowledge a finding with a reason, and the reason is recorded — "we require this licence because the state requires it" is exactly what an auditor asks for. See Compliance.

Four other things do block activation, and none is this scan: the company needs a verified work email on its own domain, the role's facts need a person's confirmation, the role needs both of its numbers set, and it needs a country. All four are reported before the button is pressed rather than as a failure after it.

What the user does

1. Create a role — type it, paste a job description, or talk it through.
2. Read the drafted title and brief, and edit them. This is prose meant to be edited.
3. Generate the rubric, then adjust criteria, descriptions and weights by hand. The weights are the part worth arguing about.
4. Set the job's stages and per-round modality.
5. Set thresholds, or leave them unset so every decision goes to a person.
6. Read the Compliance tab, and either fix the wording or acknowledge the finding with a reason.
7. Activate the job: Save and publish at the end of creation opens the same confirm as the job page's Activate, where you can also keep the role private. If a publishing gate is still open, the job page shows which one instead. Only an owner, admin or recruiter can create a role.

Limits and edge cases

• A generated rubric is a draft, not an answer. It is drawn from the role input and the company's website. If the site is thin, the company criteria are correspondingly thin, and the model is instructed to infer conservatively rather than invent specifics.
• A rubric can be missing entirely. A job with no scoreable rubric produces a neutral score rather than a falsely precise one, and nothing about that candidate can be decided automatically on rubric grounds.
• Two criteria in one rubric can be named similarly enough to collide. The system generates distinct keys rather than silently merging them, but two criteria that mean the same thing are still two claims on the same 100 points.
• The lint's patterns miss things. They are written to avoid false positives — "fluent in English" must pass where "native English speaker" fails — which necessarily lets unusual phrasings through. A bare experience range such as "0 to 2 years" is not read as a cap, because most ranges are lawful. Nothing reads a job's uploaded attachments.
• Nothing validates that a requirement is job-related. That is the employer's duty and cannot be discharged by a vendor. The platform can show that a criterion exists and that it moved a score; it cannot tell you whether requiring it is defensible.
• Activating a job is a person's action. A job drafted automatically from an ATS role stays a draft until someone activates it — and activation is refused until the company has a verified work email and the role's facts have been confirmed by a person.