Provenance and precedence

Every fact on a JMAD page carries a record of where it came from. This page explains that record, how JMAD picks a winner when two sources disagree, and how to cite a value in your own work.

The provenance record

Each field value is attached to one provenance object:

A field also carries a tier: free, paid, or premium (paid and premium are planned, see licensing and attribution). The tier travels with the value, not with the source, because the same source can supply both free and gated fields.

Observation history

JMAD preserves observations when a source changes a value. Replaying the same source record, field, raw payload reference, and value within a tile does not add a duplicate. Changed values and distinct aliases remain stored with their provenance.

Before consolidation or source enrichment (such as reverse geocoding) uses those observations, JMAD selects the current revision for each source record and field by the latest retrievedAt. When retrieval times match, the lexicographically greatest rawPayloadRef wins. All values from that revision remain eligible, including multiple aliases. Earlier revisions stay in the observation store but do not compete with current evidence for published fields or geometry. The public asset response is a consolidated view, not an observation-history endpoint.

The registry sources

These sources supply per-building records that are matched onto footprints JMAD already has, rather than creating buildings of their own. A record only contributes facts when it matches exactly one building; unmatched and ambiguous records stay in the archive and contribute nothing.

mankan is a point-in-time snapshot rather than a live feed: its publisher serves the register only through a live browser session, so JMAD ingests a periodically captured copy. A building absent from it may simply predate the capture.

Precedence

A field can have observations from several sources. Consolidate picks a winner with a fixed precedence order per field, then keeps the rest as losing candidates rather than discarding them:

Within one source, the newest observation wins. Between sources, the table above wins regardless of recency: an older PLATEAU height beats a newer OSM one, because PLATEAU's survey method is more reliable for that field than a hand-entered tag.

The Tokyo green-building and mankan registers sit at the end of the orders they appear in; jreit and edinet rank first. The registers are authoritative about the filing they describe, but a filing describes a building at one moment — often before it was finished — so a survey source that reflects the building as built takes precedence. A greenbuilding completion date still in the future when JMAD reads it (工事完了(予定)年月 is a planned date) is recorded at confidence 0.6 for the same reason, as is a greenarchive completion year inferred from the filing year.

OSM, PLATEAU, the Address Base Registry, e-Stat, Wikidata, Nominatim and the Tokyo green-building sources load as gather sources. J-REIT portfolios load for the configured REIT selection, EDINET only for configured report IDs with an API key, and mankan from a periodically captured snapshot. A registry or disclosure record contributes only when it matches exactly one existing building. Foursquare and 登記 (touki) are not implemented.

Appraisal dates must accompany the winning amount in the same source record, archived payload, and fetch. Undated amounts remain undated; retrieval time is never the valuation date.

Repeated fields

aliases and assetTypes hold a list, so precedence runs once per entry rather than once for the field. Candidates are grouped first — aliases by their normalised text, asset types by their category — and the table above picks a winner inside each group. The result is one published entry per distinct alias and one per distinct use, each with its own provenance and its own losing candidates.

That is why a building can publish both office and retail: those are two categories, so both survive. apartments from OSM and residential from a disclosure are one category, so one wins and the other becomes its losing candidate.

Conflicts

A losing candidate whose value differs from the winner is recorded on the field as a conflict: the value, its unit, and which source it came from. For 丸ビル (Marunouchi Building), heightM reads 179.2 m from Wikidata, and the field carries a conflict entry showing OSM's 18 m. Nothing overwrites the losing value or hides it; you decide what to do with a disagreement JMAD has already surfaced.

{
  "value": 179.2,
  "unit": "m",
  "tier": "free",
  "provenance": {
    "source": "wikidata",
    "sourceRecordId": "Q1332019#P2048",
    "sourceUrl": "https://www.wikidata.org/wiki/Q1332019",
    "extractionMethod": "wikidata-claim",
    "retrievedAt": "2026-08-30T04:00:00Z",
    "confidence": 0.85
  },
  "conflict": { "value": 18, "unit": "m", "source": "osm" },
  "estimated": false
}

