Skip to main content

PVEP–PDEP Boundary

1. Purpose​

The PVEP–PDEP Boundary defines the architectural separation between the ProductVerse Experience Plane (PVEP) and the Product Development and Execution Plane (PDEP).

This boundary is one of the most important boundaries in UPOS.

PVEP is the consumer-oriented experience plane through which participants discover, evaluate, acquire, consume, navigate, trust, select, and prepare product sets across the ProductVerse.

PDEP is the product-building plane through which products are authored, composed, validated, versioned, governed, published, and evolved.

The boundary matters because ProductVerse experiences should help consumers explore and select products without accidentally turning PVEP into an uncontrolled product creation environment.

The key principle is:

PVEP helps participants discover, evaluate, consume, select, and prepare products. PDEP creates, composes, validates, versions, publishes, and evolves governed products.

2. Core Boundary Statement​

The simplest boundary statement is:

PVEP explores and experiences the ProductVerse.
PDEP builds and evolves governed products.

More specifically:

PVEP:
  discover
  evaluate
  acquire
  consume
  navigate
  trust
  select
  assemble candidate sets
  route to next action

PDEP:
  author
  compose
  validate
  generate artifacts
  bind evidence
  generate or update DPPs
  version
  publish
  govern lifecycle

The boundary can also be stated as:

PVEP can prepare product intent.
PDEP realizes product intent as a governed product.

3. Why the Boundary Exists​

The ProductVerse contains many productized entities that can be discovered, selected, used, and combined.

Without a clear PVEP–PDEP boundary, several problems arise:

  • consumers may create derivative products without governance,
  • product sets may be mistaken for governed products,
  • selected products may bypass entitlement, policy, trust, risk, evidence, and DPP checks,
  • marketplace experiences may become informal product-building tools,
  • agents may compose or publish beyond their authority,
  • product lifecycle state may become unclear,
  • DPPs may be missing or generated after the fact,
  • inherited restrictions may be ignored,
  • product versioning may become uncontrolled,
  • runtime enforcement may not be prepared.

The boundary exists to ensure that product exploration remains lightweight while product creation remains governed.

4. Definitions​

4.1 ProductVerse Experience Plane​

The ProductVerse Experience Plane (PVEP) is the consumer-oriented plane through which humans, organizations, applications, agents, and products-as-consumers interact with the ProductVerse.

PVEP supports experiences for:

  • marketplace discovery,
  • product evaluation,
  • product acquisition,
  • product onboarding,
  • product consumption,
  • concierge and agent-mediated discovery,
  • product graph navigation,
  • portfolio and entitlement views,
  • product selection and assembly,
  • governance and trust inspection,
  • transition to PDEP when creation intent emerges.

PVEP is primarily an experience mediation plane.

4.2 Product Development and Execution Plane​

The Product Development and Execution Plane (PDEP) is the product-building and lifecycle-control plane through which products are authored, composed, validated, versioned, governed, published, and evolved.

PDEP supports capabilities for:

  • product intent capture,
  • product authoring,
  • product composition,
  • product descriptor creation,
  • deployment descriptor generation,
  • output port definition,
  • evidence binding,
  • DPP generation,
  • lifecycle validation,
  • versioning,
  • publication,
  • deprecation,
  • retirement.

PDEP is primarily a governed product realization plane.

5. PVEP Responsibilities​

PVEP is responsible for consumer and agent experiences across the ProductVerse.

PVEP may allow participants to:

  • discover products,
  • search products,
  • browse product listings,
  • compare products,
  • inspect product details,
  • inspect DPP summaries,
  • understand trust posture,
  • understand entitlement state,
  • understand permitted and prohibited uses,
  • consume product output ports,
  • request access,
  • subscribe or acquire,
  • view portfolio state,
  • navigate product relationships,
  • select products into a product set,
  • evaluate product-set suitability,
  • identify governance issues,
  • prepare a handoff to PDEP.

PVEP is allowed to create experience artifacts, such as:

  • saved searches,
  • product sets,
  • comparison views,
  • shortlisted products,
  • consumption preferences,
  • entitlement requests,
  • access requests,
  • marketplace acquisition requests,
  • PDEP handoff packages.

However, these artifacts are not automatically governed products.

6. PDEP Responsibilities​

