API stability and versioning

Software, dataset and schema versions are independent. Software changes can fix routing without changing data. Dataset releases can revise evidence or add records without changing the schema. Contract changes require a schema version change. /v1/meta reports the imported dataset's marker and content hash.

v0.1 is pre-1.0 and may evolve. Additive fields, collections and relationships should be backward compatible where practical; clients should tolerate additional fields and unknown future evidence categories while validating the fields they consume. Removing fields, changing meanings, units or requiredness is a breaking change and must be explicitly recorded in the changelog and release manifest.

Stable public IDs are not recycled for different concepts. Prefer deprecated claims with migration notes before removing data. Retain deprecated records for at least one announced dataset release where practical. A future incompatible API contract should use /v2; do not silently repurpose /v1 behavior. No indefinite compatibility guarantee is made during research preview.

Pin dataset versions/content hashes for reproducible research. Keep release archives: the live service serves the current imported projection, not historical snapshots. The source Git commit ties data and interpretation history together.