8- How to Turn a Job Description into a Requirements Checklist

For: workforce and placement teams who match trained candidates to open roles — and inherit every job description as a paragraph of prose.

Why: a job description is a free-text blob, so matching against it is manual keyword guesswork — slow, inconsistent between coordinators, and a place where bias hides because the reasons a candidate was passed over are never written down.

Outcome: every requisition parsed on arrival into a structured requirements checklist, each item flagged HARD (disqualifying) or COACHABLE (trainable before the start date), each role scored for fill-difficulty — the input that makes the next chapter’s matching fair, fast, and auditable.

This is Chapter 8 of the Case Intelligence series — and the first chapter on the demand side. In the previous chapter you computed a live, sourced SROI over the supply-side stores — every chapter so far has been about participants: who applied, what they started from, how they changed, what that change is worth. But placement is a two-sided market, and the running example — RiseWorks Foundation / Pathways 2027 (Train → Match → Place → Earn) — tracks the other side in two stores of its own: Employer Accounts and Job Requisitions, joined to the rest of the workspace by the same reference-key discipline (employer_name, requisition_id) that joins everything else. The checklist this chapter builds is what later lets the series name the demand gap precisely: 25 unfilled requisitions — clustered on citizen-only work authorization and CDL hard fails — sitting across from 29 surplus credentialed candidates. Neither number is visible while requirements live in prose.

As always, the steps are tagged [DIY] or [SENSE], and the split is honest. Designing the requirement schema and extracting one job description by hand are thinking work — any capable AI can help you do both this week, and the first two steps hand you the prompts. Extracting every requisition the moment it arrives, and lining all of them up against a credentialed candidate pool, is what the product does over the stores — a standalone prompt cannot parse a requisition it never receives, and it cannot see the pool the requirements have to be compared against.

A job description is prose — and prose can’t be matched

Here is how a requisition arrives: a paragraph. “Seeking a welding apprentice, must be authorized to work in the US, valid driver’s license required, OSHA 30 preferred, able to lift 50 lbs, start by November 15.” A coordinator reads it, forms a rough mental picture, and eyeballs candidates against the picture. In most placement operations, that is the entire matching process, and it fails three ways:

It is slow. Every role gets re-read from scratch every time a candidate is considered. Twenty candidates against one role means twenty re-readings of the same paragraph — and the paragraph never gets easier.

It is inconsistent. Two coordinators read the same blob and weigh “OSHA 30 preferred” differently: one treats it as a dealbreaker, one ignores it. The same candidate is qualified on Tuesday with one coordinator and unqualified on Wednesday with another, and nobody can say why.

It is where bias hides. When requirements live in someone’s head, the reasons a candidate was passed over are never written down — so they can never be audited. “Not a fit” is the phrase that ends the conversation and erases the evidence.

Traditional case-management systems — the Salesforce-and-Apricot category — make this permanent, because they store the job description as exactly what it arrived as: a free-text field. There is nowhere to put a structured requirement, so matching stays manual, and the JD field becomes the least-used data in the system. Sopact Sense treats the requirements text the way earlier chapters treated a barrier answer or a mentor note: as unstructured evidence to be structured on arrival. An Intelligent Cell reads the free-text requirements the moment a requisition lands and writes a structured checklist back to the row. And the schema is adaptive the same way the Chapter 2 rubric was: tune it on your first five or ten requisitions, and everything already in the store re-extracts against the fixed schema — early requisitions and late ones structured identically.

Hard versus coachable — the split that keeps matching humane

One design decision does most of this chapter’s work: every extracted requirement gets one of two flags.

HARD means disqualifying — no amount of coaching before the start date can satisfy it. Citizen-only work authorization cannot be coached. A CDL the program does not train for cannot be earned by a start date three weeks out. A strict background requirement is a wall, not a gap.

COACHABLE means trainable in time. A missing OSHA 30 that can be earned in about two weeks is not a rejection — it is a two-week plan, provided the start date allows it.

