Product Select & Assembly Zone

1. Purpose

The Product Select & Assembly Zone is the PVEP zone where consumers, teams, organizations, agents, applications, or products-as-consumers select products into a working product set for comparison, evaluation, planning, acquisition, consumption, or possible downstream creation.

This zone exists because ProductVerse users often do not interact with a single product in isolation.

They may ask:

• Which products should I use together?
• Which products are suitable for my intent?
• Which products do I already have access to?
• Which products are trusted enough for this purpose?
• Which products are substitutes or complements?
• Which selected products create policy, entitlement, trust, risk, evidence, licensing, or DPP issues?
• Which product set can I consume directly?
• Which product set requires governed composition in PDEP?
• When does product selection become product creation?

The key principle is:

PVEP supports product selection and pre-assembly reasoning. PDEP owns governed product building, composition, validation, versioning, and publication.

This zone deliberately uses the word Select & Assembly, not Product Composition Zone, because the architectural boundary matters.

PVEP helps consumers select, compare, organize, and prepare product sets.
PDEP turns selected products into governed new products.

---

2. Definition

The Product Select & Assembly Zone is the PVEP experience zone that enables consumers and agents to gather, compare, organize, assess, and prepare sets of products for a purpose, without making those selected products into a new governed product inside PVEP.

It may support:

• product selection,
• product set creation,
• product comparison,
• substitute comparison,
• complement selection,
• bundle evaluation,
• dependency inspection,
• entitlement checking,
• trust checking,
• risk checking,
• DPP checking,
• policy checking,
• licensing review,
• preliminary suitability assessment,
• transition to consumption,
• transition to marketplace acquisition,
• transition to PDEP when creation intent emerges.

The zone is consumer-facing and intent-oriented.

It helps answer:

Given this purpose, which products should I select,
what can I do with them,
what constraints apply,
and do I need to transition to PDEP to create something new?

---

3. Why This Zone Exists

In a ProductVerse, value often comes from multiple products used together.

A consumer may select:

• a data product,
• an AI product,
• a dashboard product,
• an API product,
• a policy product,
• an evidence product,
• a creative asset product,
• a physical component product,
• an infrastructure product,
• a training product,
• a trust or DPP product.

The selected set may be used for different intents.

Examples:

Use these products together for a project.
Compare these products before acquisition.
Collect these products into a portfolio.
Prepare a product set for a workflow.
Assess whether these products can be composed.
Select candidate products for a future PDEP build.

Without this zone, consumers are forced into either:

• isolated product detail pages, or
• premature product creation workflows.

The Product Select & Assembly Zone fills the gap between discovery and creation.

---

4. Scope

The Product Select & Assembly Zone covers:

• selecting products into a working set,
• saving product sets,
• comparing selected products,
• checking product suitability against intent,
• reviewing policy, entitlement, trust, risk, evidence, and DPP status,
• reviewing output-port availability,
• identifying substitutes and complements,
• identifying dependencies and inherited restrictions,
• preparing acquisition or access requests,
• preparing consumption journeys,
• preparing transition to PDEP.

It does not own:

• governed product authoring,
• formal product composition,
• creation of new product descriptors,
• DPDS/AIPDS/PDS generation,
• DPROD/AIPROD/PROD publication,
• DPP issuance for new products,
• lifecycle validation,
• versioning,
• marketplace publication of newly composed products.

Those capabilities belong to PDEP.

---

5. Core Boundary

The boundary can be stated as:

PVEP Product Select & Assembly Zone:
  select, compare, assess, organize, and prepare product sets.

PDEP:
  build, compose, validate, version, publish, and govern new products.

Or more directly:

PVEP assembles a candidate set.
PDEP creates a governed product.

This distinction prevents PVEP from becoming an uncontrolled product-building plane.

---

6. Select vs Assemble vs Compose

The terminology matters.

Term	Meaning in UPOS
Select	Choose one or more products for a purpose.
Assemble	Organize selected products into a working set, view, shortlist, scenario, or candidate collection.
Compose	Create a new governed product from selected products or components. Composition belongs to PDEP.

