How JobShift measures AI's labor-market impact

1. AI hiring classification

A job posting becomes an “AI hire” only if it earns a tier from a two-stage classifier. Three tiers are defined — strong, medium, and weak — and counts at every tier are published, so readers can apply a stricter or looser definition than the default.

Classification exclusions

• The token “AI” in a job title is insufficient on its own; it must appear alongside role-defining context (for example, Engineer, Scientist, Researcher).
• Phrases such as “uses AI tools”, “AI-assisted”, or “leverages AI” within a job description are not treated as strong signals; they describe the worker’s toolkit rather than the role itself.
• Per-company rules promote roles at organisations whose core business is AI (for example, all engineering roles at frontier research labs) and demote false positives at companies that include AI-related boilerplate across all job descriptions.
• Specific titles unrelated to AI engineering or research (for example, “AI Art Teacher” or “AI Ethics Reporter”) are explicitly excluded from the classification.

The classifier source is available in this repository at src/classifiers/ai_classifier_v2.py and src/classifiers/ai_org_rules.py.

For a comparison of AI-role density across hiring channels, see the Hacker News Who’s Hiring vs. ATS feeds cross-check. AI-role density on the monthly Hacker News threads runs approximately three times higher than across the broader ATS market (Greenhouse, Ashby, Workable).

2. Where layoff data comes from

JobShift draws exclusively on public sources. Pseudonymous user-generated content (such as Blind or Reddit posts) and unverified leaked documents are not included. Two types of source inform the layoff dataset.

a) WARN Act filings

The U.S. Worker Adjustment and Retraining Notification (WARN) Act requires employers with ≥100 workers to file 60-day advance notice of mass layoffs and plant closings with the state's labor department. Filings are ingested from 50 US states via a per-state scraper fleet plus historical-backfill scrapers that pull multi-year archives where the live source only exposes the current fiscal year. Coverage highlights:

• California (Cal-WARN — the largest source, 16,000+ events back to 2008 via the EDD per-FY PDF archive).
• Georgia (4,600+ events back to 1989 — the longest historical span in the dataset).
• Texas (5,100+ events back to 1999).
• Illinois, New York, Florida, New Jersey, Washington and 40+ other states with shorter but actively-refreshed coverage.

Several smaller states publish only the current fiscal year, and Wyoming maintains no public WARN registry. The full per-state coverage table (with date ranges and event counts) is available on the dashboard’s Layoffs by State panel. Each filing records a filing date, an effective date, an employer name, a site address, and a count of affected workers. The count is stored under estimated_us_count because a WARN figure is the employer’s own estimate, submitted in advance of the layoff; the eventual number of separations may differ.

b) News coverage (for AI-attribution evidence)

A WARN filing alone does not indicate why a layoff occurred. To attribute a layoff to news coverage that cites AI as a cause, WARN filings are cross-referenced with reporting from:

• Hacker News (announcements that reach the front page).
• TechCrunch (industry layoff reporting).
• Reuters / CNBC syndications carried via Layoffs.fyi's deduplicated tracker.

c) SEC 8-K filings (Item 2.05) and 10-K headcounts

Public companies must file a Form 8-K with the U.S. Securities and Exchange Commission within four business days of a material restructuring. Item 2.05 (“Costs Associated with Exit or Disposal Activities”) is the section that announces layoffs. The 8-K scraper extracts the affected worker count, the percentage of workforce, the effective date, and any disclosed severance range.

Many 8-K layoff filings disclose the cut as “approximately N% of our workforce” without an absolute headcount. For those events, the dashboard derives the absolute count by multiplying the disclosed percentage by the company’s most recent total employee count from its annual Form 10-K (“Item 1. Business” is the section where total headcount is legally required to be disclosed).

The derivation rules, applied per event:

• The 10-K snapshot used must be the most recent one filed on or before the layoff announcement date. A 10-K filed afterwards describes the post-layoff workforce; using it would double-count the cuts.
• If the freshest available 10-K is more than 24 months older than the layoff, the derivation is skipped — the underlying headcount has drifted too far to be trustworthy.
• Percentages outside the (0, 100] range, and any computed count smaller than 50 or larger than ten million workers, are also rejected as data-quality guards.
• The result is rounded to the nearest whole worker using banker’s rounding (round half-to-even) so aggregate totals stay unbiased across many events.

