Skip to main content

Conformance

This section defines the requirements for conformance with the Base Product Specification (BPS).
It establishes what it means for an implementation to be considered BPS-conformant.

1. Normative Language​

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document
are to be interpreted as described in RFC 2119.

🔎 Note on Scope
This specification defines conformance rules for the BPS meta-framework only.
BPS, by design, is not a standalone implementation specification.
Its role is to provide a base ontology that domain-specific specifications (e.g., DPDS/DPROD for Data Products, AIPDS/AIPROD for AI Products) extend.
For additional details, see the Scope and Limitations section in the Introduction.

2. Conformance Targets​

Conformance is defined for two types of artifacts:

  1. Product Descriptor Specification (PDS)

    • A deployment-oriented specification of a product (e.g., DPDS, AIPDS, PHPDS, SWPDS).
    • Covers how a product is instantiated, delivered, and operated.

  2. Product Ontology/Description (PROD)

    • A semantic description of a product (e.g., DPROD, AIPROD, PHPROD, SWPROD).
    • Covers what a product is, its purpose, context, and governance.

Any BPS-conformant product type MUST provide at least one PDS and one PROD descriptor.
They may be published together or separately.

3. Conformance Requirements​

To be considered BPS-conformant:

  • Core Model

    • A conformant descriptor MUST use the entities and relationships defined in the BPS Meta-Model.
    • Extensions MAY be added, provided they do not contradict or redefine mandatory BPS terms.

  • PDS

    • A conformant PDS MUST describe at least one input interface and one output interface.
    • It MUST declare product versioning information (Draft, Published, Deprecated, Retired).
    • It SHOULD specify operational obligations (e.g., SLAs, service levels, warranties).
    • A conformant PDS SHOULD expose at least one HealthIndicator relevant to the domain (e.g., uptime, freshness, MTBF, drift).

  • PROD

    • A conformant PROD MUST define the product’s purpose and category.
    • It MUST include ownership and accountability information (an Agent entity).
    • It SHOULD include policy and risk profiles where applicable.
    • It MAY reference external ontologies (e.g., DCAT, Dublin Core, PROV-O).
    • A conformant PROD MUST define the product’s purpose (Purpose / IntendedUse).
    • A conformant PROD SHOULD provide at least one Classification entry where a relevant scheme exists.
    • A conformant PROD MAY reference Certification records where applicable.

  • Serialization

    • Conformant descriptors MUST be serializable in at least one machine-readable format.
    • Recommended formats include:
      • JSON/YAML for PDS.
      • RDF/Turtle/JSON-LD for PROD.

4. Levels of Conformance​

BPS defines three levels of conformance:

  1. Minimal Conformance

    • Includes required core fields only.
    • Suitable for lightweight or prototype products.

  2. Standard Conformance

    • Includes all mandatory elements and most recommended elements.
    • Suitable for enterprise adoption.

  3. Extended Conformance

    • Includes mandatory, recommended, and domain-specific extensions.
    • Suitable for regulated industries, critical infrastructure, or marketplace publication.

5. Extensions​

  • Implementers MAY define domain-specific extensions (e.g., automotive products, biotech products).
  • Extensions MUST declare their namespace to avoid collisions.
  • Extensions SHOULD provide mappings back to the BPS meta-model for interoperability.

6. Conformance Testing​

  • A BPS-conformant implementation MAY be validated using automated schema or ontology checkers.
  • Conformance testing SHOULD verify:
    • Structural validity (required entities and relationships present).
    • Semantic validity (references resolve correctly, ownership is clear).
    • Serialization validity (files parse correctly in chosen format).

7. Non-Conformance​

Any product descriptor that omits mandatory elements, redefines core concepts,
or fails serialization validity MUST NOT be described as “BPS-conformant.”

8. Profiles​

Implementers may define profiles of BPS that restrict or extend its usage.
Profiles MUST clearly declare:

  • Their scope.
  • Any additional constraints.
  • Their relationship to the base BPS specification.