Semantic Insight runs two evidence practices, each with its own methodology.
The Workforce Pell record is
kept under a strict set of documentary rules, explained first below. The
task-level pipeline compares
what employers are asking for against validated occupational standards — task by task, employer by employer.
This page explains both, and
why you can trust the results.
How the Workforce Pell Record Is Kept
There is no federal registry of approved Workforce Pell programs. The
Approvals Tracker and
State Eligibility Tracker
assemble the record the government does not — and a record is only as good as the rules it is
kept under. These are the rules.
1Primary sources only
Every row cites a document, not a description of one.
Nothing enters the record from secondary reporting alone. Every entry traces to a state or
federal source — a published occupation list, an agency announcement, a governor's framework,
a federal notice — and the citation travels with the row. If a fact cannot be anchored to a
primary document, it is not in the record.
2Source-typed rows
Agency confirmations and press claims are never blended.
Each row carries its source type. Direct agency confirmation is recorded as such.
Press-reported items are labeled as claims about government actions — not the
actions themselves — until a primary document confirms them. Readers can always see
which kind of evidence they are looking at.
3Stages are never summed
A state-certified program is not an approved program.
State submission, state certification, federal submission, and federal approval are distinct
gates in a pipeline, and the tracker displays them as a funnel for exactly that reason.
Adding stages together would overstate what has actually happened — so headline counts
are always stage-specific.
4Source Watch: every source, checked daily
Maintained on a documented cadence, not ad hoc.
Every primary source behind the record — federal and state agency pages, plus the
program-evidence pages cited in the stackability trail — is monitored for changes daily.
Press coverage across all 50 states and D.C. is scanned on the same cadence. Flagged
changes are reviewed by a person and verified against the primary source before the
record moves; when a state acts, the record reflects it within 48 hours, with the
citation. Data freshness is shown on the trackers themselves; every load is dated.
5Corrections are invited — and fast
The record improves when readers push back.
Inbound corrections are verified against primary documents and applied within days, with the
change reflected on the tracker. When North Carolina's submission count was corrected by the
state agency itself — 143 programs from 45 providers — the record was updated the same week,
sourced to the agency.
6No generated content in the record
Data fields contain what documents say. Nothing else.
Language models assist research workflows, but no model-generated text enters the record's
public data fields. What a state published is what the record says; analysis and commentary
are kept separate from the record itself, and are always labeled as analysis.
Canonical Comparison, Not Keyword Counting
Most labor market analysis extracts keywords from postings and counts frequencies.
That tells you what's mentioned — but not what's missing, what's new, or whether
any of it represents real occupational change.
We compare every duty against canonical task statements from
the O*NET database — the product of decades of federally funded job analysis
where subject matter experts generate task descriptions rated for relevance
by large samples of job incumbents. Comparing against that baseline
reveals three things keyword counting can't:
Confirmed
Which tasks employers actually ask for — evidence, not assumption.
Absent
Which core tasks don't appear in postings. You can't measure what's missing without a baseline.
Beyond O*NET
Requirements employers are adding that go beyond the canonical task profile.
Keyword Analysis
"What words appear in job postings?" Treats all mentions equally.
No reference point for what should be there. Can only see what's present.
Output: frequency counts.
Canonical Comparison
"Given what this occupation requires, what are employers emphasizing, omitting, or adding?"
Reads for meaning against a validated baseline. Measures change, not just frequency.
Output: occupational change signals.
How the Five Stages Work
The hardest part of labor market analysis isn't the matching or the reporting — it's getting clean data.
Anyone who's tried to research employer demand by hand knows: formal occupation titles don't match
what employers post, most job ads are mostly boilerplate, and assembling a representative sample
for one occupation in one region can take a full day. Five stages work in sequence to automate that entire process.
1
Search — Job Retrieval & Deduplication
Formal occupation titles rarely match what employers post.
"Stockers and Order Fillers" returns nothing on Google Jobs — but "Warehouse Associate" returns hundreds.
The search stage translates each O*NET title into the terms employers actually use, drawing from
curated search mappings and ranked alternate titles.
Multi-round search: The primary query targets your metro area with a 50km radius.
If too few results, it widens to state level. If the title is too formal, it swaps to the broadest
alternate — then cycles through additional titles round by round, deduplicating across all rounds,
until enough quality postings are assembled.
AI quality screen: Every posting is read by an LLM that counts extractable duties.
Postings with fewer than 5 duties are held in reserve —
only duty-rich postings enter the analysis batch.
Deduplication: Duplicate postings inflate evidence counts and reduce employer diversity.
The search stage applies three checks:
(1) Employer + title fingerprint — catches the same employer reposting a role with different job IDs.
(2) Content fingerprint — samples the description text to catch verbatim reposts where both the company name and title differ (e.g., a staffing agency and a job board intermediary listing the same position).
(3) Duty-content comparison — after screening extracts duty sentences, a cross-posting comparison catches template duplicates that share identical responsibilities but differ in employer name or location (e.g., hospital systems posting the same role across multiple campuses).
Employer names are normalized (stripping legal suffixes like LLC, Inc.) and each employer is capped at 3 postings per search round to ensure diversity.
Google JobsO*NET alternate titlesMulti-round fallbackLLM quality screenDeduplication + employer cap
Each posting split into individual sentences (~55 per posting). An LLM classifier labels every sentence —
duty statement, qualification, benefit, or boilerplate. Only duty sentences proceed.
Typically 70–85% filtered out.
Local parserLLM classifier
3
Classification — Semantic Matching & Verification
Each duty sentence is encoded using domain-specific transformer embeddings trained on millions of job posting sentences and compared
against every O*NET canonical task by semantic similarity. High-confidence matches become candidates.
A second LLM independently confirms or rejects each candidate — "Does this sentence
actually describe the same work as the O*NET task?" — eliminating false positives
where sentences sound similar but describe different work.
Frequency classification: Confirmed tasks classified by employer agreement —
Core (70%+ of employers), Common (30–70%), Occasional (under 30%), or Not Found.
At this point, the analysis forks. Matched sentences flow to the reporting stage for skill and certification extraction.
Unmatched sentences flow to the discovery stage.
✓ Matched → Reporting
Confirmed against O*NET. Flow into skill & cert extraction.
On the matched branch, the reporting stage extracts structured skill data from confirmed duty sentences — technologies
(EHR, HVAC controls), equipment (oscilloscope, autoclave), and technical skills (vital signs, wound care).
Returns normalized 1–3 word labels, not raw text.
Certifications are extracted separately from full posting text — since certs live in
qualifications sections, not duties. The LLM reads the entire posting and returns structured
certification records (BLS, CMA, NCLEX, state licensure).
All extracted items ranked by employer frequency — not just present/absent.
LLM extractionSkill extractionCert extraction
◆ Unmatched sentences
4
Discovery — Occupation Scope Change Detection
Duty sentences that fail to match any O*NET task aren't discarded — the discovery stage runs them through a
multi-gate pipeline that detects when an occupation's scope is expanding beyond the federal standard.
Multi-employer clustering: Unmatched duties are clustered by semantic meaning using domain-specific embeddings.
"Verify insurance eligibility" from Employer A clusters with "Confirm patient coverage" from Employer B.
Only clusters spanning 2+ employers survive — single-employer mentions are noise.
Specificity filter: Each surviving cluster is evaluated in the context of the target occupation.
Generic workplace competencies that appear in any job posting — "Team Leadership,"
"Professional Development" — are filtered. Only occupation-specific requirements proceed.
National tracking: Behind the scenes, each confirmed tag is saved with its embedding
for cross-metro comparison. When independent analyses in different metros surface the same requirement
for the same occupation, the system recognizes it as a national scope change — evidence that
employer expectations have moved beyond the federal standard. This feeds the
National Sweep
but does not influence what appears on any individual regional analysis.
Both branches converge. The reporting stage takes the task coverage map, extracted skills and certifications,
and beyond-O*NET findings and assembles structured outputs —
compliance reports, planning briefs, program review, and ATS-optimized resume templates.
Each output is formatted for its framework or audience and populated with
traced evidence from the analysis. The intelligence is in the analysis —
report formatting is deterministic and auditable.
Three design choices make the analysis rigorous, traceable, and current.
A Codebook-Based Approach With Built-In Saturation
A finite occupational standard means task coverage saturates structurally — not statistically.
Every analysis compares extracted duties from quality-screened regional job postings
against canonical O*NET task statements — the product of decades of
federally funded job analysis where occupational experts and large samples of job
incumbents rate tasks for relevance. That validated task set is the codebook.
Each occupation’s codebook is O*NET’s set of 20–30 canonical task statements — the validated, federally maintained list of what workers in that occupation do.
That's a bounded answer space. Each posting is fully analyzed — duty statements, technology
requirements, and credentials are extracted by an LLM and matched against this finite set.
A quality-screened posting typically yields 5–15 substantive duty statements, so even 10
postings from different employers produce 50–150 duty-level data points against the codebook.
By 8–10 employers, the tasks that regional employers actually require have been confirmed.
Additional postings refine frequency counts but don't reveal new canonical tasks.
The same holds for beyond-O*NET findings. Duties that don't match any
canonical task are clustered by semantic similarity — so scope changes
surface as soon as multiple employers confirm the same type of requirement.
The analysis isn't asking "what percentage of all postings mention X?" — it's asking
"which of this occupation's known competencies do regional employers confirm,
and what are they adding?" That question saturates quickly.
Validated codebook
O*NET task statements are the product of federally funded occupational analysis — rated by subject matter experts and job incumbents. That's the standard every posting is measured against
Bounded answer space
Each occupation has 20–30 canonical tasks. Saturation is structural — the codebook is finite, so coverage converges with relatively few quality-screened postings
Information-rich documents
Each posting is fully analyzed by an LLM — extracting duty statements, technologies, and credentials. With 5–15 substantive duties per posting, 10 postings yield 50–150 data points against a codebook of 20–30 tasks — 2–5× coverage per task on average
Dual detection
Both canonical tasks and beyond-O*NET requirements are tracked — the analysis captures occupational evolution, not just confirmation of what's already known
Built-in saturation metric
Task coverage % directly measures completeness. The platform shows how much of the codebook is confirmed — and screened alternates can be added without a new search
Consistent with research
Qualitative saturation research confirms theme coverage at 8–9 documents (Guest et al., 2020; Wutich et al., 2024) — aligned with what the platform observes in practice
Without a codebook
Skim 3–4 postings on Indeed. Write narrative summary. No extraction, no framework, no evidence trail. No way to measure what's missing.
Codebook-based analysis
Quality-screened postings → duty statements extracted by LLM → matched against O*NET canonical tasks → coverage reported with full traceability.
Guest, G. et al. (2020). PLOS One. Wutich, A. et al. (2024). Intl. J. Qualitative Methods.
Saunders, B. et al. (2018). Quality & Quantity.
Three-Layer Verification for Every Match
No single model's judgment reaches your report — every match passes three independent checkpoints.
As described in the Classification section above,
every match passes through semantic embedding, LLM judge verification, and employer frequency classification
before it reaches your report. Each layer narrows the result set. Every confirmed match traces back to
a specific posting, employer, and sentence — nothing is aggregated away.
The system is designed to be conservative by default. A missed match is a gap you can investigate;
a false positive would be misinformation in a compliance document. The architecture prioritizes
precision over recall.
Multi-Layer Currency — Each Source Dated
Live employer data combined with federal statistical foundations — more current than any single source.
Every analysis combines data at different refresh rates. Rather than hiding this,
every report labels the vintage of each data point so reviewers know exactly what they're looking at.
Job postings
Live at time of analysis — sourced from current regional listings via Google Jobs. Each posting is timestamped in the evidence trail
O*NET tasks
Updated quarterly — current version 30.2, including 275 Emerging Tasks newly added by O*NET. Requirements that go beyond the canonical task profile are surfaced separately
BLS wages & employment
Updated annually (May survey). Current dataset: May 2025. The most recent available from BLS
BLS projections
Updated annually. Latest from BLS: 2025–2035 (Aug 27, 2026); reports currently on 2024–2034, cutover scheduled. National figures — clearly labeled as such in every report
BLS data alone
Wage data is 12–18 months old at publication. Projections are national only. No employer-specific detail.
Combined approach
Live postings show what employers want right now. Federal data provides the statistical foundation. Each layer compensates for the other's lag.