Skip to main content

Glossary of Terms

This glossary defines key terms used throughout the Base Product Specification (BPS).
Where possible, definitions are aligned with established standards such as Dublin Core (DCTerms), W3C PROV-O, and FOAF.

A​

Agent​

A bearer of accountability or responsibility for a Product or Product Version.

  • Subtypes:
    • Human — An individual person.
    • Collective — A group, team, department, or organization.
    • Non-Human — An autonomous digital entity such as an AI agent, smart contract, or DAO.
    • Hybrid — A human augmented with AI or other enhancements.
  • Alignment: PROV-O prov:Agent, FOAF foaf:Agent.

Asset​

An underlying resource used by or exposed from a Product. Examples include datasets, trained models, API specifications, software components, physical components, or other reusable resources.

B​

Business Domain​

A Business Domain is any accountable function within the enterprise that owns and governs a specific capability, decision area, or semantic boundary — whether commercial, operational, control-oriented, or enabling.

In the context of product ownership, “business” refers to capability authority, not revenue generation.

C​

Capability Registry​

A registry of platform, domain, or enterprise capabilities that can be used to instantiate, operate, govern, or consume Products.

In a product-factory architecture, the Capability Registry enables automation layers such as PFI to determine which capabilities are available, suitable, approved, and reusable for a given product intent.

  • Purpose: Support capability discovery, blueprint selection, automation, and platform readiness checks.
  • Related: PFI, PDEP, Product Runtime Execution Services, Environment Registry.

CEP (Consumer Experience Plane)​

The plane that provides consumer-facing experiences for interacting with Products through their governed interfaces, such as OutputPorts and ServiceEndpoints.

CEP is not part of the Product itself; it is a set of presentation and interaction adapters — dashboards, notebooks, portals, embedded UIs, workflow interfaces, agentic experiences, and other consumption surfaces — that consume product ports.

In HDIP-aligned architectures, CEP corresponds to the demand-side product consumption plane.

  • Purpose: Make Products usable and valuable for specific consumer personas without coupling UI/UX into product semantics or deployment.
  • Principle: Products expose ports; experiences consume ports.
  • Related: OutputPort, ServiceEndpoint, Marketplace, HealthIndicator, Consumption Intent Record.

Certification​

A formal attestation that a Product or Product Version meets specified criteria.

A Certification may include issuer, certificate name or identifier, validity period, scope, assurance level, and optional evidence links.

Classification​

A structured categorization of a Product using a recognized scheme, industry taxonomy, domain taxonomy, or internal classification model.

A Classification may include scheme, code, label, and optional explanatory context.

Consumption Intent Record (CIR)​

A structured record of a consumer’s intent to use one or more Products.

A CIR captures what the consumer wants to achieve, why the Product is needed, the intended usage context, and any relevant purpose, policy, risk, or composition requirements. It supports product discovery, access evaluation, fulfilment, and value measurement.

  • Purpose: Make consumption intent explicit, governable, and traceable.
  • Related: CEP, Product Use Case Onboarding, Marketplace, Product Runtime Execution Services.

Contract​

A set of obligations, guarantees, expectations, or promises associated with a Product Version.

Examples include SLAs, SLOs, availability guarantees, freshness guarantees, fairness guarantees, quality commitments, regulatory commitments, support commitments, or usage constraints.

D​

dct:conformsTo​

A Dublin Core metadata property indicating that a resource conforms to an external specification.

  • Example: A ProductVersion dct:conformsTo DPDS v1.0.

DPDS​

The Data Product Descriptor Specification, developed under Open Data Mesh. It provides a declarative deployment specification for Data Products.

Within BPS, DPDS is an example of a domain-specific PDS.

DPROD​

The Data Product Ontology developed under the Enterprise Knowledge Graph Foundation (EKGF). It provides semantic descriptions for Data Products.

Within BPS, DPROD is an example of a domain-specific PROD.

E​

Environment Registry​

A registry of runtime, deployment, operational, jurisdictional, or platform environments in which Products may be instantiated, executed, published, or consumed.

The Environment Registry supports automated placement, deployment feasibility checks, residency constraints, runtime policy enforcement, and environment eligibility validation.

  • Purpose: Provide authoritative knowledge of available and permitted execution environments.
  • Related: Capability Registry, PFI, PDS, Product Runtime Execution Services.

