Data lifecycle

JMAD never overwrites a fact. A correction is a new record next to the old one, not an edit in place. This page covers how that works and what it means for anyone polling JMAD for changes.

Bitemporal records

Every building carries three timestamps: validFrom, validTo, and recordedAt. validFrom/validTo describe the period the record claims to be true for in the real world; recordedAt is when JMAD wrote that version. When a correction happens, the previous row's validTo is closed and a new row is inserted with a fresh recordedAt. The previous row still exists. Nothing is deleted and nothing is patched.

This matters if you cache JMAD data or build reports from it: a value you fetched last month is still the value JMAD had on record last month, even if the current page shows something else now.

History on every page

Every building page shows its own history: one entry per version, whether that version was the building's first (created) or a later correction (updated), and which fields changed. If only a venue changed and the building's own fields stayed put, the building's history stays at one entry. This is a page-level view of the same bitemporal versioning, not a separate mechanism.

The change feed

Alongside the page-level history, JMAD writes one row per published version to a global change feed: the building ID, the version's recordedAt, whether it was a creation or an update, and when the feed entry itself was written. This is the mechanism for delta polling. If you're syncing JMAD into your own store, poll the feed's changed_at cursor rather than re-crawling every building page on a schedule.

Re-publishing the same bitemporal version, say after a retried job, is a no-op on the feed: entries are deduplicated on (building_id, building_recorded_at), so a redelivered job never doubles up.

📘

Note

The feed's changeKind today is only created or updated. Merges do happen — when two clusters collapse into one surviving ID, the retired ID's page is withdrawn and its record superseded — but there is no merged kind yet, so a merge reaches the feed as an update to the survivor and the loser simply stops appearing. Poll the retired ID's short link to see where it went. See DNK asset IDs.

Sitemap freshness

Every URL in JMAD's sitemaps carries a lastmod value pulled from the building's own recordedAt, never from when JMAD's servers happened to render the page. A build timestamp on every URL trains crawlers to ignore lastmod across the whole site; a value tied to the actual fact makes it worth reading.

Retention

observations and the change feed are append-only, by design, and right now nothing deletes from either. Whether that holds at nationwide scale, or whether older rows eventually move to cold storage, is an open question. No retention window is defined today. Don't build a workflow that assumes historical rows disappear after any particular period, because none currently does, and don't assume the current unbounded-retention behavior is a guarantee either.

See provenance and precedence for how a given version's field values are chosen, and areas and coverage for the aggregate numbers that summarize this data area by area.

Recent changes on the website

Open Recent changes from the site header. The feed reads the persisted history of the 500 most recently updated published building records. It shows recorded creation and update events, newest first, with 20 events per page. It is a bounded view of published history, not a complete audit export.

Search by displayed building name or DNK ID, or filter by location, change type, and asset type, then choose Apply filters. Expand an event to see its changed fields and open the current building record. Dates and times are displayed in Japan Standard Time, UTC+9. The event's record date and the current building page's publication date are labeled separately; the latter is not a historical event publication timestamp.

The feed describes changes to database records. It does not infer acquisitions, demolition, completion, or other events in a building's life from a record update. Checks that do not change published fields do not add history events.