🧭 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
- Information Products
- AI Products
- Compound Products where established by BPS / PIN
- Other BPS-qualified Product Families supported by 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.
The eight SSCF stages define a logical consumption lifecycle, not a requirement that every Product interaction physically execute eight synchronous runtime steps. Existing subscriptions, automated consumers, or previously established governed access MAY reuse current CIR, access, contract, and entitlement state where applicable.
Diagram note: The Spec C diagram presents nine consumer-facing interaction steps as an experience-oriented projection of the eight canonical SSCF stages. The nine interaction steps are not a second competing lifecycle.
🔴 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, governed consumption framing; declared purpose does not itself grant Product access or downstream action authorization |
| 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; catalog or marketplace presence does not itself establish Product qualification |
| 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; this is a Product-access decision, not by itself authorization for a downstream consequential Decision or Action |
| 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 Product-access policies, entitlement rules, compliance constraints, Product-level access posture; downstream consequential action authorization remains separately governed where applicable |
| 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 |
Authorization boundary: An SSCF Access Decision governs Product / Product Port access. It does not, by itself, authorize a consequential downstream Decision, Digital Action, Physical Action, Tool use, or other effect that requires separate point-of-use authorization.
🔴 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 governed access to applicable Product Ports provisioned for consumption |
| Context | Follows access approval or conditional approval |
| Scope | Access binding, entitlement materialization, Product Port access provisioning, usage contract generation |
| Primary Inputs | CIR, Product Resolution Set, Access Decision, Entitlements |
| External Dependencies | Access Provisioning Service, Entitlements Service, Product Port access infrastructure |
| Core Activities | Bind entitlements, provision access descriptors, expose governed access to applicable Product Ports, create usage contract |
| Processing Type | Platform-driven |
| Output Artifacts | Access Descriptor, Usage Contract, Product Port access binding / entitlement context |
| 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 governed Product consumption insights and economic/value signals |
| 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-model validation, signal bundle completeness checks, and evidence/attribution checks appropriate to the declared value model |
| 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, unsupported causal/value claims, 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 |
Value-evidence boundary: Usage, Cost, and Value Signals are evidence under their declared measurement/attribution models. They do not automatically establish causality, realized ROI, trustworthiness, or assurance.
🔴 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 initiate PDEP for potential new Product constitution, composition, or evolution |
| Outcome | Decision Context, Feedback Record, or transition into PDEP for governed Product constitution, composition, or evolution where applicable |
| 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 Product constitution/composition/evolution 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 a governed PDEP path for potential Product constitution/composition/evolution |
| Platform Responsibility (HDIP) | Convert signals and feedback into actionable product lifecycle events |
| Dependency Treatment | If PDEP entry is triggered, consumed Products MAY become governed dependencies in the new Product design; composition alone does not create a new Product identity |
| 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 |
Product-constitution boundary: Composition, orchestration, or combined consumption does not automatically create a new Product. A new Product exists only where intentional Product constitution and the applicable BPS / PIN and Product-family qualification are satisfied.
Decision boundary: SSCF Decision Context supports the consumer lifecycle. It is not, by itself, a GEAIRA point-of-use Authorization or a universal enterprise Decision semantic.
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 potential Product constitution/evolution through PDEP.
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, Information Products, AI Products, Compound Products where established by BPS / PIN, and other BPS-qualified Product Families supported by HDIP.
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 Product-access decisions by binding consumer identity, role, purpose, policy, and Product-specific access rules. Product entitlement does not, by itself, authorize a downstream consequential Decision or Action.
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. It governs access to the Product / Product Port and does not, by itself, constitute GEAIRA point-of-use Authorization for a consequential Decision or Action performed using the Product.
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 governed access to already-defined applicable Product Ports. Consumer onboarding does not itself create the Product Port.
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. Agentic consumption does not, by itself, establish Delegated Authority or point-of-use Authorization.
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 logical/platform capability that renders governed Product consumption into persona-appropriate experiences through the Consumer Experience Plane. It need not be realized as one mandatory standalone service.
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.
Compound Product / Product Composition
Generic Compound Product and Product-composition semantics are governed by BPS / PIN. Composition of one or more existing Products, capabilities, assets, APIs, or other resources does not automatically create a new Product identity.
In HDIP, consumption may lead to a PDEP entry where a PCON becomes a producer and may intentionally constitute a new Product subject to BPS / PIN and the applicable Product-family qualification.
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 a Data Mesh-aligned HDIP realization, the Consumer Experience Plane may realize concerns analogous to a Mesh Experience Plane. CEP itself is an HDIP construct spanning Data, Information, and Intelligence consumption and does not depend on Data Mesh as a universal operating model.
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 BPS-qualified Product whose applicable Product-family semantics identify it as a Data Product. HDIP does not infer Data Product status merely from catalog registration, reuse, or exposure.
In the PCON flow, Data Products participate in the same intent, resolution, access, CEP, observability, and feedback lifecycle, subject to their governed Product contracts and Data-specific obligations.
Information Product
A BPS-qualified Product whose applicable Information Product-family semantics identify it as an Information Product. HDIP does not infer Information Product status merely from analytical output, publication, reuse, or interface exposure.
Within SSCF, Information Products participate in the same intent, discovery, access, consumption, observability, and feedback lifecycle subject to their Product contract and applicable Information/Analytics architecture obligations.
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 PDEP-entry options. SSCF Decision Context is a Product-consumption lifecycle artifact; it is not, by itself, GEAIRA point-of-use Authorization or a universal enterprise Decision semantic.
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 access a Product for a declared purpose under specific constraints. For AI-enabled or consequential downstream use, Product entitlement does not replace any separately applicable Decision/Action authorization requirement.
HDIP
Holistic Data, Information and Intelligence Platform.
HDIP is an enterprise logical platform architecture for governed Data, Information, and Intelligence capabilities, including intentional Product creation/consumption where BPS / PIN and the applicable Product-family semantics establish Product status.
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. PDEP entry initiates governed Product design/constitution; composition alone does not create Product identity.
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. Policy evaluation/exposure does not make the Policy Service the authoritative owner or author of the underlying policy.
Product
A Product qualified under BPS / PIN and, where applicable, the relevant Product-family specification. HDIP adds platform-specific discovery, access, consumption, observability, and lifecycle realization; exposure through HDIP does not itself establish Product Intrinsic Nature or Product Family.
HDIP may support Data Products, Information Products, AI Products, Compound Products where defined by BPS / PIN, and other BPS-qualified Product Families.
Product Catalog
The authoritative HDIP registry/projection for registered Product metadata and discovery state, including references to Product identity, interfaces, lifecycle/currentness, trust information, and semantic descriptors governed by their defining authorities.
Catalog registration does not establish Product qualification or transfer semantic authority from BPS / PIN or the applicable Product-family specification. The Product Catalog supports evaluation, resolution, trust review, and Product understanding.
Product Catalog / Registry
The HDIP registry/discovery surface for Products registered with the platform, independent of Product Family.
It may contain Data Products, Information Products, AI Products, Compound Products where defined by BPS / PIN, and other supported Product kinds. Registry presence alone does not establish Product status or semantic conformance.
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 Ports are part of the governed Product interface/contract; SSCF provisions access to applicable Product Ports rather than creating them merely because an individual consumer is onboarded.
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 produces governed measurements, estimates, or attribution outputs concerning contribution, utility, impact, uplift, efficiency, or ROI according to an explicit value model. Such signals do not inherently establish causal proof.
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 measured, estimated, or attributed value/outcome signals associated with Product consumption.
Value Signals may include ROI estimates, data utility, model uplift, service performance, outcome efficiency, consumer satisfaction, or business impact indicators. A Value Signal is evidence under its declared value model and does not automatically prove that the Product caused the observed outcome.