Evaluation​

The process of assessing a Product Version against defined criteria.

An Evaluation may include evaluator, method, evaluation date, scope, benchmark, evidence, result, score, or decision outcome.

ExternalSpec​

An external standard, ontology, schema, or specification to which a Product, Product Version, PDS, PROD, or related artifact conforms.

Examples include DPDS, DPROD, AIPDS, AIPROD, OpenAPI, AsyncAPI, DCAT, PROV-O, JSON Schema, SHACL, or other recognized specifications.

G​

Governance Plane​

The cross-cutting plane responsible for policy, control, assurance, compliance, semantic governance, lineage, observability, and lifecycle accountability across Products and Product Versions.

The Governance Plane does not represent a single tool. It is a coordinated set of governance capabilities that shape how Products are created, published, accessed, consumed, monitored, and evolved.

  • Purpose: Ensure Products are trustworthy, compliant, auditable, and fit for governed use.
  • Related: PolicyRiskProfile, Provenance, HealthIndicator, PDEP, CEP, PFI, Product Signal.

H​

HDIP (Holistic Data & Information/Intelligence Platform)​

A logical architecture and operating model for productized enterprise capability creation, consumption, governance, runtime execution, and value feedback.

In BPS context, HDIP represents a platform-oriented realization pattern for democratized productization: product owners express intent, platform intelligence compiles that intent into governed Products, consumers discover and consume Products through experience layers, and value signals feed continuous evolution.

  • Purpose: Provide an architectural pattern for turning product intent into governed, reusable, observable Products.
  • Related: BPS, PDEP, CEP, PFI, Product Runtime Execution Services, Marketplace, Governance Plane.

HealthIndicator​

An operational signal describing the current or recent state of a Product Version.

Examples include uptime, freshness, latency, drift, MTBF, error rate, data quality state, availability state, or policy compliance state.

HealthIndicators are used for observability, operational assurance, trust communication, and marketplace transparency.

I​

Infrastructure / Utility Plane​

The underlying technical utility plane that provides raw enabling services such as identity, access, networking, storage, compute, security, messaging, orchestration, telemetry, CI/CD, artifact management, and resilience.

In BPS-aligned architectures, the Infrastructure / Utility Plane supports product-aware platform services but should not be confused with them. Services such as PFI and Product Runtime Execution Services use infrastructure capabilities but are not themselves raw infrastructure primitives.

  • Purpose: Provide the technical substrate required to create, deploy, operate, and consume Products.
  • Related: PFI, Product Runtime Execution Services, Environment Registry, Capability Registry.

InputPort​

A type of Interface describing inputs consumed by a Product.

Examples include datasets, events, files, APIs, user parameters, sensor streams, model inputs, prompts, or configuration values.

Interface​

The defined mechanism by which a Product provides or consumes value.

  • Subtypes: InputPort, OutputPort, ServiceEndpoint.
  • Examples: Data feed, API endpoint, prediction service, event stream, query endpoint, file export, dashboard adapter, or agent interface.

M​

Marketplace​

A discovery, evaluation, onboarding, and access point through which Products are made visible and consumable to authorized consumers.

A Marketplace may expose product metadata, semantic descriptions, trust indicators, usage terms, policies, versions, certifications, health indicators, pricing or cost information, and available interfaces.

A Marketplace is distinct from the Product itself. It is the governed product discovery and acquisition surface.

  • Purpose: Enable governed discovery, comparison, access request, and consumption onboarding.
  • Related: CEP, Product, Product Version, PROD, PolicyRiskProfile, Certification, Consumption Intent Record.

Metric​

A quantitative or qualitative measure used in evaluation, governance, monitoring, product assurance, or value assessment.

Examples include accuracy, latency, freshness, defect rate, usage count, adoption rate, cost, revenue impact, model drift, quality score, or consumer satisfaction.

O​

OutputPort​

A type of Interface describing outputs produced or exposed by a Product.

Examples include data tables, files, events, dashboards, reports, model predictions, recommendations, scores, APIs, service responses, streams, or agent outputs.

P​

PDEP (Product Development Experience Plane)​

The plane that provides the self-service lifecycle cockpit through which a Product Owner (PRO) can manage a Product end-to-end — from ideation and definition through creation, publishing, marketplace onboarding, operation, and evolution.