The Product Select & Assembly Zone may allow users to assemble a candidate set, but it should not perform governed product composition.

Example:

PVEP:
User selects Data Product A, AI Product B, and Dashboard Product C into a product set.

PDEP:
If the user wants to create a new Risk Insight Product from A, B, and C, the flow transitions to PDEP.

---

7. Product Set

A Product Set is a temporary, saved, shared, or governed collection of selected products organized for a purpose.

A Product Set may be used for:

• comparison,
• acquisition planning,
• consumption planning,
• project planning,
• portfolio curation,
• governance review,
• PDEP handoff,
• agent recommendation,
• bundle evaluation,
• impact analysis.

A Product Set is not automatically a new product.

It may become input to PDEP if the user intends to create a new product from the selected products.

7.1 Product Set Examples

Mars Habitat Safety Product Set
  - Oxygen Generation Product
  - Water Recycling Product
  - Habitat Monitoring Product
  - Crew Safety Dashboard Product
  - Habitat Safety Policy Product

Comic Publishing Product Set
  - Character Asset Product
  - Background Asset Product
  - Comic Page Product
  - Rights Evidence Product
  - Marketplace Listing Template

Regulatory Reporting Product Set
  - Transaction Data Product
  - Customer Reference Data Product
  - Reporting Rules Product
  - Validation Evidence Product
  - Report Output Product

---

8. Product Set Types

The zone may support several product set types.

8.1 Working Set

A temporary set used during exploration.

Example:

Products I am currently comparing.

8.2 Saved Set

A set saved for later use.

Example:

Candidate products for Q3 risk reporting.

8.3 Shared Set

A set shared with a team, steward, agent, or collaborator.

Example:

Products selected by a team for project evaluation.

8.4 Acquisition Set

A set prepared for purchase, subscription, access request, or onboarding.

Example:

Products to acquire for a new team.

8.5 Consumption Set

A set intended to be used together without creating a new product.

Example:

Dashboard + API + documentation + training product used by an operations team.

8.6 Candidate Composition Set

A set that may become input to PDEP.

Example:

Selected products to be composed into a new governed product.

8.7 Governance Review Set

A set requiring review because of policy, entitlement, trust, risk, evidence, DPP, or licensing constraints.

Example:

Product set includes products with conflicting redistribution rights.

---

9. User Intents Supported

The Product Select & Assembly Zone supports multiple intents.

9.1 Compare

The user wants to compare selected products.

Questions:

• Which product is better for my purpose?
• Which one is more trusted?
• Which one has fewer restrictions?
• Which one has stronger evidence?
• Which one is cheaper or easier to acquire?

9.2 Shortlist

The user wants to build a shortlist.

Questions:

• Which products are candidates?
• Which should be kept?
• Which should be removed?
• Which needs approval?

9.3 Prepare for Consumption

The user wants to use selected products directly.

Questions:

• Can I use them now?
• Which output ports are available?
• Which products require access?
• Which restrictions apply?

9.4 Prepare for Acquisition

The user wants to acquire or subscribe to selected products.

Questions:

• What licenses are required?
• What pricing or subscription model applies?
• What approvals are needed?
• Which products are already entitled?

9.5 Prepare for Composition

The user wants to create something new from selected products.

Questions:

• Can these products be composed?
• Do restrictions propagate?
• Do I need PDEP?
• What evidence will be required?
• What risk will be introduced?

9.6 Prepare for Governance Review

The user wants to understand whether selected products are safe, permitted, trusted, and governed.

Questions:

• What policy issues exist?
• What trust gaps exist?
• What evidence is missing?
• What risk tier applies?
• Which entitlements are invalid?

---

10. Core Experience Capabilities

The Product Select & Assembly Zone may provide several capabilities.

10.1 Add to Product Set

Allows users or agents to add products from marketplace, discovery, graph navigation, portfolio, or consumption experiences.

10.2 Remove from Product Set

Allows users to remove products from the set.

10.3 Compare Products