Derived counts are flagged in the database (events.headline_count_source = ‘derived_pct_headcount’) and rendered in the UI with an est. badge next to the number. Hovering the badge shows the exact formula (e.g. “15% × 108,900 (10-K asof 2024-12-31)”) plus a link to the source filings. Counts disclosed directly by the filer (WARN affected_workers, SEC workers_affected, Layoffs.fyi total) carry no badge.

d) Layoffs.fyi (community-maintained tracker)

Layoffs.fyi aggregates company-announced tech layoffs going back to 2020, including events that never reach a WARN threshold or that occur outside the US (and so are not WARN-eligible). Their corpus is ingested as a cross-source signal: a Layoffs.fyi entry alone does not attribute a cause to AI, but it helps confirm WARN filings and catches global rounds the WARN system never sees.

Source freshness

The system currently tracks 116 active sources across hiring (ATS) and layoff (WARN and news) feeds. The most recent successful refresh completed 8 hours ago. Individual source URLs and scraper implementation details are not disclosed publicly.

3. How AI attribution is determined

A WARN filing in isolation does not identify the cause of a layoff. A layoff is attributed to AI only when both of the following conditions hold:

1. A news article mentions the company within ±14 days of the filing date. The article and filing share a row in the event_news_links table.
2. The article explicitly cites AI as a cause, and the rules-based classifier scores that causal language at ≥ 0.6 confidence. Matches below the threshold are recorded in the database but excluded from the AI-attributed counts.

The classifier identifies explicit causal language — phrases such as “due to AI”, “shifting toward automation”, or “investing in AI rather than additional headcount” — and excludes mentions that are merely contextual (for example, “the company also announced new AI products”). The threshold is deliberately strict; in the current dataset, 0.37% (235 of 63,798) of layoff events meet the criteria.

4. What we show — and what we cap

When you click an aggregate number on the dashboard (e.g. 7,436 workers in California), the drill-down panel that opens shows the 10 largest individual events behind that number — not the full underlying list. This is a deliberate editorial cap, not a bug or a paywall gate.

Why the top 10

Layoff filings follow a heavy power-law: a handful of large events typically explain most of a state-level aggregate. For California's last-90-day AI-attributed layoffs, the top 5 events alone (Meta × 3, Intuit, Oracle) cover roughly 50% of the worker count. By the time you reach event #11 you're looking at filings of a few dozen workers each — signal that's already buried in the aggregate. Showing 10 lets you answer “what made up this number?” without wading through a long tail that doesn't change the story.

The cap also keeps the page honest. A 400-row table reads as “here is everything,” which would imply we believe every row is comparably reliable. We don't — small filings often have weaker source attribution, less coverage, and higher misclassification risk. Capping at the impact-ranked 10 keeps focus on the events we have the strongest evidence for.

What “by worker impact” means

Rows are sorted by headline_count (the worker count from the source filing) in descending order, with ties broken by date and then event id for stability. Events with an unknown worker count sink to the bottom — they still count toward the total in the panel header, but the top-10 slots are reserved for events we can actually weigh.

How to see more

• Use the AI-Attributed Layoffs page to browse by state with deeper history per state.
• Each row in the drill-down links to the primary source (WARN PDF, SEC 8-K, or news article). Click through for the original filing — we don't republish source documents.
• The underlying public records are available from the state WARN portals listed in section 2 above. We're a curation layer, not a primary source.

What we'll never do

• Sort the drill-down by anything other than impact + date. No promoted positions, no “featured” events, no paid placement.
• Hide events from the count in the header just because they didn't make the visible top 10. The number stays honest even when the rows are capped.
• Use the cap as a paywall trick — if we ever offer a paid tier with deeper drill-down access, it'll be priced on faster refresh and richer cross-source enrichment, not on showing the 11th-largest WARN filing.

5. Known data limitations

The following constraints apply to the dataset.

6. Independent verification

JobShift publishes ongoing cross-checks against the most widely cited public reference datasets. Two are currently available; additional comparisons are planned as the dataset expands.

Discrepancies identified by either cross-check are reviewed and incorporated into the next data refresh.

7. Read more

• Dashboard — live metrics, with state-level breakdowns of layoff activity.
• Trends and deeper analysis — AI hiring leaderboard, weekly activity timeline, and sector breakdown.