The split matters in both directions. Downstream, it is what makes matching humane: a candidate missing only coachable requirements is a near-match with a plan attached, not a “no.” And in aggregate, it is what makes the demand gap diagnosable — when 25 requisitions go unfilled, the question that matters is which hard requirement blocked them, because the answer tells you what to recruit or train for next. A pile of prose can never answer that question. A store of flagged checklists answers it in one query.

Step 1 — Design the requirement schema [DIY]

What you do. Decide, once, the fixed set of categories every job requirement falls into — and write the single rule that classifies any requirement as HARD or COACHABLE. This is a design decision you make by hand, with Prompt 1 in any AI chat window. You do not re-derive it per role; the whole point is that every requisition gets structured the same way.

What you get. A small fixed schema — categories with their typical values — plus one classification rule that applies mechanically to every requirement in every future requisition.

Why it matters. The schema is what turns prose into comparable data. Without fixed categories, every extraction is ad hoc and nothing lines up across roles or against the candidate pool. Keep it small: a schema that grows a new category for every unusual role stops being a schema and becomes prose with extra steps.

Real example — RiseWorks. Five categories, drawn from the free-text requirements field on its real requisitions:

And the one rule: a requirement is HARD if no coaching before the deadline can satisfy it; otherwise it is COACHABLE. Notice the rule is relative to the deadline, not to the requirement alone — the same missing certification is coachable against a start date six weeks out and hard against one next Monday. That relativity is why the deadline is a schema category, not a footnote.

Prompt 1: Requirement Schema Designer

PROMPT 1 — REQUIREMENT SCHEMA DESIGNER   [DIY]
Use in: any capable AI (Claude, ChatGPT). You design this once, by hand —
the schema stays fixed so every role is structured the same way.
Purpose: define the fixed categories every job requirement falls into,
plus the one rule that classifies any requirement HARD or COACHABLE.

------------------------------------------------------------
You are designing a requirement schema for job descriptions. Your
output must be deterministic: the same input must give the same output
every run.

TASK
From my description of the roles I place for, produce a fixed
requirement schema.

RULES (apply mechanically, no exceptions)
1. Start from exactly these five base categories:
  credential, license, work authorization, background, deadline.
2. Add a category ONLY if my roles contain a recurring requirement none
  of the five can hold. For each added category, quote the requirement
  from my input that forced it. Never add a category speculatively.
3. For each category, list the typical VALUES as a closed set
  (e.g. license: None / Valid / CDL-A / CDL-B).
4. State the classification rule verbatim:
  "A requirement is HARD if no coaching before the deadline can
  satisfy it; otherwise it is COACHABLE."
  Then list, for my roles, which category values are structurally HARD
  (e.g. citizen-only work authorization; a CDL we do not train for;
  strict background) and which are typically COACHABLE (e.g. a cert
  earnable in ~2 weeks).
5. Physical working conditions (e.g. "lift 50 lbs") are NOT match
  requirements — list them separately as disclosures, not categories.
6. Do not invent role types, credentials, or values I did not provide.

OUTPUT FORMAT
1. Category table: Category | Closed value set | Typically HARD or COACHABLE.
2. The classification rule, verbatim.
3. Disclosures list (working conditions excluded from matching).
4. One closing line: "Categories added beyond the base five: N".

------------------------------------------------------------
ROLES I PLACE FOR (tracks, typical employers, typical requirements):
<<< describe here >>>

WHAT MY PROGRAM CAN TRAIN OR COACH, AND HOW FAST:
<<< e.g. OSHA 30 in ~2 weeks; we do not train CDL >>>
------------------------------------------------------------

WORKED REFERENCE (RiseWorks Foundation / Pathways 2027):
five categories — credential (AWS D1.1, CompTIA Security+, CNA license,
NIMS Machining I), license (None / Valid / CDL-A / CDL-B), work
authorization (US citizen / permanent resident / work-authorized),
background (standard / strict / second-chance), deadline (start-by
date). Structurally HARD: citizen-only, CDL (not trained), strict
background. Typically COACHABLE: OSHA 30 (~2 weeks).