Supports side-by-side comparison across product attributes.

Comparison dimensions may include:

• product kind,
• provider,
• output ports,
• entitlement state,
• trust posture,
• risk posture,
• DPP state,
• evidence state,
• license terms,
• pricing,
• lifecycle state,
• dependencies,
• constraints.

10.4 Check Suitability

Evaluates whether the selected product set fits the declared intent.

Suitability may consider:

• purpose fit,
• entitlement,
• policy,
• trust,
• risk,
• evidence,
• DPP,
• licensing,
• output-port availability,
• product relationship compatibility.

10.5 Show Constraints

Displays inherited and direct constraints.

Examples:

• no external sharing,
• internal use only,
• human review required,
• no derivative use,
• attribution required,
• approved environment only,
• output-port restriction,
• audit logging required.

10.6 Identify Gaps

Shows gaps that prevent consumption, acquisition, or PDEP transition.

Examples:

• missing entitlement,
• missing license,
• missing DPP,
• expired evidence,
• unresolved risk,
• incompatible policy,
• unavailable output port,
• conflicting rights.

10.7 Recommend Substitutes

Suggests substitute products when selected products are unavailable, untrusted, too risky, too expensive, deprecated, or not entitled.

10.8 Recommend Complements

Suggests complementary products that improve the set.

Examples:

• evidence product,
• policy product,
• monitoring product,
• training product,
• connector product,
• visualization product,
• DPP product,
• runtime product.

10.9 Prepare Handoff

Prepares a structured handoff to:

• Consumption Experience Zone,
• Marketplace Experience Zone,
• Portfolio & Entitlement Experience Zone,
• Governance & Trust Experience Zone,
• PDEP.

---

11. Suitability Assessment

A Product Set may be assessed for suitability against an intent.

A suitability assessment may answer:

Is this product set suitable for the stated purpose,
for this consumer,
in this context,
under current governance conditions?

11.1 Suitability Dimensions

Dimension	Question
Purpose fit	Do the selected products match the stated intent?
Entitlement	Can the consumer use the selected products?
Output ports	Are required output ports available and entitled?
Policy	Are selected uses permitted?
Trust	Are products trusted for the intended purpose?
Risk	Does the set create unacceptable risk?
Evidence	Is required evidence present and current?
DPP	Are DPPs valid and suitable?
License	Do rights allow intended use or derivative use?
Lifecycle	Are selected products active and supported?
Dependency	Are dependencies available and trusted?
Compatibility	Do products work together technically and semantically?
PDEP readiness	If creation is intended, is the set ready for PDEP handoff?

11.2 Suitability Outcomes

Possible outcomes include:

• suitable,
• suitable with constraints,
• partially suitable,
• unsuitable,
• review required,
• approval required,
• exception required,
• PDEP required,
• insufficient context.

---

12. Governance-Aware Product Set Checks

The Product Select & Assembly Zone depends heavily on the Governance Kernel.

The Governance Kernel may evaluate:

• entitlement state,
• policy state,
• trust state,
• risk state,
• evidence state,
• DPP state,
• relationship governance,
• inherited restrictions,
• license compatibility,
• product-to-product consumption rights,
• output-port restrictions,
• PDEP readiness.

Example:

Selected product set includes:
- Product A: internal use only
- Product B: external redistribution allowed
- Product C: evidence expired

Kernel outcome:
- set is suitable for internal exploration,
- not suitable for external publication,
- Product C requires evidence refresh,
- PDEP transition requires inherited restrictions to be preserved.

---

13. Inherited Restrictions

When products are selected together, restrictions may need to be surfaced.

Examples:

Product A prohibits external sharing.
Product B requires attribution.
Product C requires audit logging.
Product D permits internal use only.

The set inherits or accumulates these restrictions.

A Product Set should clearly show:

• direct product restrictions,
• inherited restrictions,
• conflicting restrictions,
• strongest applicable restriction,
• restrictions relevant to intended purpose,
• restrictions that would apply if transitioned to PDEP.

Example:

