Schema versioning.
EDINET revises its XBRL taxonomies over time. Concepts get added, renamed, and reorganised. The ontology absorbs those changes, so revenue stays revenueacross the cutover. You version against the ontology, not against EDINET’s schemas.
EDINET schemas move; your fields don’t
Upstream, EDINET ships new XBRL schema versions periodically. A concept you read last year might be tagged under a new element this year. If you consumed the raw tags directly, every such revision would be a breaking change. Axiora insulates you: the ontology maps both the old and new elements to the same canonical field, so revenue stays revenue across the cutover.
The contract
When EDINET publishes a new schema, the work happens inside the ontology, not in your code:
EDINET ships a new XBRL schema.
New or renamed elements appear in the source filings.
Mappings are added or updated; the version bumps.
The new elements are mapped to existing canonical fields. The ontology version moves (semver).
The field names you depend on do not move.
No endpoint changes shape. You keep reading the same canonical fields.
Reading the version
Every response stamps the ontology version it was computed under at meta.ontology_version. The active version is v2.1.0. You can also query it directly at GET /v1/ontology/version.
{
"data": { "...": "..." },
"meta": {
"ontology_version": "2.1.0"
}
}meta.ontology_versionis the version that matters to your code. It tells you which mapping produced the response. EDINET’s own schema versions are an upstream detail the ontology hides from you.
Pinning a version
If you need a response computed under a specific ontology version to stay reproducible (for a citation, a backtest, or an audit trail) capture its freeze token. Replaying with ?as_of=<token> returns the original bytes under the version they were computed with, even after the ontology has moved on to a later version.