PDEP is responsible for turning intent, selected products, and product-building activity into governed products.

PDEP may:

  • create new product records,
  • assign product identity,
  • define product ownership and stewardship,
  • author product descriptors,
  • compose products from input products,
  • define output ports,
  • generate deployment descriptors,
  • generate semantic descriptors,
  • collect and bind evidence,
  • create or update DPPs,
  • evaluate lifecycle gates,
  • validate product readiness,
  • version product artifacts,
  • publish products,
  • list products in marketplace,
  • deprecate products,
  • retire products,
  • preserve audit and lineage.

PDEP owns the transition from:

candidate product set

to:

governed product

7. Product Set vs Product​

A central distinction is between a Product Set and a Product.

ConceptMeaningPlane
Product SetA selected collection of products organized for comparison, planning, consumption, acquisition, review, or possible creation.PVEP
ProductA governed productized entity with identity, ownership, descriptor, lifecycle, output ports, governance state, and possibly DPP.PDEP / ProductVerse

A Product Set may become input to PDEP.

But a Product Set is not automatically:

  • a new product,
  • a governed bundle,
  • a published artifact,
  • a versioned descriptor,
  • a DPP-backed entity,
  • a marketplace listing,
  • a runtime-consumable product.

Example:

PVEP Product Set:
  Data Product A
  AI Product B
  Dashboard Template C

PDEP Governed Product:
  Risk Monitoring Product v1.0
  composed from A, B, and C
  with product identity, owner, output ports, DPP, evidence, and lifecycle state

8. Selection vs Composition​

Selection and composition are often confused.

TermMeaningPlane
SelectChoose one or more products for a purpose.PVEP
AssembleOrganize selected products into a candidate set, shortlist, scenario, or planning view.PVEP
ComposeCreate a new governed product from selected products or components.PDEP

PVEP may support product selection and pre-assembly reasoning.

PDEP owns governed composition.

Boundary statement:

PVEP assembles candidate sets.
PDEP composes governed products.

9. Consumption vs Creation​

Another important distinction is between consumption and creation.

9.1 Consumption​

Consumption means using existing product output ports.

Examples:

  • open a dashboard,
  • invoke an API,
  • query a SQL endpoint,
  • download a permitted file,
  • read a comic product,
  • use a model endpoint,
  • consume an event stream,
  • view DPP summary,
  • launch a workflow exposed by an existing product.

Consumption belongs primarily to PVEP and Product Fabric.

PVEP mediates the experience. Product Fabric enforces runtime governance.

9.2 Creation​

Creation means producing a new governed product or materially changing an existing product.

Examples:

  • composing a new product from selected products,
  • defining a new output port,
  • creating a new descriptor,
  • publishing a product,
  • creating a new DPP,
  • generating a new product version,
  • creating a derivative product,
  • turning a product set into a marketplace listing.

Creation belongs to PDEP.

Boundary statement:

PVEP enables consumption of existing products.
PDEP governs creation of new products.

10. When PVEP Should Stay in PVEP​

A user or agent remains in PVEP when the intent is to:

  • find a product,
  • compare products,
  • inspect trust,
  • inspect DPP,
  • request access,
  • accept a license,
  • subscribe,
  • acquire,
  • use an output port,
  • view portfolio,
  • understand entitlement,
  • navigate product relationships,
  • save a product set,
  • share a shortlist,
  • prepare a candidate set,
  • understand whether creation may be possible.

Examples:

“Show me products suitable for internal analytics.”
“Compare these three AI Products.”
“Add these products to my project set.”
“Request API access.”
“Open the dashboard.”
“Show me the DPP and trust evidence.”

None of these require PDEP unless the user intends to create or modify a governed product.

11. When PVEP Should Transition to PDEP​

PVEP should transition to PDEP when the user or agent intends to:

  • create a new product,
  • compose selected products into a new governed product,
  • create a derivative product,
  • publish a product,
  • define or expose a new output port,
  • generate or update a product descriptor,
  • generate or update a DPP,
  • version a product,
  • materially change product behavior,
  • define product lifecycle state,
  • create a marketplace listing for a new product,
  • validate product readiness,
  • bind evidence to product claims,
  • establish product ownership or stewardship,
  • prepare runtime deployment for a product.

