When we get something wrong we say so here, with the date, what it affected, how many rows it touched, and what changed so that it would not happen again. We publish our own errors because a record nobody can audit is not a record.
To report something you think is wrong, email corrections@hiringrecord.com. A person reads every report and we correct confirmed errors. There is no review queue and nothing automated behind that address, so we do not quote a turnaround: a number nobody measures would be worth less to you than this sentence. Any company may also publish a response on its own page, at no cost and with no account required.
These entries are not finished. The figures below are assembled from the record and are accurate. The account of what happened, in each case, has not been written yet.
This page is not indexed while that is true. We would rather say that than publish a version of our own mistakes that reads as though it had been through a communications review.
1,732 postings recorded as absent that we had never seen to be gone
What happened
Not yet written. The facts below are complete and were queried against the record; the account of how it came about is being written by hand rather than assembled.
What it affected
Observations retracted Rows moved to posting_observation_retracted on 2026-08-22 16:27 UTC, all carrying the same retraction reason.
1,732
Postings affected One retracted observation per posting; no posting appears twice.
1,732
Employers affected Accenture 1,433, Abbott 132, GHR 85, Booz Allen Hamilton 82. The migration lists the four with their counts.
4
Closures published as a result A close requires two consecutive absences from healthy runs. None of the 1,732 postings reached a second absence, and none was in a closed state when the rows were retracted.
0
What we changed
The crawler now records, per board and per run, whether the listing was completely enumerated and why it was not: schema/055's `source_fetch_outcome`, which carries `listing_complete`, `incomplete_reason`, `pages_attempted` and `pages_succeeded`.
An absence is not inferred from a listing that was not completely enumerated. Before this, the runner suppressed the absence and wrote a line to the systemd journal on a box that is meant to be safe to destroy at any moment, so the single most audit-relevant fact in the system survived nowhere.
The retracted rows were moved rather than deleted, so the gap in an employer's history on that date has an answer that does not require reading a commit log.
391 postings carried a precise posted date that the board had invented
What happened
Not yet written. The facts below are complete and were queried against the record; the account of how it came about is being written by hand rather than assembled.
What it affected
Dates retracted, first pass schema/076, anchored to the iCIMS crawl run of 2026-08-28. Two independent identifications agreed exactly: 230 by run window, 230 by calendar date, 0 on that date outside the window.
230
Dates retracted, second pass schema/081, anchored to the run of 2026-08-29. The guard shipped on the 28th did not hold, and most of these landed on the very rows the first pass had cleared.
161
Boards affected careers-eastwestbank.icims.com on almost every posting, and careers-berkley.icims.com on 4 of 209 — so the defect is per posting rather than per board.
2
Dates refused since, on one board, every day source_fetch_outcome.dates_rejected_clock_echo, which schema/083 added so that the guard holding could be measured rather than inferred from the absence of bad rows.
225
What we changed
The extractor refuses a posted date that tracks our own request clock, rather than recording what the board served. A posting with no date is recorded as left-censored, which is what it would have been had the board sent nothing, and is the recoverable direction: a null can still be filled if a real date ever arrives, and a fabricated value would have been frozen permanently.
The clock the guard compares against is stamped per page rather than once per board. That is what the second pass was: iCIMS is one request per job, so a 226-job board runs for twelve minutes and a single stamp taken at the start goes stale — measured at 137 to 342 seconds of drift against a 90-second tolerance.
What the guard refuses is now counted and stored per board per run (schema/083), with the number of dates served as the denominator. Zero rejections means one thing on a board serving 226 dates and something entirely different on a board serving none.
The observation rows were left untouched. They record what the source actually served at the moment we fetched it, which is the evidence that the defect was real; the posting record is current state and is the right place to stop asserting something false.
2,021 closure events published for postings our own record shows were still listed
What happened
Not yet written. The facts below are complete and were queried against the record; the account of how it came about is being written by hand rather than assembled.
What it affected
Closure events withheld after the fix Postings with a close date that are either not currently closed, or whose last sighting is later than the close date shown. Counted over `posting`; the same count is published live in `meta.withheld.closure_events` on every response that carries closure events.
2,021
Published as closed while still open `close_detected_at is not null and status_state <> 'closed'`. These postings were on the employer's board; the feed said they had closed.
1,473
Published with a close date we had already outlived `status_state = 'closed' and last_seen_at > close_detected_at`. All 548 were closed on two absences recorded BEFORE our own most recent sighting of the posting, and none carries an observation recording that sighting.
548
Employers affected `count(distinct company_id)` over the 2,021. Each appeared on that employer's own page at /employer/{slug}, which serves closure events by default.
222
Longest a posting stayed listed after its published close date `max(last_seen_at::date - close_detected_at::date)` over the 2,021. The mean was 9.6 days.
17 days
Largest single employer effect Merck & Co., Inc. Shake Shack Inc. is the largest proportional one, 237 → 113. One employer, Enact Holdings, Inc., had a single closure event and it is withheld; no employer's page is left without records.
876 → 757 events
Where it was published Closure events are a record-only type: they are excluded from the open feed at /pulse by default and served on an employer's own timeline, and on an explicit request for that type. The open feed never carried them.
Employer pages only
What we changed
The feed now decides whether a posting is closed from `status_state`, which is current state, and uses `close_detected_at` only for WHEN. The two had been conflated: nothing ever clears the close date, so `close_detected_at is not null` means 'was observed closed at some point', never 'is closed now'.
A second, separate condition withholds any closure event our own record contradicts — where the posting was seen on the board after the date we would print. It is not a restatement of the first: it removes 548 events that are correctly marked closed but were decided on evidence older than our most recent sighting.
What is withheld is counted and published in `meta.withheld` on every response that carries closure events, rather than dropped silently. A page that thins with no explanation is not auditable.
The two conditions are tested independently: each is removed from the generated query in turn and the query re-run, so a condition whose removal changes nothing fails the suite instead of passing it.
The underlying cause — a posting that returns to a board writing no observation to say so — is a separate fix in the crawler, and the conditions above remain in place after it, because that fix stops new rows of this shape rather than repairing the existing ones.