RoleDawn

Methodology: where the data comes from and how accurate it is

Everything RoleDawn shows is derived from job postings that companies publish on their own public careers boards. This page explains how we collect them, how we classify them, how each signal is defined, how accurate the classification measured, and what the data cannot tell you. Signals indicate intent, not proof of budget.

Data sources

  • Public applicant-tracking-system (ATS) job boards only: Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Recruitee and Workday. We read the same public job-board endpoints and pages that candidates see.
  • We currently track 4,497 company boards (2,205 returned postings on the latest check, with 45,811 open roles).
  • We do not scrape LinkedIn or other social networks, and we do not collect or sell personal contact details. Postings are stored at company level: title, department, location, dates and a link to the original posting.
  • Company names come from the organisation name the ATS publishes for the board where available; otherwise from a cleaned-up board name.
  • Our crawler identifies itself as RoleDawnBot with a link to this page.

Crawl frequency

A scheduler runs every 15 minutes and checks the boards that were checked longest ago, so each tracked board is re-read about once a day (at most every 20 hours). Boards that fail five times in a row are retried weekly. Postings that disappear from a board are marked closed. Digests are sent once a day at 13:00 UTC, so an observed signal usually reaches you within one to two days of the posting appearing.

Role-family classification

Each job title (plus its department, when the board provides one) is mapped to one of 41 role families — RevOps, Security, Data Engineering, Hardware and so on — by a deterministic, rule-based classifier. The leading role noun wins over domain words ("Product Manager - AI Finance" is Product Management, not Finance), physical engineering titles (aerospace, mechanical, structural, electrical, civil, manufacturing) are kept out of software families, and titles that do not clearly fit stay in "Other" rather than being guessed.

Measured accuracy (2026-10-05)

Blind test on 579 open job titles drawn at random from our database after the rules were frozen:

  • The classifier assigned a role family to 516 titles (89%); the other 63 stayed "Other".
  • Of those 516, 447 (87%) matched the reference label.
  • The classifier we used before that day scored 82% on the same sample (414 of 505).

Reference labels: a language model (Claude Haiku 4.5) labelled every title first; every case where it disagreed with our classifier was then reviewed by hand. In total 2,891 titles were labelled across five random samples that day; errors found in the earlier samples were fixed and a set of reviewed labels is part of our automated tests. Many remaining errors are genuinely ambiguous titles (for example "Technical Program Manager, Infra" or "Forward Deployed Engineer"), but roughly one classified title in eight can still land in the wrong family.

Signal definitions

First posting we've seen

A role family appears on a board where we had already recorded postings and had never seen that family. It means "first we have seen since we started tracking this board" — not that the company never had such a role. It may have hired before we started tracking it, hired without a public posting, or used a different board.

New function (inferred)

On a company's first crawl we have no history, so we can only estimate. We infer a new function when the board is established (it has postings older than 60 days, 6–40 open roles across at least 3 families) and the family has only 1–2 roles, all posted in the last 21 days. We do not infer when:

  • the family matches the company's own field (for example security roles at a security company);
  • the family is technical (engineering, data, design, product, IT…) and the board has 15 or more open roles;
  • the posting uses a level such as "II" or "L5", which implies an existing ladder;
  • another posting already sits in a department named after that function, or several other postings mention its domain;
  • the family is general software engineering.

Inferred signals are labelled everywhere and are off by default in monitors; you can switch them on per monitor.

Hiring surge

A role family's new postings in the last 30 days are at least double the previous 30 days and at least 3 (or at least 5 when the previous 30 days had none). It counts postings, not hires.

Signals indicate intent, not proof of budget. A posting tells you a company plans to hire for a function. Whether it will buy tools or services, and when, is something you still need to qualify.

Known limitations

  • Coverage: only companies whose boards we track, on the seven supported ATS platforms. Companies that hire through LinkedIn, agencies, other ATS platforms or their own careers site are invisible to us. The tracked list leans towards technology companies.
  • History starts when we start: "first posting we've seen" is relative to our own history of that board.
  • Classification errors: see the measured accuracy above. Unusual, non-English or very short titles are the most error-prone.
  • Posting dates: we use the publish date the ATS provides, or the date we first saw the posting. Some boards re-date reposted roles, and Workday only shows relative dates ("Posted 3 days ago").
  • Postings are not hires: roles can be evergreen, duplicated across locations, paused or never filled. Surges can be inflated by reposts.
  • No financial data: we do not know a company's budget, funding or buying plans.

Corrections

If you see a wrong role family, a wrong signal or a wrong company name, please tell us through the contact form with the company and posting. We fix the rule rather than the single row, re-classify all stored postings, recompute affected signals and add the case to our test set.