Step 2 — Extract one job description by hand [DIY]

What you do. Take one real open role and parse its free-text requirements into the schema yourself, with Prompt 2 — every requirement into a category, every item flagged HARD or COACHABLE, the deadline noted. One role, by hand, before anything runs at scale.

What you get. One requisition turned from a paragraph into a checklist — and a verdict on the schema itself. If a real requirement does not fit any category, you have found a schema problem on one role instead of after a hundred extractions.

Why it matters. This is the calibration step, the same move as scoring one application in Chapter 2 before trusting the rubric with the pool. The extraction is only as good as the schema, and the schema is only proven by a real role.

Here is a real one. A RiseWorks requisition, exactly as the free text arrives:

“MIG Welder Apprentice — regional fabrication shop. Must be authorized to work in the US. Valid driver’s license required (no CDL). AWS D1.1 certification required; OSHA 30 preferred but we’ll train. Clean background for site access. Able to lift 50 lbs, stand 8 hours. Start by Nov 15.”

Parsed into the schema:

Read the OSHA 30 line closely, because it is where hand extraction earns its keep: the prose says “preferred but we’ll train,” and the flag says COACHABLE. A coordinator in a hurry reads “OSHA 30” and rejects a candidate who could have been ready in two weeks. The checklist cannot make that mistake, because the employer’s own words are attached to the flag.

Prompt 2: Extract One JD

PROMPT 2 — EXTRACT ONE JD   [DIY]
Use in: any capable AI (Claude, ChatGPT). Validate the schema on one
real role before anything runs at scale.
Purpose: parse a single job description into a requirements checklist,
deterministically, with the employer's own wording as evidence.

------------------------------------------------------------
You are parsing one job description into a requirements checklist.
Your output must be deterministic: the same input must give the same
output every run.

TASK
Extract every requirement from the job description below into my
schema, flag each HARD or COACHABLE, and check the deadline.

RULES (apply mechanically, no exceptions)
1. Use only my schema categories (credential, license, work
  authorization, background, deadline, plus any I added). Do not
  create categories mid-extraction.
2. Flag by the rule, not by the employer's word choice:
  - HARD      — no coaching before the deadline can satisfy it
    (given my training capabilities below).
  - COACHABLE — trainable before the deadline, given my training
    capabilities and the start-by date.
  "Required" in the prose does not automatically mean HARD, and
  "preferred" does not automatically mean COACHABLE — apply the rule.
3. Quote the employer's exact phrase for every extracted requirement.
  Every flag must carry its evidence.
4. For each COACHABLE flag, state the estimated time-to-close and
  whether the deadline allows it. If the deadline does not allow it,
  re-flag it HARD and say why.
5. Physical working conditions (e.g. "lift 50 lbs, stand 8 hours") go
  to a separate Disclosures line — never flagged, never scored.
6. If a requirement fits no category, output it under SCHEMA GAP —
  that means my schema needs a fix before I trust it at scale.
7. Do not invent requirements, certifications, or dates not present in
  the text.

OUTPUT FORMAT
Checklist table: Requirement | Category | Flag (HARD / COACHABLE) | Employer's phrase | Note
Then: Deadline line (start-by date + which coachable gaps it gates).
Then: Disclosures line.
Then: "SCHEMA GAPS: N" (with the unfitted requirements, if any).

------------------------------------------------------------
MY SCHEMA (output of Prompt 1):
<<< paste it here >>>

WHAT MY PROGRAM CAN TRAIN OR COACH, AND HOW FAST:
<<< paste it here >>>

JOB DESCRIPTION (one role, as the employer sent it):
<<< paste one here >>>
------------------------------------------------------------