This product set may be used internally.
External sharing is blocked because Product A prohibits redistribution.
Derivative publication requires PDEP review because Product B has attribution obligations.

---

14. Product Set Risk

A selected set may have risk that individual products do not show in isolation.

Examples:

• two low-risk products create a high-risk combined use,
• an AI product combined with sensitive data raises risk,
• a file export port combined with external sharing raises leakage risk,
• a physical product combined with autonomous agent control raises safety risk,
• a creative asset combined with commercial distribution raises rights risk.

Risk may be:

• inherited,
• amplified,
• mitigated,
• transformed,
• accepted,
• escalated.

The Governance Kernel should compute risk state for product sets where possible.

PVEP should render the risk state understandably.

---

15. Product Set Trust

Trust can change when products are selected together.

Examples:

• all products are trusted individually, but the combination lacks evidence,
• an upstream product has incomplete lineage,
• a source product DPP is expired,
• a product relationship is not validated,
• a selected evidence product strengthens the overall set,
• a monitoring product mitigates operational risk.

The Product Select & Assembly Zone should show:

• product-level trust,
• set-level trust,
• trust gaps,
• evidence gaps,
• DPP gaps,
• relationship trust,
• trust impact of substitutes or complements.

---

16. Product Set Entitlement

A consumer may be entitled to some selected products but not others.

Example:

Product	Entitlement
Product A	Entitled
Product B	Approval required
Product C	Not entitled
Product D	Entitled for dashboard only

The zone should help the consumer understand:

• which products can be used now,
• which require access,
• which require subscription,
• which require license acceptance,
• which require approval,
• which cannot be used for the intended purpose,
• which output ports are available.

This avoids users creating unrealistic product sets.

---

17. Product Set Licensing and Rights

For many product kinds, licensing and rights are central.

The zone should identify:

• no redistribution,
• attribution required,
• non-commercial only,
• derivative use prohibited,
• internal use only,
• sublicensing prohibited,
• external publication restricted,
• rights evidence missing,
• license acceptance required.

This is especially important for:

• creative products,
• software products,
• data products,
• AI products,
• evidence products,
• physical product designs,
• marketplace products.

Example:

This selected set cannot be used for public marketplace publication because one creative asset has non-commercial-only rights.

---

18. Transition to Consumption

If selected products can be used directly, the zone may route the user to consumption.

Example:

Selected products are already entitled and trusted.
Open dashboard.
Launch API workflow.
Start reader.
Invoke model endpoint.

Transition to consumption is appropriate when:

• the user intends to use existing products,
• no new governed product is being created,
• entitlements are valid,
• output ports are available,
• constraints can be enforced,
• risk and trust state permit use.

---

19. Transition to Marketplace

If selected products require acquisition, subscription, trial, license acceptance, or pricing review, the zone may route the user to marketplace experiences.

Example:

Three selected products require subscription.
One product requires license acceptance.
One product has a trial available.

The Marketplace Experience Zone handles:

• pricing,
• listing,
• license review,
• subscription,
• acquisition,
• onboarding,
• access request initiation.

The Portfolio & Entitlement Experience Zone then reflects resulting entitlement state.

---

20. Transition to Governance & Trust Experience

If selected products have complex governance state, the zone may route to the Governance & Trust Experience Zone.

Examples:

• DPP incomplete,
• trust under review,
• risk high,
• evidence missing,
• policy conflict,
• licensing unclear,
• exception required.

This helps users inspect governance detail without overloading the selection experience.

---

21. Transition to PDEP

The Product Select & Assembly Zone transitions to PDEP when intent becomes product creation.

Signals that PDEP is required include:

• user wants to create a new product,
• selected products need to be composed into a new governed artifact,
• new output ports are needed,
• new product descriptor is required,
• new DPP is required,
• selected products create derivative use,
• validation is required,
• versioning is required,
• publication is intended,
• marketplace listing of the new product is intended,
• lifecycle ownership and stewardship are required.

Example:

User selects Data Product A, AI Product B, and Dashboard Template C.

