We probed every .gov domain for DKAN and found three portals, all publishing the same wrong identity

The census, including the frame that failed

The first frame took CISA's dotgov-data registry, which is the authoritative list of every registered .gov domain and names the organization behind each one, and asked all 16,535 of them for a DKAN response at/api/1/metastore/schemas. It found nothing. Zero DKAN portals in the entire United States government.

That result was false, and it was the kind of false that gets published. The CISA registry lists registrable domains only, never subdomains, so the probe asked medicaid.gov and never asked data.medicaid.gov, which we already knew was a DKAN portal because we had opened it by hand an hour earlier. Keeping one known-answer case and testing the detector against it is the only reason the zero was caught rather than written up.

The second frame built candidate hostnames from five open data prefixes, gated them through DNS so that only resolving names were fetched, and probed the 3,600 that existed. Three DKAN portals answered. An earlier passive fingerprint had also miscounted data.cms.gov as DKAN, because it returns HTTP 200 with an HTML single-page shell at the DKAN API path; the probe now requires a parsed JSON object carrying a recognisable schema key, and that false positive falls out.

Both frames are in the published record. A census that shows only the frame that worked is not a census.

The finding: a default that reached production three times out of three

Every one of the three portals publishes this as the catalogue's own identity:

$ curl -s https://data.medicaid.gov/data.json | jq -r '."@id"'
http://dkan/data.json

This is not three publishers making the same mistake. It is line 3 ofschema/collections/catalog.json in DKAN itself, shipped as the default catalog template, inherited by every deployment that does not override it. The hit rate in our census is three out of three.

The consequence is small and precise. A data.json file is JSON-LD, so its @id is the subject every statement in the document hangs from. Three federal catalogues currently describe their contents against the same non-resolvable subject, so merging any two of them merges their datasets onto one catalogue node. That merge is the ordinary case for anyone aggregating DCAT-US, which is what data.gov does.

We have drafted a reproducible issue for the DKAN maintainers proposing that the identity be derived from the configured site base URL, with the template used only as a fallback. We have not filed it. Our search of the DKAN tracker was inconclusive rather than clean, so the right next step is to ask a maintainer whether this is already known or deliberate before opening anything.

The defect that is not DKAN's fault

The federal DCAT-US 1.1 JSON-LD context sets "@vocab": "http://www.w3.org/ns/dcat#". Any key the context does not explicitly map therefore becomes a term in the W3C DCAT namespace, whether or not DCAT defines it. Across the three portals this mintsdcat:references 368 times anddcat:_update 7 times. We checked both against the authoritative vocabulary at w3.org/ns/dcat.ttl. Neither exists.

references is a legitimate Project Open Data field that the context simply forgets to map. _update is an internal field name that has leaked into a published catalogue and then been promoted into a W3C namespace on its way out. Neither is DKAN's doing, and both affect every publisher using the federal context. Attribution matters here as much as detection: a finding filed against the wrong party does not get fixed.

What the publishers themselves got right, and one thing they did not

On the checks their operators control, the two CMS portals are good. All 886 bureau codes across data.medicaid.gov and data.healthcare.gov are well formed and present in the authoritative OMB register, and exactly one required field is missing across 886 datasets. That is a better record than most of the federal estate we measured in the companion study, and it deserves saying plainly.

The exception is data.sba.gov, which omits bureauCode on all 25 of its datasets. The Small Business Administration is a federal agency and the DCAT-US 1.1 federal profile requires that field. Nothing catches it, and the reason is the subject of the companion study: federal publishers are registered with data.gov under the non-federal schema, which does not require it. The platform is not at fault, the publisher has made an ordinary omission, and the assurance layer that exists specifically to catch ordinary omissions has been pointed somewhere else.

The artefact

The platform profile, the census pipeline, the per-portal measurements, the draft upstream issue and the build report are public, with eighteen offline tests pinning every published claim so that an upstream change cannot silently rewrite a finding. Code is MIT and the profile and documentation are CC BY 4.0. No DKAN source is redistributed. The wider study of the federal catalogue estate that this profile sits inside is published alongside it.

If you operate a DKAN portal, or any DCAT-US catalogue, we will send you the rows that name your deployment and the queries that produced them, at no charge. Write to fabio@thetesseractacademy.com.