Provenance is the product.

The shape of it

Six stages, one record

Every row you pull has traversed all six stages. The rest of this page walks each one — how the data is acquired, how it is normalized and resolved, how identifiers are crosswalked, how events are derived under point-in-time discipline, how it is served, and how it is signed.

Stage 01 — Acquire

Broad coverage, by signal category

No two sources publish the same way — some expose a delta API, some only exist as dozens of separate state files with no shared schema, some are full-text search engines rather than datasets. Each gets a purpose-built, idempotent, resumable fetcher; raw downloads land on dedicated bulk storage, never in the repo, and every run writes a provenance-ledger row (source, vintage, row count, status). The point isn’t the plumbing — it’s that acquisition is repeatable and recorded, so every downstream record traces back to a named source and vintage.

Stage 02 — Normalize

Set-based, idempotent, resumable

Nothing is loaded row-by-row. Bulk files stream into staging and then upsert into the normalized tables on the natural key — a USDOT number, a case number, a registry id, or, where a source carries no key, a hash of the normalized identity fields. Re-running any ingest converges to the same state.

Name and address normalization is a single, tested reference implementation: legal-suffix stripping applied repeatedly (so ACME HOLDINGS CORP LLC → ACME HOLDINGS), punctuation collapse, USPS street-word canonicalization, and a distinctive-vs-generic classifier. This matters because it is also the join key for entity resolution — which is where determinism becomes non-negotiable.

Stage 03 — Resolve

A deterministic entity graph, proven line-for-line

The employer graph resolves 3.73M entities across 5.07M source-record links — WHD, OSHA, ECHO, LEIE, SAM, OFLC LCA/PERM, and gated FMCSA rows — with no fuzzy matching and no ML. Matching runs as set-based SQL for speed, but the SQL normalization functions are generated from the TypeScript reference implementation, and every build re-verifies TS ≡ SQL on a live sample before it touches a single row — any divergence aborts the build.

// A single TypeScript reference implementation is the source of truth for
// normalization; equivalent Postgres functions are GENERATED from it. Before
// every rebuild we sample real values and check every function, TS vs SQL:

for (const r of rows) {
  assert(normalizeName(r.v)          === r.sql_norm_name);
  assert(normalizeAddressLine1(r.v)  === r.sql_norm_addr);
  assert(normalizeCity(r.v)          === r.sql_norm_city);
  assert(zip5(r.v)                   === r.sql_zip5);
  assert(normalizeState(r.v)         === r.sql_norm_state);
  assert(isDistinctiveName(...)      === r.sql_distinctive);
}
// mismatches.length > 0  →  throw, abort build.   "TS == SQL for all functions"

Confidence tiers, disclosed on every row

A record links to an entity at one of three deterministic tiers. The tier and its confidence are carried on the link and surfaced in the feed — you set the threshold, we never hide the basis.

The trap in name-and-state matching is generic names. A distinctive-name classifier (single-token and stoplisted names are not distinctive) gates the entity key: distinctive names may merge on name + state, but generic names must additionally agree on ZIP, city, or resolve to their own record — so “Smith Trucking” in Texas never collapses into one phantom entity. FMCSA’s millions of carriers are further gated: a carrier joins the cross-source graph only when its normalized name+state (plus zip/city agreement for generic names) matches a non-FMCSA record.

Stage 04 — Crosswalk

EIN ↔ CIK ↔ ticker, verified only

Public-company identity is asserted only when an identifier proves it. FEIN arrives on recent workforce filings (resolved on 88.9% of 2026 workforce rows); CIK↔EIN and the ticker come from public SEC reference data. A row’s ticker_match_basis is set to cik or ein only on an identifier match; a distinctive-name-only match to a unique registrant is flagged name_candidate and the ticker is not asserted — is_public_company stays false. 42,596 workforce rows and 1,458 distress subjects carry an identifier-verified ticker; most subjects are private, and false is the correct, common value.

Stage 05 — Derive

Point-in-time, archive-and-diff