WORKED REFERENCE (RiseWorks — MIG Welder Apprentice, start Nov 15):
AWS D1.1 -> Credential, HARD ("AWS D1.1 certification required").
Valid license, no CDL -> License, HARD (common in pool).
Work-authorized -> Work authorization, HARD, widely met.
Clean background -> Background, HARD ("for site access").
OSHA 30 -> Additional cert, COACHABLE ("preferred but we'll train",
~2 weeks, Nov 15 deadline allows).
Disclosures: lift 50 lbs, stand 8 hours.

Step 3 — Extract every requisition on arrival [SENSE]

From here on, this is product output, not a prompt you run. A chat prompt parses the one JD you paste into it; Sense holds the Job Requisitions store, so the extraction fires on every requisition as it lands — the first employer’s role and the fortieth structured against the identical schema, with nobody pasting anything. And a standalone prompt could not compute the one field that makes this step more than data entry: fill-difficulty requires knowing what the credentialed candidate pool looks like, and a chat window has never seen that pool.

Here is how it runs. An Intelligent Cell sits on the free-text requirements field of the Job Requisitions store. The moment a requisition arrives — keyed to its employer by employer_name, carrying its requisition_id — the Cell parses the prose into the five schema fields, flags each requirement HARD or COACHABLE against the start-by date, and computes a fill-difficulty score from how many of the hard requirements are rare in the credentialed pool. An Intelligent Row then assembles the requisition brief — the one-glance answer to “what does it actually take to fill this role?” Here are two real ones, side by side:

The welder brief reads back in one sentence: “To fill this you need AWS D1.1, a valid license, work authorization, a clean background, and availability by Nov 15 — OSHA 30 is trainable in time.” The SOC analyst brief carries a different message, and it carries it the day the requisition lands: this role will be hard to fill from this pool, and everyone knows it before a single candidate is proposed — not after six weeks of quiet failure. That early warning is the fill-difficulty score doing its work.

The tuning loop from Chapter 2 applies here unchanged. When RiseWorks adjusted the hard-versus-coachable rule after its first handful of requisitions — deciding, for instance, how to treat “preferred” certifications with no training offer attached — every requisition already in the store re-extracted against the revised rule. In a traditional system, that revision would apply only to roles nobody had read yet.

One setup detail that pays off daily, same as the supply side: in the store’s table view, move the Intelligent Cell and Row columns to the front — fill-difficulty, hard requirements, and the brief first, the raw JD text after. The requisition store reads like a placement queue, not a filing cabinet.

Prompt 3 — Requirement Extraction on Arrival

PROMPT 3 — REQUIREMENT EXTRACTION ON ARRIVAL   [SENSE]
This is product configuration — it runs on arrival in Sopact Sense, not
in a chat window. A standalone prompt cannot do this: it never receives
the requisitions, and it cannot compute fill-difficulty because it has
never seen the credentialed candidate pool the requirements must be
compared against.

WHERE IT SITS
One Intelligent Cell on the free-text requirements field of the Job
Requisitions store, plus one Intelligent Row that assembles the
requisition brief. Requisitions arrive keyed by employer_name (joining
the Employer Accounts store) and requisition_id (joining forward to
Placements).

