Skip to main content

Versioning

AtlasCore maintains version stability across multiple dimensions — API, data, and disclosure outputs.

API versioning​

The API is served under the /v1 prefix. Breaking changes will be introduced under a new version prefix (e.g. /v2).

Within /v1, changes follow an additive pattern:

  • New endpoints are added without breaking existing ones
  • New response fields are added without removing existing ones
  • New query parameters are optional with sensible defaults

Data versioning​

Emission factor sets​

Each NGA edition becomes a versioned factor set (e.g. au_nga_2024 for the 2023-24 workbook):

  • Only one set per source can be active at a time
  • Superseded sets are preserved for historical queries
  • Amendment types: new_edition, correction, restatement
  • Amendment history includes diff counts and linked prior set metadata

Dataset snapshots​

Every data extraction creates a numbered snapshot:

  • latest policy always returns the most recent successful snapshot
  • pinned policy references specific snapshot IDs for reproducibility
  • Quality metrics are computed per snapshot

Framework registry​

AASB S2 framework coverage is versioned:

  • Multiple standard versions are supported simultaneously (e.g. September 2024, December 2025 amended)
  • Each registry query returns a stable evidence_hash
  • Coverage statuses are resolved from pack context at query time

Disclosure artifact versioning​

Disclosure bundles are stored and versioned per company/tenant/pack scope:

  • Each generation creates a new artifact (bundles are never overwritten)
  • Artifact history is queryable with pagination
  • Latest-artifact aliases provide convenient access without knowing the artifact ID
  • Bundle metadata records the data versions, rollup basis, and generation timestamp

Deprecation policy​

When an API change requires deprecation:

  1. The deprecated feature is documented with a removal timeline
  2. The replacement is available before the deprecated feature is removed
  3. Breaking changes are communicated through release notes

Pack release versioning​

Packs follow a release-based versioning model:

  • Each release freezes the pack configuration and dataset bindings
  • Rollback to prior releases is supported
  • Release history is queryable through admin endpoints