How this data is built

This is a plain-language walkthrough of the definitions behind every KPI, chart, and entity page on Proletaria. It follows the same definitions as the public API contract; where a number can’t be honestly computed it is null or a COLLECTING state, never a placeholder.

Universe and employer selection

The tracked universe is a curated registry of employers, one record per company, reviewed before onboarding. An employer enters coverage once its public job listings have been verified as real postings; the universe is not every job board on the internet, and it is not exhaustive of the labor market.

What a posting is

A posting is one job listing an employer has published, identified by a stable listing URL. The same role reposted under a new URL is treated as a new posting; Proletaria does not attempt to de-duplicate reposts across URLs.

Active, new, and removed

A posting’s effective post date is coalesce(posted_at, first_seen) — the employer’s own stated date when it publishes one, falling back to the date Proletaria first observed the listing. A posting counts as new on the day its effective post date falls, and as removed on the first daily diff that no longer finds it live (the closed-day rule) — not the day it was last seen, which can lag the employer’s actual removal by up to one daily update. Active is simply: seen in the most recent completed diff.

Pay parsing and midpoint

Pay ranges are parsed only from what the employer discloses on the posting itself — never inferred from title, level, or location. Where a range is disclosed, the midpoint of min and max is what feeds pay medians and comparisons; a single disclosed figure is used as-is. Undisclosed pay is null, not zero or an average.

Work mode

Work mode (remote / hybrid / onsite) is read from the employer’s own posting language and location metadata. A posting with no work-mode signal is left null rather than defaulted to onsite.

Seniority rule

Seniority is extracted from title and description text where it is stated. Where a posting states no seniority signal at all, it is defaulted to mid-level rather than left null — this is a deliberate simplification, and it means the mid-level bucket is inflated by every posting that simply didn’t say. Treat senior/staff/principal and intern/junior counts as the more reliable signal; treat mid-level as “stated mid, or unstated.”

Skill extraction and vocabulary governance

Skills are extracted from posting text against a controlled vocabulary defined in this project’s skills registry, not free-text tags. Deterministic equivalences (case, punctuation, plurals) are normalized in code; semantic equivalences (for example, “data analytics” folding into “data analysis”) are reviewed aliases, never assigned by a similarity score. A name the vocabulary doesn’t yet recognize is admitted as proposed — it stays attached to the listing, but does not appear in the public skill index until reviewed. A merged skill slug leaves a redirect, so a skill URL you’ve linked to never silently breaks.

Quality gates and quarantine

Every employer’s daily update passes through validation gates before it is allowed to affect that employer’s posting counts. An update that fails validation — for example, far fewer postings than its recent history supports, or an update that could not be completed — is quarantined: that employer is excluded from that day’s diff entirely, rather than having its real postings marked “removed” by a bad read. Quarantine over deletion, always.

Disclosure and suppression floors

Aggregates are suppressed below a minimum sample so a single employer or a thin slice of data can’t be read back out of a summary statistic:

• A pay median requires at least 30 priced listings and at least 10% pay disclosure in that slice; below either floor the median is null.
• A skill co-occurrence pair requires at least 10 listings carrying both skills (pair_count ≥ 10); thinner pairs are omitted rather than shown with noisy confidence.
• Time-to-fill is a right-censored median computed over closed postings only, and is suppressed while the platform has under 90 days of history — a young employer’s time-to-fill is not yet a stable number.
• Trending and mover rankings require a baseline population — 50 listings for a skill, 20 for a title group — below which a swing is too small a base to call a trend.

Known limits

• Employer onboarding has been ramping since 2026-08-12; earlier history is thinner for employers added since, and coverage widens over time rather than starting complete.
• Time-to-fill is right-censored: a posting still open at the end of the observed window hasn’t “filled” yet by definition, so medians understate the true time-to-fill for slow-to-close roles.
• A meaningful share of active listings carry no mappable geography (remote-only language, or a location the metro model doesn’t resolve); location-based views describe the listings that do map, not the whole active set. The metro map itself shows its own mapped-vs-unmapped split live.
• Coverage mixes US and non-US employers and postings; regional comparisons should account for that mix rather than assume a single labor market.

Current coverage counts (companies tracked, active listings, days of history) are not repeated here as static numbers — see the live counters on the overview page or /api/meta, which is the single source of truth for them and updates daily.

See also the data & API page for the public API and its data-use terms, and about for what Proletaria is.