AIPS DPP — Versioning Policy

The AIPS DPP versioning policy ensures that producers, validators, and consumers can evolve and integrate AI Product Passports predictably and compatibly over time.
It inherits the principles of the BPS DPP Core versioning model, with additional AI-specific guarantees.

1. Purpose

This document defines how versions of the AIPS DPP profile evolve, how they relate to the underlying BPS DPP Core, and how semantic versioning signals compatibility and validation expectations.

The version identifier follows Semantic Versioning (SemVer) format:

<major>.<minor>[.<patch>]

Example:
0.1 → initial draft
1.0 → first stable release
1.1 → backward-compatible extension

2. Relationship with BPS DPP Core

Layer	Namespace	Version Example	Compatibility
BPS DPP Core	`https://kivanura.org/spec/bps/dpp/`	`0.1`	Base ontology, context, and validation model
AIPS DPP Profile	`https://kivanura.org/spec/aips/dpp/`	`0.1`	Extends and references BPS DPP Core version `0.1`

AIPS DPP versions are tightly coupled to a specific BPS DPP Core version.
Example: aips-dpp-0.1 depends on bps-dpp-core-0.1.

3. Release Coupling Model

AIPS and AIPS DPP are semantically aligned but release-independent.
They evolve on separate versioning tracks, each governed by its own lifecycle and changelog.

Layer	Example Version	Release Cadence	Dependency Relationship
AIPS (AI Product Specification)	`1.3`	Evolving ontology for AI products	Defines classes and metadata (e.g., `aips:Model`, `aips:Dataset`)
AIPS DPP (Passport Layer)	`0.1`	Evidence and attestation schema	Depends on specific AIPS ontology but can version independently

3.1 Independence

AIPS defines what an AI product is.
AIPS DPP defines how the product’s evidence and trust metadata are captured, flattened, and signed.
Each can release updates without forcing a corresponding bump in the other.

3.2 Compatibility Declaration

Each AIPS DPP release includes an explicit compatibility field in its metadata:

{
  "aipsDppVersion": "0.1",
  "compatibleWithAips": ["1.2", "1.3"],
  "dependsOnBpsCore": "0.1"
}

This ensures clarity between ontology version (AIPS) and passport schema version (AIPS DPP).

3.3 Example Scenario

Scenario	AIPS Version	AIPS DPP Version	Validity
Base launch	1.2	0.1	✅ Supported
Ontology extended (e.g., new model type)	1.3	0.1	✅ Still valid
New explainability evidence added	1.3	0.2	✅ Additive
Major validation overhaul	2.0	1.0	⚠️ Requires migration

In summary: AIPS defines structure, AIPS DPP defines proof. The two are loosely coupled — interoperable, but independently governed.

4. Versioning Rules

4.1 Major Versions (`X.0`)

Introduce breaking changes or incompatible validation logic.
Require new SHACL shapes, schema updates, and a new context namespace.
Consumers must explicitly migrate to the new namespace and validation layer.
Example: 0.x → 1.0 transition after public review and stabilization.

4.2 Minor Versions (`0.X`)

Introduce additive, backward-compatible enhancements:
- New Inline/ByRef sections (e.g., explainabilityInline).
- Additional optional properties.
- Updated enumerations for metricName, riskCategory, etc.
Do not break validation of earlier documents.

4.3 Patch Versions (`0.1.X`)

Reserved for non-breaking corrections such as:
- Typos in SHACL constraints or examples.
- Clarifications in documentation.
- Adjusted descriptions without structural impact.

5. Namespace and Canonical URI Policy

Each major or minor release defines a stable namespace under https://kivanura.org/spec/aips/dpp/.

Version	Canonical URI	Description
`0.1`	`https://kivanura.org/spec/aips/dpp/0.1/`	Draft, first public release
`1.0`	`https://kivanura.org/spec/aips/dpp/1.0/`	First stable release
`1.1`	`https://kivanura.org/spec/aips/dpp/1.1/`	Backward-compatible extension

Rule:

Once published, versioned URIs must remain immutable and publicly dereferenceable.

6. Backward Compatibility

A valid AIPS DPP document must continue to validate under the version it was issued for.

Scenario	Expected Behavior
Minor or patch upgrade	Still valid under new version; older validators may skip unknown fields.
Major upgrade	Revalidation required under new namespace and schema.
Deprecation	Deprecated terms remain valid for at least one minor version before removal.

7. Deprecation and Lifecycle States

Each AIPS DPP version passes through the following lifecycle:

Lifecycle Stage	Description
Draft	Working version, subject to change. Not for production issuance.
Candidate	Feature-complete; validation and review ongoing.
Stable	Public release; production-grade and immutable.
Deprecated	Still valid but recommended for migration.
Archived	No longer maintained; only for historical references.

A deprecation notice will be posted in:

/docs/aipdpp/aips-dpp-versioning-policy.md
CHANGELOG.md under /static/spec/aips/dpp/<version>/

8. Compatibility Matrix

BPS Core	AIPS	AIPS DPP	Compatibility	Notes
`0.1`	`1.2`	`0.1`	✅ Full	Current baseline
`0.1`	`1.3`	`0.1`	✅ Full	No schema change required
`0.1`	`1.3`	`0.2`	✅ Partial	Additive only
`1.0`	`2.0`	`1.0`	✅ Full	Stable generation
`1.0`	`3.0`	`2.0`	❌ Incompatible	Requires migration

9. Governance

All versioning changes follow the Kivanura Specification Governance Model:

Draft updates are tracked in the AIPS repository (/spec/aips/dpp).
Minor/major changes are reviewed via public pull requests.
Finalized artifacts are published to versioned canonical URIs.
Deprecated versions are archived with their full validation suite.

10. References

Status: Draft Maintained by: Kivanura Foundation Applies to: AIPS DPP 0.1 and above

1. Purpose​

2. Relationship with BPS DPP Core​

3. Release Coupling Model​

3.1 Independence​

3.2 Compatibility Declaration​

3.3 Example Scenario​

4. Versioning Rules​

4.1 Major Versions (X.0)​

4.2 Minor Versions (0.X)​

4.3 Patch Versions (0.1.X)​

5. Namespace and Canonical URI Policy​

6. Backward Compatibility​

7. Deprecation and Lifecycle States​

8. Compatibility Matrix​

9. Governance​

10. References​