Every job description parsed on arrival into a requirements checklist — each item flagged hard or coachable against the start date, and every unfilled role given a named reason.
For: placement and matching teams — workforce programs matching trainees to roles, fellowships matching fellows to host sites, accelerators matching founders to partners — who inherit every opportunity 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, and every unfilled job given a named reason.
What happens the moment a requisition arrives:
This is Chapter 10 of the Case Intelligence series — and the first chapter on the demand side. In Chapter 9 you computed a live, sourced SROI over the supply-side stores; every chapter so far has been about participants. But placement is a two-sided market, and the other side arrives as prose. Whether your participants are trainees, students, founders, or grantees, the method is identical.
As always, the first two steps are [DIY] — designing the schema and parsing one job description are thinking work for any AI chat window. The last two are [SENSE] — because parsing every requisition as it lands, and lining all of them up against a credentialed pool, needs the stores a chat window has never seen.
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 for every candidate considered — twenty candidates against one role means twenty re-readings of the same paragraph. It is inconsistent: two coordinators weigh "OSHA 30 preferred" differently, so the same candidate is qualified on Tuesday and unqualified on Wednesday, and nobody can say why. And it is where bias hides: when requirements live in someone's head, the reasons for a pass-over are never written down — "not a fit" is the phrase that ends the conversation and erases the evidence.
One design decision does most of this chapter's work: every extracted requirement gets one of two flags. HARD means disqualifying — citizen-only work authorization cannot be coached; a commercial driver's license the program does not train for cannot be earned in three weeks. COACHABLE means trainable in time — a missing OSHA 30 that takes about two weeks is not a rejection, it is a two-week plan, provided the start date allows it. Downstream, the split is what keeps matching humane; in aggregate, it is what makes unfilled demand diagnosable, because the question that matters about a stalled role is which hard requirement blocked it.
Decide once the fixed set of categories every requirement falls into — credential, license, work authorization, background, deadline — and the single rule that classifies each one: 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 the requirement — the same missing certificate is coachable in September and hard on November 10. That relativity is why the deadline is a schema category, not a footnote.
Here are the roles I place for — tracks, typical employers, typical requirements — and what my program can train or coach, and how fast: [paste both].
Design my requirement schema. Start from five categories — credential, license, work authorization, background, deadline — and add one only if a recurring requirement fits none of them, quoting the requirement that forced it. List each category's values as a closed set. Then apply the one rule — a requirement is HARD if no coaching before the deadline can satisfy it, otherwise COACHABLE — and tell me which of my values are structurally hard. Working conditions like "lift 50 lbs" are disclosures, not requirements — keep them out of matching.
Keep the schema small. Five categories that hold ninety-five percent of requirements beat fourteen that each hold one — a schema that grows a category per unusual role stops being a schema and becomes prose with extra steps.
Take one real open role and parse its free text into the schema yourself before anything runs at scale — the same calibration move as scoring one application before trusting a rubric with the pool. If a real requirement fits no category, you have found a schema problem on one role instead of after a hundred extractions.
Here is my schema, what my program can train and how fast, and one real job description exactly as the employer sent it: [paste all three].
Parse every requirement into the schema and flag each one HARD or COACHABLE by the rule — can coaching close it before the start date? — not by the employer's word choice: "required" is not automatically hard, and "preferred" is not automatically coachable. Quote the employer's exact phrase next to every flag, and if a coachable gap can't close before the deadline, re-flag it hard and say why. Route working conditions to a disclosures line, and if a requirement fits no category, write SCHEMA GAP instead of forcing it.
The line that earns its keep is the soft one. The welder requisition says "OSHA 30 preferred but we'll train" — a coordinator in a hurry reads "OSHA 30" and rejects a candidate who could have been ready in two weeks. The rule reads the deadline and says COACHABLE, with the employer's own words attached as evidence.
From here on, this is what the product does — not a prompt you run. A chat window parses the one job description you paste; the product holds the requisition store, so the extraction fires on every role as it lands — the first employer's requisition and the fortieth structured against the identical schema. It also computes the one field a chat window never could: fill-difficulty, which requires knowing how rare each hard requirement is in your credentialed pool. Here is the welder requisition, structured the moment it landed:
| Requirement | Flag | Employer's exact phrase |
|---|---|---|
| AWS D1.1 certification | HARD | "AWS D1.1 certification required" |
| Driver's license | HARD | "Valid driver's license required (no CDL)" |
| Work authorization | HARD | "Must be authorized to work in the US" |
| Background | HARD | "Clean background for site access" |
| OSHA 30 | COACHABLE · ~2 weeks | "OSHA 30 preferred but we'll train" |
| Fill-difficulty | MODERATE | Hard requirements common among credentialed candidates |
Every flag carries the employer's phrase, so any classification can be audited in seconds. And the fill-difficulty score is an early-warning system: a citizen-only, clearance-eligible analyst role gets flagged hard-to-fill the day it lands — before a single candidate is proposed, not after six weeks of quiet failure. Tune the hard-versus-coachable rule on your first five or ten requisitions and everything already in the store re-extracts against the revised rule — early and late roles structured identically.
The second thing no standalone prompt can do: line up every open requisition against every credentialed candidate at once. In Sense you ask across the stores in plain language:
| Side | Finding | Route to |
|---|---|---|
| Unfilled demand | 25 requisitions blocked by HARD FAILS — clustered on citizen-only work authorization and CDL licenses the program doesn't train | Recruit for cleared-role tracks; evaluate adding a CDL track |
| Surplus supply | 29 credentialed candidates SURPLUS — more welders and CNAs than open roles this quarter | Open new employer demand; throttle intake until it catches up |
| Early warning | Citizen-only analyst role flagged HIGH fill-difficulty the day it landed | Set expectations before six weeks of quiet failure |
Sit with what that table is not saying: it is not saying the program trained people badly. The 29 surplus candidates are credentialed — they did everything asked of them. The gap is a misalignment on two named, structural requirements, and each half points at a specific decision. Without structured requirements, the same reality is 25 individual disappointments and 29 individual frustrations, and the pattern connecting them stays invisible — which is exactly how it stays unfixed for years. The next chapter turns this checklist and that pool into candidate-by-role match scores.
Treating every "required" in the prose as hard. Employers write "required" loosely — the welder requisition marks OSHA 30 "preferred but we'll train." Flag by the rule, and keep the employer's phrase attached as evidence.
Classifying without the deadline. Coachable is a race against the start date, not a property of the requirement. A checklist with no deadline field makes every coachable flag a guess.
Letting the schema grow a category per role. When a requirement doesn't 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 a two-week gap becomes a two-week plan. Treat COACHABLE flags as soft rejections and you have rebuilt the old bias with better paperwork.
Skipping the employer join. A requisition with no employer name and no requisition ID is an orphan — it can never reconcile with placements, so you can never learn which employers' roles fill and which stall. The reference keys are why the unfilled pattern is computable at all.
A fixed five-category schema with one mechanical hard-versus-coachable rule. Every job description parsed into a checklist on arrival, each item flagged, each employer's own wording preserved as evidence. A fill-difficulty score that warns about hard-to-fill roles the day they land. 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.
Take your most recent open role — the actual description, as the employer sent it — and parse it with the Step 2 prompt. Flag each requirement against the real start date, then 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.
Placement coordinators who re-read the same job description twenty times a season and carry the requirements in their heads. Programs whose employer partnerships produce requisitions nobody can systematically match against. Directors who suspect their unfilled roles share a cause but can't 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.
ChatGPT, Claude, and Gemini are fine for a quick test — but not for an answer you'll put in front of a funder or board. When it has to hold up, run it in Sopact Sense.
Try it in Case Intelligence →
