Governance Kernel Relationship to PDEP
1. Purpose
The Governance Kernel Relationship to PDEP defines how the UPOS Governance Kernel supports, constrains, validates, and assures the Product Development and Execution Plane (PDEP).
PDEP is the UPOS plane responsible for product authoring, composition, validation, lifecycle control, versioning, publication, deployment preparation, and product evolution.
The Governance Kernel is the computational governance core that evaluates policy, entitlement, trust, risk, evidence, DPP, relationship, and lifecycle state.
This document explains how these two constructs work together.
The key principle is:
PDEP builds and evolves governed products. The Governance Kernel validates the governance conditions under which those products may be created, composed, published, changed, or retired.
PDEP should not invent governance truth.
The Governance Kernel should not become the product-building workflow.
They are complementary, but their responsibilities must remain distinct.
2. Core Relationship
The relationship between the Governance Kernel and PDEP can be summarized as:
PDEP
→ captures product intent
→ authors product descriptors
→ composes products
→ creates or updates product artifacts
→ prepares output ports
→ manages lifecycle transitions
→ requests governance evaluation
Governance Kernel
→ evaluates policy, entitlement, trust, risk, evidence, DPP, and lifecycle conditions
→ emits decisions, constraints, obligations, explanations, and signals
→ records audit evidence
→ allows, blocks, conditions, or escalates product lifecycle actions
In short:
PDEP = product creation and lifecycle execution
Governance Kernel = governance decision and assurance authority
3. Separation of Concerns
The separation of concerns is essential.
| Concern | PDEP | Governance Kernel |
|---|---|---|
| Product authoring | Captures and structures product intent and descriptors | Validates whether authoring is authorized and policy-compliant |
| Product composition | Selects and assembles product inputs, dependencies, and relationships | Evaluates whether composition is permitted and what restrictions propagate |
| Product lifecycle | Manages draft, validation, publication, versioning, deprecation, retirement | Evaluates lifecycle gates and emits allow/block/review decisions |
| Product descriptors | Produces or updates product specifications and metadata | Checks governance completeness, obligations, and policy requirements |
| Output ports | Defines product output ports and access modes | Evaluates output-port policy, entitlement, risk, and evidence requirements |
| DPP creation | Generates or updates product DPP artifacts | Evaluates DPP completeness, evidence support, and purpose fit |
| Evidence collection | Collects and attaches required evidence | Determines evidence sufficiency and gaps |
| Trust readiness | Prepares product for trustworthy use | Computes trust posture |
| Risk posture | Provides risk-relevant product information | Computes or validates risk state and required controls |
| Publication | Submits product for publication or listing | Evaluates publication and marketplace listing gates |
| Audit trail | Provides lifecycle and artifact history | Records governance decision traces and assurance state |
The principle is:
PDEP is governance-aware, but the Governance Kernel is governance-authoritative.
4. Why This Relationship Matters
In a ProductVerse, products are not isolated items. They may be consumed, composed, governed, listed, trusted, reused, and used as inputs to further products.
If PDEP creates products without Governance Kernel validation, the ProductVerse may accumulate:
- products without accountable owners,
- products without valid DPPs,
- products without sufficient evidence,
- products that violate policies,
- product compositions with inherited restrictions ignored,
- output ports that expose excessive risk,
- products published without trust posture,
- products listed without permitted-use clarity,
- AI Products without risk validation,
- Data Products without privacy or lineage assurance,
- Physical Products without safety evidence,
- Creative Products without rights evidence,
- Agent Products without authority constraints.
The Governance Kernel prevents uncontrolled product proliferation by ensuring that product creation and lifecycle actions are governed by authoritative decisions.
PDEP enables product creation. The Governance Kernel ensures product creation remains accountable.
5. Governance State Used by PDEP
PDEP uses Governance Kernel state throughout product development and lifecycle management.
5.1 Policy State
PDEP may need to know:
- what policies apply to this product kind,
- what policies apply to selected input products,
- what policies apply to the intended purpose,
- what policies apply to output ports,
- what policies apply to publication or listing,
- what restrictions must be inherited,
- what obligations must be satisfied.
Example:
Product may be published only if owner, DPP, evidence, lifecycle state, and support model requirements are satisfied.
5.2 Entitlement State
PDEP may need to know:
- whether the creator is authorized to author this product,
- whether selected input products may be used,
- whether product-to-product consumption is allowed,
- whether derivative use is permitted,
- whether marketplace publication is allowed,
- whether product composition rights exist.
Example:
Creator may use Product A for internal analysis but is not entitled to use it as an input to a commercial derivative product.
5.3 Trust State
PDEP may need to know:
- whether input products are trusted,
- whether source product evidence is sufficient,
- whether product dependencies are trustworthy,
- whether the resulting product can inherit or establish trust,
- whether trust gaps block publication.
Example:
One selected input product has expired evidence. Product composition is blocked until evidence is refreshed or an exception is approved.
5.4 Risk State
PDEP may need to know:
- whether the product is low, moderate, high, or critical risk,
- whether the composition amplifies risk,
- whether output ports increase risk,
- whether human review is required,
- whether lifecycle gates become stricter,
- whether override or escalation is required.
Example:
The product is R3 for production use because it affects operational decisions. Human review and monitoring evidence are required before publication.
5.5 Evidence State
PDEP may need to know:
- what evidence is required,
- what evidence is missing,
- what evidence is expired,
- what evidence is sufficient,
- what evidence must be refreshed,
- what evidence must be retained.
Example:
Publication blocked because quality evidence and owner approval evidence are missing.
5.6 DPP State
PDEP may need to know:
- whether a DPP is required,
- whether DPP is complete,
- whether DPP claims are evidence-backed,
- whether DPP matches the product version,
- whether DPP is suitable for marketplace listing,
- whether DPP should be regenerated after product change.
Example:
DPP applies to product version 1.0, but the current product version is 1.1. DPP revalidation is required.
5.7 Relationship Governance State
PDEP may need to know:
- whether product relationships are allowed,
- whether dependencies are valid,
- whether restrictions propagate,
- whether product composition is permitted,
- whether lineage and provenance are sufficient,
- whether downstream relationships are impacted.
Example:
The new product inherits a no-external-sharing restriction from one input product.
6. PDEP Lifecycle and Governance Kernel Touchpoints
The Governance Kernel should participate across the product lifecycle.
6.1 Product Intent Stage
PDEP captures product intent.
Governance Kernel may evaluate:
- whether the creator is authorized,
- whether the intended purpose is permitted,
- whether the proposed product kind requires special governance,
- whether the intended audience introduces risk,
- whether the product may require DPP, evidence, or policy controls.
Example:
Intent to create an AI Product for automated decisioning triggers high-risk governance path.
6.2 Product Design Stage
PDEP structures product descriptors, inputs, output ports, and lifecycle plan.
Governance Kernel may evaluate:
- applicable product-kind policies,
- output-port restrictions,
- evidence requirements,
- risk implications,
- trust requirements,
- required stewardship assignments.
Example:
File download output port requires stronger policy review than dashboard output.
6.3 Product Composition Stage
PDEP selects or composes products.
Governance Kernel may evaluate:
- input product entitlements,
- product-to-product consumption rights,
- composition policy,
- inherited restrictions,
- trust propagation,
- risk amplification,
- license compatibility,
- evidence requirements.
Example:
Composition allowed only if no-external-sharing restriction is preserved in the derived product.
6.4 Product Validation Stage
PDEP validates artifacts before publication or deployment.
Governance Kernel may evaluate:
- required evidence,
- DPP completeness,
- policy compliance,
- risk controls,
- trust posture,
- output port readiness,
- lifecycle gate readiness.
Example:
Validation cannot pass because safety inspection evidence is missing.
6.5 Product Publication Stage
PDEP submits product for publication or marketplace listing.
Governance Kernel may evaluate:
- publication policy,
- listing eligibility,
- DPP readiness,
- support model,
- owner and steward assignment,
- permitted-use declaration,
- trust posture,
- risk posture,
- evidence sufficiency.
Example:
Product may be listed in the internal marketplace but not public marketplace because external-use rights evidence is missing.
6.6 Product Versioning Stage
PDEP creates a new product version.
Governance Kernel may evaluate:
- whether the change is material,
- whether DPP must be regenerated,
- whether risk tier changes,
- whether evidence remains valid,
- whether output-port policies changed,
- whether consumers must be notified.
Example:
New version changes the inference model. Model evaluation evidence and DPP update are required.
6.7 Product Deprecation Stage
PDEP marks a product as deprecated.
Governance Kernel may evaluate:
- downstream impact,
- entitlement state,
- consumer notification requirements,
- substitute availability,
- risk of continued use,
- retention and evidence obligations.
Example:
Product can be deprecated, but consumers must be notified and substitute products should be recommended.
6.8 Product Retirement Stage
PDEP retires a product.
Governance Kernel may evaluate:
- downstream dependencies,
- active entitlements,
- regulatory retention obligations,
- audit preservation,
- DPP archival,
- evidence archival,
- runtime shutdown constraints.
Example:
Retirement blocked because two critical downstream products still depend on this product.
7. Governance Gate Patterns in PDEP
PDEP should use Governance Kernel gates at key lifecycle transitions.
7.1 Authoring Gate
Checks whether the creator may author the product.
PDEP authoring request
→ Governance Kernel checks creator authority, product kind, purpose, policy
→ Authoring allowed / denied / review required
7.2 Composition Gate
Checks whether selected products may be composed.
PDEP composition request
→ Governance Kernel checks input products, entitlements, licenses, inherited restrictions, trust, risk
→ Composition allowed / conditional / denied / exception required
7.3 Evidence Gate
Checks whether required evidence is present and sufficient.
PDEP validation request
→ Governance Kernel checks evidence requirements
→ Evidence sufficient / missing / expired / review required
7.4 DPP Gate
Checks whether DPP is present, complete, valid, and version-aligned.
PDEP publication request
→ Governance Kernel validates DPP
→ DPP valid / incomplete / expired / version mismatch
7.5 Publication Gate
Checks whether product may be published or listed.
PDEP publication request
→ Governance Kernel evaluates policy, entitlement, risk, trust, evidence, DPP, lifecycle
→ Publish / block / review / exception required
7.6 Output Port Gate
Checks whether a product output port may be exposed.
PDEP output-port activation request
→ Governance Kernel evaluates output-port policy, risk, entitlement, trust, enforcement requirements
→ Activate / restrict / block / review
7.7 Retirement Gate
Checks whether product may be retired.
PDEP retirement request
→ Governance Kernel evaluates downstream dependencies, retention, entitlement, lifecycle, audit obligations
→ Retire / delay / block / notify
8. Product Composition and Inherited Constraints
Product composition is one of the most important interaction points between PDEP and the Governance Kernel.
When PDEP composes products, the Governance Kernel must evaluate:
- whether source products can be used,
- whether the creator has entitlement,
- whether licenses permit derivative use,
- whether policies permit the intended composition,
- whether source product restrictions propagate,
- whether evidence must be carried forward,
- whether new trust evidence must be generated,
- whether the resulting product inherits risk,
- whether new risk is introduced.
Example:
Input Product A:
permitted for internal analytics only.
Input Product B:
permits derivative use but prohibits redistribution.
New Product C:
composed from A and B.
Kernel outcome:
Product C may be created for internal use only.
External marketplace listing is blocked unless new rights and policy clearance are obtained.
The principle is:
PDEP composes products. The Governance Kernel determines whether composition is permitted and what constraints follow the composition.
9. Product-to-Product Entitlement in PDEP
PDEP must support product-to-product entitlement.
A product may consume another product as:
- input,
- dependency,
- training source,
- runtime service,
- evidence source,
- policy source,
- content source,
- component,
- output port provider.
The Governance Kernel evaluates whether that product-to-product use is allowed.
Example:
AI Product A wants to use Data Product B for training.
Kernel evaluates:
- Data Product B permitted uses,
- training-use entitlement,
- data sensitivity,
- residency policy,
- lineage evidence,
- AI risk policy,
- DPP status,
- creator authority.
Outcome:
- training allowed only in approved environment with evidence retention.
Product-to-product entitlement is essential because ProductVerse creation is recursive.
10. DPP Creation and Validation in PDEP
PDEP is responsible for creating or updating DPP artifacts as part of the product lifecycle.
The Governance Kernel is responsible for evaluating DPP readiness.
10.1 PDEP Responsibilities
PDEP may:
- initialize DPP,
- populate product identity,
- bind DPP to product version,
- collect evidence,
- link claims to evidence,
- generate permitted-use statements,
- attach lifecycle state,
- publish DPP with product,
- update DPP after product version change.
10.2 Governance Kernel Responsibilities
The Governance Kernel may:
- check DPP presence,
- check DPP completeness,
- check evidence sufficiency,
- validate claim-evidence binding,
- validate product-version alignment,
- evaluate DPP purpose fit,
- compute DPP-derived trust state,
- block publication if DPP requirements fail.
The principle is:
PDEP produces the DPP artifact. The Governance Kernel evaluates what the DPP means for governance.
11. Evidence Requirements in PDEP
PDEP uses the Governance Kernel to identify and satisfy evidence requirements.
Evidence requirements may depend on:
- product kind,
- purpose,
- output port,
- risk tier,
- publication target,
- marketplace visibility,
- jurisdiction,
- composition inputs,
- lifecycle action,
- policy obligations.
Example evidence requirements:
- owner assignment,
- steward assignment,
- quality report,
- model evaluation,
- safety certification,
- rights evidence,
- license evidence,
- lineage record,
- provenance record,
- support model,
- operational readiness,
- retirement impact analysis.
PDEP should not treat evidence as an attachment dump.
Evidence should be claim-bound, version-aware, authority-backed, and sufficient for the requested lifecycle action.
12. Risk-Aware Product Development
PDEP should use Governance Kernel risk state during product development.
Risk may influence:
- development pathway,
- required controls,
- required evidence,
- required approvals,
- lifecycle gates,
- output-port activation,
- marketplace eligibility,
- runtime enforcement,
- human review requirements.
Example:
Low-risk product:
basic evidence and standard publication gate.
High-risk AI Product:
model evaluation, bias review, human oversight, DPP completion, risk approval, monitoring plan, restricted output ports.
Safety-critical Physical Product:
inspection evidence, certification, maintenance plan, emergency controls, operational constraints.
The principle is:
PDEP should adapt product development workflow to risk state rather than treating all products identically.
13. Trust-Aware Product Development
PDEP should use trust state to guide product readiness.
Trust-aware product development asks:
- what claims does the product make,
- what evidence supports those claims,
- what trust posture is required for the intended purpose,
- what trust gaps exist,
- what trust state will be shown in PVEP,
- what trust state will be used by marketplace,
- what trust state agents may rely upon.
Example:
Product claims regulatory-readiness.
Kernel checks lineage, quality, approval, DPP, and policy evidence.
Trust state is insufficient until all required evidence is attached.
PDEP should make trust a first-class lifecycle concern, not a marketing afterthought.
14. Policy-Aware Product Development
PDEP uses Governance Kernel policy evaluation to ensure product lifecycle and composition decisions satisfy applicable policy.
Policies may govern:
- product kind,
- purpose,
- data sensitivity,
- AI safety,
- physical safety,
- licensing,
- rights,
- publication,
- marketplace listing,
- output ports,
- lifecycle transitions,
- product-to-product composition.
Example:
Policy requires all externally listed products to expose a DPP summary and rights evidence.
PDEP blocks listing until these are present.
Policy-aware development prevents late-stage governance surprises.
15. Agent-Aware Product Development
PDEP must support products created by or for agents.
Governance Kernel checks may include:
- whether agent is authorized to create or modify products,
- whether agent authority is delegated,
- whether agent can select input products,
- whether human confirmation is required,
- whether agent-created artifacts need review,
- whether agent-created product claims require evidence,
- whether agent actions are audited.
Example:
AI agent proposes a product composition.
Kernel determines the agent may recommend composition but cannot publish without human approval.
The principle is:
Agent participation in PDEP must be governed by explicit authority, scope, evidence, and auditability.
16. PDEP Use of Governance Signals
PDEP should consume Governance Kernel signals to keep product lifecycle workflows current.
Signals may include:
- evidence expired,
- DPP expired,
- risk tier changed,
- policy updated,
- entitlement revoked,
- input product deprecated,
- dependency retired,
- trust downgraded,
- exception expired,
- product relationship blocked,
- publication gate failed.
Example:
Input product DPP expires after product composition began.
Kernel emits DPP_EXPIRED.
PDEP reopens validation and blocks publication until DPP is refreshed or input product replaced.
Signals prevent PDEP from relying on stale governance state.
17. PDEP Emission of Governance-Relevant Signals
PDEP should also emit governance-relevant signals to the Governance Kernel.
Examples:
- product intent declared,
- product draft created,
- input product selected,
- product composition requested,
- evidence attached,
- DPP draft generated,
- output port defined,
- validation requested,
- publication requested,
- product version changed,
- deprecation requested,
- retirement requested.
These signals allow the Governance Kernel to evaluate, record, and respond to product lifecycle events.
18. PDEP and Auditability
Every material governance-relevant PDEP action should be auditable.
Audit records may include:
- who or what initiated the lifecycle action,
- selected input products,
- product version,
- output ports,
- policies evaluated,
- entitlements checked,
- risk state,
- trust state,
- evidence references,
- DPP version,
- constraints derived,
- lifecycle gate decision,
- approval or exception records.
The principle is:
A governed product lifecycle without auditability is not governed.
19. Boundary with PVEP
PVEP and PDEP interact, but they have different responsibilities.
PVEP may allow consumers to:
- discover products,
- evaluate products,
- select product sets,
- inspect trust,
- request access,
- understand constraints,
- detect creation intent,
- initiate transition to PDEP.
PDEP handles:
- product authoring,
- governed composition,
- validation,
- DPP generation,
- evidence collection,
- versioning,
- publication,
- lifecycle control.
The Governance Kernel supports both, but differently.
PVEP uses governance state to guide experience.
PDEP uses governance state to validate product creation and lifecycle.
20. Boundary with Product Fabric
PDEP defines and prepares products and output ports. Product Fabric enforces runtime governance after products become consumable.
The Governance Kernel connects both:
PDEP:
product definition, output ports, lifecycle, publication
Governance Kernel:
policy, entitlement, risk, trust, evidence, lifecycle decisions
Product Fabric:
runtime enforcement, access, masking, routing, logging
Example:
PDEP defines API output port.
Kernel evaluates API output-port policy.
Product Fabric enforces API access, entitlement, rate limits, and logging.
21. Boundary with Marketplace
PDEP may publish products to marketplaces.
The Governance Kernel evaluates whether marketplace listing is allowed.
Marketplace displays the listing and acquisition experience.
PDEP:
prepares product for listing
Governance Kernel:
checks listing eligibility, DPP, rights, trust, risk, policy
Marketplace / PVEP:
displays product listing, acquisition, trust, pricing, licensing, access flows
Marketplace publication should not bypass Governance Kernel publication and listing gates.
22. PDEP Governance Kernel Interfaces
PDEP may use Governance Kernel interfaces such as:
- authoring authority check,
- product intent governance check,
- policy applicability check,
- product composition check,
- product-to-product entitlement check,
- evidence sufficiency check,
- DPP validation check,
- risk evaluation,
- trust evaluation,
- output-port approval check,
- lifecycle gate check,
- publication gate check,
- marketplace listing check,
- retirement impact check,
- exception request interface,
- signal subscription interface,
- audit interface.
PDEP should prefer structured kernel responses over embedding governance logic locally.
23. Example PDEP Governance Flow
1. Product creator declares intent.
2. PDEP creates draft product record.
3. Governance Kernel evaluates authoring authority and product-kind policy.
4. Creator selects input products.
5. Governance Kernel evaluates product-to-product entitlement, composition policy, inherited restrictions, trust, and risk.
6. PDEP generates product descriptor and draft DPP.
7. Governance Kernel checks evidence requirements and DPP completeness.
8. PDEP attaches evidence and defines output ports.
9. Governance Kernel evaluates output-port policy and risk.
10. PDEP requests publication.
11. Governance Kernel evaluates publication gate.
12. If allowed, PDEP publishes product and emits lifecycle signal.
13. PVEP and marketplace render product state.
14. Product Fabric enforces runtime governance.
24. Governance Decision Rendering in PDEP
PDEP should translate Governance Kernel decisions into product-builder actions.
| Kernel decision | PDEP behavior |
|---|---|
| Allow | Continue workflow. |
| Deny | Block lifecycle step or composition. |
| Conditional allow | Continue only if constraints are captured and enforceable. |
| Approval required | Route to approval workflow. |
| Exception required | Route to exception workflow. |
| Evidence missing | Request required evidence. |
| DPP incomplete | Require DPP completion. |
| Risk escalation required | Route to risk authority. |
| Insufficient context | Ask creator for missing information. |
| Pending | Pause workflow until evaluation completes. |
PDEP should not hide governance blockers. It should explain and guide remediation.
25. Design Guidance
25.1 Treat Governance as Build-Time and Runtime
Governance begins during product creation, not after publication.
25.2 Use Governance Gates Early
Do not wait until final publication to discover policy, entitlement, trust, or risk blockers.
25.3 Preserve Product Creation Boundary
The Governance Kernel validates product governance. PDEP owns product authoring and lifecycle execution.
25.4 Make Composition Governance First-Class
Product-to-product composition must evaluate entitlement, policy, trust, risk, evidence, and inherited constraints.
25.5 Bind Evidence to Claims
PDEP should collect evidence against product claims, not as unstructured attachments.
25.6 Generate DPP as Part of Lifecycle
DPP should not be a post-publication artifact. It should evolve with the product.
25.7 Make Risk Pathways Adaptive
High-risk products should follow stricter development and validation pathways.
25.8 Support Agent Participation Safely
Agents may assist PDEP workflows, but their authority, scope, and actions must be governed.
25.9 Consume Governance Signals
PDEP must respond to changes in policy, evidence, DPP, risk, trust, entitlement, and dependency state.
26. Anti-Patterns
26.1 Governance Only at Publication
Waiting until publication to apply governance creates rework and risk.
26.2 PDEP Embedding Local Governance Logic
If PDEP hardcodes governance logic, it may diverge from the Governance Kernel.
26.3 Product Composition Without Entitlement
Using input products without checking product-to-product entitlement weakens recursive governance.
26.4 DPP as Afterthought
DPP should not be manually attached after product completion.
26.5 Evidence as Attachment Dump
Evidence should be claim-bound, version-aware, and evaluated for sufficiency.
26.6 Ignoring Inherited Restrictions
Derived products must preserve restrictions from source products where applicable.
26.7 Agent-Created Products Without Authority
Agent participation in product creation must be authorized, scoped, and auditable.
26.8 Lifecycle Without Signals
PDEP must react when evidence expires, DPP changes, risk changes, or dependencies become invalid.
26.9 Publication Without Runtime Enforcement Plan
Product publication should ensure Product Fabric can enforce required constraints.
27. Summary
PDEP and the Governance Kernel form a core UPOS partnership.
PDEP creates, composes, validates, versions, publishes, and evolves products.
The Governance Kernel computes and assures the governance conditions that make those actions safe, compliant, trusted, entitled, risk-aware, evidence-backed, and auditable.
PDEP depends on the Governance Kernel for:
- authoring authority checks,
- policy applicability,
- product-to-product entitlement,
- composition governance,
- inherited restrictions,
- evidence requirements,
- DPP validation,
- trust evaluation,
- risk evaluation,
- output-port approval,
- lifecycle gate decisions,
- publication readiness,
- retirement impact analysis,
- governance signals,
- audit records.
The central boundary is:
PDEP builds governed products.
Governance Kernel validates governance conditions.
Product Fabric enforces runtime governance.
PVEP renders governance state to consumers and agents.
In short:
PDEP is where products are made real. The Governance Kernel is what makes that product creation governable, trustworthy, and accountable.