AIPS DPP Implementation Guide for Producers

Purpose

This guide explains how AI Product producers can create, publish, and maintain Digital Product Passports (DPPs) that comply with both the Base Product Specification (BPS) DPP Core and the AIPS DPP Profile.

A DPP provides transparency and verifiability for AI Products thereby allowing internal stakeholders, partners, and regulators to review essential metadata, provenance, and trust signals before or after onboarding.

---

1. Composition and Dependencies

Each AIPS DPP document is composed of:

1. The BPS DPP Core context and validation layers
   (bps-dpp-core-0.1.context.jsonld, .shacl.ttl, .schema.json)
2. The AIPS DPP Profile context and domain-specific extensions
   (aips-dpp-0.1.context.jsonld, .shacl.ttl, .schema.json)
3. Optional additional references for related AI model governance artifacts (e.g., Model Cards, Evaluation Reports).

All AIPS DPP JSON-LD instances must include both contexts:

"@context": [
  "https://kivanura.org/spec/bps/dpp/0.1/bps-dpp-core-0.1.context.jsonld",
  "https://kivanura.org/spec/aips/dpp/0.1/aips-dpp-0.1.context.jsonld"
]

---

2. Key Implementation Steps

Step 1 — Define Product Identity

Each DPP begins by identifying the AI Product using a stable URI or URN.

"subject": "urn:org:ml:product:fraud-detector:v2.1.0",
"issuer": "did:org:aiplatform",
"issuedAt": "2025-10-10T10:00:00Z",
"status": "Valid"

Tip: The subject should match the canonical ID used in your internal product catalog or AI registry.

---

Step 2 — Include Core BPS DPP Fields

Every AIPS DPP inherits these mandatory core fields from the BPS DPP Core:

Field	Type	Description
subject	string	Product identifier
issuer	string	DID or org ID of issuer
issuedAt	dateTime	Timestamp of issuance
status	string	Valid, Revoked, or Superseded
contentHash	string	Canonicalized content hash
signature	string	Digital signature or verifiable credential proof

These are verified during API retrieval or marketplace display.

---

Step 3 — Add AIPS-Specific Inline and ByRef Sections

Each AI Product DPP must include at least one Inline or ByRef section for each supported domain area.

Section	Inline Example	ByRef Example	Purpose
modelCardInline	Basic model description and intended use	—	Quick transparency
modelCardByRef	—	Link to a full Model Card document	Full metadata
evalInline	Summary metrics (e.g., accuracy, F1-score)	—	Transparency
evalByRef	—	Link to evaluation dataset or detailed report	Verification
trainingDataInline	Dataset names and types	—	Light provenance
trainingDataByRef	—	URI of dataset manifests or lineage	Deep provenance
riskInline	Known risks and mitigations	—	Governance
riskByRef	—	External risk documentation	Compliance

All Inline sections should be small and human-readable; ByRef sections must include at least uri and hash.

---

Step 4 — Generate Hashes and Digital Signatures

AIPS DPPs inherit signature and hashing logic from BPS DPP Core:

1. Canonicalize the JSON-LD (as per bps-dpp-core-0.1.c14n.md)
2. Compute contentHash (e.g., SHA-256)
3. Sign the hash with an organizational private key using JWS or VC signature standards.

Producers must store the public key (or DID Document) to enable downstream verification.

---

Step 5 — Publish Lite and Full DPPs

Type	Purpose	Typical Audience
Lite DPP	Flattened public view; no external calls required	Marketplace browsers, general users
Full DPP	Complete inline + ByRef bundle	Authorized auditors, regulators, platform teams

Example API endpoints:

GET /api/v1/dpp/{productId}?lite=true
GET /api/v1/dpp/{productId}?lite=false

Both variants use the same schema; the difference lies in the degree of detail.

---

Step 6 — Version and Lifecycle Management

Each new AI Product release or major retraining event must issue a new DPP:

Scenario	Action
Model retraining	New version and new DPP with updated hashes
Model update with same data	Increment patch version
Model deprecated	status = "Revoked"
Model replaced	status = "Superseded" and add supersedes reference

All past DPPs should remain verifiable for traceability.

---

Step 7 — Publish via Marketplace or Registry

AIPS DPPs are discoverable in marketplaces or registries that support the BPS DPP API contract. Each AI Product tile should expose a QR code or deep link resolving to the DPP API endpoint.

For example:

https://aips.kivanura.org/api/v1/dpp/urn:org:ml:product:fraud-detector:v2.1.0

---

3. Validation Workflow

1. Core validation — check against bps-dpp-core-0.1.shacl.ttl
2. Domain validation — check against aips-dpp-0.1.shacl.ttl
3. Integrity validation — verify hash and signature
4. Policy validation — optional; cross-reference compliance results

Producers should automate this validation via a CI/CD pipeline before publishing.

---

4. Recommended Tooling

Function	Recommended Tool	Notes
JSON-LD canonicalization	pyld or rdf-canonize	Used to compute contentHash
SHACL validation	rdf-validate-shacl or TopBraid SHACL API	Core + AIPS layers
Signature generation	JWS or VC libraries (e.g., did-jwt-vc, Jose4j)	For verifiable signing
API hosting	OpenAPI-compatible framework (e.g., FastAPI, Express)	Implements BPS DPP contract

---

5. Governance and Audit Considerations

• Each DPP must have an identifiable issuer accountable for its contents.
• Revocation and supersession should be logged transparently.
• For externally shared DPPs, consider time-bound keys or temporary access tokens.
• Redaction rules can be defined for sensitive fields (refer to security-privacy.md in BPS DPP Core).

---

6. To Conclude

The AIPS DPP Profile operationalizes the principles of the BPS DPP Core for AI systems:

• Composes with BPS Core for structure and trust.
• Adds AI-specific metadata for model transparency.
• Supports Lite and Full passports for tiered disclosure.
• Enables verifiable, machine-readable governance for AI Products.

This approach ensures that AI Products within the AIPS ecosystem can be trusted, auditable, and interoperable across data and AI marketplaces.

---