Passage Data
Your data has to become the thing the receiver actually accepts. That transform is the whole of what we do — we map the columns we can confirm from your values, build the file, and name what we refused to interpret. Before you submit, not after.
Free until 1 September 2026, 00:00 UTC · no account · your records are
discarded after the check — we keep the column mapping, never the rows.
See a real sample report — a 5,271-record government waterfowl survey,
with the archive, the questions and the findings, if you would rather look before
uploading.
One name per line, or comma-separated. This checks the 10-character truncation cap, whether any of your names would collide once cut, and the 255-field limit — the same facts exporting to a shapefile would apply to you, before you have a file for us to read.
Click any tool. Filled dot we build today · hollow on the roadmap.
We audited 5,064 occurrence records that were already
published to GBIF — they had passed the pipeline and were being served. Of GBIF's
own OccurrenceIssue codes we are able to raise, 8 in total,
none applied to these records. We returned 4,268 findings of our own.
Every code we raised carries the FS_ prefix, which means
it is ours and states its own warrant — never GBIF's name carrying our meaning:
FS_COORDINATE_UNCERTAINTY_ABSENT 1,972FS_PRECISION_EXCEEDS_UNCERTAINTY 1,230FS_COORDINATE_PRECISION_LOW 1,028FS_DATE_PRECISION_REDUCED 38And not one of them is an error — nothing here says a record is wrong as stated. 3,458 of these records carry something a downstream user may need and a receiving body does not check. GBIF's validator answers will this load, and these had already loaded — the two questions are simply different ones.
One file, 5,064 records, drawn from GBIF's own API and not chosen by us. A second file from the same source, different taxa: 400 records, 219 findings, again none of them GBIF's, 55.0% clean. Every figure here is read from ops/data.json, regenerated by re-running the audit over the raw records — none is typed into this page.
GBIF's validator checks a Darwin Core Archive you have already built. It reports what is wrong with it; it does not map your columns and it does not produce the archive. If you do not have an archive yet, there is nothing for it to validate.
We start from the file you actually have — a spreadsheet, a database export, a workbook —
confirm each column against its own values rather than its header, and refuse anything
genuinely ambiguous instead of guessing. A column named latitude holding
longitudes is a real failure mode, and a name match cannot see it.
And the two reports do not overlap. Not because GBIF is wrong: their validator answers “will this load”, and there is no code in their vocabulary for most of what we report. The measurement is above — a set of records that had already been published to GBIF, where nothing in their vocabulary fired and our audit still had a great deal to say. The sample report below is the same story on a different file — a well-made government survey where 20 terms map, the archive builds, and 399 of the 400 records we sampled still carried something worth telling you about.
No grade, no rating, no seal — a grade is a scale we would have to invent, and you would have no way to check it. Every finding instead names the rule it applied and where that rule comes from, and anything your values could not settle is refused rather than guessed. A finding is a statement about your record, never about the world.
Each line above carries a code. What the refusal codes mean →
| Column | Status | Darwin Core term | Why |
|---|