The feeds sell changes, and changes only mean something if the past is fixed. Two disciplines make that true:

The distress composite is a full deterministic rebuild over ten observational markers (WARN 180d, Form 5500 participant-drop ≥20% YoY, final filing, and Schedule H asset drop, IRS auto-revocation, SEC NT late / 8-K distress-item / going-concern, FMCSA authority revocation, and — only for subjects already carrying a marker — an active enforcement case). It counts records present, with dates. It is never a score.

Stage 06 — Serve & attest

Keyset serving, signed provenance

Feeds serve through opaque keyset cursors — the cursor encodes the last row’s sort key, so a drain is exact and its cost is flat at any depth, even as new rows land mid-pull. And every response is signed: an _meta block naming dataset, source, source URL, and vintage, plus an HMAC-SHA256 signature over the canonicalized payload + provenance.

// canonical() sorts object keys recursively → a stable byte string, so the
// same payload always signs identically. HMAC-SHA256 over {payload, dataset,
// source, source_url, vintage} with the gateway secret. scheme: hmac-sha256-v1.
const message   = canonical({ payload, dataset, source, source_url, vintage });
const signature = createHmac("sha256", secret).update(message).digest("hex");
// On dispute we can prove a given payload was served with a given source & vintage.

The signing chain extends past the read: saved-Parse deliveries are HMAC-signed with the Parse’s own secret (X-Govparse-Signature), and delivery is at-least-once — the per-feed watermark advances only after your endpoint returns 2xx.

The estate

Breadth and freshness, without the map

ParseData draws from two dozen public federal and state sources across the 7 signal categories above — together, millions of official records, every one an as-filed government record with its date, resolved to 3.73M employer entities. We deliberately don’t publish a table-by-table map of the estate or the acquisition scripts behind it; what earns your trust is that each record is normalized, entity-resolved, point-in-time, and attested — not a recipe you could clone.

Each source refreshes on the cadence its publisher actually uses — daily for opportunity feeds, weekly for enforcement re-exports, quarterly for disclosure drops, annually for the largest program files. The entity graph rebuilds after each ingest wave, so resolution always sees the freshest sources. These are real scheduled jobs kept in lockstep, not aspirations.

Counts are records present, with dates — never a score or a characterization of any company. The machine-readable endpoint contracts over these datasets are in the catalog.

Field-level detail

Join keys, classifications, and metrics

The health and pharma datasets carry provider- and hospital-level join keys and classifications, so a pull can target by identifier, drug class, molecule, prescriber specialty, or staffing metric. Each field is a value as filed with the agency — never a score or a characterization of any prescriber, hospital, or company.

The drug-class map groups Part D molecules into observed therapeutic classes — GLP-1, SGLT2, DPP-4, statin, and more — so a Part D pull can be scoped to a class or a single molecule and rolled up per prescriber NPI and specialty. On the hospital side, a CCN joins cost-report full-time-equivalent staffing to the Timely & Effective Care throughput measures for the same facility. It is a classification of the drug and a count of what was filed, not a judgment about any provider.

Guardrails

Where the build stops itself

• TS↔SQL parity gate. Entity resolution aborts if the generated SQL normalization diverges from the TypeScript reference on any sampled value.
• Distinctive-name & FMCSA gates. Generic names cannot merge on name+state alone; carriers cannot enter the cross-source graph without a non-FMCSA corroborating record.
• Threshold guards. The participant-drop marker requires ≥20% YoY decline on a base of ≥25 participants, so tiny plans can’t manufacture a false signal.
• Idempotency + run ledger. Every ingest is upsert-on-natural-key and writes an ingest_runs row (vintage, row_count, status); a partial run resumes cleanly.
• Search caps & disclosure. total_matched caps at 1,000 with total_matched_capped flagged; match tiers, confidence, and crosswalk basis are always on the row.

The receipts for all of this — schemas, samples, and per-column source and cadence — live on each feed page, and the machine-readable endpoint contracts are in the catalog.