Examples:

“Create a new risk monitoring product from these selected products.”
“Publish this selected product set as a bundle.”
“Create a new AI Product using this Data Product.”
“Turn these comic assets into a Comic Product Bundle.”
“Expose a new API for this product.”
“Generate a DPP for this new product.”

These require PDEP because they create or modify governed product state.

12. Boundary Decision Questions​

PVEP can determine whether to stay in PVEP or transition to PDEP using a set of boundary questions.

QuestionIf yes
Is the user only discovering, comparing, or evaluating products?Stay in PVEP.
Is the user consuming an existing output port?Stay in PVEP; Product Fabric enforces.
Is the user requesting access, subscription, or license?Stay in PVEP / Marketplace / Entitlement flow.
Is the user saving or sharing a product set?Stay in PVEP.
Is the user creating a new product identity?Transition to PDEP.
Is the user composing selected products into a new governed artifact?Transition to PDEP.
Is a new descriptor, DPP, output port, or lifecycle state required?Transition to PDEP.
Is the user creating derivative use or publication?Transition to PDEP.
Is versioning, validation, or publication required?Transition to PDEP.
Is runtime deployment preparation required?Transition to PDEP.

The most important question is:

Is a new governed product being created or changed?

If yes, the flow belongs in PDEP.

13. Boundary Examples​

13.1 Data and AI Example​

PVEP:
User selects a Customer Data Product and Churn Prediction AI Product.

Still PVEP:
User compares trust, risk, entitlement, and DPP state.

Transition to PDEP:
User wants to create a new Customer Retention Insight Product from them.

13.2 Creative Product Example​

PVEP:
User selects character assets, background assets, and a comic template.

Still PVEP:
User reviews licenses and compares styles.

Transition to PDEP:
User wants to create and publish a Comic Product Bundle.

13.3 Physical Product Example​

PVEP:
User selects a Rocket Engine Product, Fuel System Product, and Telemetry Product.

Still PVEP:
User reviews compatibility, certification, and risk.

Transition to PDEP:
User wants to define a new Rocket Stage Product composed from those products.

13.4 Agent Example​

PVEP:
AI agent recommends a product set to a human user.

Still PVEP:
Agent explains suitability, trust, and entitlement.

Transition to PDEP:
Human confirms intent to create a new governed product from the set.

14. PVEP-to-PDEP Handoff​

When PVEP transitions to PDEP, it should pass structured context.

A handoff package may include:

  • product set identifier,
  • selected products,
  • product versions,
  • intended outcome,
  • declared purpose,
  • intended product kind,
  • desired output ports,
  • consumer or creator identity,
  • agent involvement,
  • governance state,
  • known constraints,
  • inherited restrictions,
  • entitlement state,
  • trust state,
  • risk state,
  • evidence state,
  • DPP state,
  • licensing constraints,
  • relationship context,
  • candidate substitutes,
  • unresolved issues,
  • user notes,
  • agent recommendations.

Example:

pdepHandoff:
  source: pvep-product-select-assembly-zone
  productSetId: set-123
  intendedOutcome: create-new-risk-monitoring-product
  intendedProductKind: ai-enabled-analytics-product

  selectedProducts:
    - id: product-data-001
      version: 2.1
    - id: product-ai-002
      version: 1.4
    - id: product-dashboard-template-003
      version: 1.0

  purpose:
    code: internal-risk-monitoring

  governanceState:
    entitlement: partially-entitled
    trust: conditionally-trusted
    risk: R3
    dpp: one-input-dpp-expired

  knownConstraints:
    - no-external-sharing
    - audit-logging-required
    - human-review-required

  unresolvedIssues:
    - request-access-to-product-ai-002
    - refresh-dpp-for-product-data-001
    - complete-model-evaluation-evidence

The handoff should not silently create a product. It should initiate a governed PDEP workflow.

15. PDEP-to-PVEP Feedback​

The boundary is bidirectional.

After PDEP creates, validates, publishes, or changes a product, PVEP may render the resulting product state.

PDEP may send PVEP:

  • new product availability,
  • product listing status,
  • lifecycle state,
  • trust state,
  • DPP state,
  • entitlement requirements,
  • output-port availability,
  • publication status,
  • deprecation status,
  • governance warnings,
  • consumption links,
  • marketplace listing reference.