PDEP focuses on intent, governance posture, product meaning, lifecycle state, and outcomes, while delegating implementation realization to automation and platform intelligence such as PFI.

In HDIP-aligned architectures, PDEP corresponds to the supply-side product creation and lifecycle plane.

  • Purpose: Make product creation and lifecycle management self-service and business-native.
  • Principle: The owner steers; the factory compiles.
  • Related: PFI, PDS, PROD, PolicyRiskProfile, Product Version.

PDS (Product Descriptor Specification)​

A deployment blueprint that describes how a Product is instantiated, delivered, operated, and governed at runtime.

  • Scope: Technical and operational aspects of a Product.
  • Examples:
    • DPDS — Data Product Descriptor Specification.
    • AIPDS — AI Product Descriptor Specification.
    • PHPDS — Physical Product Descriptor Specification.
    • SWPDS — Software Product Descriptor Specification.
  • Purpose: Ensure reproducibility, portability, operational clarity, and deployment consistency across environments.
  • Alignment: Analogous to configuration and deployment standards such as YAML, Kubernetes manifests, infrastructure-as-code, or deployment descriptors.

PFI (Product Factory Intelligence)​

An automation and decision layer that compiles product intent and product descriptors into a real, provisioned Product by selecting blueprints and capabilities, wiring tooling and infrastructure, enforcing policy, generating required artifacts, and configuring runtime operations.

PFI acts as a “product compiler/factory,” turning declarative specifications into deployable, governable, observable Products.

PFI is a product-aware platform intelligence layer, not a raw infrastructure service.

  • Typical outputs: Provisioned runtime resources, configured ports, generated tests and controls, documentation, evidence artifacts, observability setup, and marketplace registration bindings.
  • Related: PDEP, PDS, PROD, Provenance, HealthIndicator, PolicyRiskProfile, Product Runtime Execution Services.

PolicyRiskProfile​

The governance attributes of a Product Version, including applicable policies, regulatory context, risk classification, access posture, usage constraints, compliance obligations, and assurance requirements.

A PolicyRiskProfile helps determine how a Product Version may be published, accessed, consumed, monitored, or restricted.

PROD (Product Ontology/Description)​

A semantic blueprint that describes what a Product is, including its meaning, purpose, context, relationships, and governance-relevant semantics.

  • Scope: Conceptual identity, business meaning, governance context, compliance posture, and semantic relationships.
  • Examples:
    • DPROD — Data Product Ontology.
    • AIPROD — AI Product Ontology.
    • PHPROD — Physical Product Ontology.
    • SWPROD — Software Product Ontology.
  • Purpose: Enable discoverability, governance, semantic interoperability, contextual understanding, and product trust.
  • Alignment: Anchored in ontology, knowledge graph, and metadata standards such as DCAT, Dublin Core, PROV-O, and related semantic frameworks.

Product​

The abstract root concept representing a unit of value offered for consumption.

A Product may be physical, digital, data-oriented, AI-oriented, software-oriented, service-oriented, or hybrid. In BPS, Product is intentionally domain-neutral.

Common attributes include identifier, title, description, category, purpose, owner, version, interfaces, classifications, contracts, provenance, and governance metadata.

Product Runtime Execution Services​

Product-aware runtime services that execute, expose, and operate Products through governed interfaces such as views, APIs, streams, service endpoints, workflows, inference endpoints, or agent interfaces.

Product Runtime Execution Services sit above raw infrastructure and below consumer or development experience layers. They materialize Product Versions into consumable runtime forms while enforcing policy, access, observability, and operational constraints.

  • Purpose: Provide the governed execution substrate for Products after they have been compiled, deployed, or published.
  • Related: PFI, PDS, Interface, OutputPort, ServiceEndpoint, CEP, Infrastructure / Utility Plane.

Product Signal​

A signal emitted by or about a Product or Product Version, describing usage, quality, cost, value, reliability, compliance, adoption, drift, feedback, lifecycle state, or operational condition.

Product Signals support observability, value measurement, governance, product improvement, and marketplace trust.

  • Purpose: Provide evidence for operational health, consumer value, and continuous product evolution.
  • Related: HealthIndicator, Metric, Provenance, CEP, Product Version.