If the user wants to create a new Risk Monitoring Product from them,
PVEP transitions to PDEP with the selected product set and governance context.

Boundary principle:

Product selection can happen in PVEP.
Product creation happens in PDEP.

---

22. PDEP Handoff Package

When PVEP transitions to PDEP, it should pass a structured handoff package.

A PDEP handoff package may include:

• selected products,
• intended purpose,
• consumer or creator identity,
• product set name,
• product set rationale,
• required output or desired product outcome,
• known entitlements,
• policy constraints,
• inherited restrictions,
• trust state,
• risk state,
• DPP state,
• evidence gaps,
• licensing constraints,
• product relationships,
• candidate substitutes,
• user notes,
• agent recommendations,
• unresolved questions.

Example:

pdepHandoff:
  productSetId: set-123
  intendedOutcome: create-new-risk-monitoring-product
  selectedProducts:
    - product-a
    - product-b
    - product-c
  purpose: internal-risk-monitoring
  knownConstraints:
    - no-external-sharing
    - audit-logging-required
  governanceState:
    entitlement: partially-entitled
    trust: conditionally-trusted
    risk: R3
    dpp: one-input-dpp-expired
  recommendedNextSteps:
    - request-access-to-product-b
    - refresh-dpp-for-product-c
    - initiate-pdep-composition-gate

---

23. Agent-Mediated Product Selection

Agents may help users create and refine product sets.

An agent may:

• suggest products,
• remove unsuitable products,
• explain constraints,
• compare alternatives,
• check entitlements,
• identify trust gaps,
• identify risk amplification,
• propose substitutes,
• propose complements,
• recommend PDEP transition.

However, agents must operate under explicit authority.

Examples:

AI agent may recommend products but may not subscribe to them.

Machine agent may prepare a product set but may not initiate PDEP publication.

Institutional agent may approve low-risk product selection only within delegated scope.

Agent-mediated product selection should use Governance Kernel checks for:

• agent authority,
• permitted actions,
• product suitability,
• entitlement,
• trust,
• risk,
• policy,
• DPP,
• evidence.

---

24. Relationship to Product Graph Navigation Zone

The Product Graph Navigation Zone helps users explore product relationships.

The Product Select & Assembly Zone lets users act on that exploration by selecting products into a set.

Example flow:

Product Graph Navigation:
Consumer sees that Product A depends on Product B and complements Product C.

Product Select & Assembly:
Consumer adds Product A, B, and C to a product set and checks suitability.

The graph reveals relationships. The selection zone organizes product choices.

---

25. Relationship to Portfolio & Entitlement Experience Zone

The Portfolio & Entitlement Experience Zone shows what the consumer already has and may use.

The Product Select & Assembly Zone uses that information when assessing product sets.

Example:

Selected Product A is already entitled.
Selected Product B requires approval.
Selected Product C is not included in current subscription.

Portfolio provides rights context. Selection uses rights context to guide action.

---

26. Relationship to Governance Kernel

The Governance Kernel provides authoritative governance state for product sets.

The Product Select & Assembly Zone consumes:

• decision outcomes,
• policy state,
• entitlement state,
• trust state,
• risk state,
• evidence state,
• DPP state,
• relationship governance state,
• inherited restrictions,
• exception requirements,
• approval requirements,
• explanations,
• signals.

The zone should not compute policy, entitlement, trust, or risk locally beyond display logic.

---

27. Relationship to Product Fabric

Product Fabric enforces runtime governance when selected products are consumed.

Example:

PVEP:
Shows that Product A API can be invoked.

Product Fabric:
Enforces API access, entitlement, rate limit, audit logging, masking, and policy restrictions.

If selected products are only being evaluated or prepared for PDEP, Product Fabric may not yet be involved.

---

28. Relationship to Marketplace Experience Zone

Products selected into a set may require marketplace actions.

Marketplace handles:

• product listing,
• pricing,
• licensing,
• subscription,
• acquisition,
• onboarding,
• trial,
• access request.

The Product Select & Assembly Zone may provide a “prepare acquisition” or “request all required access” experience.

