Inclusive job description optimizer

An inclusive job description optimizer should return a draft that names the flagged phrase, shows where it sat in the original, and proposes a rewrite the talent-brand or TA lead can accept, edit, or discard. If the original is already clean, the draft stays empty. That empty result is a pass, not a failure.

The model does not publish. Greenhouse, Lever, Ashby, and similar ATS tools remain the system of record. Textio and other language tools can sit in the same workflow as a class of checkers. None of them should be treated as the publisher. A TA lead still reviews the draft and hits publish in the ATS.

Quality is traceable. Someone who was not in the room should see which phrase triggered the flag, why it was flagged, and what the replacement is. A rewrite that cannot point to a phrase is invented work, not a quality outcome.

This pass sits in sourcing, before candidates apply. Keep it upstream of a conversational career site agent and a personalized outreach sequence generator. Those tools should not inherit an unreviewed posting.

Start with the live or pending posting as stored, not a remembered version from Slack. Paste the full text: title, team blurb, responsibilities, requirements, nice-to-haves, and the equal-opportunity footer. If the posting lives in Greenhouse, Lever, or Ashby, load that version. Do not load a marketing one-pager and assume it matches the ATS.

Give the model a narrow job: flag phrases that exclude, inflate, or obscure, and cite each one with a short quote from the source. Do not ask it to make the posting convert better. Conversion is a funnel question. The optimizer does not invent a conversion percent and does not take a conversion target as a success metric.

Lock the output shape before you run: flagged phrase copied from the posting; location (section and nearby sentence); reason in one sentence; proposed rewrite of that sentence or bullet, not a full restyle unless the lead asked for it; a remainder that lists what was left untouched. If you skip the remainder, the model restyles the whole posting to look busy. That restyle is a failure even when the new prose sounds friendlier.

Run the flags first. Do not rewrite in the same breath as detection. A two-step pass makes the cites checkable: you find the quote in the original, then you look at the draft sentence.

Treat the cite as a locator. The quote should be long enough to search, short enough that it is one phrase. "Rockstar" in a requirements bullet is a cite. "We move fast" is usually not, unless your style guide flags it. If the model cannot produce a quote that exists in the source, drop the flag.

After flags are listed, generate the draft. Change only the cited spans, plus the minimum glue so the sentence still reads. If three bullets were flagged, three bullets change. The rest stays as the TA lead wrote it.

Then a human publishes. The TA or talent-brand lead compares original, flags, and draft in one view, edits anything that drifted from the role, and publishes in the ATS. Treating the draft as live is a failure mode. Pasting an unreviewed rewrite into Greenhouse, Lever, or Ashby, or pushing it to the career site, skips the quality check this use case exists to provide.

A later hiring decision bias audit looks at decisions, not postings. Structured resume scoring looks at how you score applicants. This optimizer does not replace either. It only cleans the text that starts the funnel.

Take a posting for a senior product manager on a B2B team. The original includes "Must be a native English speaker" in requirements and "Looking for a young, hungry hustler who can live in Slack" in the team blurb. Those two phrases are the whole job for the optimizer.

The first flag cites "Must be a native English speaker." Native-speaker requirements screen for origin and accent, not for the writing and facilitation the role needs. The rewrite: "Written and spoken English sufficient to run stakeholder reviews and write product specs." The second flag cites "young, hungry hustler who can live in Slack." That line is age-coded and stamina-coded, and it does not describe the work. The rewrite: "Comfortable coordinating in Slack and in scheduled reviews; the role includes overlapping time zones."

Everything else stays: degree line, compensation range, product domain, equal-opportunity paragraph. The draft is those two substitutions, shown next to the cites. The TA lead keeps the native-speaker line out, tweaks the Slack line to match how the team works, and publishes.

This is an illustration, not a measured case. There is no lift number and no conversion percent attached to the rewrite. If someone asks what the change did to conversion, the honest answer is that this tool does not measure that. You can look at apply rates later in the ATS. You do not let the model invent one.

If the posting has no phrase that meets your flag list, the optimizer returns empty: no flags, no rewrite, original stands. Do not prompt the model to always suggest three improvements. That instruction produces a rewrite with no flagged phrase.

A rewrite with no cite is unverifiable. You cannot tell whether the model reacted to a real issue or to a habit of sounding helpful. Invented work looks like swapping "we" for "you," adding a culture paragraph, or restating requirements as "you will." None of that is the outcome. Quality is a cited pair or a blank.

When empty comes back, the TA lead still publishes, or schedules publish, from the original. They do not hunt for a draft that was never warranted. If they disagree with empty, they add a phrase to the flag list (for example, a degree that is not required) and run again. They do not ask the model to justify a rewrite after the fact.

Textio-class language checkers and ATS-native helpers can disagree with empty. Treat disagreement as a second opinion to reconcile, not as a reason to auto-accept the more aggressive draft. The cite still has to exist in your posting.

Keep a human on the publish path. The optimizer can sit as a step before posting in Greenhouse, Lever, or Ashby, or as a document the talent-brand lead comments on. It cannot own the live URL.

Before publish, confirm every changed sentence has a cite that still matches the original; no conversion percent, applicant forecast, or "this will attract a broader pool" claim appears in the draft or the notes; empty drafts stayed empty; role facts (level, location, pay, visa, on-call) were not invented; the career-site version will match the ATS after publish.

If the rewrite softened a requirement the hiring manager still means, the lead puts the requirement back in plainer language rather than dropping the flag. The pass is inclusive, readable language for the work as it is, not a different job.

Stop when the cited draft is accepted or when empty is accepted. Do not keep regenerating until the posting sounds more modern. That loop is how uncited rewrites sneak in. Publish, then move to sourcing work that uses the live posting, with the same human still accountable for what candidates read.