Skip to main content

PDS vs. PROD – Deployment and Semantics

A recurring design principle in the Base Product Specification (BPS) is the clear separation between:

  • PDS (Product Descriptor Specification)
    A deployment blueprint describing how a product is instantiated, delivered, and operated.

  • PROD (Product Ontology/Description)
    A semantic blueprint describing what the product is, its meaning, purpose, and relationships.

1. Origins in the Data Product Space​

In the data community, two complementary but independently initiated efforts emerged:

  • DPDS (Data Product Descriptor Specification, Open Data Mesh)

    • Declarative deployment spec.
    • Defines input/output ports, infrastructure needs, SLAs, ownership, etc.

  • DPROD (Data Product Ontology, Enterprise Knowledge Graph Foundation)

    • Semantic description.
    • Defines product meaning, business context, relationships, compliance attributes.

⚠️ Importantly, DPDS and DPROD were not originally designed to complement one another — they arose from different communities with different priorities. Yet, in practice, they address two halves of the same need.

2. Why the Separation Matters at Meta-Level​

At the meta-product level, having both PDS and PROD makes strategic sense:

  • Deployment vs. Semantics are fundamentally different concerns.

    • Deployment is about operational instantiation (who runs what, where, how).
    • Semantics is about conceptual identity and governance (what it means, why it exists, how it relates).

  • This separation enables:

    • Technology neutrality: Different deployment platforms, same semantic backbone.
    • Interoperability: Multiple products can interrelate semantically even if deployed differently.
    • Governance clarity: Regulators, auditors, and business stakeholders engage more with PROD than PDS.
    • Evolution resilience: Deployment standards evolve faster; semantics remain stable.

3. Application Beyond Data​

By elevating this distinction to BPS, every product domain can benefit:

  • AI Products:

    • AIPDS = how a model or agent is deployed (datasets, endpoints, monitoring).
    • AIPROD = what the model is for, its role, ethical and risk semantics.

  • Physical Products (e.g., a storage device):

    • PHPDS = factory production details, delivery logistics, warranty services.
    • PHPROD = classification, capacity semantics, compliance certifications.

  • Software Products:

    • SWPDS = deployment descriptor (Kubernetes manifest, OpenAPI, infra details).
    • SWPROD = semantic purpose (e.g., "payment orchestration service").

4. Strategic Insight​

The PDS/PROD duality ensures that product specifications are both operationally actionable and semantically meaningful:

  • Without PDS, a product cannot be deployed in a controlled, reproducible way.
  • Without PROD, a product cannot be understood, governed, or related in context.

Together, they form the two halves of a complete product specification.

5. Illustrative Comparison of PDS and PROD Across Domains​

The following table demonstrates how the PDS/PROD duality applies across different product domains.
These examples are illustrative only — spec creators may choose prefixes that are broad (e.g., PHPDS for all Physical Products) or granular (e.g., STORPDS for Storage Devices, AUTOPDS for Automotive Products) depending on their needs.

Domain (Example)Deployment Spec (PDS)Semantic Spec (PROD)Scope & PurposeTypical ArtifactsPrimary Audience
Data ProductsDPDSDPRODDPDS: declarative deployment (ports, infra, SLAs). DPROD: semantic meaning, governance.YAML descriptors, ontologies, catalogsData platform teams, data stewards, consumers
AI ProductsAIPDSAIPRODAIPDS: how models/agents are deployed and monitored. AIPROD: what the AI is for, risks, compliance.Model cards, monitoring configs, risk profilesMLOps, AI ethics/governance, business owners
Physical ProductsPHPDSPHPRODPHPDS: manufacturing, logistics, lifecycle. PHPROD: classification, certifications, regulatory semantics.BOMs, warranty docs, ISO certsSupply chain, regulators, product managers
Software ProductsSWPDSSWPRODSWPDS: deployment manifests (e.g., Kubernetes, OpenAPI). SWPROD: semantic purpose, business context.Helm charts, OpenAPI specs, service catalogsDevOps, architects, business stakeholders

6. Meta-Level View: Every Product Has PDS and PROD​

7. Visualizing PDS vs. PROD​

🔎 Important Clarification:

  • The prefix choice is illustrative, not prescriptive.
  • A community may adopt broad categories (e.g., PHPDS for all physical products) or define fine-grained ones (e.g., STORPDS for storage, AUTOPDS for automotive).
  • What matters is the separation of concerns:
    • PDS = deployment blueprint (how a product is instantiated).
    • PROD = semantic blueprint (what a product means in context).

Where do the following cross-domain elements sit?​

  • Purpose / IntendedUse → PROD (semantic blueprint)
  • Classification → PROD (semantic blueprint)
  • Certification → PROD (semantic/governance; may reference external bodies)
  • HealthIndicator → PDS (operational/observability), with summaries optionally surfaced in PROD

8. Conclusion​

The lesson learned from the data space (DPDS and DPROD) is that deployment and semantics should always be treated as distinct, but complementary dimensions of any product.

At the BPS level, we therefore generalize this into a universal pattern:

  • Every product domain should define its own PDS and PROD pair.
  • This creates both operational clarity and semantic richness, ensuring products can be deployed, governed, and discovered consistently across domains.