Example:

PDEP publishes Product X.
PVEP updates marketplace listing, product graph, portfolio, governance trust view, and consumption entry points.

16. Governance Kernel Role at the Boundary​

The Governance Kernel supports the PVEP–PDEP boundary by determining:

  • whether selected products may be used together,
  • whether derivative use is permitted,
  • whether PDEP transition is required,
  • what restrictions propagate,
  • whether creator or agent authority is sufficient,
  • whether input products are trusted,
  • whether evidence is sufficient,
  • whether DPP state is valid,
  • whether risk is acceptable,
  • whether lifecycle gates apply.

The Governance Kernel should provide boundary decisions such as:

  • remain in PVEP,
  • proceed to consumption,
  • proceed to marketplace acquisition,
  • proceed to governance review,
  • transition to PDEP,
  • transition to PDEP with warnings,
  • transition blocked until entitlement/evidence/trust issue resolved.

Example:

Selected products can be consumed directly for internal use.
PDEP is required only if user wants to create a derivative product.

17. Product Fabric Role at the Boundary​

Product Fabric enforces runtime decisions when products are consumed.

PVEP may show an action as available, but Product Fabric must enforce:

  • access,
  • entitlement,
  • masking,
  • filtering,
  • output-port restrictions,
  • rate limits,
  • audit logging,
  • jurisdiction routing,
  • agent invocation constraints.

Boundary example:

PVEP:
Shows API access available.

Product Fabric:
Enforces API entitlement, audit logging, and no external sharing restrictions.

Product Fabric does not replace PDEP. It enforces runtime use of already governed products.

18. Marketplace Role at the Boundary​

Marketplace experiences often sit close to the boundary.

Marketplace supports:

  • discovery,
  • listing,
  • pricing,
  • licensing,
  • subscription,
  • acquisition,
  • onboarding,
  • access request.

Marketplace does not create new governed products unless it routes to PDEP.

Example:

Marketplace:
User subscribes to existing Product A.

PDEP:
Not required.

Marketplace:
User wants to publish a new product bundle.

PDEP:
Required.

19. Agent Role at the Boundary​

Agents may assist with discovery, selection, recommendation, comparison, and handoff preparation.

Agents may not cross into product creation unless explicitly authorized.

Agent actions should be evaluated for:

  • delegated authority,
  • permitted scope,
  • product access,
  • product selection rights,
  • composition rights,
  • publication rights,
  • human confirmation requirements,
  • audit obligations.

Example:

AI agent may recommend a PDEP transition.
AI agent may prepare a PDEP handoff package.
AI agent may not publish the product unless explicitly authorized.

Boundary principle:

Agent assistance in PVEP does not imply agent authority in PDEP.

20. Governance States at the Boundary​

Boundary transitions should consider several governance states.

StateBoundary relevance
EntitlementCan selected products be used or composed?
PolicyAre intended uses permitted?
TrustAre products fit for the intended purpose?
RiskDoes the intended action require review or controls?
EvidenceIs evidence sufficient for consumption or creation?
DPPAre DPPs valid and product-version-aligned?
LicenseAre derivative use, redistribution, or publication allowed?
LifecycleAre selected products active, deprecated, retired, or under review?
Agent authorityIs the acting agent allowed to prepare or perform transition?
Product relationshipsDo dependencies or restrictions propagate?

21. Common Boundary Scenarios​

21.1 Direct Consumption​

Intent:
Use existing product.

Boundary:
Stay in PVEP / Consumption Experience.

Governance:
Kernel checks entitlement and usage.
Product Fabric enforces runtime access.

21.2 Product Set Planning​

Intent:
Create a shortlist or candidate set.

Boundary:
Stay in PVEP / Product Select & Assembly.

Governance:
Kernel checks suitability, constraints, and warnings.

21.3 Product Acquisition​

Intent:
Subscribe to or acquire existing products.

Boundary:
Stay in PVEP / Marketplace.

Governance:
Kernel checks eligibility, entitlement, license, trust, and policy.

21.4 Product Composition​

Intent:
Create new product from selected products.

Boundary:
Transition to PDEP.

Governance:
Kernel checks composition, inherited restrictions, evidence, trust, risk, and lifecycle gates.