Example:

Selected product set includes five products.
Two are already entitled.
Two require access request.
One requires subscription.
PVEP routes the consumer to marketplace and entitlement flows.

---

29. Relationship to Consumption Experience Zone

When the product set is ready for direct use, the user may move to consumption.

Examples:

• open a dashboard,
• invoke a model endpoint,
• use an API,
• start a reader,
• launch a workflow,
• connect selected products to an existing tool.

Consumption uses existing product output ports. It does not create a new governed product unless the workflow transitions into PDEP.

---

30. Experience Patterns

30.1 Product Cart Pattern

Similar to a shopping cart, but governance-aware.

The cart holds selected products and shows entitlement, trust, risk, DPP, policy, and license state.

30.2 Product Workspace Pattern

A working area where users organize products around a project, mission, or intent.

30.3 Compare Matrix Pattern

A matrix for comparing selected products across capabilities and governance dimensions.

30.4 Suitability Scorecard Pattern

A summarized assessment of the selected set against intent.

Use with caution: structured assessment should remain authoritative, not just a numeric score.

30.5 Constraint Summary Pattern

A compact summary of inherited restrictions and obligations.

30.6 Handoff Pattern

A structured transition to PDEP, Marketplace, Consumption, or Governance & Trust views.

30.7 Agent Recommendation Pattern

An agent suggests additions, removals, substitutes, or next actions based on intent and governance state.

---

31. Design Guidance

31.1 Preserve the PDEP Boundary

Do not let this zone become a hidden product-building plane.

31.2 Make Product Sets Explicit

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

31.3 Show Governance Early

Policy, entitlement, trust, risk, DPP, evidence, and license issues should be surfaced before users invest effort.

31.4 Explain Inherited Restrictions

When a selected product carries restrictions, show how those restrictions affect the set.

31.5 Distinguish Direct Use from Derivative Use

A consumer may be allowed to use a product but not derive a new product from it.

31.6 Support Product-Kind Agnostic Selection

Do not assume selected products are only data products or AI products.

31.7 Support Agents Safely

Agents may assist selection, but their authority and actions must be governed.

31.8 Make Handoff Structured

When transitioning to PDEP, pass selected products and governance context as structured artifacts.

31.9 Avoid False Readiness

A product set should not be shown as ready if entitlement, trust, risk, evidence, DPP, or licensing issues remain unresolved.

---

32. Anti-Patterns

32.1 PVEP Composition

Creating new governed products inside PVEP bypasses PDEP.

32.2 Product Set Equals Product

A selected product set is not automatically a product.

32.3 Ignoring Inherited Restrictions

Selected products may carry policy, license, or trust constraints.

32.4 Treating Access as Derivative Rights

Being entitled to use a product does not mean being allowed to build a new product from it.

32.5 Hiding Governance Until PDEP

Users should see major blockers before transition.

32.6 Agent Overreach

Agents should not acquire, invoke, compose, or publish beyond explicit authority.

32.7 Selection Without Purpose

Suitability cannot be assessed without a declared or inferred purpose.

32.8 Numeric Suitability Without Explanation

Scores without reasons create false confidence.

32.9 Runtime Assumption

Selecting products does not mean runtime access is provisioned or enforceable.

---

33. Summary

The Product Select & Assembly Zone is the PVEP zone where consumers and agents select, compare, organize, and assess product sets across the ProductVerse.

It supports:

• product sets,
• comparison,
• shortlisting,
• suitability assessment,
• entitlement checks,
• trust checks,
• risk checks,
• DPP checks,
• evidence gap detection,
• license and rights review,
• inherited restriction visibility,
• product set readiness,
• transition to consumption,
• transition to marketplace,
• transition to governance review,
• transition to PDEP.

Its most important boundary is:

PVEP supports product selection and pre-assembly reasoning.
PDEP owns governed product composition, validation, versioning, and publication.

In short:

The Product Select & Assembly Zone helps consumers assemble candidate product sets responsibly, while preserving PDEP as the governed product-building plane.