The ontology layer.

“Revenue” has to mean the same thing whether you read it for one company in 2016 or another in 2025, under JGAAP or IFRS. The ontology makes that true: a versioned map from raw XBRL elements to canonical fields, applied by typed code.

Why an ontology

EDINET filings are XBRL: each number is tagged with a concept name, a context, and a unitRef. But two filers can tag the same economic figure differently, the same filer can change tags between years, and the three accounting standards in use (JGAAP, IFRS, US-GAAP) name things differently. Read the raw tags directly and every consumer re-implements the same reconciliation. The ontology does it once.

The result: a stable, canonical field name like revenue or stake_pct carries the same meaning across companies, years, and standards.

From XBRL element to field

A number is lifted from a schema-validated XBRL element by deterministic, typed code, identified by its concept, context, and unitRef. It is then mapped through the ontology to a canonical field. Nothing is inferred, rounded, or guessed along the way; the XBRL document is the source of truth and the database is a cache of what the parser read.

mapping

typed XBRL element            ontology (v2.1.0)         canonical field
─────────────────────────     ──────────────────────     ───────────────
jppfs:NetSales        ┐
jpigp:Revenue         ├──────▶  map → normalise    ──────▶  revenue
us-gaap:Revenues      ┘
jpcrp:StakePct        ───────▶  map → normalise    ──────▶  stake_pct

The ontology is queryable: GET /v1/ontology/fields lists the canonical fields, GET /v1/ontology/fields/{field_name} describes one, and GET /v1/ontology/version returns the active version.

Normalising across standards

Most concepts reconcile cleanly across JGAAP, IFRS, and US-GAAP. Some genuinely do not exist under a given standard, the important case. Where a concept has no equivalent, the field is not blank: it is null with a reason, which tells you a missing value is a genuine absence, not a zero.

A null is explained, not empty.

For example ordinary_income(経常利益) is structurally null under IFRS, which has no such concept. The ontology records why, and points you at the standard’s nearest equivalent. See Null reasons for the full table.

Numbers never touch a model

The ontology is typed code, not a language model. No figure is ever produced, corrected, or interpolated by an LLM. The one place a model is used is language (translating narrative sections and naturalising entity names) and that path never crosses into the numbers. The two layers are kept apart by construction; see the verifiability model.

Numbers

XBRL → ontology → field. Typed code only.

Deterministic mapping from schema-validated elements to canonical fields. No model in the path.

Language

Translations and names are LLM-assisted.

The model layer never sees, edits, or emits a number. The Japanese original is always preserved.

The version is pinned per response

The ontology is versioned with semver. The active version is v2.1.0. Every response stamps the version it was computed under at meta.ontology_version, so you always know which mapping produced a figure. When EDINET ships a new schema, mappings are added or updated in the ontology. The canonical field names you depend on do not move. See Schema versioning for that contract.