21.5 Product Publication​

Intent:
Publish product or product bundle.

Boundary:
PDEP required.

Governance:
Kernel checks publication policy, DPP, evidence, rights, risk, and listing eligibility.

21.6 Product Graph Exploration​

Intent:
Explore relationships, dependencies, substitutes, or flows.

Boundary:
Stay in PVEP unless user intends to create, modify, or publish a product.

22. User Experience Patterns for Boundary Handling​

22.1 Stay Here Pattern​

Used when the user can continue in PVEP.

Example:

You can use these products directly. No product creation is required.

22.2 Prepare Handoff Pattern​

Used when creation intent is emerging but more context is needed.

Example:

This looks like a candidate product composition. Prepare a PDEP handoff?

22.3 Transition Required Pattern​

Used when the action clearly belongs to PDEP.

Example:

Creating a new governed product requires PDEP. We will carry your selected products and governance context forward.

22.4 Blocked Transition Pattern​

Used when PDEP transition cannot proceed yet.

Example:

PDEP transition is blocked because one selected input product lacks derivative-use entitlement.

22.5 Conditional Transition Pattern​

Used when PDEP transition can proceed with warnings.

Example:

You can proceed to PDEP, but the selected set carries inherited no-external-sharing restrictions.

23. Design Guidance​

23.1 Make the Boundary Explicit​

Users should know whether they are selecting products, consuming products, or creating a new product.

23.2 Do Not Hide Product Creation​

Creating a new governed product should be an explicit transition, not a side effect of adding products to a set.

23.3 Preserve Lightweight Exploration​

PVEP should remain easy for discovery, evaluation, and selection.

23.4 Govern Creation Early​

When creation intent appears, show governance implications before PDEP handoff.

23.5 Carry Context Forward​

Do not force users to re-enter product set, intent, entitlement, trust, risk, and DPP context after transition to PDEP.

23.6 Support Agents Carefully​

Agents may prepare or recommend PDEP transition, but authority must be checked before product-building actions.

23.7 Show Why PDEP Is Needed​

Users should understand that PDEP is required because governed product creation, composition, validation, versioning, or publication is occurring.

23.8 Avoid UI-Only Governance​

PVEP should not enforce lifecycle governance by UI only. PDEP and Governance Kernel must validate creation.

23.9 Keep Product-Kind Agnostic​

The boundary applies to data, AI, software, physical, creative, governance, evidence, infrastructure, and future product kinds.

24. Anti-Patterns​

24.1 Product Set Becomes Product Silently​

A selected set should not automatically become a governed product without PDEP.

24.2 Marketplace Publishing Without PDEP​

Publishing a new product or bundle directly from marketplace bypasses product lifecycle governance.

24.3 PVEP as Hidden PDEP​

If PVEP creates descriptors, DPPs, output ports, versions, or lifecycle states, it has crossed into PDEP.

24.4 Agent Overreach​

Agents should not compose, publish, or modify products beyond delegated authority.

24.5 No Governance Handoff​

Transitioning to PDEP without carrying constraints, risk, trust, evidence, entitlement, and DPP context creates rework and risk.

24.6 Treating Consumption as Creation​

Using an existing output port is not product creation.

24.7 Treating Selection as Entitlement​

Adding a product to a set does not grant rights to use or compose it.

24.8 Treating Entitlement as Derivative Rights​

Access to use a product does not automatically permit derivative product creation.

24.9 Ignoring Product Versioning​

PDEP must manage versions when selected products become inputs to a new product.

25. Summary​

The PVEP–PDEP Boundary ensures that UPOS separates product experience from product creation.

PVEP supports discovery, evaluation, acquisition, consumption, graph navigation, portfolio views, trust inspection, product selection, and pre-assembly reasoning.

PDEP supports authoring, composition, validation, evidence binding, DPP generation, versioning, publication, and lifecycle control.

The central distinction is:

PVEP assembles candidate product sets.
PDEP composes governed products.

The boundary is supported by the Governance Kernel, which evaluates policy, entitlement, trust, risk, evidence, DPP, relationship, and lifecycle state, and by Product Fabric, which enforces runtime consumption.

In short:

PVEP is where participants explore, experience, and select products. PDEP is where selected intent becomes a governed product.