Asset types are the exception: they carry no conflict and are not counted in conflictsFlagged. Sources naming different uses for one building is the expected case, not a disagreement to resolve, so each use is published in its own right.

The sources list

Every page carries a sources array, served on its own by GET /japan/api/v1/assets/{id}/sources and by the MCP get_asset_sources tool. There is one entry per source record consulted for that building, identified by its source and sourceRecordId.

An entry's fields lists the fields that record won: the fields whose published value carries that entry's source and sourceRecordId in its own provenance. A source that observed a field but lost it to a higher-precedence source is not listed under that field, so fields answers "what did this source supply" and never "what did this source look at". A source that won any one asset type is listed once under assetTypes.

Two consequences to plan for:

• An entry can have an empty fields array. A record that lost every field it observed, or that only supplied geometry, still appears, because sources is the complete list of records consulted and is what attribution is owed to.
• To find who disagreed about a field, read that field's own conflict, above. The losing side of a field is published per field, not per source.

Estimated values

Reported gross floor area (J-REIT, EDINET, or a green-building register's 延べ面積) wins when available and is not marked estimated. Otherwise gross floor area is computed as footprint times total floors (footprintM2 × (floorsAbove + floorsBelow)), attributed to source dnk with extractionMethod: "computed". A field built this way is marked estimated: true on the page and in the API response, so you can filter it out if you only want directly sourced facts. 丸ビル's gfaM2 is estimated from its 9,890 m² footprint and 41 total floors.

A building inside a larger complex can also borrow yearBuilt and architect from it. When a Wikidata item describes the complex rather than the building (GranTokyo, not its South Tower), that item does not name or anchor the building, but it still lends those two fields at the lowest precedence, used only when none of the building's own sources supplies them. Such a field keeps the complex's Wikidata provenance with extractionMethod: "inherited-complex", is marked estimated: true, and carries inheritedFrom with the complex's nameJa and nameEn (either can be null). The building page labels it "estimated, from the complex …".

Citing a value

Cite the sourceUrl and retrievedAt on the specific field you used, not the building page as a whole. Two fields on the same page can trace to different sources and different retrieval dates. The Markdown twin of every page renders this per field, so an agent quoting a fact can quote its source in the same breath.

A value from jreit cites the REIT's own page for that property, so a citation lands on the disclosure a reader can check rather than on the portfolio table or data feed JMAD fetched. A REIT that publishes no per-property page is cited at its human-readable portfolio listing, not the data feed JMAD fetched. Every edinet value cites the filing document it was read from.

Access is not a licence. greenarchive reads pages whose publisher asserts all rights reserved, so JMAD classifies it as proprietary and treats the extracted facts, not the page text or images, as what it may carry forward — the same treatment jreit gets. See licensing and attribution before reproducing anything sourced from it.

See the field dictionary for what each field means, and DNK asset IDs for how the building itself is identified.

Inspect evidence on a building page

Source chips beside building attributes open the winning field's source URL in a new tab. The Sources & conflicts tab lists joined source records and retained disagreements. A joined record is evidence to inspect, not independent verification of every published value. Estimates and conflict flags remain visible on the building record.

Evidence changes and history

Consolidation compares a field's value, unit, tier, winning provenance and retained alternatives. A source record, URL, retrieval date, extraction method or confidence change can therefore create a new canonical version and publication job even when the displayed value is unchanged. Geometry provenance and venue evidence are compared too. Reordering identical alternatives does not by itself create a change.

History's changed-field list includes evidence changes for scalar fields, aliases and asset types. Consumers should inspect provenance when a field appears in history with the same displayed value. Geometry evidence updates regenerate the page, although geometry is not a scalar entry in that changed-field list.

An exact replay does not create another version merely because JMAD recomputes a dnk value later. For dnk provenance with extractionMethod: computed, comparison ignores only the recomputation timestamp; other provenance attributes and the computed value still matter. Retrieval-date changes from external sources remain meaningful.