🧭 HDIP©: Data PDEP Stages
🧭 HDIP©: Data PDEP Stages - Detailed Stage by Stage
🔴 Stage 0 — Preconditions
| Row Heading | Stage 0 Definition |
|---|---|
| Stage Number | 0 |
| Stage Name | Preconditions |
| Lifecycle Phase | Preconditions |
| Purpose | Ensure that the foundational capabilities, assets, and conditions required for data product creation exist before any intent is declared |
| Outcome | A validated environment where product creation can begin with sufficient semantic, technical, and governance readiness |
| Context | Occurs before any product-specific activity; establishes enterprise and domain readiness |
| Scope | Availability of ADS, canonical models, registries, platform services; not product-specific design |
| Primary Inputs | Existing enterprise assets (ADS, schemas, ontologies, platform services) |
| External Dependencies | ADS Registry, Schema Registry, Ontology/EDM, Platform Infrastructure (TAP/HDIP baseline) |
| Core Activities | Validate existence of ADS, confirm canonical models (e.g. PCDM), ensure registries are populated, confirm platform availability |
| Processing Type | Platform-assisted + governance-driven |
| Output Artifacts | Readiness state (implicit), registered assets in registries |
| State Transition | From “No context” → “Environment ready for intent declaration” |
| Governance Controls | Enterprise standards enforcement (canonical models, registry completeness) |
| Validation Mechanisms | Registry validation, schema availability checks, platform readiness checks |
| DPRO Responsibility | None (passive) |
| Platform Responsibility (HDIP/DPFI) | Maintain registries, ensure platform readiness, validate enterprise assets |
| Dependency Treatment | Not applicable (no product dependencies yet) |
| Quality Sensitivity | Very high — poor registry quality leads to incorrect dependency resolution later |
| Failure Modes / Risks | Missing ADS registration, inconsistent schemas, lack of canonical model, incomplete registries |
| Observability Signals | Registry completeness metrics, schema coverage, ADS availability |
| Feedback Loop | Feeds into enterprise data governance and platform enablement teams |
🔴 Stage 1 — Intent Record
| Row Heading | Stage 1 Definition |
|---|---|
| Stage Number | 1 |
| Stage Name | Intent Record |
| Lifecycle Phase | Design (Intent) |
| Purpose | Capture the business intent of the data product in a technology-agnostic manner |
| Outcome | A formal Intent Record defining purpose, audience, and expected value |
| Context | First product-specific stage; defines WHAT the product should represent |
| Scope | Business intent, not implementation; no pipelines, no infrastructure |
| Primary Inputs | Business need, domain knowledge |
| External Dependencies | None (conceptual stage) |
| Core Activities | Define purpose, identify audience, articulate value, define usage expectations |
| Processing Type | Human-driven (DPRO) with optional AI assistance |
| Output Artifacts | Intent Record (FRD-level artifact) |
| State Transition | From “Idea” → “Defined product intent” |
| Governance Controls | Intent clarity and alignment with domain ownership |
| Validation Mechanisms | Review for clarity, completeness, and non-technical framing |
| DPRO Responsibility | Define intent clearly without referencing technical sources |
| Platform Responsibility (HDIP/DPFI) | Assist, validate structure, ensure no infra leakage |
| Dependency Treatment | Derived products: dependencies may be declared; Foundational: no dependency declaration |
| Quality Sensitivity | Extremely high — mis-specified intent leads to wrong product |
| Failure Modes / Risks | Technical leakage (mentioning Kafka/PTDS), vague intent, unclear audience |
| Observability Signals | Intent completeness score, clarity metrics |
| Feedback Loop | Iterative refinement with stakeholders |
🔴 Stage 2 — Authority Confirmation
| Row Heading | Stage 2 Definition |
|---|---|
| Stage Number | 2 |
| Stage Name | Authority Confirmation |
| Lifecycle Phase | Design (Governance) |
| Purpose | Ensure that the product is being defined by the rightful domain authority |
| Outcome | Confirmed ownership and accountability (DPRO) |
| Context | Ensures governance correctness before semantic definition |
| Scope | Ownership validation, not design |
| Primary Inputs | Intent Record |
| External Dependencies | Org structure registry, role/identity systems |
| Core Activities | Validate domain ownership, confirm DPRO authority |
| Processing Type | Platform-assisted governance check |
| Output Artifacts | Authority confirmation record |
| State Transition | From “Unverified ownership” → “Authorized product definition” |
| Governance Controls | Domain ownership rules, role validation |
| Validation Mechanisms | Role-based checks, domain mapping validation |
| DPRO Responsibility | Assert ownership |
| Platform Responsibility (HDIP/DPFI) | Validate ownership against org model |
| Dependency Treatment | Not applicable |
| Quality Sensitivity | Very high — wrong ownership leads to invalid product |
| Failure Modes / Risks | Misaligned ownership, cross-domain conflicts |
| Observability Signals | Ownership validation logs |
| Feedback Loop | Escalation to governance bodies |
🔴 Stage 3 — Policy Intent
| Row Heading | Stage 3 Definition |
|---|---|
| Stage Number | 3 |
| Stage Name | Policy Intent |
| Lifecycle Phase | Design (Governance & Compliance) |
| Purpose | Define the governance, compliance, and access expectations for the data product |
| Outcome | Policy intent describing sensitivity, access, residency, retention |
| Context | Introduces governance constraints before semantic construction |
| Scope | Policy definition, not enforcement |
| Primary Inputs | Intent Record, domain policies |
| External Dependencies | Policy Registry, regulatory frameworks |
| Core Activities | Define access posture, sensitivity classification, compliance requirements |
| Processing Type | Human-driven with platform guidance |
| Output Artifacts | Policy Intent Artifact |
| State Transition | From “Unconstrained product” → “Governance-aware product” |
| Governance Controls | Policy standards, regulatory alignment |
| Validation Mechanisms | Policy completeness checks, compliance validation |
| DPRO Responsibility | Define policy intent |
| Platform Responsibility (HDIP/DPFI) | Translate into policy models later |
| Dependency Treatment | Not applicable |
| Quality Sensitivity | High — weak policy intent leads to governance risks |
| Failure Modes / Risks | Missing compliance rules, over/under-restriction |
| Observability Signals | Policy coverage metrics |
| Feedback Loop | Compliance review cycles |
🔴 Stage 4 — Semantic Descriptor (DPROD Draft)
| Row Heading | Stage 4 Definition |
|---|---|
| Stage Number | 4 |
| Stage Name | Semantic Descriptor (DPROD Draft) |
| Lifecycle Phase | Design (Semantics) |
| Purpose | Define the business meaning, structure, and conceptual model of the data product |
| Outcome | A structured semantic descriptor (draft DPROD) describing entities, relationships, and meaning |
| Context | First stage where intent is translated into formal semantic constructs |
| Scope | Entities, attributes, relationships, lifecycle concepts; no execution logic |
| Primary Inputs | Intent Record, domain knowledge |
| External Dependencies | Business Dictionary, Ontology/EDM, Schema Registry |
| Core Activities | Define entities (e.g. Payment, PaymentEvent), attributes, relationships, lifecycle states, map to canonical models (e.g. PCDM) |
| Processing Type | Human-driven with platform assistance |
| Output Artifacts | Draft DPROD (semantic model) |
| State Transition | From “Intent” → “Structured semantic definition” |
| Governance Controls | Alignment with enterprise ontology and canonical models |
| Validation Mechanisms | Semantic validation against ontology, naming standards, schema alignment checks |
| DPRO Responsibility | Define semantic meaning and structure |
| Platform Responsibility (HDIP/DPFI) | Assist with ontology alignment, validate consistency |
| Dependency Treatment | Foundational: semantics implicitly constrain ADS; Derived: semantics reference input DPRODs |
| Quality Sensitivity | Critical — defines meaning of product; errors propagate to all downstream stages |
| Failure Modes / Risks | Misaligned semantics, duplication of concepts, unclear entity definitions |
| Observability Signals | Semantic consistency metrics, ontology alignment score |
| Feedback Loop | Iteration with domain experts and ontology governance |
🔴 Stage 5 — Business Assertions / Evidence Rules
| Row Heading | Stage 5 Definition |
|---|---|
| Stage Number | 5 |
| Stage Name | Business Assertions / Evidence Rules |
| Lifecycle Phase | Design (Logic & Validation) |
| Purpose | Define the business logic, rules, and conditions that establish correctness and trust in the data |
| Outcome | A set of declarative business assertions that can be compiled into executable validation logic |
| Context | Translates semantic model into enforceable business truth |
| Scope | Validation rules, lifecycle constraints, business conditions; no technical implementation |
| Primary Inputs | Semantic Descriptor (Stage 4) |
| External Dependencies | Business rules repository, domain standards |
| Core Activities | Define rules (e.g. lifecycle sequencing, completeness, validity conditions), define confidence logic |
| Processing Type | Human-driven with platform assistance |
| Output Artifacts | Assertion set (Evidence Rules) |
| State Transition | From “Defined semantics” → “Validated business truth model” |
| Governance Controls | Rule consistency, domain validation |
| Validation Mechanisms | Logical validation, rule completeness checks |
| DPRO Responsibility | Define business assertions |
| Platform Responsibility (HDIP/DPFI) | Prepare for compilation into executable logic |
| Dependency Treatment | Foundational: rules constrain ADS selection; Derived: rules apply across input products |
| Quality Sensitivity | Extremely high — determines correctness and trustworthiness |
| Failure Modes / Risks | Missing rules, contradictory assertions, weak validation |
| Observability Signals | Rule coverage metrics, validation success/failure rates (post-deployment) |
| Feedback Loop | Continuous refinement based on runtime signals |
🔴 Stage 6 — Usage Contract
| Row Heading | Stage 6 Definition |
|---|---|
| Stage Number | 6 |
| Stage Name | Usage Contract |
| Lifecycle Phase | Design (Consumption) |
| Purpose | Define how the data product will be consumed, including expectations for performance, freshness, and usability |
| Outcome | A usage contract specifying consumption modes, SLAs, and experience expectations |
| Context | Bridges product design with consumer needs |
| Scope | Consumption modes, latency expectations, access patterns, explainability |
| Primary Inputs | Intent Record, Semantic Descriptor |
| External Dependencies | Consumer personas, usage archetypes (CS/PU/MO/CT framework) |
| Core Activities | Define real-time vs batch needs, query patterns, API expectations, explainability requirements |
| Processing Type | Human-driven with platform guidance |
| Output Artifacts | Usage Contract |
| State Transition | From “Defined product” → “Consumer-ready specification” |
| Governance Controls | SLA policies, access expectations |
| Validation Mechanisms | Contract completeness checks, alignment with platform capabilities |
| DPRO Responsibility | Define usage expectations |
| Platform Responsibility (HDIP/DPFI) | Validate feasibility, map to capabilities |
| Dependency Treatment | Indirect — influences execution plan but not dependency type |
| Quality Sensitivity | High — impacts performance, usability, and adoption |
| Failure Modes / Risks | Unrealistic SLAs, unclear consumption patterns |
| Observability Signals | Usage metrics, latency, consumer satisfaction |
| Feedback Loop | Consumer feedback, COVP signals |
🔴 Stage 7 — Product Preview (Abstract)
| Row Heading | Stage 7 Definition |
|---|---|
| Stage Number | 7 |
| Stage Name | Product Preview (Abstract) |
| Lifecycle Phase | Design (Validation & Review) |
| Purpose | Provide a non-technical preview of the product for validation before compilation |
| Outcome | A conceptual representation of the product as it will appear to consumers |
| Context | Final checkpoint before entering automated compilation |
| Scope | Sample views, lifecycle representations, semantic correctness; no execution details |
| Primary Inputs | Semantic Descriptor, Assertions, Usage Contract |
| External Dependencies | Visualization tools, preview engines |
| Core Activities | Generate sample outputs, visualize lifecycle, validate semantics with stakeholders |
| Processing Type | Platform-generated with human validation |
| Output Artifacts | Product preview (mock outputs, sample views) |
| State Transition | From “Designed product” → “Validated product design” |
| Governance Controls | Semantic validation, stakeholder approval |
| Validation Mechanisms | Review sessions, semantic correctness checks |
| DPRO Responsibility | Review and approve preview |
| Platform Responsibility (HDIP/DPFI) | Generate preview from declarative artifacts |
| Dependency Treatment | Not yet resolved; preview is independent of actual binding |
| Quality Sensitivity | High — last chance to catch semantic errors |
| Failure Modes / Risks | Misinterpretation of semantics, incorrect preview |
| Observability Signals | Approval status, review feedback |
| Feedback Loop | Iteration back to Stages 4–6 |
🔴 Stage 8 — Compilation (DPFI Core)
| Row Heading | Stage 8 Definition |
|---|---|
| Stage Number | 8 |
| Stage Name | Compilation |
| Lifecycle Phase | Compilation |
| Purpose | Transform declarative product intent, semantics, and governance into a fully resolved, executable, and context-aware product architecture |
| Outcome | A Resolved Product Graph, Synthetic Context (SYNCTX) (if applicable), HDIP Product Descriptor (HPD), Logical Execution Plan, and Selected Blueprint |
| Context | First fully automated stage; converts all declarative artifacts into computable graph structures and execution-ready designs |
| Scope | Dependency resolution, semantic graph construction, SYNCTX inference, policy compilation, execution planning, HPD generation, blueprint selection |
| Primary Inputs | Intent Record, Semantic Descriptor (DPROD draft), Business Assertions, Policy Intent, Usage Contract |
| External Dependencies | ADS Registry, Data Product Catalog, Capability Registry, Policy Registry, Blueprint Library, Ontology / EDM |
| Core Activities | 1. Resolve dependencies (ADS or DPRODs) 2. Construct semantic graph 3. Compile assertions into executable rules 4. Compile policy fabric 5. Infer Synthetic Context (SYNCTX) where required 6. Generate Logical Execution Plan 7. Select optimal blueprint 8. Generate HDIP Product Descriptor (HPD) |
| Processing Type | Fully automated (DPFI-driven) |
| Output Artifacts | • Resolved Product Graph • Dependency Graph • Logical Execution Plan • Selected Blueprint • Synthetic Context (SYNCTX) (conditional) • HDIP Product Descriptor (HPD) |
| State Transition | From “Declarative Product Definition” → “Executable & Context-Aware Product Design” |
| Governance Controls | Policy enforcement, semantic validation, dependency validation, synthetic boundary validation |
| Validation Mechanisms | Schema compatibility checks, assertion validation, policy consistency checks, dependency resolution validation, SYNCTX consistency validation (joinability, relationship integrity) |
| DPRO Responsibility | None (review only if required) |
| Platform Responsibility (HDIP/DPFI) | Perform full compilation, resolve dependencies, construct semantic and relational graphs, infer SYNCTX, generate HPD, produce execution-ready design |
| Dependency Treatment | Dependencies are resolved and normalized into execution inputs; relationships are elevated into semantic and synthetic context graphs |
| Quality Sensitivity | Critical — determines correctness of product semantics, execution, and synthetic behavior |
| Failure Modes / Risks | Incorrect dependency resolution, semantic mismatch, incorrect SYNCTX inference, wrong blueprint selection, incomplete policy compilation |
| Observability Signals | Compilation logs, dependency resolution trace, SYNCTX inference trace, blueprint selection rationale, validation results |
| Feedback Loop | Feeds back to Stage 1–7 for correction (intent, semantics, assertions, policy, usage) |
🔴 Stage 9 — Deployment (DPDS Generation & Execution)
| Row Heading | Stage 9 Definition |
|---|---|
| Stage Number | 9 |
| Stage Name | Deployment |
| Lifecycle Phase | Deployment |
| Purpose | Materialize the compiled product design into a running, provisioned, and operational data product |
| Outcome | A deployed data product with active pipelines, storage, and output ports |
| Context | Executes the blueprint and execution plan generated in Stage 8 |
| Scope | DPDS generation, infrastructure provisioning, pipeline execution, output port creation, observability setup |
| Primary Inputs | Resolved Product Graph, Execution Plan, Selected Blueprint |
| External Dependencies | Infrastructure (GCP/GDC/etc.), compute engines, storage systems, streaming services |
| Core Activities | Generate DPDS, provision resources (schemas, compute, storage), connect inputs, execute transformations, enforce assertions, materialize output ports, configure observability |
| Processing Type | Fully automated (platform-driven) |
| Output Artifacts | Deployed pipelines, provisioned infrastructure, active output ports, observability configuration |
| State Transition | From “Executable Design” → “Running Data Product” |
| Governance Controls | Runtime policy enforcement, access control enforcement |
| Validation Mechanisms | Deployment success checks, runtime validation, pipeline health checks |
| DPRO Responsibility | None (passive observer) |
| Platform Responsibility (HDIP/DPFI) | Execute deployment, provision infrastructure, ensure correct execution |
| Dependency Treatment | Dependencies are bound and connected (ADS streams or product ports) |
| Quality Sensitivity | Fully dependent on Stage 8; faithfully executes whatever was compiled |
| Failure Modes / Risks | Deployment failures, misconfigured pipelines, incorrect bindings, runtime errors |
| Observability Signals | Deployment logs, pipeline metrics, latency, error rates, resource utilization |
| Feedback Loop | Feeds back to Stage 8 (blueprint/execution correction) |
🔴 Stage 10 — DPROD Finalization & Registration
| Row Heading | Stage 10 Definition |
|---|---|
| Stage Number | 10 |
| Stage Name | DPROD Finalization & Registration |
| Lifecycle Phase | Publication |
| Purpose | Formalize the deployed system as a discoverable, governed, and consumable data product |
| Outcome | A fully registered Data Product with DPROD, DPP, lineage, and accessible output ports |
| Context | Final stage where product becomes part of the HDIP ecosystem |
| Scope | DPROD finalization, catalog registration, lineage capture, DPP generation, marketplace exposure |
| Primary Inputs | Deployed product (from Stage 9), final semantic and policy artifacts |
| External Dependencies | Data Catalog, Marketplace, Lineage Service, Knowledge Graph, DPP framework |
| Core Activities | Finalize DPROD, register product, capture lineage, generate DPP, enable discoverability |
| Processing Type | Fully automated with optional governance oversight |
| Output Artifacts | Final DPROD, DPP (Digital Product Passport), catalog entry, lineage graph |
| State Transition | From “Running System” → “Discoverable Data Product” |
| Governance Controls | Product registration standards, compliance validation, trust signals |
| Validation Mechanisms | Registration checks, lineage validation, DPP completeness checks |
| DPRO Responsibility | Review and accept published product |
| Platform Responsibility (HDIP/DPFI) | Finalize artifacts, register product, expose in marketplace |
| Dependency Treatment | Dependencies are recorded and exposed as lineage, not used for execution anymore |
| Quality Sensitivity | Dependent on Stage 9 correctness; formalizes whatever is deployed |
| Failure Modes / Risks | Incorrect lineage, incomplete metadata, broken discoverability |
| Observability Signals | Product usage metrics, access patterns, lineage queries, consumer feedback |
| Feedback Loop | Feeds into continuous assurance (post-publication evolution) |
HDIP SSPD PDEP Spec C Glossary
This glossary defines the key terms used in the HDIP Self-Service Product Development / Product Development and Evolution Process (SSPD / PDEP) Spec C flow for Data Products.
Spec C is the lifecycle-accurate view of how a Data Product Owner (DPRO) declares business-native intent and how the HDIP platform validates, compiles, governs, deploys, registers, observes, and evolves the resulting Data Product.
Access & Entitlements
The enterprise service responsible for managing who or what may access a Data Product, product output, governed runtime view, or related product capability.
In the Spec C flow, Access & Entitlements is used by the Governance Compiler to bind policy intent to executable access controls such as RBAC and ABAC.
Assertion Compiler
The HDIP platform service that validates and compiles business assertions into deterministic, executable, tool-agnostic validation and execution logic.
It checks that assertions are complete, non-contradictory, semantically bound, and compatible with the Unified Governance Bundle.
Assertion Set
A versioned artifact containing the consolidated business assertions for the Data Product.
The Assertion Set captures business rules, precedence, missing-data behavior, deterministic logic, and trust criteria that the platform can compile into executable validation and enforcement logic.
Assertion Validation Report
An artifact produced by the Assertion Compiler that records whether business assertions are deterministic, complete, logically consistent, and compatible with product semantics and governance constraints.
Authority Context
The DPRO-declared context describing the mandate, role-hat, and legitimacy under which the DPRO is acting.
Authority Context helps the platform determine whether the DPRO has the right to create, publish, or compose the Data Product.
Authority Decision
A platform-generated artifact recording the result of authority validation.
It may contain PASS, CONDITIONAL, or FAIL evidence and can enrich the Intent Record with mandate and composability evidence.
Authority Validator
The HDIP platform service that validates whether the DPRO has the appropriate mandate to define and publish the Data Product.
It may also validate input product composability through IPCC-style checks.
Blueprint Binding
A versioned artifact that records the selected blueprint and runtime binding choices for the Data Product.
It may include patterns such as RBB, RCM, RERP, and RMP, and captures how the compiled product plan is bound to platform capabilities, environments, cost constraints, and operational posture.
Blueprint Resolver
The HDIP platform service that selects an appropriate implementation blueprint for the Data Product.
In this Spec C flow, it resolves a daily-batch optimized blueprint using the Compilation Pack, governance constraints, usage contract, exposure decision, capability registry, environment registry, and cost model.
Business Assertions
Business-authored rules that define the correctness, trust, validity, and expected behavior of the Data Product.
Business assertions are expressed by the DPRO in business terms and compiled by the platform into deterministic validation and enforcement logic.
Business Dictionary
An enterprise service containing approved business terms, definitions, synonyms, and domain vocabulary.
In the flow, the Semantic Grounding service uses the Business Dictionary to align Data Product meaning with shared enterprise language.
Capability Registry
An enterprise registry of platform capabilities available for product development and deployment.
It is used during preconditions checking and blueprint resolution to determine whether the platform has the capabilities needed to compile, provision, and operate the Data Product.
Catalog
See Data Catalog.
Compilation Pack
A versioned artifact generated by the Compilation Pack Generator.
It bundles the logical execution and enforcement plans required to translate declarative product design into a feasible platform-realizable product. In this flow, it may include LEG, GEP, DQEP, DCEP, RVS, OSP, and EAP.
Compilation Pack Generator
The HDIP platform service that compiles the full declarative product definition into a platform-realizable package.
It consumes the Intent Record, Authority Decision, Unified Governance Bundle, Semantic Descriptor, Assertion Set, Usage Contract, and Exposure Decision to produce the Compilation Pack.
Compile Preview
A DPRO-facing review step that shows what the platform intends to build before deployment.
The preview remains business-native and does not expose tools, pipelines, infrastructure, or engineering implementation detail.
Cost Model / FinOps
The enterprise capability used to evaluate and optimize the economic feasibility of product deployment and operation.
In the flow, the Blueprint Resolver uses the Cost Model / FinOps service to assess cost feasibility for the selected implementation pattern.
Daily Batch Posture
The DPRO-declared or platform-recognized operational posture for the Data Product.
In this flow, it indicates that the Data Product is optimized for daily batch operation, including evidence-ledger behavior, schedules, freshness expectations, and replay posture.
Data Catalog
The enterprise discovery and registration service for Data Products.
It stores product metadata, semantic descriptors, governance posture, trust information, discoverability information, and registration state.
Data Controls
See DC Services.
Data Product
A domain-owned, governed, discoverable, addressable, and observable product that exposes trusted data through controlled product interfaces.
In HDIP PDEP, a Data Product is created from business-native intent and compiled by the platform into deployment, semantic, governance, runtime, and marketplace artifacts.
Data Product Owner
See DPRO.
DC Services
Enterprise Data Control services that support runtime control enforcement and control validation.
In this flow, DC Services participate in the Unified Governance Bundle and help ensure that product controls are executable and enforceable.
Deployable Specification
A platform-facing specification used to deploy the Data Product.
In the Data Product flow, this is represented by DPDS.
Deployer
The HDIP platform service responsible for provisioning and deploying the Data Product.
It consumes DPDS, Blueprint Binding, governance constraints, and usage expectations to create governed runtime views, schedules, runtime bindings, and promotion-gate evidence.
DPRO
Data Product Owner.
The DPRO is the business-domain accountable owner of the Data Product’s meaning, purpose, usage expectations, and business assertions. In HDIP, the DPRO is a data semantics expert, not a data engineer.
DPROD
Data Product semantic descriptor.
DPROD is the marketplace-ready product descriptor that captures the Data Product’s semantic meaning, governance posture, usage expectations, lineage context, trust information, and discoverability metadata.
DPROD Publisher
The HDIP platform service responsible for finalizing and publishing the DPROD.
It registers the product into the Data Catalog and Marketplace and surfaces the product’s semantic, governance, runtime, lineage, and trust context.
DPDS
Data Product Deployment Specification.
DPDS is the platform-facing deployable specification generated by HDIP. It describes how the Data Product should be provisioned, deployed, configured, scheduled, governed, and operated.
DPDS Generator
The HDIP platform service that generates the DPDS.
It consumes the Compilation Pack, Blueprint Binding, Unified Governance Bundle, Usage Contract, and related compiled artifacts to produce a versioned deployment specification.
DQ Services
Enterprise Data Quality services that support quality rule definition, execution, monitoring, and reporting.
In this flow, DQ Services are incorporated into the Unified Governance Bundle and later help enforce promotion and runtime quality gates.
EDM
See Enterprise Data Model.
Entitlements
See Access & Entitlements.
Environment Registry
An enterprise registry describing available runtime environments, deployment targets, routing constraints, residency zones, and environment readiness.
It is used during preconditions checking and blueprint resolution.
Enterprise Data Model
The enterprise-level conceptual or logical model used to standardize key business entities, relationships, and data structures.
In the flow, the Semantic Grounding service uses the Enterprise Data Model to align the Data Product’s semantic descriptor with enterprise meaning.
Enterprise Ontology
The enterprise semantic graph or conceptual ontology that defines entities, relationships, taxonomies, and meaning across domains.
The Semantic Grounding service uses the Enterprise Ontology to validate product semantics and detect conflicts or ambiguity.
Enterprise Services
The shared platform and governance capabilities used by HDIP to create, govern, deploy, register, observe, and evolve Data Products.
Examples include Catalog, Marketplace, Business Dictionary, EDM, Ontology, Policy Service, DQ Services, DC Services, Observability, Lineage, and Cost Model / FinOps.
Evolve
The DPRO-facing lifecycle step where product signals are used to improve, correct, extend, or retire a Data Product.
Evolution is driven by operational, usage, DQ, compliance, drift, and consumer feedback signals.
Exposure Decision
An artifact produced by the Usage Contract Validator.
It defines the allowed scopes, product views, consumption surfaces, exposure constraints, and usage boundaries for the Data Product.
Gate: Assertions
A deterministic validation gate that checks whether the compiled business assertions are complete, deterministic, and semantically valid.
It may return PASS, CONDITIONAL, or FAIL depending on validation outcome.
Gate: Authority
A validation gate that determines whether the DPRO has sufficient mandate and composability authority to proceed.
It may return PASS, CONDITIONAL, or FAIL.
Gate: Blueprint
A validation gate that determines whether the selected blueprint is feasible in terms of cost, residency, environment routing, and platform capability.
Gate: Feasibility
A validation gate that determines whether the Compilation Pack is technically and operationally feasible.
It validates whether the compiled product plan can be realized by available platform capabilities.
Gate: Governance
A validation gate that determines whether the governance intent has been resolved into enforceable policy, DQ, and DC controls.
Gate: Intent
A validation gate that determines whether the Intent Record is sufficiently complete and publishable.
It checks clarity, business framing, product purpose, inputs, consumers, and sensitivity information.
Gate: Preconditions
A validation gate that determines whether the ecosystem is ready for product creation.
It checks capability readiness, environment readiness, and availability of required governance and platform fabric.
Gate: Promotion
A deployment and publication gate that determines whether the Data Product can be promoted to a published or operational state.
It checks runtime policy, DQ/DC, and governance gates before final promotion.
Gate: Semantics
A validation gate that determines whether the semantic descriptor is conflict-free and aligned with enterprise vocabulary, EDM, and ontology.
Gate: Usage
A validation gate that determines whether the usage contract is governable, realistic, and usable.
It checks exposure, SLA, freshness, replay, and consumption expectations.
Governance Compiler
The HDIP platform service that compiles DPRO-declared governance intent into an executable Unified Governance Bundle.
It resolves policy, data quality, data control, privacy, residency, retention, and entitlement requirements.
Governance Intent
The DPRO-authored declaration of governance expectations for the Data Product.
It includes privacy, residency, retention, entitlement posture, sensitivity, and compliance expectations.
Governed Runtime Views
Runtime artifacts created by the Deployer that expose the Data Product through governed, policy-shaped views.
They may include masking, row-level filters, column-level filters, ABAC enforcement, and consumer-specific runtime constraints.
HDIP
Holistic Data & Information Platform.
HDIP is the architecture that enables governed creation, deployment, discovery, consumption, observability, and evolution of Data Products, AI Products, and other product types.
HDIP Platform
The automated productization layer that validates, compiles, deploys, registers, and observes Data Products.
In Spec C, it acts as an automated technology organization that transforms business-native artifacts into a governed, running product.
Intent Record
A versioned artifact capturing the DPRO’s business-native product intent.
It includes purpose, expected value, inputs, target consumers, sensitivity, context, and later enrichment from authority validation.
Intent Service
The HDIP platform service that captures, structures, validates, and enriches the DPRO’s intent.
It produces the Intent Record and validates whether the intent is publishable.
IPCC
Input Product Composability Check.
IPCC is the validation of whether input products, marketplace-listed products, or reusable product dependencies can legitimately be composed into the new Data Product.
LEG
Logical Execution Graph.
A compiled execution representation that describes how product logic should be executed in a way agnostic of the tooling.
Lineage
The enterprise service that captures and exposes relationships among source assets, transformations, runtime views, generated artifacts, and published Data Products.
Lineage supports traceability, auditability, trust, and impact analysis.
Marketplace
The enterprise product marketplace where Data Products are published, discovered, evaluated, subscribed to, or reused.
In this flow, DPROD publication makes the Data Product available in the Marketplace.
Observability
The enterprise capability that makes product health, runtime behavior, DQ, compliance, usage, drift, and operational signals visible.
In the PDEP flow, Observability surfaces product signals that support evolution and trust.
One-Click Publish
The DPRO-facing action that triggers platform-managed DPDS generation, provisioning, deployment, DPROD finalization, catalog registration, and marketplace publication.
One-click publish does not mean uncontrolled deployment; it triggers gated automated productization.
Ontology
See Enterprise Ontology.
PackGen
See Compilation Pack Generator.
PDEP
Product Development and Evolution Process.
PDEP is the lifecycle through which a product is created, validated, compiled, deployed, published, observed, and evolved.
Policy Service
The enterprise service that stores, evaluates, and exposes executable policy rules.
Policies may include access, privacy, residency, retention, purpose limitation, regulatory constraints, and product-specific governance obligations.
Precondition Report
An artifact produced by the Preconditions Checker.
It records the readiness state of required capabilities, environments, registries, and governance fabric before product creation proceeds.
Preconditions Checker
The HDIP platform service that verifies whether the ecosystem is ready for product creation.
It checks capability readiness, environment readiness, and availability of required enterprise services.
Product Catalog
See Data Catalog.
Product Signals
See Signals.
Provision & Deploy
The HDIP platform service step that provisions environments, runtime views, schedules, controls, and execution bindings for the Data Product.
It uses DPDS, Blueprint Binding, governance constraints, and usage expectations.
Publisher
See DPROD Publisher.
Runtime Views
See Governed Runtime Views.
Semantic Conflict Report
An artifact produced by Semantic Grounding that records semantic blockers, conflicts, ambiguity, warnings, or ontology alignment issues.
It helps prevent inconsistent or duplicated product meaning.
Semantic Descriptor
A versioned artifact that captures the resolved business meaning of the Data Product.
It defines entities, events, measures, relationships, vocabularies, and ontology alignment.
Semantic Draft
The DPRO-authored business meaning draft.
It describes the product’s intended entities, events, measures, relationships, and vocabulary before platform grounding.
Semantic Grounding
The HDIP platform service that aligns the DPRO’s semantic draft with the Business Dictionary, Enterprise Data Model, and Enterprise Ontology.
It produces the Semantic Descriptor and Semantic Conflict Report.
Signals
A product evolution artifact containing observable runtime and trust signals.
In this flow, Signals may include data quality, drift, usage, compliance, runtime telemetry, promotion evidence, and other product health indicators.
SSPD
Self-Service Product Development.
SSPD is the HDIP approach where a product owner declares intent, meaning, governance, assertions, and usage expectations in business terms, while the platform handles compilation, deployment, registration, and operation.
Start New Product
The DPRO-facing step that initiates the self-service product creation journey.
It triggers precondition checks before detailed intent declaration begins.
Unified Governance Bundle
A versioned artifact containing executable governance controls for the Data Product.
It combines policy, DQ, DC, privacy, residency, retention, entitlement, and compliance constraints into a form that later stages can validate and enforce.
Usage Contract
A versioned artifact describing how the Data Product is expected to be consumed.
It may include freshness, replay, explainability, exposure, SLA/SLO, consumer guarantees, usage mode, and operational posture.
Usage Contract Validator
The HDIP platform service that validates the DPRO’s usage expectations.
It produces the Usage Contract and Exposure Decision and checks whether the product can be made governable and usable under the declared expectations.