CELL — on the free-text requirements field (Job Requisitions store)
Instruction: "The moment a requisition arrives, parse its requirements
text into the fixed schema fields: credential, license, work
authorization, background, deadline, plus additional certs. Flag each
requirement HARD (no coaching before the start-by date can satisfy it)
or COACHABLE (trainable in time, given the program's training list).
Quote the employer's exact phrase next to every flag. Route physical
working conditions to a disclosures field — never flag or score them.
Then compute FILL-DIFFICULTY from how many HARD requirements are rare
in the credentialed candidate pool (citizen-only and CDL score high).
Write the structured checklist, flags, and fill-difficulty back to the
requisition row. If a requirement fits no schema field, write SCHEMA
GAP instead of forcing it."

ROW — REQUISITION BRIEF (assembly spec)
Assemble per requisition:
 1. One-sentence brief: "To fill this you need <hard requirements>,
    available by <deadline> — <coachable items> trainable in time."
 2. The full checklist with flags and employer phrases.
 3. Fill-difficulty with its reason (which hard requirement is rare
    in the pool).

SAMPLE RETURN (real requisitions):
 MIG Welder Apprentice (start Nov 15)
   Brief: "To fill this you need AWS D1.1, a valid license, work
   authorization, and a clean background, available by Nov 15 —
   OSHA 30 trainable in time."
   Fill-difficulty: MODERATE — hard requirements common among
   credentialed candidates.
 Junior SOC Analyst (US citizen, active clearance eligible)
   Fill-difficulty: HIGH — citizen-only is a hard requirement most of
   the pool cannot meet. Flagged the day it lands, before a single
   candidate is proposed.

THE ADAPTIVE LOOP
Tune the hard-vs-coachable rule on the first 5–10 requisitions (e.g.
how to treat "preferred" certs with no training offer). Every
requisition already in the store re-extracts against the revised rule —
early and late roles structured identically.

Step 4 — Surface the supply/demand gap [SENSE]

The second thing no standalone prompt can do: line up every open requisition against every credentialed candidate at once. This is the Sopact Assistant (with the Claude MCP connection) working across the stores — Job Requisitions on one side, the credentialed pool from the Exit store on the other, joined through the same workspace. Asked where demand and supply miss each other, it returns a pattern, not a pile:

Sit with what that table is and is not saying. It is not saying the program trained people badly — the 29 surplus candidates are credentialed; they did everything asked of them. It is saying the demand side and the supply side are misaligned on two named, structural requirements, and it names the fix on each side: a recruiting change and a curriculum decision on one, an employer-development push and an intake decision on the other. That is a strategy conversation with evidence in it. Without structured requirements, the same reality shows up as 25 individual disappointments and 29 individual frustrations, and the pattern connecting them is invisible — which is exactly how it stays unfixed for years.

This table is also the payoff the previous chapter promised. Chapter 7’s funnel showed 29 credentialed candidates between “58 credentialed” and “29 placed” with no placement to show for it. Now those candidates have an explanation that traces to specific hard requirements on specific requisitions — and the next chapter turns this checklist and that pool into candidate-by-role match scores.

Run it yourself: Prompt 4 — Gap Surfacer

PROMPT 4 — GAP SURFACER   [SENSE]
Run this in the Sopact Sense Assistant over your store. It works
because the Assistant (with the Claude MCP connection) reads across the
joined stores — Job Requisitions on the demand side, the credentialed
pool from Exit/Completion on the supply side — which no standalone
prompt can see.

ASSISTANT PROMPT
------------------------------------------------------------
Across all open requisitions and the credentialed candidate pool:
1. Show which requirements leave roles UNFILLED — cluster the unfilled
  requisitions by the HARD requirement that blocks them, and name the
  requirement, not the individual roles.
2. Show where candidates are SURPLUS — tracks with more credentialed
  candidates than open requisitions this quarter.
3. Translate each cluster into the action it implies: recruit or train
  for the blocking requirement on the demand side; open new employer
  demand or throttle intake on the supply side.
4. Keep it a pattern, not a list of individual failures — no
  candidate-level or employer-level blame.
------------------------------------------------------------

WHAT IT RETURNS (RiseWorks Foundation / Pathways 2027, real numbers):
 UNFILLED DEMAND
   25 requisitions unfilled — clustered on two hard requirements:
   citizen-only work authorization (defense and cleared roles) and
   CDL licenses the program does not train for.
   Action: recruit citizens for cleared-role tracks; evaluate adding
   a CDL track.
 SURPLUS SUPPLY
   29 credentialed candidates surplus — more welders and CNAs than
   open welding and CNA requisitions this quarter.
   Action: open new employer demand for those tracks; throttle intake
   until demand catches up.

READ IT RIGHT
The 29 surplus candidates are credentialed — they did everything asked
of them. The gap is a matching and eligibility pattern, not a training
failure, and each half points at a specific decision. This is also the
explanation behind Chapter 7's funnel: the candidates between
"58 credentialed" and "29 placed" now trace to named hard requirements
on named requisitions.

WHY A CHAT PROMPT CAN'T DO THIS
A standalone prompt sees one JD at a time. It has no requisition store,
no credentialed pool, and no joins — so it can parse prose, but it can
never tell you which requirements systematically block fills or where
supply outruns demand. The Assistant answers over the stores, in
seconds, and the answer updates as requisitions and credentials land.

Common mistakes (and what to do instead)

Treating every “required” in the prose as HARD. Employers write “required” loosely — the MIG welder req says OSHA 30 is “preferred but we’ll train.” Flag by the rule (can coaching close it before the deadline?), not by the employer’s word choice, and keep the employer’s phrase attached as evidence.

Classifying without the deadline. Coachable is a race against the start-by date, not a property of the requirement. The same missing certificate is COACHABLE in September and HARD on November 10. If your checklist has no deadline field, every coachable flag on it is a guess.

Letting the schema grow a category per role. Five categories that hold ninety-five percent of requirements beat fourteen categories that each hold one. When a requirement does not fit, first ask whether it is really a requirement — “able to lift 50 lbs” is a working condition to disclose, not a match criterion to score.

Rejecting candidates for coachable gaps. The split exists so that a two-week gap becomes a two-week plan. If your process treats COACHABLE flags as soft rejections, you have rebuilt the old bias with better paperwork — route coachable gaps to training, and save the “no” for hard fails.

Skipping the employer join. A requisition with no employer_name and no requisition_id is an orphan — it can never reconcile with the Placements store, so you can never learn which employers’ roles fill and which stall. The reference keys are not bureaucracy; they are why the 25-unfilled pattern is computable at all.

What you have now

A fixed five-category requirement schema with one mechanical hard-versus-coachable rule. Every job description parsed into a structured checklist on arrival, each item flagged, each employer’s own wording preserved as evidence. A fill-difficulty score that warns you about hard-to-fill roles the day they land, not the month they stall. And across the stores, the demand gap as a named pattern — 25 unfilled requisitions traced to citizen-only and CDL hard fails, 29 surplus credentialed candidates traced to thin employer demand — each half pointing at a specific action. The demand side is now data, and it is the input the matching engine needs.

Why this works

Because the schema is fixed and the extraction runs on arrival, every role is structured identically without a human re-reading prose — the fortieth requisition costs the same as the first. Because every flag is pinned to the employer’s own words and a deadline, any classification can be audited in seconds. Because the hard-versus-coachable split is mechanical, near-matches become plans instead of rejections, and unfilled roles become diagnoses instead of mysteries. And because the requisitions join the same workspace as the candidate pool, supply and demand finally sit in one queryable place. The skeptic’s one-liner: you cannot match people to prose — structure every role on arrival, and every unfilled job gets a named reason.

The one thing to do this week

Take your most recent open role — the actual JD, as the employer sent it — and run Prompt 2. Parse it into the five categories, flag each requirement HARD or COACHABLE against the real start date, and show the checklist to whoever does your matching. If they disagree with a flag, you have found the inconsistency that was already happening silently between coordinators. One structured role is the seed of the demand side.

Video walkthrough (coming soon)

A screen-by-screen walkthrough — standing up the Job Requisitions store, watching the MIG welder requisition structure itself on arrival, and asking the Assistant for the 25-versus-29 gap — is in production. Check back on the Academy.

Who this is for

Placement coordinators who re-read the same job description twenty times a season and carry the requirements in their heads. Workforce programs whose employer partnerships produce requisitions nobody can systematically match against. Program directors who suspect their unfilled roles share a cause but cannot name it. If a candidate was ever rejected for a certification they could have earned before the start date, the fix starts here.

Structure your demand side in Sopact Sense — sopact.com/academy.

Next in the series: How to Score Candidate–Role Matches Without Bias — the checklist you built meets the credentialed pool, and every candidate–role pair gets a scored, auditable match with the gap named.