Turn a job description into a requirements checklist by extracting each stated requirement, retaining the employer’s exact wording and asking the employer to confirm its purpose, timing and acceptable evidence. Separate mandatory requirements, preferences, possible development needs and unresolved questions. Approve the checklist before using it to review candidates.
By Sopact Academy · Updated September 12, 2026. Role descriptions, records and numbers below are fictional teaching examples.
Make the role clear before reviewing people
Bring: one current role description, its owner and proposed start date.
Leave with: a versioned checklist that a coordinator can apply and an employer can correct.
This begins the placement track of the Case Intelligence course. The participant records built in earlier lessons describe the available evidence; this lesson defines the opportunity those records may be considered against. The related lesson covers candidate–role review.
Build and test the checklist in six steps
- Define the source, status, evidence and timing fields.
- Extract the description and resolve ambiguity with the employer.
- Separate mandatory requirements from development options.
- Refer potentially inappropriate criteria for responsible review.
- Save the approved version with the working records.
- Use current requirements to investigate unfilled demand.
Why the checklist needs more than keyword extraction
A description may mix essential duties, preferences, benefits and copied text. “Training provided” can sit beside a credential marked “required.” A license may be needed to drive during work, or it may simply be an imprecise way of asking whether someone can reach the site. Those differences affect the review.
AI can help locate wording, but it cannot settle an employer’s intention from an ambiguous sentence. A checklist is useful because it makes those questions visible before a candidate is assessed. The source statement and the approved interpretation should remain separate fields.
For workforce and placement teams, the result should also support a conversation about development. Some skills can be learned before work starts or through agreed employer training. Others need a different pathway or more time. Do not turn “we could train this” into a promise until the provider, schedule, funding and candidate’s interest are confirmed.
Step 1 — Define the information each requirement needs
Start with the employer and requisition identifiers, description version, location, relevant dates and role owner. Give each requirement its own identifier so a later change does not silently replace the rule used in an earlier review.
| Field | What to record | Why it matters |
|---|---|---|
| Source wording | Exact passage and description version | Lets the employer and reviewer inspect the original meaning |
| Requirement type | Duty, skill, credential, license, schedule, location or another justified category | Keeps unlike information separate |
| Employer-confirmed status | Mandatory at the stated point, preferred, or clarification needed | Extraction is not approval |
| Evidence accepted | Document, relevant work sample, structured discussion or other agreed method | Candidates should know how they can demonstrate the requirement |
| Timing | Application, start date, after starting or a specific deadline | A start-date requirement is different from a preference |
| Development option | Training route, availability, cost owner and confirmation status | A possible route is not a completed qualification |
| Review record | Owner, approval date, rationale and superseded version | Supports correction and consistent review |
Use a small, understandable set of categories, but do not force every role into five fixed fields. A recurring requirement outside the schema may justify an addition. A one-off ambiguity may only need a clarification note. Test whether the added field changes a real decision before collecting it everywhere.
Step 2 — Parse the description, then resolve ambiguity
Read one description manually first. Highlight each requirement and record what the text actually says. Do not infer a qualification from a job title or turn a preferred skill into a mandatory one. Ask the employer to review both the extracted list and the items the parser might have missed.
Using only this role description, extract each stated requirement and its exact supporting passage. Return requirement ID, category, stated status, timing and any ambiguity. Do not invent a mandatory condition or infer that a preference is disqualifying. Keep duties and working conditions visible. List clarification questions for the employer. Do not approve requirements, assess candidates or make legal conclusions.
Suppose the employer says: “Workshop trainee, proposed start November 15. Read basic diagrams. Safety orientation provided after starting. OSHA 30 preferred. Some driving between sites may be needed.” The word “may” is a question to resolve, not an automatic license gate.
| Fictional source wording | Initial extraction | Question before approval |
|---|---|---|
| “Read basic diagrams” | Skill mentioned; level unspecified | Which diagrams and tasks? What evidence shows the required starting level? |
| “Safety orientation provided after starting” | Employer-provided induction | Who delivers it, when, and what can the employee do before completion? |
| “OSHA 30 preferred” | Preference, not a confirmed mandatory prerequisite | Which industry course is relevant? Is a completion card required for this site or simply preferred? |
| “Some driving between sites may be needed” | Potential duty requiring clarification | Is driving essential, how often, and is another arrangement available? |
| “Proposed start November 15” | Proposed date | Is the date fixed, and which requirements must be met by then? |
This example deliberately leaves questions unresolved. A parser that supplies confident answers would make the checklist look complete while hiding uncertainty. “Clarification needed” is a useful state that prevents unsupported rules from entering the review process.
Step 3 — Separate requirement status from development timing
A simple hard-versus-coachable flag mixes two decisions: whether the employer requires something and whether a person could develop it in time. Store those decisions separately. A preferred skill remains a preference even if it cannot be learned before the start date.
For a confirmed mandatory requirement, record when it must be satisfied and which alternatives the employer accepts. If a candidate needs development, discuss the route and constraints without promising completion. An available course seat, transport, assessment date and employer acceptance all matter; a guessed two-week timeline is not enough.
OSHA explains that its Outreach courses provide training completion cards, not certifications, and do not replace training required by specific OSHA standards. Describe the credential accurately and verify the employer’s actual requirement rather than treating “OSHA 30” as a universal screening rule.
Step 4 — Review potentially inappropriate requirements
Employer wording is evidence of what was written, not proof that a criterion is appropriate. Escalate broad phrases such as “clean background” or “citizens only” to the employer’s responsible reviewer. Do not let an AI convert them into automatic rejection instructions.
For US recruitment, the Department of Justice’s hiring guidance distinguishes work authorization from citizenship and describes limited grounds for citizenship restrictions. Do not use citizenship or an inferred immigration status as a weighted preference.
Likewise, keep physical duties visible instead of deleting them as “not requirements.” Their relevance and the appropriate accommodation process need review. The EEOC’s AI and disability resources address how automated tools can screen out qualified people. A checklist should support a fair process, not make disability or accommodation decisions.
These sources address US employment. Fellowship, host-site and other opportunity settings may have different rules and responsibilities. Reuse the record structure where useful, but review the criteria and process for that setting.
Step 5 — Connect approved requirements to the working records
Keep the role record linked to its employer, source description, approved checklist and later revisions. Participant evidence belongs to the participant and enrollment record. The candidate–role review is a separate relationship between them, with its own date and reviewer.
In a configured Sopact workflow, new descriptions and documents can be collected, structured against a defined schema and linked to those records. Use the resulting draft to find missing or conflicting information. Approval remains a distinct step; saving a description should not silently approve its requirements or reject candidates.
When the employer revises a requirement, compare the versions. Identify affected reviews and decide which need reconsideration. Preserve the original decision record and its rule version. Reprocessing data can be useful, but overwriting earlier conclusions would remove the history needed to explain them.
Step 6 — Use the checklist to investigate unfilled demand
Structured role data lets a placement team ask more precise questions. Count open roles separately from available participants and candidate–role pairs. Check whether a role is current and whether candidates remain available before describing a shortage or surplus.
| Review question | Evidence to compare | Possible next step |
|---|---|---|
| Which requirements are repeatedly unclear? | Employer-confirmation status across current descriptions | Improve the employer intake form or clarification process |
| Which development routes could help? | Approved requirements, provider availability and participant preferences | Explore a training option; confirm demand before adding a program |
| Why are roles still open? | Employer updates, candidate interest, pay, location, schedule and review history | Investigate competing explanations; do not assume a skill shortage |
| Do we have more prepared participants than relevant roles? | Distinct available participants and suitable, current openings | Discuss employer development and participant options before changing intake |
A fill-difficulty score is only useful if its definition and evidence are clear. An absence of a credential in your database may mean the credential was not collected, rather than that nobody has it. Pay, working hours, geography and participant preferences can explain an unfilled role even when skills match. Start with an evidence checklist before inventing a predictive score.
Common mistakes to catch in the pilot
- Treating extraction as employer approval. Keep the source and confirmed interpretation separate.
- Calling every missing item a failure. Distinguish missing evidence, an unmet requirement and a preference.
- Promising a training timeline. Confirm the practical route and whether it is accepted.
- Hiding a rule change. Save versions and identify affected reviews.
- Ignoring participant choice. A role that looks suitable on paper may not fit the person’s goals or circumstances.
Watch the wider training-to-placement workflow
4 minutes 13 seconds · Sopact demonstration using synthetic training records.
▶ Play: Training Program Data
Exercise: approve one role before using it
Choose one open role. Have two coordinators extract its requirements independently. Compare what they omitted, inferred or classified differently. Send unresolved questions to the employer and record the answers alongside the source wording.
Then ask a colleague to use the approved checklist without your help. Can they identify the evidence needed, the timing and who owns a clarification? Test one changed requirement and confirm that earlier reviews remain visible. Only then extend the process to more roles.
Frequently asked questions
What belongs in a job requirements checklist?
The requirement, source passage, employer-confirmed status, timing, accepted evidence and review owner. Keep the role and description version identifiable. Include development options as separately confirmed information, not as inferred promises.
Does “required” always mean an automatic rejection?
No. Confirm what the employer means, when it is required and which equivalent evidence or arrangements are accepted. Resolve inappropriate or ambiguous criteria through the responsible process. A parser should not make that decision.
How should missing candidate evidence be handled?
Mark it unknown or awaiting evidence. That is different from a confirmed unmet requirement. The related lesson explains how to preserve this distinction in candidate–role review.
Can AI estimate whether a role will be hard to fill?
It can summarize documented gaps and patterns for review. Any difficulty estimate needs a defined population, current data and validation. It should not be presented as a proven prediction simply because the software produces a score.
What should happen when an employer changes a requirement?
Save a new version, record the change and identify affected reviews. Decide which need reconsideration and communicate through the agreed process. Do not overwrite the evidence and criteria behind an earlier decision.
Related placement practice: review candidate–role matches with a clear rubric.