AIPS DPP — Conformance Levels

This section defines the conformance classes and validation expectations for implementers of the AI Product Digital Product Passport (AIPS DPP) profile.
It complements the BPS DPP Core specification by defining AI-specific extensions, Inline/ByRef requirements, and verification rules.

---

1. Purpose

Conformance levels ensure consistent implementation across AI product producers, validators, and auditors.
They define what must be included in a compliant Lite or Full AIPS DPP and how each DPP should be validated against the BPS Core and AIPS extension artifacts.

---

2. Conformance Classes

Conformance Class	Intended Audience	Description	Access Model
AIPS-DPP-Lite	Public marketplace discovery, consumer pre-onboarding	Flattened passport; Inline sections only; contains summary of model, evaluation, and risks.	Public (read-only)
AIPS-DPP-Full	Auditors, regulators, internal compliance, enterprise partners	Complete passport; Inline and ByRef sections; includes provenance, detailed evaluation, and policy evidence.	Authenticated (role-based or token-based)

---

3. Mandatory and Optional Sections

Section	Lite (Inline)	Full (Inline/ByRef)	Description
Model Card	✅ Required	✅ Required	Describes model type, version, purpose, limitations.
Evaluation Results	✅ Required	✅ Required	Summarized metrics and evaluation datasets.
Training Data	✅ Required	✅ Required	Dataset name, version, and provenance summary.
Training Pipeline	⚪ Recommended	✅ Required	Framework, pipeline metadata, or reference URI.
Risk Register	⚪ Recommended	✅ Required	Known risks, severity, mitigations, and references.
Policy Findings	⚪ Optional	✅ Required	Results of governance or residency checks.
Knowledge Graph Snapshot	⚪ Optional	⚪ Optional	Optional RDF/JSON-LD graph describing model lineage or relationships.

---

4. Validation Layers

Each AIPS DPP must pass two validation layers:

Layer	Validation Artifacts	Description
Layer 1 — BPS Core Validation	bps-dpp-core-0.1.schema.json, bps-dpp-core-0.1.shacl.ttl	Validates general DPP structure and cross-domain consistency.
Layer 2 — AIPS Extension Validation	aips-dpp-0.1.schema.json, aips-dpp-0.1.shacl.ttl	Validates AI-specific sections (modelCard, eval, trainingData, etc.).

Both layers must pass for a DPP to be considered AIPS-compliant.

---

5. Validation Workflow

1. Schema Validation
   Validate JSON-LD structure using aips-dpp-0.1.schema.json (includes references to BPS schema).

2. SHACL Validation
   Validate semantic and structural constraints:

   • BPS Core → ensures presence of Inline or ByRef for each section.
   • AIPS Extension → enforces AI-specific field rules (e.g., modelCard required).

3. Hash and Signature Verification
   Verify contentHash and signature using canonicalized payload and registered producer public key.

4. Profile Verification
   Confirm that the profiles field includes the URI:
   https://kivanura.org/spec/aips/dpp/0.1/

---

6. Conformance Summary Table

Requirement	Lite	Full
subject, issuer, issuedAt, status	✅	✅
contentHash, signature	✅	✅
modelCardInline or modelCardByRef	✅	✅
evalInline or evalByRef	✅	✅
trainingDataInline or trainingDataByRef	✅	✅
trainingPipelineInline or trainingPipelineByRef	⚪	✅
riskInline or riskByRef	⚪	✅
policyInline or policyByRef	⚪	✅
kgInline or kgByRef	⚪	⚪
Digital Signature Verification	✅	✅
SHACL Validation (BPS + AIPS)	✅	✅

---

7. Lifecycle and Deprecation

• Each AIPS DPP version (e.g., 0.1) inherits validation logic from the corresponding BPS Core version (0.1).
• When AIPS introduces new fields:
  • Minor version bump if backward compatible (e.g., add inferenceLatency).
  • Major version bump if validation rules change (e.g., new required section).
• Deprecated fields remain valid for at least one full minor version before removal.

---

8. References

• BPS DPP Core Specification
• AIPS DPP Schema
• AIPS DPP SHACL Shapes
• AIPS DPP Context

---

Version: 0.1
Maintained by: Kivanura Foundation
Status: Draft for public review