Product Signal Bundle​

A consolidated set of Product Signals used to assess the operational, economic, experiential, and governance state of a Product or Product Version.

A Product Signal Bundle may aggregate usage signals, cost records, value indicators, feedback records, health indicators, compliance evidence, provenance updates, and lifecycle signals.

  • Purpose: Provide a unified evidence package for product monitoring, value assessment, governance, and evolution.
  • Related: Product Signal, HealthIndicator, Metric, Product Version, Provenance.

Product Use Case Onboarding​

A governed onboarding process for complex product consumption scenarios where a consumer’s intent requires more than ordinary discovery and access.

Product Use Case Onboarding is typically relevant when consumption involves multiple Products, product composition, regulated purpose, cross-domain usage, decision-impacting workflows, or additional assurance requirements. It may enrich a Consumption Intent Record with purpose, risk, composition, policy, and assurance context.

  • Purpose: Ensure complex product usage is contextually valid, governable, and fit for purpose before or alongside consumption.
  • Related: Consumption Intent Record, CEP, Marketplace, PolicyRiskProfile, Product Runtime Execution Services.

Product Version​

An immutable snapshot of a Product at a point in time.

A Product Version captures the state of the Product’s descriptors, interfaces, contracts, provenance, governance profile, and other versioned characteristics.

Common attributes include versionId, releaseDate, status, provenance, conformance references, lifecycle state, and associated artifacts.

Example statuses include Draft, Published, Deprecated, Retired.

Provenance​

The description of origins and derivations of a Product Version, including source assets, generating activities, responsible Agents, and transformation history.

  • Alignment: W3C PROV-O, including prov:wasDerivedFrom, prov:wasGeneratedBy, and prov:wasAttributedTo.

Purpose / IntendedUse​

A concise statement describing the primary function, goal, or application context of a Product.

Purpose / IntendedUse guides discoverability, policy evaluation, governance, risk assessment, access decisions, and value measurement.

S​

ServiceEndpoint​

A type of Interface describing callable services exposed or consumed by a Product.

Examples include REST APIs, GraphQL endpoints, gRPC endpoints, event-driven services, prediction endpoints, scoring services, workflow endpoints, or agent interfaces.

Symbiant​

A single entity micro-enterprise formed by a Product Owner (PRO) working in tight partnership with machine intelligence such as agents, automation, and platform intelligence.

A Symbiant can create and steward Products with end-to-end autonomy, agency, and accountability, without requiring a traditional large cross-functional team.

In the BPS vision, Symbiants are enabled by:

  • BPS as a product grammar,

  • domain specifications as domain validity layers,

  • PFI as factory / compilation automation,

  • PDEP as self-service lifecycle control,

  • Marketplace + CEP for discovery and consumption.

  • Related: Agent (Hybrid), PDEP, PFI, Marketplace, Product Version.

U​

UPOS (Universal Product Operating System)​

A product-kind agnostic meta-architecture (abstract reference architecture) that defines the canonical planes, capability blocks, and lifecycle patterns required to create, provision, govern, distribute, consume, and continuously evolve Products across domains.

UPOS is not intended to be implemented verbatim. Instead, it provides reusable conceptual guidance from which domain-specific architectures are derived (e.g., HDIP as a specialization of UPOS for Data and AI Products).

  • Canonical planes:
    • PFI (Product Factory Intelligence) — compilation/factory automation
    • PDEP (Product Development Experience Plane) — self-service lifecycle cockpit
    • Marketplace — discovery, acquisition, entitlements
    • CEP (Consumer Experience Plane) — persona experiences consuming product ports
  • Related: BPS, PDS, PROD, PFI, PDEP, CEP, Marketplace, Product Version.

Miscellaneous Standards References​

  • DCAT: W3C Data Catalog Vocabulary — used for dataset and catalog description.
  • Dublin Core / DCTerms: Metadata terms for describing resources, conformance, creators, dates, identifiers, and related metadata.
  • FOAF: Friend of a Friend Ontology — defines foaf:Agent.
  • GoodRelations: Ontology for commercial product offers and e-commerce.
  • PROV-O: W3C Provenance Ontology — models derivation, activity, attribution, and provenance relationships.
  • ISO/IEC 22989, 42001: AI standards relevant for accountability, terminology, management systems, and risk management.