🧭 HDIP ©: Product Consumption CEP stages

🧭 HDIP ©: Product Consumption Stages - Detailed Stage by Stage
This page defines the HDIP Self-Service Product Consumption Flow (SSCF) for the Product Consumer (PCON).
The flow applies to any HDIP-supported product type, including:
- Data Products
- AI Products
- Composite Products
- Future product types exposed through HDIP
The core principle is:
PCON consumes products through governed, purpose-bound, observable, and value-measurable consumption paths.
Canonical and Secondary Consumption Modes
The stages below describe the canonical HDIP consumption mode:
Canonical Mode 1 — Intent First
In this mode, the PCON first declares a consumption intent. HDIP then normalizes that intent into a Consumption Intent Record (CIR) and uses it to resolve suitable products.
This does not make the secondary mode invalid.
Secondary Mode 2 — Browse First
In simpler scenarios, the PCON may begin by browsing the Product Marketplace or Product Catalog. However, before access, consumption, observability, and feedback can proceed, HDIP must still infer or confirm a CIR.
Therefore:
Browse-first is a convenience entry mode; intent-first is the canonical HDIP mode.
🔴 Stage 1 — Declare Consumption Intent
| Row Heading | Stage 1 Definition |
|---|---|
| Stage Number | 1 |
| Stage Name | Declare Consumption Intent |
| Lifecycle Phase | Intent Declaration |
| Purpose | Capture what the PCON wants to achieve, why it is needed, and the context in which consumption will occur |
| Outcome | A formal Consumption Intent Record (CIR) capturing intent, purpose, context, and consumption archetype |
| Context | First stage of the canonical HDIP SSCF flow; assumes Intent-First mode |
| Scope | Business or operational intent; not technical product selection, access provisioning, or implementation details |
| Primary Inputs | PCON intent, purpose, context, expected outcome, consumption need |
| External Dependencies | Intent Interpreter, consumption archetype model, optional persona/context registry |
| Core Activities | PCON declares intent; platform interprets and normalizes intent; CIR is generated |
| Processing Type | Human- or agent-driven declaration with platform normalization |
| Output Artifacts | CIR — Consumption Intent Record |
| State Transition | From “Unexpressed need” → “Computable consumption intent” |
| Governance Controls | Intent completeness, purpose clarity, permitted consumption framing |
| Validation Mechanisms | Intent structure validation, archetype alignment, missing-context checks |
| PCON Responsibility | Express the consumption need clearly in business, analytical, system, AI, or agentic terms |
| Platform Responsibility (HDIP) | Normalize intent, enrich with archetype classification, create CIR |
| Dependency Treatment | No products have been selected yet; dependencies are not resolved at this stage |
| Quality Sensitivity | Very high — weak intent leads to poor product resolution and inappropriate access decisions |
| Failure Modes / Risks | Vague intent, missing purpose, over-technical expression, incorrect archetype inference |
| Observability Signals | Intent completeness score, CIR creation events, archetype confidence |
| Feedback Loop | CIR may be refined before product resolution |
| Canonical / Secondary Mode Note | This stage describes Canonical Mode 1: Intent First. In Secondary Mode 2: Browse First, marketplace browsing may precede this stage, but HDIP must still infer or confirm a CIR before governed access is granted |
🔴 Stage 2 — Resolve Product Set
| Row Heading | Stage 2 Definition |
|---|---|
| Stage Number | 2 |
| Stage Name | Resolve Product Set |
| Lifecycle Phase | Discovery & Resolution |
| Purpose | Translate the CIR into a ranked, explainable set of candidate products |
| Outcome | A Product Resolution Set containing candidate products, fit rationale, ranking, and resolution context |
| Context | Follows CIR creation; product resolution is driven by intent rather than manual search alone |
| Scope | Candidate product discovery, matching, ranking, and fit explanation |
| Primary Inputs | CIR, Product Catalog metadata, Marketplace listings, product semantics, trust metadata |
| External Dependencies | Product Catalog / Registry, Product Marketplace, Product Resolution Engine |
| Core Activities | Query catalog, inspect marketplace availability, evaluate fit against intent, construct ranked resolution set |
| Processing Type | Platform-driven with optional PCON exploration |
| Output Artifacts | Product Resolution Set |
| State Transition | From “Computable intent” → “Candidate product set” |
| Governance Controls | Product eligibility pre-checks, availability filtering, trust metadata visibility |
| Validation Mechanisms | Fit scoring, semantic matching, catalog lookup, marketplace availability checks |
| PCON Responsibility | Review candidate products if needed |
| Platform Responsibility (HDIP) | Resolve products using CIR, catalog, marketplace, semantics, and trust metadata |
| Dependency Treatment | Product dependencies become visible as part of resolution, but are not yet provisioned |
| Quality Sensitivity | High — poor resolution may lead to irrelevant, unsafe, or unusable product selection |
| Failure Modes / Risks | Missing catalog metadata, poor semantic alignment, stale marketplace listing, over-reliance on keyword search |
| Observability Signals | Resolution success rate, candidate ranking confidence, no-match events |
| Feedback Loop | Failed or poor resolution may trigger CIR refinement or product marketplace improvement |
🔴 Stage 3 — Evaluate Product Fit and Request Access
| Row Heading | Stage 3 Definition |
|---|---|
| Stage Number | 3 |
| Stage Name | Evaluate Product Fit and Request Access |
| Lifecycle Phase | Evaluation & Acquisition |
| Purpose | Allow the PCON to evaluate candidate products and request governed access to selected products |
| Outcome | An Access Decision and entitlement context for the selected product set |
| Context | Follows product resolution; candidate products are assessed for meaning, trust, suitability, and permitted use |
| Scope | Product evaluation, trust review, selection, policy evaluation, entitlement decision |
| Primary Inputs | CIR, Product Resolution Set, Product Catalog metadata, DPP/trust signals, PCON identity/context |
| External Dependencies | Policy Service, Access & Entitlements, Product Catalog, DPP/trust metadata |
| Core Activities | Evaluate product fit, review trust metadata, select/request products, evaluate policy, produce access decision |
| Processing Type | PCON-driven selection with platform-governed policy evaluation |
| Output Artifacts | Access Decision |
| State Transition | From “Candidate products” → “Approved, denied, or conditional access decision” |
| Governance Controls | Purpose-bound access policies, entitlement rules, compliance constraints, product-level access posture |
| Validation Mechanisms | Policy checks against CIR, selected product set, PCON identity, and entitlement rules |
| PCON Responsibility | Select products and request access for the declared intent |
| Platform Responsibility (HDIP) | Evaluate access request against policy, entitlements, purpose, and selected product set |
| Dependency Treatment | Selected products are treated as requested consumption targets; downstream access is not yet provisioned |
| Quality Sensitivity | Critical — access must reflect both the product and the declared purpose |
| Failure Modes / Risks | Access granted without purpose validation, entitlement mismatch, trust metadata ignored, inappropriate product use |
| Observability Signals | Access request events, policy decisions, denial reasons, conditional approval patterns |
| Feedback Loop | Denied or conditional access may trigger intent refinement, approval workflow, or product substitution |
🔴 Stage 4 — Provision Purpose-Bound Access
| Row Heading | Stage 4 Definition |
|---|---|
| Stage Number | 4 |
| Stage Name | Provision Purpose-Bound Access |
| Lifecycle Phase | Access Provisioning |
| Purpose | Materialize governed access to selected products based on the access decision, entitlements, CIR, and product resolution set |
| Outcome | Access Descriptor, Usage Contract, and Product Ports provisioned for governed consumption |
| Context | Follows access approval or conditional approval |
| Scope | Access binding, entitlement materialization, product port provisioning, usage contract generation |
| Primary Inputs | CIR, Product Resolution Set, Access Decision, Entitlements |
| External Dependencies | Access Provisioning Service, Entitlements Service, Product Port infrastructure |
| Core Activities | Bind entitlements, provision access descriptors, expose governed product ports, create usage contract |
| Processing Type | Platform-driven |
| Output Artifacts | Access Descriptor, Usage Contract, Product Ports |
| State Transition | From “Approved access decision” → “Governed access ready for consumption” |
| Governance Controls | Purpose-bound access, policy-shaped provisioning, entitlement enforcement, port-level controls |
| Validation Mechanisms | Entitlement binding checks, port exposure validation, access descriptor validation |
| PCON Responsibility | None beyond accepting or initiating provisioned access |
| Platform Responsibility (HDIP) | Provision product access safely through governed ports and usage constraints |
| Dependency Treatment | Selected products are bound through governed ports; internal implementation is not exposed |
| Quality Sensitivity | Very high — incorrect provisioning can bypass governance or block legitimate use |
| Failure Modes / Risks | Incorrect entitlement binding, over-broad access, missing usage contract, broken product ports |
| Observability Signals | Provisioning events, port activation status, entitlement binding logs |
| Feedback Loop | Provisioning failures feed back to access governance and platform operations |
🔴 Stage 5 — Consume Through CEP
| Row Heading | Stage 5 Definition |
|---|---|
| Stage Number | 5 |
| Stage Name | Consume Through CEP |
| Lifecycle Phase | Consumption & Experience |
| Purpose | Enable the PCON to consume products through the Consumer Experience Plane using governed product ports |
| Outcome | Persona-appropriate consumption views or experiences |
| Context | Follows access provisioning; product ports, usage contract, and access descriptor are available |
| Scope | Product consumption through dashboards, SQL, APIs, streams, feature pipelines, or agentic workflows |
| Primary Inputs | Product Ports, Access Descriptor, Usage Contract |
| External Dependencies | CEP Renderer, Consumer Experience Plane |
| Core Activities | Invoke governed product ports, render persona-specific experience, generate consumption views |
| Processing Type | PCON-initiated, platform-mediated |
| Output Artifacts | Consumption Views |
| State Transition | From “Access ready” → “Product actively consumed through CEP” |
| Governance Controls | Port-level controls, usage contract enforcement, access descriptor constraints |
| Validation Mechanisms | Port invocation checks, CEP rendering checks, access enforcement at runtime |
| PCON Responsibility | Consume product through the appropriate experience mode |
| Platform Responsibility (HDIP) | Render product experience through CEP without exposing internal product implementation |
| Dependency Treatment | Product dependencies remain hidden behind product ports and CEP views |
| Quality Sensitivity | High — poor experience weakens adoption even when product is technically valid |
| Failure Modes / Risks | Broken CEP rendering, inaccessible ports, unclear views, persona mismatch |
| Observability Signals | View interactions, port usage, CEP rendering events |
| Feedback Loop | Consumption experience feeds usage tracking and later feedback |
🔴 Stage 6 — Capture Usage Signals
| Row Heading | Stage 6 Definition |
|---|---|
| Stage Number | 6 |
| Stage Name | Capture Usage Signals |
| Lifecycle Phase | Usage Instrumentation |
| Purpose | Capture telemetry generated by governed product consumption |
| Outcome | Usage Signals artifact |
| Context | Occurs automatically as products are consumed through product ports and CEP |
| Scope | Port usage, CEP interaction, view interaction, contract-contextualized consumption telemetry |
| Primary Inputs | Product Ports, CEP Renderer, Consumption Views, Usage Contract |
| External Dependencies | Usage Tracking Service |
| Core Activities | Track port usage, capture CEP telemetry, capture view interactions, contextualize usage against usage contract |
| Processing Type | Automated platform instrumentation |
| Output Artifacts | Usage Signals |
| State Transition | From “Consumption activity” → “Measured product usage” |
| Governance Controls | Usage contract context, privacy controls, telemetry minimization policies |
| Validation Mechanisms | Telemetry completeness checks, usage-event validation, contract-context binding |
| PCON Responsibility | None; usage capture is automatic |
| Platform Responsibility (HDIP) | Capture usage signals without requiring manual reporting by the PCON |
| Dependency Treatment | Consumption dependencies are reflected in usage signals only at governed product boundary level |
| Quality Sensitivity | High — inaccurate usage signals distort cost, value, PMDD, and feedback loops |
| Failure Modes / Risks | Missing telemetry, double counting, unbound usage events, privacy leakage |
| Observability Signals | Usage event count, port usage metrics, view interaction metrics |
| Feedback Loop | Usage signals feed cost, value, observability, and product signal bundle generation |
🔴 Stage 7 — Compute and Observe Product Signals
| Row Heading | Stage 7 Definition |
|---|---|
| Stage Number | 7 |
| Stage Name | Compute and Observe Product Signals |
| Lifecycle Phase | Value Realization & Observability |
| Purpose | Compute economic, value, and product-level signals from usage and make them observable |
| Outcome | Cost Records, Value Signals, Product Signal Bundle, Product Consumption Observability |
| Context | Follows usage signal capture; transforms raw consumption telemetry into product intelligence |
| Scope | Cost computation, value computation, signal aggregation, product observability |
| Primary Inputs | Usage Signals, CIR, Usage Contract |
| External Dependencies | FinOps Engine, Value Computation Engine, Product Observability Engine, Observability surface |
| Core Activities | Compute cost records, compute value signals, aggregate usage/cost/value into Product Signal Bundle, expose through observability |
| Processing Type | Automated platform computation with PCON-visible observability |
| Output Artifacts | Cost Records, Value Signals, Product Signal Bundle |
| State Transition | From “Measured usage” → “Observable product value and economic posture” |
| Governance Controls | FinOps policies, value measurement rules, observability access policies |
| Validation Mechanisms | Cost attribution checks, value computation validation, signal bundle completeness checks |
| PCON Responsibility | Observe usage and value posture where relevant |
| Platform Responsibility (HDIP) | Compute cost/value signals and make product consumption observable |
| Dependency Treatment | Product dependency effects may be reflected in aggregate cost and value signals |
| Quality Sensitivity | Very high — poor cost/value computation misleads product decisions and marketplace evolution |
| Failure Modes / Risks | Misattributed cost, weak value model, missing signal aggregation, misleading observability |
| Observability Signals | Product Signal Bundle, ROI trends, cost trends, usage trends, value realization metrics |
| Feedback Loop | Signals feed PCON decision, feedback, PMDD, marketplace ranking, and product evolution |
🔴 Stage 8 — Decision, Feedback & Creation Loop
| Row Heading | Stage 8 Definition |
|---|---|
| Stage Number | 8 |
| Stage Name | Decision, Feedback & Creation Loop |
| Lifecycle Phase | Decision & Evolution |
| Purpose | Use product signals to determine whether to continue, stop, provide feedback, or create/compose a new product |
| Outcome | Decision Context, Feedback Record, or transition into PDEP for new product creation/composition |
| Context | Final stage of SSCF; closes the consumption loop and enables recursive product ecosystems |
| Scope | Consumer decisioning, feedback capture, signal-informed improvement, optional PDEP entry |
| Primary Inputs | Product Signal Bundle, PCON decision, explicit feedback |
| External Dependencies | Feedback Processor, PDEP Entry, product lifecycle systems |
| Core Activities | Create decision context, process explicit feedback, generate CFR, route creation/composition intent to PDEP if needed |
| Processing Type | PCON-driven with platform processing |
| Output Artifacts | Decision Context, CFR — Consumption Feedback Record |
| State Transition | From “Observed product value” → “Continue / stop / feedback / create” |
| Governance Controls | Feedback governance, product evolution controls, creation intent routing |
| Validation Mechanisms | Feedback validation, signal-feedback correlation, PDEP entry validation |
| PCON Responsibility | Decide whether to continue, stop, give feedback, or initiate creation/composition |
| Platform Responsibility (HDIP) | Convert signals and feedback into actionable product lifecycle events |
| Dependency Treatment | If new product creation is triggered, consumed products may become dependencies in the new PDEP flow |
| Quality Sensitivity | Critical — this stage drives product improvement, marketplace learning, and recursive product creation |
| Failure Modes / Risks | Feedback ignored, weak decision context, poor signal interpretation, broken PDEP transition |
| Observability Signals | Feedback volume, continuation rate, churn rate, creation triggers, composition triggers |
| Feedback Loop | Feeds product evolution, PMDD, marketplace ranking, and PDEP |
To Summarize HDIP © SSCF
HDIP SSCF is not a simple consumption journey.
It is a governed product consumption lifecycle where:
Intent leads to product resolution, product resolution leads to governed access, governed access leads to CEP-mediated consumption, consumption produces product signals, and product signals drive feedback, continuation, or new product creation.
This is what makes HDIP a recursive product ecosystem rather than a static platform.
HDIP © Product Consumption Glossary
This glossary defines the key terms used in the HDIP Self-Service Product Consumption Flow (SSCF) for a Product Consumer (PCON).
The glossary applies to consumption of any HDIP-supported product type, including Data Products, AI Products, Composite Products, and future product types.
Access & Entitlements
The enterprise service responsible for managing and enforcing who or what may access a product, product port, interface, or consumption capability.
In the PCON flow, Access & Entitlements supports governed access decisions by binding consumer identity, role, purpose, policy, and product-specific access rules.
Access Decision
A formal artifact produced by the Policy & Entitlement Evaluation stage that records whether a PCON is allowed, denied, or conditionally allowed to access a selected product set.
The access decision is purpose-bound and must consider the CIR, selected products, consumer context, policy rules, and entitlement state.
Access Descriptor
An artifact describing how a PCON may access approved product ports.
It may include endpoint references, access mode, authentication context, entitlement binding, usage constraints, and runtime access conditions.
Access Provisioning
The HDIP platform capability responsible for materializing governed access after an access decision has been approved or conditionally approved.
Access provisioning creates or binds access descriptors, usage contracts, and product ports.
Acquire / Onboard
The PCON stage where the consumer requests access, subscribes, purchases, or otherwise initiates onboarding to a selected product or product set.
This does not itself grant access; it triggers policy and entitlement evaluation.
Agentic Persona
A CEP overlay persona representing an agent, workflow, autonomous process, or AI-enabled orchestration layer consuming products to perform tasks or create downstream outcomes.
Typical agentic consumption modes include workflow orchestration, product composition, and automated task execution.
Analytical Persona
A CEP overlay persona representing analysts, data scientists, quantitative users, or analytical systems consuming products through query, exploration, or analytical tooling.
Typical analytical consumption modes include SQL, Trino, BigQuery, notebooks, and joined datasets.
Browse-First Mode
A secondary HDIP consumption mode where a PCON begins by browsing the Product Marketplace or Product Catalog before explicitly declaring intent.
Browse-first mode is valid for simpler use cases, but it must still result in an inferred or confirmed CIR before governed access, consumption, observability, and feedback proceed.
Business Persona
A CEP overlay persona representing business consumers who experience products through business-oriented interfaces such as dashboards, KPIs, scorecards, summaries, or decision-support views.
Catalog
See Product Catalog.
CEP
See Consumer Experience Plane.
CEP Overlay
A persona-specific interpretation layer that changes how consumption is presented, experienced, measured, and valued.
In the SSCF, the same product consumption flow may appear differently depending on whether the PCON is business, analytical, AI, system, or agentic.
Example overlays include:
| CEP Node | Business | Analytical | AI | System | Agentic |
|---|---|---|---|---|---|
| Consume | Dashboard | SQL / Trino / BQ | Feature pipeline | API / stream | Workflow orchestration |
| Views | Aggregated KPIs | Joined datasets | Feature datasets | JSON / events | Workflow outputs |
| Usage | Consumption patterns | Query logs | Training usage | API calls | Workflow runs |
| Value | ROI | Data utility | Model uplift | Service performance | Outcome efficiency |
CEP Renderer
The HDIP platform service that renders governed product consumption into persona-appropriate experiences through the Consumer Experience Plane.
The CEP Renderer uses Product Ports, Access Descriptors, Usage Contracts, and consumer persona context to produce Consumption Views such as dashboards, SQL/query interfaces, APIs, streams, feature pipelines, workflow outputs, or agentic interfaces.
CFR
See Consumption Feedback Record.
CIR
See Consumption Intent Record.
Composite Product
A product created by composing one or more existing products, such as Data Products, AI Products, media products, APIs, or other composite products.
In HDIP, consumption can lead to composition, where a PCON becomes a producer by entering PDEP.
Consume / Experience
The stage where a PCON uses a product through the Consumer Experience Plane.
Consumption occurs through governed product ports, access descriptors, and usage contracts. It may result in dashboards, queries, APIs, streams, feature pipelines, workflow outputs, or other persona-specific experiences.
Consumer Experience Plane
The HDIP layer that enables consumers to experience products through persona-appropriate interfaces.
CEP does not replace product ports. Instead, it renders governed product access into useful experiences such as dashboards, SQL interfaces, APIs, feature pipelines, streams, or agentic workflows.
In Data Mesh plane terms, the Consumer Experience Plane corresponds primarily to the Mesh Experience Plane, because it is the consumer-facing layer where product discovery, access, consumption, and experience are mediated.
Consumption Feedback Record
A formal artifact capturing feedback from product consumption.
The CFR may include explicit PCON feedback, issues, ratings, satisfaction, adoption signals, improvement requests, or signal-informed feedback derived from observed usage, cost, and value patterns.
Consumption Intent Record
A computable artifact capturing the PCON’s declared consumption intent.
The CIR records what the consumer wants, why it is needed, the context of use, relevant consumption archetype, and purpose-bound framing. It drives product resolution, access evaluation, value measurement, and feedback interpretation.
Consumption Intent
The PCON’s expression of desired outcome, need, purpose, and context.
In canonical HDIP consumption, intent is declared before products are selected. This allows the platform to resolve products based on desired outcome rather than forcing consumers to search manually.
Consumption Views
Artifacts generated by the CEP renderer that represent the product in a persona-appropriate consumable form.
Examples include dashboards, joined datasets, feature datasets, JSON responses, event streams, workflow outputs, summaries, or analytical views.
Cost Records
Artifacts capturing the economic cost of product consumption.
Cost records may include query cost, API call cost, inference cost, compute cost, storage/read cost, chargeback, showback, or cost attribution by consumer, product, purpose, or usage contract.
Data Product
A domain-owned, governed product that exposes data through well-defined, trusted, discoverable, and consumable product ports.
In the PCON flow, Data Products are consumed like any other product type through intent, resolution, access, CEP, observability, and feedback.
Decide Next
The PCON stage where the consumer decides whether to continue consuming, stop consuming, provide feedback, request alternatives, or initiate creation/composition of a new product.
This stage closes the consumption loop and may trigger PDEP.
Decision Context
An artifact that captures the basis for the PCON’s next decision.
It is informed by the Product Signal Bundle and may include continuation, discontinuation, feedback, escalation, substitution, or create/compose options.
Discover Products
The PCON stage where candidate products are discovered or resolved.
In canonical HDIP mode, discovery is driven by the CIR. The product discovery process uses the Product Resolution Engine, Product Catalog, and Product Marketplace.
Entitlement Binding
The process of associating an approved access decision with concrete access rights, roles, credentials, scopes, or runtime permissions.
Entitlement binding ensures that approved access is enforceable at product-port level.
Evaluate Product Fit
The PCON stage where candidate products are assessed for relevance, meaning, trust, cost, usability, and suitability against the declared intent.
Evaluation uses the Product Catalog, Product Resolution Set, DPP/trust metadata, and product semantics.
Feedback
The explicit or signal-informed response from a PCON after consuming a product.
Feedback may include issues, ratings, improvement suggestions, discontinuation reasons, satisfaction signals, or creation/composition intent.
Feedback Processor
The HDIP platform service that converts explicit feedback and signal-informed feedback into a formal CFR and routes it to relevant lifecycle processes.
It may inform product evolution, PMDD, marketplace ranking, governance review, or PDEP initiation.
FinOps
The enterprise capability responsible for measuring, attributing, optimizing, and governing the economic cost of product consumption.
In the PCON flow, FinOps contributes Cost Records and supports cost transparency, showback, chargeback, and cost-to-value analysis.
FinOps Engine
The HDIP platform service that computes cost records from usage signals, usage contracts, and economic rules.
The FinOps Engine explains economic consumption; it does not, by itself, fully compute business value.
Governed Access
Access that is purpose-bound, policy-shaped, entitlement-backed, and enforced through product ports and access descriptors.
Governed access is not generic permission to use a product; it is permission to use a product for a declared purpose under specific constraints.
HDIP
Holistic Data & Information Platform.
HDIP is an architecture for productizing data, intelligence, and information-producing capabilities through governed creation, consumption, observability, and recursive composition.
Intent-First Mode
The canonical HDIP consumption mode.
In Intent-First Mode, the PCON first declares what they want to achieve. The platform then creates a CIR and resolves suitable products using the Product Resolution Engine, Product Catalog, and Product Marketplace.
Intent Interpreter + Normalizer
The HDIP platform service that converts a PCON’s declared intent into a structured, computable CIR.
It may normalize language, infer consumption archetypes, clarify purpose, and validate completeness.
Marketplace
See Product Marketplace.
Observability
The capability to make product consumption signals visible, queryable, monitorable, and actionable.
In the PCON flow, observability primarily refers to Product Consumption Observability rather than low-level platform operations.
Observability Engine
The HDIP platform service that exposes the Product Signal Bundle through an observability surface.
It makes usage, cost, value, trust, and feedback signals visible for consumers, product owners, governance teams, and platform operators.
PCON
Product Consumer.
PCON is a role played by an agent, human or non-human, when consuming a product. A PCON may consume a product to experience information, perform work, trigger automation, or compose a new product.
A PCON can later become a producer by entering PDEP.
PDEP
Product Development and Evolution Process.
PDEP is the HDIP creation/composition lifecycle entered when a consumer decides to create or compose a new product based on consumption outcomes.
PDEP Entry
The transition point from consumption into product creation or composition.
In the PCON flow, PDEP Entry is triggered when the Decision Context indicates that the PCON wants to create, compose, or evolve a product.
Platform Observability
The monitoring of HDIP platform health, reliability, security, infrastructure, service performance, and operational SLOs.
Platform Observability is distinct from Product Consumption Observability. It monitors the platform services enabling the flow, not merely the consumption of an individual product.
Policy & Entitlement Evaluation
The HDIP platform service that determines whether a PCON may access a selected product set for a declared purpose.
It evaluates the CIR, selected products, consumer identity/context, policy rules, and entitlement state.
Policy Service
The enterprise service that stores, evaluates, or exposes policy rules.
Policies may cover access, purpose limitation, privacy, residency, retention, compliance, risk, contractual obligations, and product-specific constraints.
Product
A governed, discoverable, consumable unit of value exposed through HDIP.
Products may include Data Products, AI Products, Composite Products, media products, API products, agent products, or other future product types.
Product Catalog
The enterprise system of record for product metadata, semantics, trust information, product identity, interfaces, lifecycle state, and discovery metadata.
The Product Catalog supports evaluation, resolution, trust review, and product understanding.
Product Catalog / Registry
A unified system of record and discovery surface for all HDIP products, independent of type.
It may contain Data Products, AI Products, Composite Products, and other product kinds.
Product Consumption Observability
The capability to observe, measure, and interpret how a product is consumed and what usage, cost, trust, value, and feedback signals are produced.
It answers:
How is this product being consumed, by whom, for what purpose, at what cost, and with what value?
Product Discovery Orchestrator
The HDIP platform service that coordinates product discovery and resolution.
It works with the CIR, Product Resolution Engine, Product Catalog, and Product Marketplace to support intent-driven product discovery.
Product Marketplace
The enterprise surface where products can be discovered, compared, acquired, subscribed to, or requested.
In HDIP, the Marketplace is not the sole origin of intent. It participates in discovery and acquisition after or alongside CIR creation.
Product Ports
Governed product access interfaces exposed to consumers.
Product ports may include APIs, SQL endpoints, streams, feature pipelines, dashboards, agent interfaces, files, events, or other controlled access mechanisms.
Products are consumed through ports, not through internal implementation details.
Product Resolution Engine
The HDIP platform service that maps a CIR to candidate products.
It uses product metadata, semantics, trust information, marketplace availability, policy context, and fit scoring to produce a Product Resolution Set.
Product Resolution Set
An artifact containing candidate products resolved against the CIR.
It may include product identifiers, ranking, fit scores, rationale, trust indicators, compatibility notes, and constraints.
Product Signal Bundle
A composite artifact that aggregates Usage Signals, Cost Records, and Value Signals.
The Product Signal Bundle is used for product observability, decision context, feedback processing, PMDD, marketplace learning, and product evolution.
Product Signals
A general term for measured signals generated by product consumption.
In the SSCF, Product Signals are represented as Usage Signals, Cost Records, Value Signals, and the aggregated Product Signal Bundle.
Purpose-Bound Access
Access granted for a declared and governed purpose.
In HDIP, access is not merely about who the PCON is or what product they selected. It also depends on why the product is being consumed and under what declared context.
Resolve Product Set
The stage where HDIP translates the CIR into candidate products.
Resolution is intent-driven and uses catalog metadata, marketplace information, semantics, and product fit logic.
Self-Service Product Consumption Flow
The HDIP consumer lifecycle that allows PCONs to declare intent, resolve products, evaluate fit, request access, consume through CEP, capture signals, observe value, and decide next steps.
Also known as SSCF.
Signals
See Product Signal Bundle.
SSCF
Self-Service Consumption Flow.
The HDIP flow for product consumption by PCONs. It defines the journey from intent declaration to product resolution, governed access, consumption, observability, feedback, and potential PDEP entry.
System Persona
A CEP overlay persona representing a software system, API client, automation process, integration runtime, or service consuming products programmatically.
Typical system consumption modes include APIs, streams, events, and JSON payloads.
Usage Contract
An artifact describing the allowed, expected, and measurable conditions of product consumption.
It may include SLA/SLO expectations, usage mode, consumption constraints, obligations, quotas, freshness expectations, and permitted purpose.
Usage Signals
Artifacts capturing measured product consumption.
Usage Signals may include port usage, API calls, SQL queries, dashboard views, model calls, workflow runs, feature consumption, view interactions, and contract-contextualized telemetry.
Usage Tracking
The HDIP platform service responsible for capturing and normalizing usage telemetry from product ports, CEP interactions, views, and usage contract context.
Value Computation
The HDIP platform capability that computes outcome contribution from usage, intent, usage contract, and product context.
Value computation is distinct from FinOps: FinOps explains cost, while value computation explains contribution, utility, impact, uplift, efficiency, or ROI.
Value Computation Engine
The HDIP platform service that computes Value Signals from Usage Signals, CIR, usage contract, product context, and value rules.
Value Signals
Artifacts representing the value or outcome contribution of product consumption.
Value Signals may include ROI, data utility, model uplift, service performance, outcome efficiency, consumer satisfaction, or business impact.